Opportunistically Exploiting Internet of Things for Wireless Sensor Network Routing in Smart Cities

Abstract

With the emergence of Internet of Things (IoT), the research on Smart Cities with wireless sensor networks (WSNs) got leveraged due to similarities between objectives in both Smart City and IoT. Along with them, research in controlling WSN faces new challenges and opportunities for data aggregation and routing has received consistent focus from researchers. Yet new techniques are being proposed to address modern challenges in WSN and efficient resource utilization. Moreover, solutions are required to integrate existing deployed WSN with ever increasing numbers of IoT devices in Smart Cities, that benefit both. In this work, we present an approach for routing in a WSN, in which IoT is used opportunistically to reduce the communication overhead of the sensors. In our approach, WSN deployed in a Smart City interacts with the IoT devices to route the data to the sink. We build a prototype Integration Platform for the WSN that allows interaction with IoT devices and utilizes them opportunistically that results in an energy efficient routing of data. Simulation results show that the direction is quite promising and our approach offers to utilize IoT to gain unique advantages.

1. Introduction

In this era, there are billions of sensor-enabled intelligent devices on the Internet that collectively form a huge entity known as Internet of Things (IoTs) [1]. According to Cisco [2], by 2020 fifty billion devices will be connected to the Internet, thus depicting the potential and complexity of using such an inter-connectivity. An underlying simple concept of “Anything connected at anytime” [3] in an IoT opens new ways of interdisciplinary research. From bare hardware sensing platforms to upper most application layer, IoTs has created new horizons for researchers. IoT devices are spread city wide, perform their functions and share information for the betterment of quality of citizens’ lives. It is important to notice similarities in the aims and objectives of both Smart City and IoTs [1].

IoTs encapsulate Wireless Sensor Networks (WSN) as an important component. WSN emerged as a dominant technology, much before the emergence of IoT, addressing a wide spectrum of application domains [4,5]. With successful deployment of IoT infrastructure and Smart City test-beds in real cities, i.e., Padova [6] and Santander [7], more and more government municipalities and corporations are interested to leverage the strengths of Smart City. The aim is to make better use of public resources, increasing the quality of life of the citizens, while minimizing the operational costs.

For monitoring and surveillance of a Smart City application, sensors are deployed in a large area, city wide. Typical examples include traffic management systems [8], structural health management systems [9], traffic signal monitoring [8], electronic toll collection systems [10], highway data collection [8], and automatic number plate recognition systems [11].

Routing is essentially a service required in a WSN wherein sensors sense data using individual inexpensive sensor nodes and routes the data towards the sink for drawing meaningful conclusions. Since the advent of WSN in 1960’s [12], there is a plethora of techniques and protocols proposed for routing and data aggregation in WSN [13,14,15]. Though sensors are becoming smarter, cheaper, and smaller in size, they are always energy constrained [4]. Therefore, there is an unparalleled need for developing innovative energy efficient routing approaches. In the applications mentioned above, often data has to traverse through a long series of intermediate sensors before it reaches the sink. Thus, much of the WSN energy is consumed in multi-hop routing.

Practically, Smart City and IoTs in our cities are currently in infancy. There are very few fully functional IoTs serving the objective of a Smart City. The majority of research works are related to IoT frameworks, ideas, prototypes, and use cases, which is quite common for an emerging technology. The ultimate aim of a deployed IoT in the context of Smart City is that every IoT device can be connected and can share data with other devices for the public betterment. Recent developments in Low Power Long Range (LPLR) network protocols [16] e.g., LoRa, SigFox, offer low power alternative for sensors. Yet, they also have shortcomings and cannot be used in each and every application where sensors are required [16,17]. Moreover, with trends towards Heterogeneous ad hoc networks [18], a wide community still uses and will keep using traditional mutltihop WSN as a part of their solution [19], and may use LPLR as well. Thus, our approach can be easily integrated in such scenarios.

