Energy conservation is one of the challenging issue among numerous stringent requirements for the implementation of WSN security using key management. There are many ongoing research aimed at realising a practical and robust keying model that tends to address this problems. Some WSN applications require additional hardware cost that supports mobility and high energy consumption for the movement from one location to another. The point of concentration is based on the understanding that energy for communication among sensor nodes constitutes a larger part of total energy of the network and hence the security concern and schemes in maintaining energy efficient data gathering is limited and most time unthinkable to apply.
The current physical component of WSN motes has to be redesign to accommodate energy harvester devices for a long term solution to energy consumption in the sensor nodes. Nevertheless, using a shortest path for nodes communication to gateway or base station can save measurable amount of energy and allow sleep mode which is the current best antidote to energy consumption. Other methods considered includes Distance-based technique: This technique involves controlling the distance of the node placement and adopting the power control mechanism to balance the energy consumption. And Density-based technique: Chang et al developed this scheme that controls the number of WSN nodes deployed in each area, using a sleep-wakeup mechanism to balance the energy consumption. Also, If the transceiver spends too much energy sending and receiving, it is necessary to compensate by reducing both the message size and number of steps of the security protocols.
In the implementation of a routing mechanism for the enhanced security technique, I envisioned a method that will intelligently combine Mesh Pre-allocation, routing and set-up stage for encryption with trade off in energy consumption and also creates shortest path for nodes communicating with the base station. By implementing a Contiki programming abstraction known as protothreads, that are stackless with a low memory overhead in two different protocols, Rime and uIP, the following results were generated in Cooja. The simulator that executes Contiki programs in two different ways. Either by running the program node as compiled native code directly on the host CPU, or by MSP430 emulator. Cooja is also able to simulate non-Contiki nodes, such as nodes implemented in java or even nodes running on another operating system.
To allow communication within the wireless sensor network, we needed to implement a routing mechanism that would:
- Allow node to communicate with base station
- Allow node to communicate with other nodes
- Allow node to communicate even if they are not neighbours
- Allow node to find the shortest path to the destination
- Be easy to implement
- Be energy efficient
We decided to use our modified mesh routing mechanism from Contiki OS standard library, because it provided all the features stated above.
The smart mesh routing mechanism sends packets using multi-hop routing to a specified receiver somewhere in the network and uses three channels, one for multi-hop forwarding and two for the route discovery. As part of route discovery, it floods the entire network with route discovery request packets until the packet reaches its destination. When the packet reaches its destination, the destination node floods the network with route discovery response packet until it reaches the original route discovery request packet sender then knows that the shortest path to the receiver goes through the neighbour it received the response from first. It then chooses the neighbour as the next hop and using the multi-hop routing sends the data to the receiver.
In this scheme as shown in the Figure, node with ID 1 wants to communicate with mode with ID 6, so it floods the network with route discovery request packet and receives multiple responses, but chooses the first and therefore the fastest one.
We have measured power consumption using energest in our code by capturing energest values before and after the transmission and computing the actual consumption. Energest is use for obtaining per-component power consumption in Contiki. Thus, using the formula below if we do not divide by runtime, calculates the energy consumption during runtime.
Enhanced Routing Scheme
Power (pW) = (txend – txstart) * 20mA * 3V / 32768
The 20mA are pre-measured (or from data sheet), 3V is the operational voltage (approximated) and 32768 is ticks per second (as of Contiki 2.5). By measuring and computation of the final values we got following power consumption as shown below, but with the value of the Multi-hop Communication (sender) of the Rime stack multiplied by 0.1 because the original value distorts other values displayed in the graph.
Power Consumption Analysis of uIP and Rime using Enhanced scheme
If you take closer look on the chart on the Figure below you will see that the value of multihop transmission using Rime protocol is missing. That’s because it takes so long that it causes request timeout each time the program is run. This is because of insufficiency of Rime protocol. The nodes were tested for both single-hop and multi-hop using the worst case scenario where each node sees only 2 neighbors and a message has to travel through each node in the network.
Power Consumption Analysis of uIP and Rime using Enhanced scheme for worst case scenario
About the Author
Celestine Iwendi is a Sensor and Electronics Researcher at the University of Aberdeen, UK.