Featured Examples
Sample configuration files for all networks are available in the Examples Menu in NetSim Home Screen. These files provide examples on how NetSim can be used – the parameters that can be changed and the typical effect it has on performance.
IOT
Energy Model
Open NetSim, Select Examples->IOT-WSN->Internet of Things->Energy Model then click on the tile in the middle panel to load the example as shown in Figure-1.
Figure-1: List of scenarios for the example of Energy Model
The following network diagram illustrates what the NetSim UI displays when you open the example configuration file.
Figure-2: Network set up for studying the Energy Model
Settings done in sample network
Grid is set to 1000 × 500 from grid setting property panel on the right. This needs to be done before the any device is placed on the grid.
Click on LOWPAN Gateway and expand the right property panel, enable the Beacon Mode and change the Superframe Order to 12 and the Beacon Order to 12 under the Interface 1 (Zigbee) layer.
Figure-3: Datalink layer Properties for Lowpan Gateway
Click on sensor, go to physical layer in Interface (Zigbee) layer and change the power source to Battery.
Click on link and open property panel on the right and set the channel characteristics No pathloss in Ad hoc link Properties.
Configure a sensor application between Sensor 2 and Wired node 4 from the Set Traffic tab in ribbon on the top.
Enable the sleep energy vs time plot by clicking on configure reports tab > Plots and run the simulate for 50 sec.
In Simulation metrics window, click on Additional metrics in the left panel and check the Battery model metrics, users should get zero value for Sleep energy (mJ) consumed.
Go back to Simulation window change following properties in LOWPAN Gateway for another sample.
Set Superframe Order (SO) and Beacon Order (BO) as 10 and 12 respectively (0 <= SO <= BO <= 14)
Re-run the Simulate for 50 sec.
Results:
In the simulation results window click on additional metrics on the left and scroll down for the Battery model metrics for both the cases.
In Superframe order 12 and Beacon order 12 Sample, users can observe sleep energy consumed value will be zero in Battery model metrics since sensor is in active state all the time. i.e., if SO=12 and BO=12, there won’t be any inactive portion of the Superframe.
Figure-4: Battery Model Table for SO=12 & BO=12
Similarly, Open the Sleep energy vs time plot from simulation results window, compare the sleep energy consumed by sensor over the simulation time for both cases when SO =12 and BO =12 and SO =10 and BO =12.
Figure-5: The above plot shows the sleep energy consumed when SO=12 and BO=12. The sleep energy consumed is zero since there is no inactive portion in the beacon interval, and the sensors remain active throughout beacon interval.
In Superframe order 10 and Beacon order 12 Sample, sleep energy consumed will be non-zero since sensor goes to sleep mode during the inactive portion of the Superframe.
Figure-6: Battery Model Table for SO=10 & BO=12.
Figure-7: In the above plot, we observe that sleep energy remains zero when SO=10 and BO=12 during the active period, i.e., till 15728.64 ms. After this period, sleep energy consumption increases linearly due to the inactive portion of the super frame.
Working of RPL Protocol in IoT
Open NetSim, Select Examples->IOT-WSN->Internet of Things->Working of RPL Protocol in IoT then click on the tile in the middle panel to load the example as shown in Figure-8.
Figure-8: List of scenarios for the example of Working of RPL Protocol in IoT
The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file.
Figure-9: Network set up for studying the Working of RPL Protocol in IoT
Settings done in sample network:
Set grid length as 120 × 60m from grid setting property panel on the right. This needs to be done before the any device is placed on the grid.
Click on LOWPAN Gateway or sensor. In the right property panel, change the routing protocol to RPL under network layer as shown Figure-10.
Figure-10: Routing Protocol to RPL in Network layer
Click on link, expand the right property panel change Channel characteristics 🡪 Path Loss only, Path Loss Model 🡪 Log Distance and path loss exponent 🡪 3.5 .
Configure sensor applications as shown in the below table by clicking on set traffic tab from the ribbon on the top.
Application Properties |
|||
|---|---|---|---|
Application ID |
Application Type |
Source Id |
Destination Id |
1 |
SENSOR APP |
1 |
8 |
2 |
SENSOR APP |
3 |
8 |
3 |
SENSOR APP |
5 |
8 |
Table-1: Application properties
Procedure to get detailed RPL log file:
Go to help option in the title bar.
Click on Open Source code.
Go to the RPL Project in the Solution Explorer. Open RPL.h file and change //#define DEBUG_RPL to #define DEBUG_RPL as shown below Figure-9.
Figure-11: Visual Studio
Right click on the RPL project in the solution explorer and click on rebuild.
After the RPL project is rebuilt successfully, go back to the network scenario.
Enable the Application throughput vs time and Link throughput vs time plots under plots in configure reports tab and run simulation for 100 sec and go to Result window 🡪 Logs, open rpl log file.
Figure-12: Simulation Result window Results
Figure-13: RPL log file
Note:
Detailed information of the RPL log file is available for the standard version of NetSim. For academic users, the rank value can be observed by enabling Wireshark and also python script is available to know the parent and sibling information.
Please find the below link to download and run the python utility: https://support.tetcos.com/support/solutions/articles/14000134056-how-to-visualize-the-rpl-dodag-in-netsim-iot-simulations-
The observations of rpl log file which is generated in NetSim is given in the below Table-2.
Node |
Rank |
Updated Rank |
Parent list |
Updated Parent Node ID |
Sibling Node ID |
Received DIO From Node ID |
|---|---|---|---|---|---|---|
Node |
30 |
27 |
Node 2, Node 4 |
Node 2 |
Node 3 |
Node 2, Node 3, Node 4 |
Node 2 |
15 |
15 |
Node 6 |
Node 6 |
Node 4 |
Node 4, Node 6 |
Node 3 |
28 |
28 |
Node 2, Node 4, Node 5 |
Node 4 |
Node 1 |
Node 1, Node 2, Node 4, Node 5 |
Node 4 |
15 |
15 |
Node 6 |
Node 6 |
Node 2 |
Node 2, Node 6 |
Node 5 |
27 |
27 |
Node 4 |
Node 4 |
Node 4 |
Table-2: RPL Log file contains Rank, Updated Rank, parent list, Updated Parent Node ID, Sibling Node ID and Received DIO From Node ID etc.
DIO message is sent by the root node, i.e. LowPAN Gateway, with Rank 1 to Sensor 2 and Sensor 4 as shown Figure-14.
Figure-14: DIO messages sent by the LOWPAN Gateway to Sensors
On receiving the DIO message, Node 4 will recognize the DODAG Id of Root Node and identifies it as Parent node. Rank of Node 4 will get updated to 15. Also, Node 2 is recognized as sibling of Node 4.
Now, node 4 will broadcast DIO message to other nodes as shown Figure-15.
Figure-15: Wireless Sensor 4 broadcasting DIO message to other Sensors
Node 1 receives DIO message from Node 4 and it identifies the DODAG Id of Node 4. Hence, Node 1 recognizes Node 4 as the Parent Node. Rank of Node 1 will get updated to 30. As Node 3 is within the range of Node1, Node 3 is identified as a sibling of Node1.
Node 1 will then broadcast DIO messages as shown Figure-16.
Figure-16: Wireless Sensor 1 broadcasting DIO message to other Sensors
Node 2 receives the DIO message from Node 6 and identifies it as Parent node. The Rank of Node 2 gets updated to 15. Node 2 now broadcasts the DIO message to other nodes as shown in Figure-17.
Figure-17: Wireless Sensor 2 broadcasting DIO message to other Sensors
Node 3 receives DIO message from Node 4 and the rank of Node 3 gets updated to 28. Node 4 is identified as the parent node of Node 3.
Node 3 then broadcasts DIO message to other nodes as shown in Figure-18.
Figure-18: Wireless Sensor 3 broadcasting DIO message to other Sensors
Node 5 receives DIO message from Node 3, hence, it identifies Node 4 as th parent node. The rank of Node 5 gets updated to 27.
Node 5 then broadcasts DIO message as shown in Figure-19
Figure-19: Wireless Sensor 5 broadcasting DIO message to other Sensors
Further, Node 1 receives DIO message from Node 2 and the parent list of Node 1 gets updated to Node 4 and Node 2. Also, the rank of Node 1 gets updated to 27.
According to the link quality, DODAG is formed.
Node 2 and Node 4 are siblings and their parent is Node 6 (Root Node). Rank is 15.
Node 1 and Node 3 are siblings.
Node 1 established its parent as Node 2. Rank is 27.
Node 3 establishes its parent as Node 4. Rank is 28.
Node 5 doesn’t have any siblings and establishes its parent as Node 4. Its rank is 27.
Figure-20: Based on link quality, DODAG is formed and Rank assigned to sensors and lowpan gateway
Modes of Operation in IoT RPL
The DODAG nodes process the DAO messages according to the RPL Mode of Operations (MOP), which are presented below. Independent of the MOP used, DAO messages may require reception confirmation, which should be done using DAO-ACK messages.
Although it is designed for the Multipoint-to-Point (MP2P) traffic pattern, RPL also admits the data forwarding using Point-to-Multipoint (P2MP) and Point-to-Point (P2P). In MP2P, the nodes send data messages to the root, creating an upward flow as shown in Figure-21. In P2MP, sometimes termed as multicast, the root sends data messages to the other nodes, producing a downward flow depicted in Figure-23.
In P2P, a node sends messages to the other node (non-root) of DODAG; thus, both upward and downward forwarding may be required as illustrated in Figure-22. RPL defines four MOPs that should be used considering the traffic pattern required by the application and the computational capacity of the nodes. In the first, MOP 0 (Point to multipoint), RPL does not maintain downward routes; thus, consequently, only MP2P traffic is enabled. In storing without multicast MOP (MOP 2 (Point to point)), downward routes are also supported, but are different from MOP 1; the nodes maintain, individually, a routing table constructed using DAO messages to provide downward traffic. Hence, downward forwarding occurs without the use of the root node, as illustrated in Figure-24 Storing with multicast has a functioning similar to MOP 2 (Point to point) plus the possibility of multicast data sending. This type of transmission permits the non-root node to send messages to a group of nodes formed using multicast DAOs.
Figure-21: Multipoint to Point
Figure-22: Point to Point
Figure-23: Point to Multipoint
Figure-24: RPL Storing Mode
Open NetSim, Select Examples->IOT-WSN->Internet of Things->Mode of Operations IoT RPL then click on the tile in the middle panel to load the example as shown in Figure-25.
Figure-25: List of scenarios for the example of Mode of Operations IoT RPL
The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file.
Figure-26: Network set up for studying the Mode of Operations IoT RPL
Multipoint to Point
Settings done in sample network
Set grid length as 200 × 100m from grid setting property panel on the right. This needs to be done before the any device is placed on the grid.
Routing protocol has been set as RPL for LOWPAN Gateway and Sensor. Click on device , expand the right-side property panel and go to Network Layer set Routing Protocol as shown in Figure-27.
Figure-27: Routing Protocol to RPL in Network layer
Click on the link, expand the right-side property panel, and set the channel characteristics to 'Path Loss Only’. Then, set the path loss model to 'Log Distance' and the path loss exponent to 4.2.
Configure sensor applications as shown in the below table by clicking on set traffic tab from the ribbon on the top.
Application Properties |
|||
|---|---|---|---|
Application ID |
Application Type |
Source Id |
Destination Id |
1 |
SENSOR APP |
1 |
11 |
2 |
SENSOR APP |
3 |
11 |
3 |
SENSOR APP |
8 |
11 |
Table-3: Application properties
In NetSim GUI Packet Traces and Plots are Enabled. Run simulation 100s and observe that all the sensors are sending data to route node in packet trace.
Result
Packet trace: The nodes send data messages to the root, creating an upward flow which can be observed in the packet trace. Once the simulation is completed, to view the packet trace file, click on “Packet Trace” under Traces option present in the left-hand-side of the Simulation Results Dashboard and filter the PACKET TYPE to Sensing. you can observe the flow of Sensor Application packets as shown in Figure-28.
Figure-28: Packet Trace for Multipoint to Point
Point to Multipoint
Settings done in sample network
Set the all the properties same as Multipoint to Point scenario
Configure sensor applications as shown in the below table by clicking on set traffic tab from the ribbon on the top.
Application Properties |
|||
|---|---|---|---|
Application ID |
Application Type |
Source Id |
Destination Id |
1 |
SENSOR APP |
11 |
1 |
2 |
SENSOR APP |
11 |
3 |
3 |
SENSOR APP |
11 |
8 |
Table-4: Application properties
Run simulation 100s and observe that all the sensors are sending data to route node in packet trace.
Result
Packet trace: Root sends data messages to the other nodes, producing a downward flow which can be observed in the packet trace. Once the simulation is completed, to view the packet trace file, click on “Packet Trace” under Traces option present in the left-hand-side of the Simulation Results Dashboard and filter the PACKET TYPE to Sensing, you can observe the flow of Sensor Application packets as shown below:
Figure-29: Packet trace for Point to Multipoint
Point to Point
Settings done in sample network
Set the all the properties same as Multipoint to Point scenario.
Configure sensor applications as shown in the below table by clicking on set traffic tab from the ribbon on the top.
Application Properties |
|||
|---|---|---|---|
Application ID |
Application Type |
Source Id |
Destination Id |
1 |
SENSOR APP |
1 |
5 |
Table-5: Application properties
Run simulation 100s and observe that all the sensors are sending data to route node in packet trace.
Result
Packet trace: Root sends data messages to the other nodes, producing a downward flow which can be observed in the packet trace. Once the simulation is completed, to view the packet trace file, click on “Packet Trace” under Traces option present in the left-hand-side of the Simulation Results Dashboard and filter the PACKET TYPE to Sensing, you can observe the flow of Sensor Application packets as shown below:
Figure-30: Packet trace for Point to Point
Storing Mode
Settings done in sample network
Set the all the properties same as Multipoint to Point scenario.
Configure sensor applications as shown in the below table by clicking on set traffic tab from the ribbon on the top.
Application Properties |
|||
|---|---|---|---|
Application ID |
Application Type |
Source Id |
Destination Id |
1 |
SENSOR APP |
1 |
5 |
Table-6: Application properties
Run simulation 100s and observe that all the sensors are sending data to root node in packet trace.
Result
In storing without multicast MOP (MOP 2 (Point to point)), downward routes are also supported, but are different from MOP 1 (Point to multipoint); the nodes maintain, individually, a routing table constructed using DAO messages to provide downward traffic. Hence, downward forwarding occurs without the use of the root node. The results can be analyzed from the packet trace.
Packet trace: Once the simulation is completed, to view the packet trace file, click on “Packet Trace” under Traces option present in the left-hand-side of the Simulation Results Dashboard and filter the PACKET TYPE to Sensing, you can observe the flow of Sensor Application packets as shown below.
Figure-31: Packet trace for RPL Storing Mode
DDOS attack in an IoT Network
Introduction
A DoS (Denial of Service) attack in IoT (Internet of Things) involves overwhelming a device or network with traffic to disrupt its normal operation and deny service to legitimate users. This can be achieved by flooding the network with a large volume of traffic or sending packets with malformed headers to exploit vulnerabilities in the target system. The impact of a DOS attack on an IoT device or network can be significant, as many IoT devices have limited processing power and memory resources. As a result, they may not be able to handle the large volume of traffic generated by the attack, leading to service disruptions or even device failures. When multiple attackers coordinate a DoS attack, it is known as a DDoS (Distributed Denial of Service) attack.
Botnet Attack
A botnet attack in IoT (Internet of Things) is a type of cyber-attack where a network of compromised IoT devices, such as smart home appliances, security cameras, and routers, is used to carry out malicious activities. In a botnet attack, a hacker gains control of a large number of IoT devices, often through exploiting vulnerabilities or weak security measures, and uses them to launch coordinated attacks.
Once a hacker has control of a botnet, they can carry out a variety of malicious activities, including:
DDoS attacks: A distributed denial-of-service (DDoS) attack floods a website or network with traffic, making it unavailable to legitimate users.
Data theft: A hacker can use a botnet to steal sensitive data, such as financial information or personal data, from devices on the network.
Spamming: A botnet can be used to send large volumes of spam emails or messages.
Crypto mining: A hacker can use a botnet to mine cryptocurrency using the processing power of compromised devices.
Bit-and-piece Attack
A "bit and piece" DDoS attack in an IoT network is a type of Distributed Denial of Service (DDoS) attack that targets Internet of Things (IoT) devices by sending small amounts of traffic to a large number of devices. This type of attack is also known as a low-rate DDoS attack.
In a bit-and-piece attack, the attacker sends a small amount of traffic to multiple IoT devices, such as smart home appliances, security cameras, or routers. The traffic may include a range of packet types, such as TCP, UDP, and ICMP, and the packets may be sent intermittently over a long period of time. Because the traffic is distributed across many devices, each individual device receives a small amount of traffic that is difficult to distinguish from legitimate traffic. However, when combined, the traffic overwhelms the network and causes a denial of service for legitimate users trying to access the network.
Network Setup for Botnet Attack
Case 1: Without Malicious Node (No attacker)
In NetSim, click on Examples > IOT-WSN > DDoS attack in an IOT Network
Figure-32: List of scenarios for the example of DDoS attack in an IOT Network.
Drop 9 Sensors, 1 LOWPAN gateway, 1 router, and 1 wired node(Server) as shown in the figure.
Click on the sensor, expand the property panel on right and set the routing protocol to RPL.
Click on link and expand the link property panel on right and set the channel characteristics to path loss and Pathloss model is set to Log Distance with Pathloss exponent 4.5.
Configure sensor traffic from all sensors to server by clicking on set traffic tab in ribbon on top, such that the packets are transmitted to the gateway via sensor 9. The traffic rate is low; it is 20 packets per second. Set Transport Protocol to UDP, Packet size = 50 Bytes and IAT (µs) = 50000
Run the simulation for 100 seconds and measure the throughput obtained by sensors 1 through 8.
Case 2: With a Malicious Node (DoS attack node)
Figure-33 : Network setup for 1 malicious node
Configure traffic from all sensors 1 through 8 such that the packets are transmitted to the gateway via sensor 9. The traffic rate is low; it is 20 packets per second. Set Transport Protocol to UDP, Packet size = 50 Bytes and IAT (µs) = 50000
Add a malicious node. Configure traffic such that packets are transferred via sensor 9. This has a "high" generation rate to flood the network; it is 1000 packets per second. Set Packet size = 50 Bytes and IAT (µs) = 1000
Run the simulation for 100 seconds and measure the throughput obtained by sensors 1 through 8.
Results and Observation
Application |
Case 1 - Normal Operation Throughput (Mbps) |
Case 2 - DoS Attack Throughput (Mbps) |
|---|---|---|
Sensor 1 |
0.003789 |
0.000712 |
Sensor 2 |
0.001201 |
0.000192 |
Sensor 3 |
0.004383 |
0.00076 |
Sensor 4 |
0.007476 |
0.001221 |
Sensor 5 |
0.005849 |
0.003633 |
Sensor 6 |
0.004195 |
0.003338 |
Sensor 7 |
0.001424 |
0.001544 |
Sensor 8 |
0.006226 |
0.004386 |
Malicious Node |
N/A |
0.014886 |
Sum Throughput (Mbps) Sensor 1 through 8 |
0.034543 (34.54 Kbps) |
0.015786 (15.78 Kbps) |
Table-7 : Application Throughput for Case1 and Case 2.
From table, we observe that the introduction of the malicious node led to a more than 50% drop in throughput, from 34.54 Kbps to 15.78 Kbps.
In NetSim, Click on Examples > IOT-WSN > DDoS attack in an IOT Network
Case 1: Without Malicious Node (No attacker)
Figure-34 : Network setup for normal scenario
Drop 10 sensors, 1 LOWPAN Gateway, Router and 1 Wired node (server) as shown in the figure.
Click on the sensor, expand the property panel on right and set the routing protocol to RPL.
Click on link and expand the link property panel on right and set the channel characteristics to path loss and Pathloss model is set to Log Distance with Pathloss exponent 4.5.
Configure 9 applications. Each application is from a sensor (1, 2, …, 9) to the server, such that packets of size 50 Bytes are sent at a rate of 20 packets/ sec. Set Transport Protocol to UDP, Packet size = 50 Bytes and IAT (µs) = 50000
The network topology and routing are such that traffic from all sensors flow through relay (sensor 10), and then to the gateway and onwards to the server.
Run the simulation for 100 seconds and measure the throughput obtained by sensors 1 through 9.
We then simulate 3 attack cases.
Figure-35 : Case 2 - 1 malicious node
Figure-36 : Case 3 - 2 malicious nodes
Figure-37 : Case 4 – 3 malicious nodes
Case 2: Add 1 malicious node (wired). Configure custom traffic from malicious node to all sensors (1, 2, …, 9). Packets of size 10 Bytes (representing a small amount of attack data) are sent at a rate of 20 packets/sec exponentially. Set Transport Protocol to UDP, Packet Size =10 Bytes and exponential distribution for IAT (µs) = 50000.
Case 3: Add 2 malicious nodes (wired). Configure custom traffic from 2 malicious nodes to all sensors (1, 2, …, 9). Packets of size 10 Bytes (representing a small amount of attack data) are sent at a rate of 20 packets/sec exponentially. Set Transport Protocol to UDP, Packet Size =10 Bytes and exponential distribution for IAT (µs) = 50000.
Case 4: Add 3 malicious nodes (wired). Configure custom traffic from 3 malicious nodes to all sensors (1, 2, …, 9). Packets of size 10 Bytes (representing a small amount of attack data) are sent at a rate of 20 packets/sec exponentially. Set Transport Protocol to UDP, Packet Size =10 Bytes and exponential distribution for IAT (µs) = 50000
Run the simulation for 100 seconds and measure the throughput obtained by sensors 1 through 9 in each case.
Results and Observation
Application |
Case 1: Normal Operation Throughput (Mbps) |
Case 2: 1 - attacker node Throughput (Mbps) |
Case 3: 2 - attacker nodes Throughput (Mbps) |
Case 4: 3 - attacker nodes Throughput (Mbps) |
|---|---|---|---|---|
Sensor 1 |
0.003577 |
0.002401 |
0.001968 |
0.001752 |
Sensor 2 |
0.000853 |
0.000672 |
0.000596 |
0.00048 |
Sensor 3 |
0.002185 |
0.001577 |
0.001445 |
0.001233 |
Sensor 4 |
0.007332 |
0.004942 |
0.003966 |
0.003546 |
Sensor 5 |
0.004501 |
0.003417 |
0.002724 |
0.002428 |
Sensor 6 |
0.004527 |
0.00317 |
0.002582 |
0.002242 |
Sensor 7 |
0.001184 |
0.000976 |
0.000788 |
0.000672 |
Sensor 8 |
0.006346 |
0.004406 |
0.003609 |
0.002953 |
Sensor 9 |
0.002189 |
0.001625 |
0.001329 |
0.001089 |
Sum Throughput (Mbps) of Legitimate Traffic |
0.032694 (32.6 Kbps) |
0.023186 (23.1Kbps) |
0.019007 (19.1Kbps) |
0.016395 (16.3Kbps) |
Table-8 : Application Throughput for various cases.
We observe:
25% drop in throughput of legitimate traffic with 1 bit-and-piece DDoS attack node.
50% drop in throughput of legitimate traffic with 3 bit-and-piece DDoS attack nodes.
WSN
Beacon Time Analysis
Open NetSim, Select Examples->IOT-WSN->Wireless Sensor Networks->Beacon Time Analysis then click on the tile in the middle panel to load the example as shown in Figure-38.
Figure-38: List of scenarios for the example of Beacon Time Analysis.
The following network diagram illustrates what the NetSim UI displays when you open the example configuration file.
Figure-39: Network set up for studying the Beacon Time Analysis
Settings done in sample config file
The following grid properties are already set, as Manually Via Click and Drop.
In the SinkNode, the Super frame mode and Beacon mode are set to 10 and 12, respectively. To configure it, click on the SinkNode. On the right side, expand the property panel, go to the data link layer of the Interface (Zigbee) layer, and set the Superframe Order (SO) to 10 and the Beacon Order (BO) to 12.
Figure-40: Setting Super frame and Beacon order in Sink node
In the position layer of wireless sensors and the sink, the mobility model is set to Random way point.
In Adhoc link properties change the channel characteristics as Path Loss only, Path Loss Model to Log Distance and path loss exponent as 2.
Create sensor traffic between Wireless Sensor 1 and WSN Sink 3 from the Set Traffic tab in the top ribbon. Click on the created application, set the transport layer protocol to UDP, and leave the other properties as default.
Enable Packet trace from the configure report tab in the ribbon on the top.
Figure-41: Enabling the Packet trace in Configure Reports tab
Run the simulation for 200 seconds.
Theoretical Beacon Time Calculation
Beacon Interval (BI)= Super Frame duration (SD) + Inactive Period (IP). The Super frame duration (SD) is also known as the Active period.
\(BI\ = \ aBaseSuperframe\ duration \times 2^{BO}\ = \ 15.36ms\ \times \ 2^{12}\ = \ 62914.56ms\ \sim\ 62s.\)
\(SD\ = \ aBaseSuperframe\ duration \times 2^{SO}\ = \ 15.36ms\ \times 2^{10}\ \ = \ 15728.64ms.\)
\(aBaseSuperframe\ duration\) is a constant defined by the standard and is equal to \(15.36\ ms\)
To find Inactive period,\(\ IP\ = \ BI\ - \ SD\ = \ 62914.56ms\ - \ 15728.64ms\ = \ 47185.92ms.\)
Super Frame duration is divided into 16 slots (1st slot is allocated for beacon frame).
Each slot time\(\ = \frac{15728.64ms}{16}\ = \ 983.04ms\)
NetSim Results:
Open packet trace and filter CONTROL PACKET TYPE to Zigbee BEACON FRAME, users should get four Zigbee beacon frames at 0, 62.9, 125.8, 188.7 secs (approx.) for each Sensor Node, because the time interval between two beacons frames is 62 seconds. Since we have 2 nodes so user can get 4 beacon frames for each node.
Figure-42: Packet Trace showing the Zigbee beacon frames for each sensor nodes
4 beacons were transmitted, so \(beacon\ time\ = \ 983.04ms \times \ 4\ = \ 3932.16millisec\ \)(since 1 beacon = 1 time slot). Check the beacon time in IEEE 802.15.4 metrics window.
CAP Time Analysis
Open NetSim, Select Examples->IOT-WSN->Wireless Sensor Networks->CAP Time Analysis then click on the tile in the middle panel to load the example as shown in Figure-43.
Figure-43: List of scenarios for the example of CAP Time Analysis
The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file.
Figure-44: Network set up for studying the CAP Time Analysis
Settings done in example config file
The following grid properties are already set, as Manually Via Click and Drop.
In the SinkNode, the Super frame mode and Beacon mode are set to 10 and 12, respectively. To configure it, click on the SinkNode. On the right side, expand the property panel, go to the data link layer of the Interface (Zigbee) layer, and set the Superframe Order (SO) to 10 and the Beacon Order (BO) to 12
Figure-45: Datalink layer Properties window for Sink node
In the position layer of wireless sensors and the sink, the mobility model is set to Random way point.
In Adhoc Link Properties change Channel characteristics -> Path Loss only, Path Loss Model -> Log Distance and path loss exponent -> 2.
Create sensor traffic between Wireless Sensor 1 and WSN Sink 3 from the Set Traffic tab in the top ribbon. click on the created application, set the transport layer protocol to UDP, and leave the other properties as default
Enable Packet trace from the configure report in the ribbon on the top.
Run the Simulation for 100 sec.
Theoretical CAP Time Calculation
To find CAP time, BI is 62914.56ms -> So in 100s, two beacon frames should be transmitted at 0 & 62s.
Check no. of beacon frames transmitted in 802.15.4 metrics.
Here CFP = 0 because there is only 1 sensor.
\(CAP\ Time\ = \ SD\ - \ beacon\ time\ = \ (15728.64ms)\ - \ (983.04ms)\ = \ 14745.6ms.\)
Open packet trace and filter Control Packet Type to Zigbee Beacon Frame, users should get two ZigBee beacon frames at 0, 62.9secs, because the time interval between two beacon frames is 62 seconds. Since we have 2 nodes so user can get 2 beacon frames for each node.
Since two Beacon frames are transmitted,
\[CAP\ time\ = \ 2 \times \ 14745.6ms\ = \ 29491200µs.\]
NetSim Results:
In the NetSim simulation results window, click on Additional Metrics and scroll down to the IEEE 802.15.4 Metrics table. Compare the theoretical CAP time with the CAP time in the IEEE 802.15.4 Metrics table.
CAP time = 29491200.0000Microsec.
Figure-46: IEEE802.15.4 Metrics Table in Results Windows
Static Routing in WSN
Open NetSim, Select Examples->IOT-WSN->Wireless Sensor Networks->WSN Static Route then click on the tile in the middle panel to load the example as shown in Figure-47
Figure-47: List of scenarios for the example of WSN Static Route
The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file.
Figure-48: Network set up for studying the WSN Static Route
Case 01: Without Static Route
Settings done in the network
The following grid properties are already set, as Manually via Click and Drop.
The sensor application is created between Sensor 1 and 6 from set traffic tab from top ribbon.
Packet trace is enabled from the configure reports tab.
Simulation time is set to 100 sec.
Results: Open the packet trace and observe the data flow. Sensor 1 sends packets directly to Sinknode 6.
Figure-49: NetSim packet trace showing packet flow for case 1 - Without static routing.
Case 01: With Static Route
Settings done in the network.
For the above sample (without static route), we have configured the static routes for sensors. The following steps explain how to configure static routes.
Configuring Static Routes
Click on the wireless sensor 1. In the right property panel, go to the network layer under IPv4 and enable Static IP Route.
Then, click on via GUI in Configure Static IP Route and set the Network Destination, Gateway, Subnet Mask, Metrics, and Interface ID as shown in the screenshot below. click add and then OK.
Figure-50: Static IP Routing Configuring window.
Similarly, configure static routes for other sensors as follows
Device |
Network Destination |
Gateway |
Subnet Mask |
Metrics |
Interface ID |
|---|---|---|---|---|---|
Wireless Sensor 1 |
192.168.0.7 |
192.168.0.3 |
255.255.255.0 |
1 |
1 |
Wireless Sensor 2 |
192.168.0.7 |
192.168.0.4 |
255.255.255.0 |
1 |
1 |
Wireless Sensor 3 |
192.168.0.7 |
192.168.0.5 |
255.255.255.0 |
1 |
1 |
Wireless Sensor 4 |
192.168.0.7 |
192.168.0.6 |
255.255.255.0 |
1 |
1 |
Wireless Sensor 5 |
192.168.0.7 |
192.168.0.7 |
255.255.255.0 |
1 |
1 |
Table-9: Static Route Configuration for Sensors
After setting the properties click on run simulation for 100 sec.
Results
Open the packet trace and observe the packet flow. The data will be transmitted according to the statically configured routes.
SENSOR 1 🡪 SENSOR 2 🡪 SENSOR 3 🡪 SENSOR 4 🡪 SENSOR 5 🡪 SINK NODE
Figure-51: NetSim packet trace showing packet flow for case 2- With static routing
Analysing throughput, latency and energy consumption as we scale the number of sensors
We examine a scenario in which sensors are arranged in a circular configuration around a central sink, with all sensors positioned within the carrier sense range of each other. As the number of sensors increases, we analyse throughput, latency, and energy consumption in ZigBee’s (802.15.4) beaconless and beacon enabled modes across different packet sizes.
Network Layout
Figure 4 52: Schematic of network layout. In all cases the sensors are 75m from the sink. (A) Scenario with 2 sensors and sink node (SN), (B) Scenario with 10 sensors and a sink, (C) Scenario with 20 sensors and a sink node. The sources of traffic are Sensor 1 (S1), Sensor 2 (S2), Sensor 3 (S3) etc. and the destination is the Sink Node (SN). The transmission range of the sensors is 177m and while the carrier sense range is 223m.
Network Scenario
Open NetSim, Select Examples > IOT-WSN > Wireless Sensor Networks > Analyzing throughput, latency and energy consumption as we scale the number of sensors > Analyzing Throughput, Latency, and Energy Consumption in Beacon-Disabled Mode and then click on the tile in the middle panel to load the example as shown Figure-53.
Figure-53: List of scenarios for the example of Analyzing Throughput, Latency, and Energy Consumption in Beacon-Disabled Mode.
The following network diagram illustrates what the NetSim UI displays when you open the example configuration file.
Figure-54: Network scenario modelled in NetSim. This scenario consists of 2 sensors and 1 sink node where the distance between every sensor and the sink node is 75m.
Case 1:
Create a scenario with 2 Sensor nodes and 1 Sink nodes.
Distance between the sensors and sink nodes should be 75m.
Click on Sink node and expand the property panel on right side and disable the beacon mode in datalink layer of Interface (Zigbee) properties.
Device Properties |
|
|---|---|
Network layer properties |
|
Routing protocol |
DSR |
Interface (Wireless) properties |
|
Physical layer properties |
|
ED Threshold (dBm) |
-87 |
Power |
Battery |
Table-10: Device properties for sensors
Similarly repeat this step for all other sensors.
Configure the Static Route from Sensors to Sink Node as shown below.
Static routes were configured in each source node such that the data gets transmitted directly from source to destination without any dynamic route formation by the routing protocols.
Static routes (whereby N_i always transmits to N_((i+1)) ) are set to ensure single hop transmission. Thereby each node transmits data to the next-hop node according to the topology.
To set the static routes, go to Wireless Sensor properties > Network Layer > Enable Static Route IP and click on Configure static route via GUI and update as below.
Figure-55: Static route configuration for sensor 1
The Static route IP were configured in Wireless Sensor 1, Wireless Sensor 2, Wireless Sensor 3 etc. and Wireless Sensor 20 as shown below:
Device |
Network Destination |
Gateway |
Subnet Mask |
Metrics |
Interface ID |
|---|---|---|---|---|---|
Wireless Sensor 1 |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Wireless Sensor 2 |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Wireless Sensor 3 |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Wireless Sensor 4 |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Wireless Sensor i |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Wireless Sensor 20 |
192.168.0.1 |
192.168.0.1 |
255.255.255.255 |
1 |
1 |
Table-11: Static route configured in devices.
Create a CUSTOM application from Sensor to Sink Node by clicking on set traffic tab from the ribbon on the top. Click on created application and expand application property on right panel, set packet size to 50 bytes and Inter arrival time to100000 µs.
Run the Simulation for 1000 seconds.
Similarly increase the number of nodes to 4, 6, 8, 10, 12, 14, 16,18, 20 and record the results.
Results
Case 1: Beacon Mode Disable (Low Latency)
Results for throughput and latency can be observed from the application metrics window of simulation results window and to observe transmit energy, receive energy and idle energy, click on additional metrics in the left and scroll down to the battery model metrics.
Figure-56: Observe battery model metrics from NetSim simulation results window.
Number of sensor nodes |
Avg. Transmit Energy (mJ) |
Avg. Receive Energy (mJ) |
Avg. Idle Energy (mJ) |
Average Throughput (Mbps) |
Aggregate Throughput (Mbps) |
Average Latency (Delay) (µs) |
|---|---|---|---|---|---|---|
2 |
1860.16 |
0.00 |
11517.82 |
0.0035 |
0.0070 |
6768 |
4 |
1829.45 |
0.00 |
11523.87 |
0.0032 |
0.0128 |
10566 |
6 |
1726.93 |
0.00 |
11543.78 |
0.0028 |
0.0167 |
12927 |
8 |
1596.88 |
0.00 |
11569.16 |
0.0024 |
0.0190 |
14317 |
10 |
1476.38 |
0.00 |
11592.55 |
0.0020 |
0.0204 |
15255 |
12 |
1377.65 |
0.00 |
11611.73 |
0.0017 |
0.0208 |
15999 |
14 |
1298.89 |
0.00 |
11626.97 |
0.0015 |
0.0209 |
16651 |
16 |
1228.78 |
0.00 |
11640.55 |
0.0013 |
0.0210 |
17190 |
18 |
1174.44 |
0.00 |
11651.14 |
0.0012 |
0.0208 |
17683 |
20 |
1127.08 |
0.00 |
11660.36 |
0.0010 |
0.0203 |
18167 |
Table-12:NetSim results for simulations of case 1.
Figure-57:Plot for Throughput (Mbps) vs Number of Nodes. Beacon Mode is Disabled.
Figure-58: Plot for Energy (mJ) vs Number of Nodes. Beacon Mode is Disabled.
Figure-59: Plot for Latency (µs) vs Number of Nodes. Beacon Mode is Disabled.
Discussion
The aggregate throughput increases initially but then decreases by increasing the number of nodes. The initial increase is because for small number-of-nodes the contention is less and increasing the node count increases the channel utilization.
With beacon mode disabled, all nodes remain active throughout the simulation, constantly ready to receive or transmit data. The transmitting energy per node decreases as more nodes are added to the network, which is due to the distribution of transmissions among more sensors. However, this operational mode results in a high average idle energy as nodes consume power even when they are not actively transmitting data.
This transmission mode is suitable for applications that prioritize low latency over energy efficiency.
Network scenario
Open NetSim, Select Examples > IOT-WSN->Wireless Sensor Networks > Analyzing throughput, latency and energy consumption as we scale the number of sensors > Analyzing Throughput, Latency, and Energy Consumption in Beacon-Enabled Mode for Energy Efficiency then click on the tile in the middle panel to load the example as shown in Figure-60.
Figure-60: List of scenarios for the example of Analyzing Throughput, Latency, and Energy Consumption in Beacon-Enabled Mode for Energy Efficiency.
Case 2:
Consider the same scenario as Case 1
Go to Sink Node > Interface ZIGBEE > Datalink Layer, Set the Beacon Mode to Enable and Set the Beacon Order to 12 and Super frame Order 10.
Run the Simulation for 1000 seconds.
Results
Number of sensor nodes |
Avg. Transmit Energy (mJ) |
Avg. Receive Energy (mJ) |
Avg. Idle Energy (mJ) |
Avg. Sleep Energy (mJ) |
Average Throughput (Mbps) |
Aggregate Throughput (Mbps) |
Average Latency (Delay) (µs) |
|---|---|---|---|---|---|---|---|
2 |
1703.73 |
0.2831 |
2658.87 |
638.39 |
0.0032 |
0.0065 |
20442177 |
4 |
1479.89 |
0.2831 |
2702.32 |
638.39 |
0.0025 |
0.0098 |
20668437 |
6 |
1282.07 |
0.2831 |
2740.72 |
638.39 |
0.0019 |
0.0114 |
20627134 |
8 |
1137.54 |
0.2831 |
2768.78 |
638.39 |
0.0015 |
0.0118 |
20497185 |
10 |
1028.29 |
0.2831 |
2789.99 |
638.39 |
0.0012 |
0.0116 |
20454173 |
12 |
949.96 |
0.2831 |
2805.19 |
638.39 |
0.0009 |
0.0113 |
20261225 |
14 |
883.15 |
0.2831 |
2818.16 |
638.39 |
0.0008 |
0.0107 |
20173343 |
16 |
832.50 |
0.2831 |
2827.99 |
638.39 |
0.0006 |
0.0102 |
19829588 |
18 |
792.54 |
0.2831 |
2835.75 |
638.39 |
0.0005 |
0.0097 |
19779115 |
20 |
756.68 |
0.2831 |
2842.71 |
638.39 |
0.0005 |
0.0092 |
19432628 |
Table-13: NetSim results for simulations of case 2.
Figure-61: Plot for Throughput (Mbps) vs Number of Nodes. Beacon Mode is Enabled.
Figure-62: Plot for Energy (mJ) vs Number of Nodes. Beacon Mode is Enabled.
Figure-63:Latency(µs) vs Number of Nodes. Beacon Mode is Enabled.
Discussion
Case 2 introduces beacon-enabled mode in the network, significantly altering energy consumption patterns and network performance. When beacon mode is enabled, nodes in the network operate with defined periods for active and sleep states. Nodes wake up at specific beacon intervals to transmit and receive data, and then go back to sleep. This operation significantly reduces the average idle energy consumption because nodes are not constantly powered on waiting to receive or transmit data. Instead, they spend a substantial portion of time in the low-power sleep state, which is reflected in the sleep energy metrics in the results.
However, this also introduces a substantial increase in average latency, as nodes must wait for their turn to transmit during the beacon intervals, leading to delays in packet forwarding. This is reflected in the latency values, which are orders of magnitude higher than in Case 1. Throughput slightly decreases compared to Case 1, is due to the time spent in low-power states, reducing the effective transmission time.
This transmission mode is suitable for applications that prioritize energy efficiency over latency.
Network scenario
Open NetSim, Select Examples > IOT-WSN > Wireless Sensor Networks > Analyzing throughput, latency and energy consumption as we scale the number of sensors > Effect of Packet Size vs Energy Consumption then click on the tile in the middle panel to load the example as shown in Figure-64.
Figure-64: List of scenarios for the example of Effect of Packet Size vs Energy Consumption.
Case 3: Effect of Packet Size vs Energy Consumption
Consider the same scenario as Case-2
Create a CUSTOM Application with Source ID as Sensor and Destination ID as Sink Node, with the Packet Size 20 Bytes and Inter Arrival Time 100000 µs.
Run the Simulation for 1000 seconds.
Record the results from results dashboard.
Similarly vary the packet size in application to 60B and 100B respectively.
Rerun the simulation for 1000 seconds. Record the results from the results dashboard.
Results
Number of sensor nodes |
Packet Size (B) |
Avg. Transmit Energy (mJ) |
Avg. Receive Energy (mJ) |
Avg. Idle Energy (mJ) |
Avg. Sleep Energy (mJ) |
Average Throughput (Mbps) |
Aggregate Throughput (Mbps) |
Average Latency (Delay) (µs) |
|---|---|---|---|---|---|---|---|---|
2 |
20 |
1200.53 |
0.28 |
2756.56 |
638.4 |
0.0014 |
0.0028 |
20319671 |
4 |
20 |
1142.49 |
0.28 |
2767.83 |
638.4 |
0.0012 |
0.0047 |
21071912 |
6 |
20 |
1081.05 |
0.28 |
2779.75 |
638.4 |
0.001 |
0.0061 |
21440249 |
8 |
20 |
1023.47 |
0.28 |
2790.93 |
638.4 |
0.0009 |
0.0071 |
21903767 |
10 |
20 |
969.01 |
0.28 |
2801.5 |
638.4 |
0.0008 |
0.0078 |
22150841 |
12 |
20 |
919.89 |
0.28 |
2811.04 |
638.4 |
0.0007 |
0.0083 |
22737334 |
14 |
20 |
879.28 |
0.28 |
2818.92 |
638.4 |
0.0006 |
0.0084 |
22943219 |
16 |
20 |
839.94 |
0.28 |
2826.55 |
638.4 |
0.0005 |
0.0084 |
23845867 |
18 |
20 |
790.46 |
0.28 |
2836.16 |
638.4 |
0.0005 |
0.0082 |
33464665 |
20 |
20 |
746.35 |
0.28 |
2844.72 |
638.4 |
0.0004 |
0.0079 |
44959110 |
2 |
60 |
1898.03 |
0.28 |
2621.16 |
638.4 |
0.004 |
0.0081 |
20736084 |
4 |
60 |
1731.53 |
0.28 |
2653.48 |
638.4 |
0.0034 |
0.0135 |
21670506 |
6 |
60 |
1569.88 |
0.28 |
2684.86 |
638.4 |
0.0028 |
0.017 |
22822081 |
8 |
60 |
1424.32 |
0.28 |
2713.12 |
638.4 |
0.0024 |
0.0191 |
23630100 |
10 |
60 |
1223.77 |
0.28 |
2752.05 |
638.4 |
0.0019 |
0.0191 |
53919154 |
12 |
60 |
1074.47 |
0.28 |
2781.03 |
638.4 |
0.0016 |
0.0188 |
79323930 |
14 |
60 |
967.4 |
0.28 |
2801.81 |
638.4 |
0.0013 |
0.0185 |
95181466 |
16 |
60 |
885.83 |
0.28 |
2817.65 |
638.4 |
0.0011 |
0.0181 |
107682323 |
18 |
60 |
821.14 |
0.28 |
2830.21 |
638.4 |
0.001 |
0.0175 |
115764304 |
20 |
60 |
770.42 |
0.28 |
2840.05 |
638.4 |
0.0009 |
0.017 |
123905731 |
2 |
100 |
2556.55 |
0.28 |
2493.33 |
638.4 |
0.0067 |
0.0134 |
21258705 |
4 |
100 |
2231.26 |
0.28 |
2556.48 |
638.4 |
0.0053 |
0.0211 |
22658685 |
6 |
100 |
1919.71 |
0.28 |
2616.95 |
638.4 |
0.0042 |
0.0252 |
27512241 |
8 |
100 |
1545.9 |
0.28 |
2689.52 |
638.4 |
0.0031 |
0.025 |
73068592 |
10 |
100 |
1310.88 |
0.28 |
2735.14 |
638.4 |
0.0025 |
0.0246 |
100074374 |
12 |
100 |
1151.74 |
0.28 |
2766.03 |
638.4 |
0.002 |
0.0241 |
118197099 |
14 |
100 |
1035.23 |
0.28 |
2788.65 |
638.4 |
0.0017 |
0.0234 |
129367238 |
16 |
100 |
944.31 |
0.28 |
2806.3 |
638.4 |
0.0014 |
0.0229 |
138470037 |
18 |
100 |
876.48 |
0.28 |
2819.46 |
638.4 |
0.0012 |
0.0221 |
145188141 |
20 |
100 |
819.23 |
0.28 |
2830.58 |
638.4 |
0.0011 |
0.0214 |
150341336 |
Table-14: Results table of Case-3.
Figure-65: Plot for Sum Throughput (Mbps) vs Number of Nodes with different packet size.
Figure-66:Plot for Energy (mJ) vs Number of Nodes with different packet size.
Discussion
Table-14 presents detailed metrics for energy consumption, throughput, and latency across various numbers of nodes and packet sizes (20B, 60B, and 100B).
Throughput Observations:
Average Throughput: This metric decreases with the increase in the number of nodes for all packet sizes. A more nodes are added, the data transmission per node reduces, due to increased contention and collisions on the network.
Aggregate Throughput: In contrast to average throughput, aggregate throughput increases initially as the number of nodes increases but then starts to decrease as further nodes are added. The initial increase is because for small number-of-nodes the contention is less and increasing the node count increases the channel utilization. However, beyond a threshold with more nodes, the likelihood of collisions increases due to more frequent attempts to access the channel simultaneously.
Energy Consumption Observations:
Transmit Energy: Average transmit energy decreases as the number of nodes increases. This is due to the distribution of transmissions among more nodes.
Receive and Sleep energy: Receive energy and sleep remains relatively consistent across different numbers of nodes and packet size increases. This indicates that the receive and sleep mode energy consumption is not dependent on the network size or the packet size but is dependent on the node's configuration (hardware) settings.
Insights:
Packet Size Efficiency: Larger packet sizes lead to more effective use of the network capacity, as observed by increase in aggregate throughput with packet size. Larger packets can better amortize the overheads of transmission, leading to improved application throughputs.
Energy vs. Throughput Trade-offs: There is an observable trade-off between energy consumption and throughput. While larger packets improve throughput, they also require more transmit energy. Conversely, while smaller packets lead to lower transmit energy, they achieve lower throughput.