IP is Dead, Long Live IP for Wireless Sensor networks

Wireless Networks community has been observing many research efforts to devise protocols specific to application domains, with energy efficiency being the primer. There has been a growing consensus in the community, towards building a generalized WSN architecture, so as to combine these disjoint protocols under a common protocol layer, and address the WSN problems in broader networking sense and let the designers and implementers work towards a common goal of improving the system as a whole.

Since the nascent days of WSN, IPV6 was seen as a candidate to provide such architecture, but the majority of researchers denounced its use in WSN due to several concerns as lack of resources like memory, Energy, processing power and bandwidth. The large ip headers and payloads, end-to-end protocols were deemed un-necessary to WSN.

Since then IP, and WSN have evolved through a lot of research and increased practical deployment experience. It is worthwhile looking again towards IP protocol, to assess if it could provide sensor networks the much-coveted backbone architecture.

It is impractical to use IPV6 architecture in its current format due to obvious reasons of relatively huge header as well as assumptions about link connectivity. This paper propose an IPV6 based architecture for WSN, which would conform to the layering abstractions, services and interfaces of protocol stack, yet allow integration of existing duty cycled mac layer protocol concepts which have already been proven to be quite effective and efficient.

IPV6 architecture:

The architecture specifies WSN existing at the edge of IP networks, with border routers communicating with the external IP network.

The IPV6 network for WSN emulates the link layer, Network Layer and Transport layer abstraction of IPV6 architecture in wired networks. A combination of sample listening and localized schedule synchronization is used to emulate IP link.

Sampled listening uses short chirps as wakeup signal, and append destination address as well as schedule synchronization information to it, so as to avoid overhearing problem as well as synchronize a rendezvous time for sender and receiver with minimal chirp transmission. The scheduled time lets the receiver sleep, and then wakeup exactly at the point of data transfer. We’ll discuss about the problems with this approach in the next section.

Given the size of IP packets, there exist a layer 2.5 between Link layer and Network layer, which compress and fragments the data packets as necessary. The compression scheme works by eliding the obvious information as Version, Traffic class etc. as well as removing redundant information like Link Level Identifiers, as they could be derived form the link layer header as well. The 6LP_IPHC compression scheme uses 1 bit of compression state, and is able to compress 48byte UDP/IPV6 header up to 6 bytes.

Network layer duties include Neighbor discovery, Auto Configuration, Forwarding and Routing. The border routers propagate Routing Advertisements to announce optimal routes, as well as network parameters. The trickle algorithm is applied to assure minimal overhead by RA transmission. The increasing sequence numbers of RA’s make sure that only the most recent RA versions are applied by the nodes. Autoconf feature of IPV6 allows the unattended nodes to self configure identifier by appending the link layer identifier to Local link identifier, or else DHCP could be employed to let a centralized server allocate identifiers to the nodes.

Forwarding and routing are the other two features of network layer. Each intermediate node works as a default router, and maintains next hops for a partial number of neighbors, as well as a default route to border router to redirect rest of the packets. The border routers learn the default routes and reverse link them to analyze and generate optimal links to all the nodes. The destination path is injected in datagram’s header, so as to make sure it reaches the destination. Loops and inefficient links are identified by inserting expected hop count and eTX for next hop on the datagram and the receiving hop checks if the hop count is lesser than expected to detect loops, and if ETX is lesser than expected than it indicates increased path cost has not been updated.

We had thorough discussions over a lot of issues related to the paper:

Experimental Setup and Test-bed: The experimental deployment to evaluate protocol, doesn’t really prove a great deal as it considers very mild data rate if 1 packet per minute, which doesn’t really test the network congestion at all. The slow data rate perfectly explains the low duty cycle of 0.65%! The general consensus was that the tests seemed a bit hollow, and the protocol in its current state would struggle in harsher environment, with unpredictable data rates.

Congestion Control: The congestion control algorithm used in the protocol looks very inefficient as it waits for congestion to happen and then starts applying backpressure to decrease the data rate. This could lead to extensive link level retransmissions, which could be lost as well, as they would just add more to the congestion, and eventually the links would drop packets after exceeding retransmission count.

Rendezvous Time setup and Synchronization: Again, with low or no contention whatsoever it seems very easy to set up rendezvous time and transfer data but think about a huge network with many nodes contending to send data to a receiver! In this case with so many nodes undergoing sleep – wakeup schedule and transferring chirps it is inevitable that rendezvous times would collide, and it would be very tough to reach consensus, without avoiding extended wakeups and hurting overall energy efficiency.

Frame Pending bit and Starvation: The advantage with this approach is that the receiver doesn’t have to wait for timeout to decide that data is not pending, as the sender explicitly sets the frame pending bit. The issue of starvation was discussed in the class, and as it seems, it is impossible to avoid starvation in the current approach if some node decides to send forever by always setting the frame pending bit. This would lead to starvation for other motes as well as worse energy efficiency.

An issue was pointed out in the review for the approach of using IPV6 data packet structure for acks. The smaller acks could be comfortably sent between the chirps as well as data streams, but how would this extended Ack structure affect it is debatable.

Another interesting thought was, the possibility of WSN acting as a bridge between IP networks. Then, would it route the IP packets for other IP networks? This would severely affect the energy efficiency of WSN network.

The introduction of security in WSN courtesy IPV6 is definitely appreciable. Given the sensitivity of a lot of WSN deployments, security surely is an implicit requirement.

The discussion ended with probably the most basic yet debatable question:

Do we really need IPV6 with all its complexity and extra baggage (long headers) at all in WSN? If it is about connecting to outside network, why not let the border routers speak IP, and let the WSN speak its own language, in its efficient ways?

The answer was the same, when different hardware, software organizations agreed over common protocols and platform for Internet. The answer remains the same now as well! The extended future of WSN calls for a generalized architecture and the need for sensor nodes speak the same language (IP) as the rest of the IP world speaks. One interesting thought is that IPV6 architecture would give each sensor node an IP address, which makes it possible to access every “dust” around us!