Communication Protocols for Wireless Sensor Networks

The protocol stack used in wireless sensor networks is as shown below. It consists of physical layer, data link layer, network layer and application layer. 802.15.4 is an IEEE standard for physical and data link layers. The ZigBee protocol specifies standards above MAC and physical layer. However other than these standards, there are many other protocols and papers defined for MAC, Network, Application layers. We shall brief them in this section.



Protocol Stack of Wireless Sensor Network.

QoS in Sensor Networks

Quality of service required for different applications in sensor networks can be different. Some may require more precise and accurate information some may require less. Some applications might not tolerate any delay in notification after the detection of event and some may tolerate the delay. Some applications may monitor a large area with more number of active sensors and some applications might monitor only small area with less number of active sensors.

In sensor network the importance is on collective data delivery rather than packet form a single node, because in sensor network many sensor nodes produce similar data. So in sensor network terms such as collective latency, collective bandwidth usage, collective packet loss, collective information throughput come into picture.
Collective latency is the time between, the first packet related to an event is received by the sink and last packet related to that event is received at the sink, no matter which node produced the data. Collective bandwidth is the bandwidth required to report an event to the sink by sensor nodes al together. Collective packet loss is the number of packets lost al together during reporting of an event.
Any QoS mechanism introduced for WSN should be very simple, it should not be, computationally complex, time consuming, requiring large amount of memory. Because the sensor nodes are energy, memory constrained and sensor nodes do not use very high end processors also.

QoS support in sensor network should consider the fact that, event driven sensor networks are characterized by long periods of silence, when there are no events detected and small periods where large amount of traffic is produced, when any event is detected. And all the data produced are generally destined to sink, so traffic form nodes to sink will very large. So the QoS has to support this unbalanced traffic.

The probability of having redundant data is quite large in sensor networks, so the redundant data should be reduced as much as possible may be data aggregation. But one has to consider the delay involved and complexities involved in data aggregation and take a decision.

Sensor networks are very dynamic; there are high chances of, node failures, link failures, node mobility and node state transitions. So QoS support for sensor network should consider all the above factors.

The number of sensor nodes in sensor network is very large, probability of addition of nodes is also quite high, and so any sensor network application should be scalable.There are different types of data supported by the sensor networks QoS provided should support all different types of data.

Connection of Sensor Network with TCP/IP Network , Article -2

Continuing from the previous article ........

Unifying Micro Sensor Networks with the Internet via Overlay Networking is another paper, which proposes to use sensor network overlay over TCP/IP networks. By using such an overlay sensor network can use data centric approach, i.e. assigning unique address to each and every senor node is not essential. The sensor network overlay is formed by extending address less sensor network routing into internet as application overlay. The figure below shows the Sensor network overlay on TCP/IP networks.



Sensor Network Overlay on TCP/IP network.

The nodes in internet with Sensor network overlay are called as virtual sensor nodes, and these help in forming virtual sensor network.
TCP/IP overlay over Sensor Network paper proposes to use TCP/IP stack in the sensor nodes.
The key advantage is that it makes WSN highly compatible with internet as both them will have almost similar protocols running. However this TCP/IP stack can be loaded into sensor nodes which have higher memory and higher processing capabilities. The authors have developed something called as u-IP stack. This is similar to normal TCP/IP stack but with lesser features. The memory required to load the stack is also less compared to full TCP/IP stack. The figure below shows the TCP/IP overlay on WSN.




TCP/IP Overlay on WSN

In yet another paper called “VIP Bridge Method” authors propose to use node centric or location centric WSN. It is not applicable for data centric WSN. This paper uses a VIP Bridge it does mapping between IP address and location address or local address of the sensor node. The sensor nodes will not have IP address configured, but the IP address to each node exists in VIP Bridge. The sensors will be identified in the WSN by the local identifiers the VIP Bridge does the conversion require. The VIP Bridge does translation form sensor network to TCP/IP and vice versa. This paper explains the method to do the conversion. The advantage of this VIP Bridge method is that communication is done between TCP/IP network and WSN using IP address itself and the local sensor identifier is used for communication within the senor networks. The internet users need not know the protocols used in WSN they can use WSN as if it is a normal TCP/IP network. In other words WSN is transparent to internet users. The architecture of the VIP Bridge method is as shown below.




VIP Bridge Architecture.

Connection of Sensor Network with TCP/IP Network, Article - 1

There are many situations where sensor networks need to be connected via TCP/IP network. In other words it might be necessary to integrate many sensor networks into one virtual sensor network using TCP/IP network.
To allow users all over the world to use a WSN deployed in some remote place it is necessary to connect WSN to TCP/IP network. The users may issue a query to get information form WSN or it might be necessary to issue a command or some information to a particular node in WSN. The particular node might be one of several higher capability nodes in the WSN.