In practice, there is a transitional phase where existing deployed WSNs are working, functioning, serving, and administered separately, while other smart devices are around them, achieving basic goals of a Smart City and being administered by public sector or a private organization. In our work, we aim to exploit the IoT devices opportunistically in routing data of separately administered WSN.

Sensors essentially use their energy resources in (i) sensing, (ii) local computation, (iii) communication of its own data, and (iv) communication of other sensors data. This paper presents an opportunistic use of IoT for better resource utilization of a WSN by building Integration Platform (IT Platform). In our work, we reduce resource utilization by allowing sensors to route few data packets of other sensors to the Sink. Thus, instead of utilizing traditional WSN routing protocols, we opportunistically use IoT devices in the surrounding environment for routing. This enables the Sensor in deployed area to conserve energy [20].

To better understand the problem scenario, let us consider a series of sensors deployed at road side of a Smart City, and there are intelligent cars (as IoT devices) using the road. Figure 1 shows an example scenario in Dubai City where monitoring sensors are deployed at the highway bridge. Our main idea is that instead of sensors routing data to the sink located at the end of the road, IT Platform can be used to let a passing smart car collect the data (on sensor’s behalf) and deliver it to the sink. In case a smart car starts moving away from the sink, it will inform a sensor of WSN, which in turn may use another IoT device or may use WSN routing. Usually, IoT devices that are near WSN, are more likely to get re-charged by their own sources. In contrast, the WSN, once deployed, is hardly re-charged. Thus, it is natural to use communication resources of these IoT devices and save energy of sensors in WSN. Since the IoT device owners enable resource sharing and allow IT Platform to be installed, they should receive some reward. Although detailed discussion of this reward is out of scope of this paper, we do state a couple of examples. The reward could be in the form of points, redeemed at a car parking or public charging space. It could also be in the form of giving access to a specific public information portal.

We want to emphasize that using our IT Platform, we are making explicit use of IoT devices, considering them as a part of the environment [20] in which WSN is deployed. This is contrary to the traditional research conducted for routing in WSN for IoT, where in most cases an existing protocol is adapted and reused for routing in WSN for IoT applications. Thus, IoT devices are not an integral part of our WSN, rather they are the Smart devices passing by the area where a separately administered WSN is deployed. This makes our approach a novel data collection and routing scheme.

The main contribution of this paper is (1) a novel idea with a prototype that uses IoT devices in a pragmatic scenario for conserving energy in a WSN, (2) IT Platform connects an existing WSN with IoT devices that are in the surrounding environment, and (3) evaluation of the prototype from multiple aspects. We describe our problem scenario and illustrate by extensive simulations that demonstrate and evaluate the IT Platform. It is observed that by using IT Platform that opportunistically uses IoT devices, not only WSN energy is conserved but packet reception rate is also improved.

The rest of the paper is organized as follows. Section 2 summarizes other research efforts related to our work. In Section 3, problem scenario and requirements are defined. IT Platform is detailed in Section 4. The Castalia simulator, experiment details, and evaluation are discussed in Section 5. Finally, Section 6 concludes the paper.

2. Related Work

Our work is related to routing and data aggregation in the context of IoTs and Smart City. Right from the beginning of WSN in 1970’s, routing in WSN has always been one of the main concern. There are a large number of techniques proposed for energy efficient routing and data aggregation. These include routing with heterogeneous sensor nodes, cross network protocols and platforms, and routing with mobile sinks. A few recent surveys by Pantazis et al. [21], Sheng Yu et al. [22], and Sara et al. [13], can be referred for details. An interesting research related to our work, is to use few high power long range devices in a network of short ranged sensor nodes. For instance, Yarvis et al. [23], demonstrates that the network life time and delivery ratio can be increased by using few long range sensors.

