To implement LEACH in WSN, all the sensors in the network are divided into different Clusters. For this implementation, we have used 4 clusters. The clusters are fixed in the sense that its members don’t change over time.
Each cluster has a sensor which acts as a Cluster Head (CH). The sensor with the maximum remaining energy is selected as the Cluster Head. The Cluster Head changes after some fixed number of packet receptions, which in this case is taken as 4.
The member sensors in the cluster communicate only with the Cluster Head. The sensors transmit their packets directly to the Cluster Head in a single hop. The Cluster Head, in turn, forwards these packets to the Sink either directly or via other Cluster Heads. The route from the Cluster Head to the sink has been defined as static routes.
Netsim’s default WSN libraries only have AoDV and DSR in layer 3. To run LEACH protocol, a few changes have been made in some of the files in DSR dll and Zigbee dll, and a new file LEACH.c containing the LEACH function is added.
A new DSR.dll should be built and placed in NetSim’s bin path. For this follow instructions provided in NetSim’s help on how to write custom code. For this new DSR dll to run LEACH, copy the following files in DSR dll
Follow a similar procedure for Zigbee dll by including the following files:
Next, to enable LEACH, uncomment the line “#define _LEACH” at the beginning of the DSR.h file. Next, to enable Static ARP, uncomment the “#define _STATIC_ARP” line in the same DSR.h file. This is done to prevent loss of power / time in setting up the ARP table initially.
Now, rebuild the DSR dll and Zigbee dll using Visual Studio, and copy the updated dlls in the Bin folder of NetSim.
For running LEACH, we have divided the network into 4 clusters. The sensor with the maximum energy is selected as the cluster head, and is updated after every 4 packet transmissions by the cluster head.
Since we are using Static ARP, the nodes do not need to send ARP control packets. Packet transmission can start immediately.
The sensors generate the first packet at a random time less than the sensing interval. After that each sensor generates a packet after every sensing interval.
Static routes have been defined between the Cluster heads as given below:
- Cluster Head 1 Cluster Head 3 Sink
- Cluster Head 2 Cluster Head 4 Sink
- Cluster Head 3 Sink
- Cluster Head 4 Sink
When a Network Out event is generated, the nodes just need to identify the next hop. The next hop is selected in the following manner:
- First of all, it checks whether the Device ID is the same as the Source ID to determine whether the present node is the source or an intermediate node.
- If the node itself is the source, then the next hop is the Cluster Head of that cluster.
- If the current node is not the source, then it must be the cluster head when the packet was forwarded to it by the source or the previous cluster head. It then checks its cluster number. Then the next hop is selected according to the static routes mentioned above.
Similarly, when a Network In event is generated, the node checks whether it’s Device ID is the same as the Destination ID. If not, it generates a Network Out event which again finds the next hop as explained previously. If it is the Destination, then a Transport In event is created.
Source Codes are attached below
Zigbee — Source C Code
DSR — Source C Code
Visit: www.tetcos.com Email: firstname.lastname@example.org