So connecting WSN with TCP/IP network is very important but due to sensor node’s limitations it is not possible to install full existing TCP/IP stack into a sensor node. So to connect WSN and TCP/IP network many new methods are proposed.

Different authors propose different methods to connect WSN and TCP/IP networks. In “Integrating Future Large-scale Wireless Sensor Networks with the Internet” application level gateway is used to connect WSN and TCP/IP network. This paper classifies WSN as homogeneous and heterogeneous WSN. It provides solutions to connect both homogeneous and heterogeneous networks to TCP/IP networks. Homogeneous sensor network is one in which all sensor nodes have similar capabilities and heterogeneous sensor network is one in which some node have more capabilities than other nodes and outside user wants to interact with the more capable nodes directly. To connect homogeneous sensor network to TCP/IP networks this paper proposes to use a gateway as shown in the figure below. Gateway Based Approach for connecting Sensor Networks with TCP/IP Networks

The gateway is viewed as front end for the distributed database. The user who wants information form WSN may issue query to the gateway. Query optimization is provided through data centric in network processing. The response is obtained from WSN by the gateway and reply is sent to the user. The gateway acts as the interface between WSN and internet.
The advantage of this approach is both WSN and internet can be completely independent; it’s the headache of gateway to do conversions required. And it is most easy approach as very less amount of changes are required to the existing architecture; a gateway need’s to be added in between internet and WSN. The drawback of this approach is that ever gateway has to be designed according to the WSN. And as we see this has single point of failure, i.e. if gateway goes down WSN becomes inaccessible. To overcome the above said problem we can use two or more gateways also.

To connect heterogeneous WSN to TCP/IP network the paper proposes to use an IP overlay over the WSN. In the heterogeneous network some nodes have more capability or some nodes may be acting as cluster heads. These nodes can be given IP address, and these nodes may be directly accessed by the user using internet. In this type of network an IP overlay network is created over the underlying WSN to connect user directly to higher capable nodes. To create an IP overlay network it is necessary to create a tunneling mechanism to allow the more capable nodes to communicate among themselves using address centric approach. To create tunnels between the more capable nodes the paper proposes to use either Directed Diffusion or ACQUIRE protocols. Directed Diffusion can be used for high IP traffic applications and ACQUIRE can be used for low IP traffic applications. The figure below makes the concept clearer.

Heterogeneous network, the red line shows the tunneling formation using Data Diffusion or ACQUIRE protocol.

The red color line in the figure above shows the tunnel between the higher capable nodes using normal sensor nodes. This tunnel makes IP overlay possible over existing WSN architecture. Once the tunnel is established it will be possible to the users to interact with the higher capable nodes directly using existing WSN architecture itself.

A paper called “A Delay-Tolerant Network Architecture for Challenged Internets” proposes to use a method to integrate the challenged networks. Challenged networks are those which have a very long end-end delay, low bandwidth, high rate of network portioning, high error rates. Sensor network can be considered as a challenged network so this paper is applicable to the sensor network also. This paper uses an application layer above transport layer in TCP/IP stack as well as in WSN stack called the bundle layer. This layer is responsible to store and forward packet. This is shown in the figure below.

Connecting WSN and Internet using DTN gateway

It looks similar to gateway approach described before, but it has several dissimilarities with the application level gateway approach. The DTN gateway is universal to connect any network, it is not application based. It takes into account many aspects of different challenged network but application level gateway fails to do so. One region itself can have two or more DTN gateways, so even within a region if partition takes place DTN gateway based approach works where as the earlier one fails.

The network is divided into different regions. One region itself has many DTN gateways. The DTN gateways communicate with each other. Initially routing is done based on the region address using the bundle layer in the DTN gateways. Once the packet reaches the destined region the address of the host is used to reach the host in the destination. The address format will be (region address, host address) host address can be of any type. So this architecture works for any network. This paper speaks about integration of all challenged networks and TCP/IP network. The figure in the next page shows DTN based architecture.

DTN based Architecture

The advantage of this architecture is that it can be used to connect any type of network, and it supports more than one DTN gateway in only one network patch. The DTN gateway takes care of interface between different networks. So every network can be designed independently. The disadvantage of this architecture is the extra bundle layer that needs to be installed.

This Article will be continued in the next post ...

Fault Tolerance in Sensor Networks

The probability of failure of sensor nodes in sensor networks can be very high in some applications. So it very necessary to design the sensor networks such that, the failure of sensor nodes do not affect the proper functioning of network. Much importance has been given to make sensor network fault tolerant and reliable.

In a paper called “Fault tolerant clustering of WSN” fault tolerance of WSN is increased using detection of failed gateways, and re associating the senor nodes attached to the failed gateway with another existing gateway. Periodic checking for failure of gateways is done. If a failure is found, all sensor nodes attached to the failed gateway are reattached to a new gateway. This method prevents re election of the gateway, and increases reliability of wireless sensor networks.