With the advent of IoT and Smart City, the routing protocols are revisited. Most of the routing and data aggregation schemes in IoT can be categorized in to two kinds. One is related to the IoT applications only, where the research discusses IoT application requirements and suggests adjustments or compatibility of a protocol in the new application domain. For instance, Machado et al. [24] present an improvement of AODV (Ad hoc On-demand Distance Vector) routing protocol [25] for the IoT applications that considers QoS (Quality of Service), reliability, and energy efficiency. Park et al. [26] also enhances AODV protocol using a probabilistic approach for increasing the network lifetime and reducing consumed energy. There are works that focus on specific WSN types, such as wireless mulimedia sensor networks [27].

In contrast, the second kind of research, which is more related to our work, uses multiple types of machines with heterogeneous capabilities to communicate and aggregate data. This requires substantial support by middle-ware frameworks and platforms to cope with heterogeneity of devices. For instance, Sancheze et al. [7] illustrate the design of a large scale IoT test bed and discuss the use of hierarchical architecture for routing data. Similarly, Zanella et al. [6], present technologies, protocols, and architecture for Smart Cities and suggest guidelines adapted in Padova Smart City project.

A rather different approach is used by Al-fagin et al. [28], wherein a priced public sensing framework is proposed for public data delivery gathered from cloud and heterogeneous resources. The work is data centric, focused on supply and demand chain of public data from mobile phones. Orsino et al. [29] introduce data collection in cellular devices using device to device communications in an IoT and Smart City setting. This results in more efficient resource utilization and minimizes energy consumption. They use one device that aggregates data from several surrounding devices and then sends the data to cellular station, instead of each device sending data individually. Very recently, an overview of using traditional WSN protocols for achieving device to device communication in IoT has been presented by Bello et al. [30].

Our work is different from existing works since it considers a static WSN, deployed in a Smart City. Mobile IoT devices owned by public or private owners are external to this deployed WSN. This is a typical scenario for technological evolution in a city, where every device may get connected yet some internal systems may remain individually working. Thus, as explained later, we exploit the presence of these IoT devices. They are used by our platform for the benefit of both WSN and IoT devices. In our IT Platform, we can use any routing protocol that is suitable to the domain of WSN applications. We use AODV routing protocol [25], which is a well accepted and a well studied protocol for WSN [21].

Emerging technologies of low power long range sensors [16] mostly use ISM band and keep power consumption low at the cost of increased delay and low data rate. These technologies, typically LoRa and SigFox, use star topology to connect to the base station while we are interested in improving a generic WSN that uses multihop routing.

To the best of our knowledge, the work close to our research of using environment opportunistically is by Cardone et al. [31] and Jayaraman et al. [32]. In the former, the authors construct MANETs (Mobile Ad hoc NETworks) of a machinery in a mine to route urgent data. While in the latter, the authors use context-aware mobile phones to act as data collectors from sensors. Our work is different from both as sensors work in multiple activity modes and search for IoT devices in vicinity while their basic idea is to use context based architecture or MANETS by smart devices. Moreover, our sensors are in sleep mode when not communicating to save energy. Khalil et al. [33] integrate an existing WSN of a Smart building to an IoT environment using gateways and main server to deliver the data to the mobile user. However, their work is not related to exploiting IoT devices, rather they connect WSN with Internet and hence the mobile user.

3. Problem Details

In this section, we describe the scenario and the details of the problem we address.

3.1. Problem Scenario

Typically, each sensor node consumes energy in three major ways of, sensing, local computation, and communication. The communication is related not only for its own data, but also for multi hop routing of other sensor’s data to the sink. In the context of Smart City, we want to exploit the presence of IoT devices near our WSN. Consider a typical case in a city where sensors are deployed city wide. Sensor nodes are equipped with short range communications. The data is gathered at the sink, located in the middle of the city. In a normal scenario, the data is aggregated at the sink by using multi hop routing in WSN. IoT devices, are moving on the road where sensors are deployed along its sides. Figure 2 shows example of a typical scenario of city center of Sharjah, UAE.

3.2. Requirements

Considering the above scenario, our IT Platform should be able to satisfy the following requirements:

• Interaction with the IoT devices: The IT Platform should enable WSN to interact with IoT devices when they are available.
• Independent routing: The platform must allow WSN to continue delivering data to the sink using their normal routing protocol, if there is no IoT devices in the vicinity. This is important since WSN should not be fully dependent on IoT devices, as IoT devices are not a part of their network. Rather they are exploited opportunistically.
• Energy efficiency: By exploiting IoT devices, energy consumption in WSN is conserved.
• Network lifetime: The energy of WSN should be consumed in such a way that a few sensor nodes shouldn’t be drained quicker than rest of the network, rather all sensor nodes should be used in a balanced way. This means that along with energy conservation the time duration between first dieing node and the most dieing nodes (making network non-functional) shouldn’t be long.
• Data delivery: Typically when IoT devices are exploited, the amount of received packets should either be the same or should be increased as compared to routed only using WSN. Thus, packet loss could be minimized.

Following, assumptions are made that simplify the problem scenario and provide better understanding:

• IoT devices are Vehicles/cars/passengers;
• WSN is surrounded by IoT devices, but can function without them; and
• WSN nodes send their data to a single sink.

4. The Integration Platform

Before discussing IT Platform, we first clarify our envisioned IoT. Although there are many alternative definitions of IoTs, we particularly want to state the one by Versman et al. [3] as “Internet of Things could allow people and things to be connected Anytime, Anyplace, with Anything and Anyone, ideally using Any path/network and Any service”. We adopt this definition since we believe that it encompasses a broader vision of IoT.

In our IT Platform, we used a two layered approach for routing data, WSN layer and IoT layer. As shown in Figure 3, the IoT layer is independent of WSN, and is not a part of WSN. IoT devices are moving in the vicinity of the WSN nodes, while their communication capabilities for data transfer in WSN is being exploited. To route the data packets to the sink. WSN layer can use any routing protocol, according to the requirements of its application. We use AODV (Adhoc On-demand Distance Vector) routing protocol [25] which is a well known routing protocol for WSNs.

Figure 4 shows the role of the IT Platform in internal architecture of both a sensor node and an IoT device. IT Platform is responsible for routing the data packets either using WSN routing or an IoT device. When an IoT device is in the vicinity, it is discovered and data is sent to it. When IoT device moves away from sink, IT Platform fetches data back to WSN layer by selecting a suitable sensor. If there are enough IoT devices around, the sensors remain in the sleep state and avoid multihop routing. The work-flow is briefed in the following subsections.

4.1. IoT Discovery and Negotiation in IT Platform

When a sensor has data, it first tries to send it via IoT layer. A hello message is broadcasted to find any IoT device in vicinity. If an IoT receives such message and its direction is towards Sink, it replies to the sensor. The reply message contains IoT’s distance from the Sink, and the speed. When multiple IoTs reply, on discovering them the sensor will select one based on RSSI value, distance and speed of IoT using Algorithm 1. In lines 7 and 8, while calculating the score of an IoT device, the RSSI value is given increased importance as compared to distance and speed. $bestValue$ is the score of so far best IoT device. The sensor sends a confirmation message and on receiving the acknowledgement of that message, the data is sent to the selected IoT device. The IoT acknowledges the data reception.

	Algorithm 1 getBestIoT
	iots[] = //array of IoT objects iot.rssi = //received signal strength indicator value iot.distance = //Maximum distance between two points minus distance of IoT from Sink iot.speed = //Maximum allowed speed in which communication is possible minus speed of IoT
1:	proceduregetBestIot(iots[])
2:	for each $p\in iots$ do //remove iot replies with less than threshold RSSI.
3:	if $p.rssi<threshholdRssi$ then
4:	iots.remove (p)
5:	end if
6:	end for
7:	best = iots[1]
8:	for each $p\in iots$ do
9:	bestValue = 2 * best.rssi + best.speed + best.distance
10:	pValue = 2 * p.rssi + p.speed + p.distance
11:	if $pValue>bestValue$ then
12:	best = p
13:	end if
14:	end for
	return best