In “Prolonging Sensor Network Lifetime with Energy Provisioning and Relay Node Placement” authors propose to provide extra energy to the AFN (Aggregating and Forwarding Node) similar to gateway. As a result of providing extra energy, failure of gateways can be prevented hence sensor network become more fault tolerant. The approach also proposes to use extra relay nodes after AFN and provide extra energy to the relay nodes also. The SPINDS algorithm proposed in this paper tries to solve the joint problem of relay node placement and energy provisioning.

In another approach called “WSN with Guaranteed Capacity and Fault Tolerance” authors propose deployment of extra nodes form a robot helicopter. These extra nodes are deployed to make wireless sensor network fault tolerant. All the nodes will not be awake simultaneously. Redundant nodes will be sleeping and wake up only when an active node dies.

In a patent called “Fault Tolerance in WSN” authors try to make WSN fault tolerant by the usage of secondary and tertiary gateways along with primary gateway. The primary gateway synchronizes the secondary and tertiary gateway with itself. If the primary gateway fails, secondary gateway takes up its place and if the secondary gateway fails tertiary gateway take up its place. This increases fault tolerance of WSN.

Energy Usage in Sensor Nodes

Data transmission and reception, and sensing are the prime cosumers of power in a sensor node . In other words Transceiver, Controller, Sensors and to some extent the memory are the components that feed on the avaialable energy in a sensor node.

Transceiver is costliest in terms energy usage. A bit transmitted or received is equal to 1500-2700 instructions being executed. Hence it is adviceable to put sensor nodes(transceivers) to sleep when not is use. There are three states, sleep state, operational state and idle sate. Operational state consumes the max, Idle state being next and sleep state consumes the least.. The energy required to change state from sleep to active is considerable, so one has decide on when a sensor node should sleep and when should it be awake.

The energy cosumption of each component is described below
Microcontroller: The MSP430 family features a wider range of operation modes: One fully operational mode, which consumes about 1.2 mW (all power values given at 1 MHz and 3 V). There are four sleep modes in total. The deepest sleep mode, LPM4, only consumes 0.3 μW, but the controller is only woken up by external interrupts in this mode. In the next higher mode, LPM3, a clock is also still running, which can be used for scheduled wake ups, and still consumes only about 6 μW.
Memory: The main consumer in memory is the Flash Memory. Reading, Writing and Erasing flash memory all consume energy. Among them writing consumes the most energy.
Transreceiver: Energy is consumed in transreceiver during transmission, reception, start up (switch off to switch on). The following example explains the energy consumption pattern. µAMPS -1 consumes 279mW for reception, 151 mW for transmission and 58.7mW for start up.
Sensors: Predicting power consumption of sensors is not easy task, as variety of sensors consume different amount of energy. Passive sensors consume very less energy and the energy consumed by them is negligible compared to other energy consumption however active sensors consume considerable amount of energy.

Software Architecture of a Sensor Node

An Operating System, Sensor Module, Antenna Module, Communication Module, Applications, Mobilizer Module, and Location and navigation module make the software of a senor node. Some sensor nodes may have all of modules and some may have only few modules according to the necessity. The naming and classification of these modules may be different in other literature's but let us stick to the above module names in this article and get to know about them. The following figure gives the overall software architecture of sensor node.

Overall Software Architecture of a Sensor Node

Operating System: This is hardware common micro code which will be used by all other high level node resident modules. As is generally the case the purpose of operating system is to shield the higher level modules from machine level functionality of the microprocessor. We can have Tiny-OS, which is open source software designed particularly targeting WSNs. It is written using Nesc. Nesc is made up of modules and configuration files, these are called as components. Tiny-OS is made up of components, components provide and use interfaces. The modules contain the actual implementation and configuration files wire the modules. There are tasks and hardware events for execution, tasks can be postponed but hardware events cannot be postponed.

Sensor Module: This module is responsible, to provide drivers to sensors present in the sensor node, to collect data from sensor when they are generated, to switch on and off the sensors, configure the sensors, and any other function that is related to sensors is done by this module.

Mobilizer Module: This module is responsible for the mobilizer’s driver, controlling of the mobilizer, this module comes into picture only if the sensor has a mobilizer in it.

Location and Navigation Module: This module is responsible for finding location of the sensor node and providing drivers for the location finding instruments if they are present on the sensor node.

Antenna Module: This module is responsible for the driver of the transceivers like CC2420. Any driver’s main function is to shield the software modules from the machine level functionality of the hardware.

Communication Module: This module is responsible for the route set up, channel allocation, new node detection, route table maintenance, encryption, decryption of the data , providing other security features required, providing good QoS, error checking and correction, data buffering, data forwarding many others.

Applications: This module is responsible for data aggregation, in node processing, and other application specific functions.