15:	end procedure

When a sensor doesn’t get any reply from IoT, it uses its WSN routing protocol and sends the data to the next hope accordingly. If the next hope is in IoT mode (modes discussed in next sub-section), the sensor knows the next hope (neighbor’s) time slot and sends data accordingly. When next hop is in Normal mode, its Rx will be ON all the time and can receive data from the sender sensor at any time.

4.2. Sensor Activity Modes in WSN Layer

There are two activity modes for Sensors; (1) Normal mode, (2) IoT mode. The sensors select between the communication modes using a gossiping protocol [34]. The main idea is that by default a sensor remains in Normal mode which uses maximum energy. When there are ample IoT’s in the environment to take the communication load from sensors, sensors switch to IoT mode that uses lesser energy. The algorithm for switching between the two modes is discussed in Section 4.5. When appropriate, IoT mode is turned On for some time.

The time is divided into frames of 500 ms, and each frame is subdivided into slots as shown in Figure 5. In each frame, there is an initial listening slot (ILS), in which all sensors keep their receivers on regardless of which mode they are in. When in IoT mode, there are 10 equal slots for communication so that (1) Radio remains On only in relevant time; (2) minimal signal interference from neighbors while message passing; and (3) the neighbors do not face contention. The slots are assigned among sensors using a simple method, node id modulo number of slots in a frame.

$$ReceiveSlotNo=SNId/noOfSlotsInFrame$$

(1)

In this way each node is aware of its own communication slot and its neighbors communication slots.

In normal mode, the radio Rx is On for the whole time. When there is any data to send then it goes to Tx mode and after transfer switch back to Rx mode. It is ensured that Rx is on at ILS in the beginning of each frame. In IoT mode, the Rx turns On only at ILS and if any data is expected, it keeps Rx ON in the sensors own communication slot. The Tx is turned ON according to the Rx slot of the next hop.

For IoT discovery and negotiation the sensor’s own communication slot is used. For the rest of the frame sensors the radio is in the sleep mode for saving energy.

4.3. Sensor Selection By IoT

When an IoT changes its direction and goes away from the Sink, it has to drop data back to the WSN layer. To avoid sending data to sensors while they are sleeping, IoT device is given the time synchronization information about when sensors are awake and ready to listen to data. When data is sent to IoT (Section 4.1), frame start times are also shared. This makes IoT aware of the ILS at WSN layer. Therefore, it broadcasts a dropHello message to WSN layer sensors considering this ILS’s time. Sensors reply IoT with in a dropReply message with their location, Rx slot and energy level. Based on RSSI value, energy level and distance from Sink, IoT selects a best sensor using Algorithm 2. In lines 2 to 4, the replies of Sensor nodes with lower than threshold value of RSSI are discarded, which ensures quality in communication. Lines 6 to 10 finds the Sensor node with best score. The IoT then informs the sensor to send the data in the sensor’s Rx slot.

4.4. Traversing of Data Packets

In a nutshell, data packets are sent towards the sink using two layered approach. Figure 6 depicts basic sequence of communication between Sensor nodes and an IoT devices. After discovery and negotiation with IoT, Sensor sends the packet to the IoT device. IoT acknowledges the receipt of packet to the sensor so that sensor does not have to forward the packet using default routing protocol. When the IoT device changes the direction, it sends the information (data packet) back to the WSN layer, where the receiving sensor repeats the process.

	Algorithm 2 getBestSN
	SN[] = //array of SN objects SN.rssi = //received signal strength indicator value SN.distance = //Maximum distance between two points minus IoT’s distance from Sink SN.energyLevel = //Remaining Energy of Sensor
1:	proceduregetBestSN(SN[])
2:	for each $p\in SN$ do //remove SN replies with less than threshold RSSI.
3:	if $SN\left[i\right].rssi<threshholdRssi$ then
4:	SN.remove (p)
5:	end if
6:	end for
7:	best = SN[1]
8:	for each $p\in SN$ do
9:	bestValue = 2 * best.rssi + best.energyLevel + best.distance
10	pValue = 2 * p.rssi + p.energyLevel + p.distance
11:	if $pValue>bestValue$ then
12:	best = p
13:	end if
14:	end for
	return best
15:	end procedure

In case the IT Platform component in the Sensor is unable to find any IoT device that is moving towards the Sink, the sensor continues the multi hop routing using its default routing protocol in the WSN layer. When the IoT device changes its direction, IT Platform enables IoT to send data packet back to WSN layer. Algorithm 3 shows the IsDirectionToSink algorithm in the platform for the IoT device. The algorithm is used to decide if it is moving towards or away from the sink based on euclidean distance as shown in lines 2 to 3.

Table 1. List of messages exchanged by elements of integration platform (IT) Platform.

Message	From	To	Description
send (helloIoT)	SN	IoT	Message to search IoT in vicinity
send (distance, speed)	IoT	SN	IoT reply message to SN
send (selectedOK)	SN	IoT	SN confirms IoT as selected candidate
send (OK)	IoT	SN	IoT reply OK to selection as approval to send data and waits for dataPacket.
send (dataPacket, synchTime)	SN	IoT	SN sends dataPacket along with synchTime of WSN
send (dataAck)	IoT	SN	Acknowledge message for data reception
send (dropHello)	IoT	SN	Hello message to find SN to drop dataPacket to WSN layer.
send (energy, RxSlot, location)	SN	IoT	Reply to dropHello message with SN’s energy level and location
send (selectedOK)	IoT	SN	IoT confirms SN as selected SN for sending data
send (OK)	SN	IoT	Reply OK to selection as approval to send dataPacket
send (dataPacket)	IoT	SN	IoT drops datapacket to selected SN
send (dataAck)	SN	IoT	Acknowledge message for data reception

, shows the list of messages used in communication during traversing of Data Packets.

	Algorithm 3 IsDirectionToSink
	previousX = //previous X position of IoT device previousY = //previous Y position of IoT device currentX = //current X position of IoT device currentY = //current X position of IoT device sinkX = // X position of Sink sinkY = // Y position of Sink getDistance(x1,y1, x2,y2) // returns euclidean distance between two points
1:	procedureisDirectionToSink(data)
2:	currentDistance = getDistance(currentX, currentY, sinkX, sinkY)
3:	previousDistance = getDistance(previousX, previousY, sinkX, sinkY)
4:	if $currentDistance>previousDistance$ then
5:	returnValue = True
6:	else
7:	returnValue = False
8:	end if
	return returnValue
9:	end procedure

4.5. Gossip Protocol

By default the sensor remains in the Normal mode. Based on two factors, (1) number of replies from IoT devices and (2) number of received messages (IoTExists messages) from neighbors, IoT mode is turned On for 1 min. IoT exists messages are sent using gossip algorithm inspired from SIR gossip protocols [34]. The Gossip protocol algorithm is shown Algorithm 4. The push method is used by a Sensor node when it is discovering IoT devices. In line 6, on receiving ample replies from IoT devices, it changes its state to IOT and pushes this information to other sensor nodes using pushIoTExistMessage(m) method at line 12.

	Algorithm 4 GossipAlgorithm
	sendIoTExistMessageTo (P,m) = //sends message m to neighbor P isIoTRepliesEnough() = //returns True if no. of IoT replies is $>=3$, else returns False state = //represents the current state of node
1:	proceduregossipAlgorithm() //Push method
2:	while true do
3:	wait $\Delta$
4:	if $isIoTRepliesEnough\left(\right)$ then
5:	m.age = −1
6:	pushIoTExistMessage(m)
7:	end if
8:
9:	end while
10:	end procedure
11:	procedureonIoTExistReceive(m) //Push Receiver method
12:	if $m.age<2$ then
13:	pushIoTExistMessage(m)
14:
15:	end if
16:	end procedure
17:	procedurepushIoTExistMessage(m)
18:	P = //random neighbor
19:	if $state==NORMAL$ then
20:	state = IOT
21:	end if
22:	IoTTimerSet(1min)
23:	m.age ++
24:	sendIoTExistMessageTo (P,m)
25:	end procedure

Once a sensor decides to turn On IoT mode, it is for 1 minute. It broadcasts IoTExist (age = 1) messages to other sensors. Each receiving sensor that receives using procedure at line 8, re-broadcasts message after incrementing age unless age of the received message is two. Thus such messages stop after two hops.

If a Sensor node does not receive such messages, and only one IoT reply, then it keeps itself in the Normal mode. The sensor can still communicate with IoTs. However its energy consumption can not be avoided.

4.6. Advantages of IT Platform

We used a layered approach which is not hierarchical. We claim that there are several advantages of this approach. For example:

• Using IT Platform and IoT devices, there is no notable overhead on a sensor due to communication between the two layers.
• When the network gets disconnected due to nodes with depleted energy or any other reason, then packets can still reach the the Sink via IoT devices.
• Overall WSN communication load is reduced by exploiting the IoT devices. This is because the inter communication between the sensor nodes for multi-hop routing to the Sink is reduced.
• By allowing sensors nodes to sleep more, the idle listening is reduced and less energy is consumed.
• The platform does not require any extra computations, thus no additional computational overhead on sensors.
• There is no additional sensing load on the sensors of WSN.

5. Simulation Details and Results

To evaluate the proposed approach, we used a well known network simulator Omnet++ (version 4.6). For simulating WSN particularly, we used Castalia framework [35] on top of Omnet++. Castalia is a specialized simulator that mimics the real world sensors. It is commonly used by developers for prototype testing of naive ideas and protocols [36].

5.1. Evaluation Metrics

WSN performance can be evaluated by a variety of metrics. Corresponding to our requirements discussed in Section 3.2, and considering those used by most of the researchers, we used the following metrics:

• Energy consumed: Average energy consumed by all sensors is depicted using this metric. The simulator measures energy consumption by considering the amount of time sensor radio has been in receive or transfer mode [37]. It is independent of data transfer or receive activity in a mode rather depends on duration the sensor is in specific mode.

  Table 2. Power consumption in CC2420 Radio.

  Parameter	Power
  Radio Off	0.04 mW
  Radio Sleep	1.4 mW
  Radio Receiver	62 mW
  Radio Transmitter (0 dBm)	57.42 mW
  Radio Transmitter (−5 dBm)	46.2 mW

  displays the energy consumption of CC2420 Radio we simulated, in different modes [38].
• Network lifetime: This metric also depicts energy consumed, but shows the lifetime of the whole network. Using a conservative approach, the network is considered non-functional whenever the first node dies.
• Nodes Alive: Shows the percentage of sensor nodes alive at specific simulation time.
• Packet reception rate: This metric shows the rate of number of packets received by the sink as compared to the number of packets sent by each of the sensors. Any duplicate packet is discarded by the sink. The packet loss is there because, in all kinds of wireless communication, as we are using realistic simulation models (Section 5.2), it is common that there is some packet loss.

5.2. Simulation Environment

In our simulator, we visualize our approach with realistic wireless channel conditions and radio models. Interference is handled using received signal strength. Due to this realistic channel modeling, there is some packet loss caused by interference or poor value of received signal strength. The wireless channel is defined as a map of path loss and not simply by connection between sensor nodes. Moreover, at radio level, probability of reception depends on SINR (Signal to Interference and Noise Ratio). Multiple TX power levels of Radio can be configured for individual sensor nodes.

5.3. Simulation Setup

A two dimensional coordinate plane is used with 10 to 100 m, with multiple network configurations of 20 to 90 nodes, spread uniformly. There is one sink in the middle of the network. Mobile IoT devices randomly move in the region in straight lines. The radio power of each Sensor nodes and IoT device is −5 dBm and 1 dBm, respectively. The simulation time of each run of the experiment is set to 915 s, and each experiment is repeated 20 times with random seeds. Considering the data rate guidance by Zanella et al. [6], Sensor nodes generates 20 bytes of data every 2 s. This data rate is specifically suitable for monitoring applications wherein data rate is consistent but not very high. As discussed by Zanella et al. [6], many application domains of WSN have similar data rates with most of the sensors generating data at a consistent frequency.

5.4. Simulation Results

In this section, we discuss the evaluation results of our simulations using the three metrics discussed earlier.

To restate, IoT devices are not a part of WSN, rather they are external to the WSN, and WSN opportunistically uses them to route its data. Figure 7 shows our main result that with our prototype implementation Sensor nodes energy consumption is reduced almost four folds. WSNOnly means no IoT’s are involved in routing data to Sink. With-IoTs means there are IoTs available that move around in WSN environment and the IT Platform uses them opportunistically.

A more detailed view of energy consumption is depicted in Figure 8. As shown in Figure 8a, with increase in network size when only WSN routing is used, energy consumption is increased in a linear fashion. While with the IT Platform, the energy consumption is increasing much slowly. With bigger networks the gain of using IT Platform is three times larger.

We designed an experiment to understand the effect of using IoT devices. In this simulation, we kept the network fixed and added IoT devices in the environment. The results are shown in Figure 8b, where less energy is consumed with more IoT devices. This is because using IT Platform, the sensors are able to sleep more and their routing load is lowered. When the number of IoT devices is 30, there is a three times gain in energy conservation. In Figure 8c, it is found that as a result of lower energy consumption, the network lifetime is increased. The WithioTs line shows that the gain is almost three to four times consistently as network size is increased.

In Figure 9, we showed results of analyzing the energy usage of sensors over the simulation time. The gradual depletion of energy in sensor nodes can be clearly seen in Figure 9a. Figure 9b shows the sudden death of the whole network in three seconds, while a slow death of network in 20 s is seen in case IoT devices are used. Thus, it gives more margin of action to take appropriate measures. Furthermore, due to the use of IoT devices, the sensors are still able to send data to the Sink when their multihop routing is no longer working due to dead sensor nodes.

From the perspective of Reception rate, as depicted by Figure 10, it is slightly increased and more stable by the use of IT Platform. We think that it is due to our careful selection of IoTdevices and sensor nodes using RSSI values. Moreover, due to the use of frames and slots for communication, there is less chance of interference while communicating. This packet loss is due to near realistic modeling of Radio and wireless channel of Castalia.

6. Conclusions

Our society is continually adapting and embracing the new paradigms of IoTs and Smart City as they come along with not only new requirements and challenges, but have new opportunities to embrace and exploit as well. Moreover, there is a need to integrate existing systems with new paradigms that utilize new platforms and frameworks.

In this paper, we have introduced and detailed an IT Platform that exploits IoT devices to bypass existing traditional multihop routing in WSN. This leads to an overall improvement in the performance of WSN with respect to energy consumption, network lifetime, and reception rate without creating any significant load on the sensors. The IT Platform enables WSN to save its communication cost and use its energy mainly in sensing, while giving reward opportunities to the IoT device owners. Currently, our cities have Smart devices, but are not fully integrated with each other and do not exploit the full potential of IoTs and Smart Cities. Thus, IT Platform can be used in such scenarios to improve the efficiency of a deployed WSN using the ever growing number of IoT devices in the city.

In the future, we plan to use our framework alongside other energy saving recent MAC protocols like TMAC. We will evaluate the effect of using IoT devices if TMAC protocol is used while overcoming the synchronization challenges for mobile IoT. Moreover, we can also extend our work by improving the algorithms for specific application domains and by evaluating our approach with multiple routing protocols. Additional efforts are required to fine tune the frame size and slot size according to the network density and network traffic, which can yield more energy savings.