IoT and WSN

Introduction#

Internet of Things (IoT) is an ecosystem of devices that connect to and communicate via the internet. A typical IOT deployment consists of

• Embedded devices / sensors.
• Communication over an IP network (between the devices and to/from cloud servers).
• Cloud services, Big Data, Analytics / Machine learning on the cloud.

NetSim can simulate the IoT network communication. The sensors used in NetSim are abstract, which means that they could be any kind of sensor or embedded device. Any data transmitted by these devices have to be in the form of ‘IP Packets’. NetSim simulates the transmission of these IP packets. It does not focus on “the application payload” being sent and is not concerned with data storage & analytics of this payload.

NetSim’s Internet of Things (IoT) and Wireless Sensor Network (WSN) libraries stack comprises of

• Application Layer: Sensor App as well as applications such as Voice, Video, CBR etc.
• Transport Layer: UDP
• Network layer: AODV and RPL
• MAC and PHY layers: 802.15.4 Zigbee

NetSim models IoT as a WSN that connects to an Internetwork through a 6LowPAN Gateway. The 6LowPAN Gateway uses two interfaces: a Zigbee (802.15.4) interface and a WAN Interface. The WSN sends data to a 6LowPAN Gateway. The Zigbee interface allows wireless connectivity to the WSN while the WAN interface connects to the external Internetwork.

IEEE 802.15.4 uses either Beacon Enabled or Disabled Mode for packet transmission. In Beacon Enabled Mode, nodes use slotted CSMA/CA algorithm for transmitting packets else they use Unslotted CSMA/CA.

Simulation GUI#

In the Main menu select New Simulation $\rightarrow$Wireless Sensor Networks as shown Figure 2-1

Creating Scenario#

Fast Configuration#

Fast Config window allows users to define device placement strategies and conveniently model large network scenarios especially in network such as MANET, WSN and IoT. The parametersassociated with the Fast Config Window are explained below:

Grid length: It is the area of simulation environment. Users can change the length of the grid in the range of 50-1000000m.
Side length: It specifies the area in the grid environment within which the devices will be placed. User can change the side length of the grid in the range of 50 - 1000000m. Side length should be multiple of 50. Side length should always be lesser than or equal to the Grid length.

Device Placement - Automatic Placement:

1. Uniform Placement: Devices will be placed uniformly with equal gap between the devices in area as specified inside length. This requires users to specify the number of devices as square number. For E.g., 1, 4, 9, 16 etc.

2. Random Placement: Devices will be placed randomly in the grid environment within the area as specified inside length.

3. File Based Placement: In order to place devices in user defined locations file-based placement option can be used. The file has the following general format:

<DEVICE_NAME>,<DEVICE_TYPE>,<X_COORDINATE>,<Y_COORDINATE>

Where, DEVICE_NAME is any name that will be assigned to the device. And DEVICE_TYPE is the unique Device Identifier specific to each type of device in NetSim.

The following table provides a list of all possible devices in MANET, WSN, and IOT Networks that support the Fast Configuration along with their respective device types:

NETWORK DEVICE_TYPE
Manets 1.WIRELESSNODE
Manets 2.BRIDGE_WIREDNODE
3.BRIDGE_WIRELESS NODE
4.WIREDNODE ROUTER
5.L2_SWITCH
WSN 1.Sensors
2.SinkNode
IOT 1.IOT_Sensors
2.LOWPAN_Gateway
3 WIREDNODE
4.WIRELESSNODE
5.IOT_ROUTER
6.ACCESSPOINT
7.L2_SWITCH

Note: For more details about File Based Placement, refer Section 3.6

1. Number of Devices: It is the total number of devices that is to be placed in the grid environment. It should be a square number in case of Uniform placement.
2. Manually Via Click and Drop: Selecting this option will load an empty grid environment where users can add devices manually by clicking and dropping the devices as required.

Wireless Sensor Networks#

The devices that are involved in WSN are:

Wireless_Sensor: In general, sensors monitor and records the physical conditions of the environment which is then sent to a central location (Sink node) where the data is collated and analyzed for further action. Sensors in NetSim are abstract in terms of what they sense, and NetSim focuses on the network communication aspects after sensing is performed.
WSN_Sink (in WSN): Sink node is the principal controller in WSN. All sensors send their data to this sink node. In NetSim, users can drop only one sink node in a WSN.
Ad-hoc Link: Ad hoc link depicts a decentralized type of wireless network. The network is adhoc because it does not rely on any pre-existing infrastructure, such as routers in wired networksor access points in managed wireless networks. In NetSim, Ad hoc link are used to connect theSensors and the Sink node. Ad hoc links are used here for a visual representation of connection of all the devices in an Ad hoc basis.

Note:While designing a network, after dropping the sensor nodes and the sink node, click on the Adhoc link present in the top ribbon/toolbar and drop it inside the grid like you did for sensors and sink node. Once the Ad hoc link is present inside the grid, click on the same and now click on the other devices (say sensors or sink) you wish to connect. Similarly repeat the same procedure to connect all the devices to the Ad hoc link.

Internet of Things#

The devices that are involved in IoT are:

IoT_Sensor - In general, sensors monitor and records the physical conditions of the environment which is then sent to a central location (Sink node) where the data is collated and analysed for further action. Sensors in NetSim are abstract in terms of what they sense, and NetSim focuses on the network communication aspects after sensing is performed.
LoWPAN Gateway (in IoT) - LoWPAN is an acronym of Low power Wireless Personal Area Networks. The LoWPAN IoT gateway functions as a border router in a LoWPAN network, connecting a wireless IPv6 network to the Internet. The wired portion of the network in IoT runs IPv4 whereas the wireless portion runs IPv6. The IPv6 routing protocols supported as AODV and RPL.
Ad-hoc Link - Ad hoc link depicts a decentralized type of wireless network. The network is ad hoc because it does not rely on any pre-existing infrastructure, such as routers in wired networks or access points in managed wireless networks. In NetSim IoT, Ad hoc link are used to connect the IoT_Sensors and the 6LowPAN_Gateway. Ad hoc links are used here for a visual representation of connection of all the devices in an Ad hoc basis.

Users can also add routers and nodes as shown below. Routers can be connected to the 6LoWPAN-Gateway and nodes/switches can be connected to routers using wired/wireless links.

Differences between IoT and WSN in NetSim#

WSN IOT
WSN consists of a network of only sensors IOT has a gateway which can be used to connect to internet(having routers, switches,APs etc..)
WSN runs IPv4 and features a sink. (not a gateway). IOT runs IPv6 in the sensor network (802.15.4 MAC/PHY) and IPv4 on the inter-network portion.
Routing protocols in NetSim WSN include, DSR, AODV, OLSR, and ZRP. Routing protocols in NetSim IoT include, AODV and RPL.

Note: Refer MANET Technology library for working of AODV, DSR, OLSR and ZRP.

Device Attributes#

GENERAL PROPERTIES
Right click on any sensor and select properties. The general properties of the sensor are:

• Device name is the name of sensor which is editable and will reflect in the GUI before and after simulation.
• X /Lat and Y/Lon are the coordinates of a sensor.
• Z coordinate by default will be zero (this is reserved for future use).

Interface count is 1 since sensors share the wireless Multipoint-to-Multipoint medium.

Mobility Models: Mobility models can be used to model movement of sensors. The mobility models provided in NetSim are:

• Random Walk mobility model: It is a simple mobility model based on random directions and speeds.
• Random Waypoint Mobility Model: It includes pause time between changes in direction and/or speed.
• Group mobility: It is a model which describes the behavior of sensors as they move together i.e., the sensors having common group id will move together.
• Pedestrian Mobility Model: This model is applicable to each node (local parameter), and the configuration parameters are:

• Pedestrian_Max_Speed (m/s) (Range: 0.0 to 10.0. Default: 3.0)
• Pedestrain_Min_Speed (m/s) (Range: 0.0 to 10.0. Default: 1.0)
• Pedestrian_stop_probability (Range: 0 to 1)
• Pedestrian_stop_duration (s). (Range: 1 to 10000)

In this model it is assumed that the pedestrian stops at traffic lights. The stop_probability represents the probability of encountering a traffic light. This is checked for every Calcuation_interval. Once stopped, the pedestrian waits for a duration equal to stop_duration for the light to turn green. A new direction is chosen randomly after every stop with θ (angle between new direction and current direction) taking values of 0, 90, 180, 270. These θ values represent the pedestrian continuing in the same direction, taking a left, taking a U turn and taking a right respectively.
A new speed is chosen randomly after evert stop. Min_speed ≤ Speed ≤ Max_Speed.
The maximum number of stops and starts is 10.

• File Based mobility: In File Based Mobility, users can write their own custom mobility models and define the movement of the mobile users. The name of the trace file generated should be kept as mobility.txt and it should be in the NetSim Mobility File format.

APPLICATION PROPERTIES – Transport Protocol, by default set to UDP. To run with TCP,users have to select TCP protocol from the drop down.

NETWORK LAYER- NetSim WSN, supports the following MANET routing protocols.

DSR (Dynamic source routing): Note that in wireless sensor networks, by default Link Layer Ack is enabled. If Network Layer ack is enabled users must set DSR_ACK in addition to Zigbee_ACK in MAC layer

AODV (Ad-hoc on-demand distance vector routing):
AODV (Ad Hoc on Demand Distance Vector) is an on-demand routing protocol for wireless networks that uses traditional routing tables to store routing information. AODV uses timers at each node and expires the routing table entry after the route is not used for a certain time. Some of the features implemented in NetSim are,

• RREQ, RREP and RERR messages.
• Hello message.
• Interface with other MAC/PHY protocols such as 802.15.4, TDMA / DTDMA.

ZRP (Zone routing protocol): For interior routing mechanism NetSim uses OLSR protocol.
Hello interval describes the interval in which it will discover its neighbor routes.
Refresh interval is the duration after which each active node periodically refresh routes to itself

TC Interval is a Topology control messages are the link state signaling done by OLSR. These messages are sent at TC interval every time.
Zone radius: After dividing the network range of the divided network will be based on zone radius. A node's routing zone is defined as a collection of nodes whose minimum distance in hops from the node in question is no greater than a parameter referred to as the zone radius.
OLSR (Optimized link State Routing): Except zone radius all the parameters are similar to ZRP.

802.15.4 (Zigbee Protocol) runs in MAC layer. In the sink node or pan coordinator properties users can configure the Beacon frames and the Superframe structure

Superframe Order – It describes the length of the active portion of the Superframe, which includes the beacon frame. Range is from 0-15.
Beacon Order- Describes the interval at which coordinate shall transmit its beacon frames.Range is from 1-15.
GTS Mode (Guaranteed Time Slot) – If it is enabled it allows a device to operate on the channel within a portion of the super frame that is dedicated (on the PAN) exclusively to the device.
Battery life Extension subfield is 1 bit in length and shall be set to one if frames transmitted to the beaconing device.
Superframe Duration is divided into 16 equally sized time slots, during which data transmission is allowed. The value of super-frame duration by default is 15.36ms.
Max CSMA Backoff is the CSMA-CA algorithms will attempts before declaring a channel access failure. Having range 0-5
Minimum CAP length is the minimum number of symbols forming the Contention access period. This ensures that MAC commands can still be transferred to devices when GTSs (Guaranteed time slots) are being used.
Max and Min backoff exponent values of CSMA-CA algorithms having range 3-5. Max frame retriesis the total number of retries after failed attempts.
Unit Backoff period is the number of symbols forming the basic time period used by the CSMA-CA algorithms.

PHYSICAL LAYER
The frequency band used in NetSim WSN simulations is 2.4 GHz, and the bandwidth is 5 MHz.NetSim simulates a single channel ZigBee network and does not support multiple channels.

Data rate is the number of bits that are processed per unit of time. The data rate is fixed at 250 kbps per the 802.15.4 standard.
Chip Rate: A chip is a pulse of direct sequence spread spectrum code, so the chip rate is the rate at which the information signal bits are transmitted as pseudo random sequence of chips.
Modulation technique: O-QPSK (Offset quadrature phase shift keying) sometimes called as staggered quadrature phase shift keying is a variant of phase-shift keying modulation using 4 different values of the phase to transmit.
MinLIFSPeriod is minimum long inter frame spacing Period. It’s a time difference between short frame and long frame in unacknowledged case and time difference between short frame and acknowledged in acknowledge transmission.
SIFS (Short inter frame Symbol) is generally the time for which receiver wait before sending the CTS (Clear To Send) & acknowledgement package to sender, and sender waits after receiving CTS and before sending data to receiver. Its main purpose is to avoid any type of collision.Min SIFS period is the minimum number of symbols forming a SIFS period.
Phy SHR durationis the duration of the synchronization header (SHR) in symbol for the current PHY
Phy Symbol per Octet is number of symbols per octet for the current PHY.
Turn Around Time is transmitter to receiver or receiver to transmitter turnaround time is defined as the shortest time possible at the air interface from the trailing edge of the last chip (of the first symbol) of a transmitted PLCP protocol data unit to the leading edge of the first chip (of the first symbol) of the next received PPDU.
CCA (Clear Channel assessment) is carrier sensing mechanisms in Wireless Network. Here is the description:

• Carrier Sense Only: It shall report a busy medium only upon the detection of a signal complaint with this standard with the same modulation and spreading characteristics of the PHY that is currently in use by the device. This signal may be above or below the ED threshold.
• Energy Detection: It shall report a busy medium upon detecting any energy above the ED threshold.
• Carrier Sense with Energy Detection: It shall report a busy medium using a logical combination of detection of a signal with the modulation and spreading characteristics of this standards and Energy above the ED threshold, where the logical operator may be AND or OR.

Receiver sensitivity is the minimum magnitude of input signal required to produce a specified output signal having a specified signal-to-noise ratio, or other specified criteria. It’s up to our calculation what we want a receiver sensitivity.
Receiver ED threshold is intended for use by a network layer as part of a channel selection algorithms. It is an estimate of the received signal power within the bandwidth of the channel. No attempt is made to identify or decode signal on the channel. If the received signal power is greater than the ED threshold value, then the channel selection algorithms will return false.
Transmitter Power is the signal intensity of the transmitter. The higher the power radiated by the transmitter’s antenna the greater the reliability of the communication system. And connection medium is Wireless.
Reference Distance $(𝒅𝟎)$ is known as the reference distance and the value of $𝑑0$ is usually defined in the pathloss model or in the standard. $PL_{d0}$ is the pathloss at reference distance. In 805.15.4, the standard defines $𝑑0$ = 8𝑚 and $𝑃𝐿_{𝑑0}$ = 58.5𝑑𝐵. Please see Propagation-Model.pdf manual for more information.

POWER MODEL

• Power source can be battery or main line. This model in NetSim is used for energycalculations. In case of battery following parameters will be considered: -
• Recharging current is the current flow during recharging. Range is from 0-1mA.
• Energy Harvesting is the process by which energy is derived from external source, captured, and stored. NetSim supports an abstract Energy Harvesting model a specified amount of energy (calculated from recharging current and voltage specified) is added to the remaining energy of the node periodically to replenish the battery.
• Initial Energy is the battery energy range is from 0 to 1000mW.
• Transmitting current for transmitting the power. Range 0-20mA. Transmit power and transmit current are independent in NetSim. Since the focus of NetSim is packet simulation, the power modeling is abstract. It is left to the user to change the transmit current accordingly (when increasing/decreasing the transmit power) if the user’s goal is to study power consumption.
• Idle mode is the current flow during the ideal mode range is between 0-20mA.
• Voltage is a measure of the energy carried by the charge. Range is from 0-10V.
• Received current is the current required to receive the data having range from 0-10mA.
• Sleep mode current is current flowing in sleep mode of battery range is from 0-20mA.

Note: The resultant energy metrics and their definitions are provided in the NetSim User Manual in the Outputs section. The following table shows the properties of sensor in NetSim.

Global properties (and default settings)
Network layer
Routing protocol DSR
ACK request Enable
Max Csma BO 4
Max Backoff Exponent 5
Min Backoff Exponent 3
Max frame retries 3
Local properties (and Default settings)
Physical layer
phySHRduration(symbols) 3
Physymbolperoctet 0.4
CCA mode CARRIER_SENSE_ONLY
Reciever sensitivity(dbm) -85
ED_Threshold (dbm) -95
Transmitter power(mW) 1
Power
Power source Battery
Energy harvesting ON
Recharging current (mA) 0.4
Initial energy (mw) 1000
Transmitting current (mA) 8.8
Idle mode current (mA) 3.3
Voltage (v) 3.6
Receiving current (mA) 9.6
Sleep mode current (mA) 0.237
• Users need to connect the sensors and LoWPAN gateway using adhoc links.
• Interconnection among other devices is same as in Internetworks.
• LoWPAN gateway can be connected with router using links.
• Right click on the appropriate node or link and select Properties. Then modify the parameters according to the requirements.
• Routing Protocol in Application Layer of router and all user editable properties in DataLink Layer and Physical Layer of Access Point and Wireless Node are Global/Local i.e. changing properties in one node will automatically reflect in the others in that network.
• In Sensor Node, Routing Protocol in Network Layer and all user editable properties in DataLink Layer, Physical Layer and Power are Global/Local i.e. changing properties in one node will automatically reflect in the others in that network. The following are the main properties of sensor node in PHY and Datalink layers as shown Figure 2-9/Figure 2-10/Figure 2-11

• Set the values according to requirement and click OK.
• Click on the Application icon present on the ribbon and set properties. Multiple applications can be generated by using add button in Application properties

• Set the values according to requirement and click OK

Detailed information on Application properties is available in section 6 of NetSim User Manual

Setting Static Routes#

In Device Properties > Network layer > Configure static route IP, users can set static routes. When static routes are set the dynamic routing protocol entries are overwritten by the static routing entries. Static route configured explained in Internetworks technology library document, Section Configuring Static Routing in NetSim

Static route option is available for all sensors in WSN.

The Static routes option is not available in wireless portion of the IoT network as IoT devices work with IPv6 network addressing. The devices present in the wired portion of network say have IPv4 addressing. Hence static routes can be configured in the wired section (till the gateway) of an IoT network.

Enable Packet Trace, Event Trace & Plots (Optional)#

Click Packet Trace / Event Trace icon in the tool bar and check Enable Packet Trace / Event Trace check box and click OK. To get detailed help, please refer sections 8.4 and 8.5 in User Manual. Select Plots icon for enabling Plots and click OK.

Run Simulation#

Click on Run Simulation icon on the top toolbar.

Set the Simulation Time and click on OK.

Model Features#

L3 Routing: DSR, OLSR, ZRP and AODV#

Refer to the MANETs technology library (PDF) document for detailed information. Note that:

• WSN supports DSR, OLSR, ZRP and AODV protocols
• IOT supports AODV and RPL protocol, since only AODV and RPL have IPv6 support in NetSim

L3 Routing: RPL Protocol#

Routing Protocol for Low power and Lossy Networks (RPL) Overview
Low-power and Lossy Networks consist largely of constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated). These routers are interconnected by lossy links, typically supporting only low data rates that are usually unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply point-to-point, but in many cases point-to-multipoint or multipoint-to point.
RPL Routing Protocol works in the Network Layer and uses IPv6 addressing. It runs a distance vector routing protocol based on Destination Oriented Directed Acyclic Graph (DODAGs).

Terminology of RPL routing protocol:

• DAG (Directed Acyclic Graph): A directed graph having the property that all edges are oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes.
• DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition, all DAGs must have at least one DAG root and all paths terminate at a DAG root. In NetSim, only single root is possible. i.e. the 6LowPAN Gateway
• Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root (the DODAG root) with no outgoing edges.
• Up: Up refers to the direction from leaf nodes towards DODAG roots, following DODAG edges. This follows the common terminology used in graphs and depth-first search, where vertices further from the root are "deeper" or "down" and vertices closer to the root are "shallower" or "up"
• Down: Down refers to the direction from DODAG roots towards leaf nodes, in the reverse direction of DODAG edges. This follows the common terminology used in graphs and depth-first search, where vertices further from the root are "deeper" or "down" and vertices closer to the root are "shallower" or "up"
• Rank:A node's Rank defines the node's individual position relative to other nodes with respect to a DODAG root. Rank strictly increases in the Down direction and strictly decreases in the Up direction.
• RPLInstanceID: An RPL Instance ID is a unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function
• RPL instance: When we have one or more DODAG, then each DODAG is an instance. An RPL Node may belong to multiple RPL Instances, and it may act as router in some and as a leaf in others. Any sensor can be configured as a Router or Leaf. Leaf nodes does not take part in RPL routing.
• DODAG ID: Each DODAG has an IPV6 ID. This ID is given to its root only. And as the root doesn’t change ID also don’t change
• Objective Function (OF): An OF defines how routing metrics, optimization objectives, and related functions are used to compute Rank. Furthermore, the OF dictates how parents in the DODAG are selected and, thus, the DODAG formation.

RPL Objective Function#

The objective function in NetSim RPL seeks to find the route with the best link quality. The objective function: static UINT16 compute_candidate_rank(NETSIM_ID d, PRPL_NEIGHBOR neighbour) can be found in Neighbor.c under the RPL project.
Link quality calculations, available in Zigbee Project 802.15.4 c file in function get_link_quality(). $$𝐿𝑞 = (1 − (\frac{p}{rs}))$$ where p = Received power (dBm) and rs = Receiver sensitivity(dBm) And Final $$Link quality = \frac{Sending Quality+Receiving Quality}{2}$$ The rank calculations are done in Neighbour.c in RPL project and is. $$Rank = (Max_{increment}-min_{increment})\times(1-L_q)^2+Min_{Increment}$$ The link quality in this case is based on received power and can be modified by the user to factor in distance, delay etc, Link quality is calculated by making calls to the functions in the following order:

1. compute_candidate_rank() – RPL \Neighbor.c
2. fn_NetSim_stack_get_link_quality() - NetSim network stack which in turn calls
3. zigbee_get_link_quality() – ZigBee \802_15_4.c

The function fn_NetSim_stack_get_link_quality() is part of NetSim's network stack which is closed to user. However the function zigbee_get_link_quality() is open to the users and can be modified if required

Topology Construction#

NetSim IOT WSNs do not typically have predefined topologies, for example, those imposed by point-to-point wires, so RPL has to discover links and then select peers sparingly. RPL routes are optimized for traffic to or from one or more roots that act as sinks for the topology. As a result, RPL organizes a topology as a Directed Acyclic Graph (DAG) that is partitioned into one or more Destination Oriented DAGs (DODAGs), one DODAG per sink

RPL identifiers: RPL uses four values to identify and maintain a topology:

• The first is an RPLInstanceID. An RPLInstanceID identifies a set of one or more Destination Oriented DAGs (DODAGs). A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different Objective Functions (OFs) and/or applications. The set of DODAGs identified by an RPLInstanceID is called a RPL Instance. All DODAGs in the same RPL Instance use the same OF
• The second is a DODAGID. The scope of a DODAGID is a RPL Instance. The combination of RPLInstanceID and DODAGID uniquely identifies a single DODAG in the network. A RPL Instance may have multiple DODAGs, each of which has a unique DODAGID.
• The third is a DODAGVersionNumber. The scope of a DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed from the DODAG root, by incrementing the DODAGVersionNumber. The combination of RPLInstanceID, DODAGID, and DODAGVersionNumber uniquely identifies a DODAG Version.
• The fourth is Rank. The scope of Rank is a DODAG Version. Rank establishes a partial order over a DODAG Version, defining individual node positions with respect to the DODAG root.

DIS (DODAG Information Solicitation) transmission:

Root sends DIS message to the Router/Leaf which are in range. The Router in turn broadcasts its further and so on.
DIO (DODAG Information Object) transmission:
RPL nodes transmit DIOs using a Trickle Timer. This message is multicasted downwards in a DODAG. With DIO child parent relationship and sibling relationship is established. DODAG Construction

• Nodes periodically send link-local multicast DIO messages.
• Stability or detection of routing inconsistencies influence the rate of DIO messages.
• Nodes listen for DIOs and use their information to join a new DODAG, or to maintain an existing DODAG.
• Nodes may use a DIS message to solicit a DIO as shown below.
• Rank is then established. Rank is decided based on the DIS message received from the Root and the link quality.
• Based on information in the DIOs the node chooses parents to the DODAG root
• As a Result, the nodes follow the upward routes towards the DODAG root.
• If the destination is unreachable then the root will drop the packet.
• Note that DIS messages are sent by the sensors which are not part of the DODAG. The sensors which are part of the DODAG and which received the DIO message will send the\DAO message in return, whereas the sensors which did not receive the DIO messages will send the DIS message.

RPL Log File#

Once simulation is completed, users can access the rpl_log file from the results dashboard as shown below Figure
However, to get detailed information related to Rank Calculations the DEBUG_RPL preprocessor directive needs to be uncommented in the code

Procedure to get the RPL log file:

• Click on Workspace Options and then click on Open Code and open the codes in Visual Studio. Set x86 or x64 according to the NetSim build which you are using.
• 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:
• Right click on the RPL project in the solution explorer and click on rebuild.
• After the RPL project is rebuild successful, go back to the network scenario.

Now after any IoT-RPL simulation, an RPL log file is generated with detailed information about the DODAG formation. An example rpl_log file is shown below Figure

Explanation of the log file: Step 1:

• Node 5 receives a DIO msg from Node 6 (i.e., root).
• Node 5 finds the DODAG id.
• Based on the DIO message received from Node 6, Node 5 choses its “Parent as Node 6” and establishes its “New Rank = 17”. It does not have any siblings.

Step 2:

• Node 1 receives a DIO msg from Node 6 (i.e. root).
• Node 1 finds the DODAG id.
• Based on the DIO message received from Node 6, Node 1 choses its “Parent as Node 6” and establishes its “New Rank = 17”. It does not have any siblings.

Step 3:

• Node 6 receives as DAO message from Node 1 with the new route information about the destination and the Gateway.

Step 4:

• Node 2 receives a DIO msg from Node 1 (i.e. Sensor which is configured as Router).
• Node 2 finds the DODAG id.
• Based on the DIO message received from Node 1, Node 2 choses its “Parent as Node 1” and establishes its “New Rank = 33” since it is in the next Rank level. It does not haveany siblings.

Likewise, DODAG formation throughout the simulation is logged inside the rpl_log file

Viewing RPL control messages in Wireshark#

Wireshark option can be enabled in the ZigBee devices to capture network traffic during the simulation. RPL control messages such as DAO, DIO etc. can be seen in Wireshark as shown below Figure

Following is a screenshot of a DIO message where the Rank information is highlighted as shown Figure

MAC / PHY: 802.15.4 Overview#

IEEE802.15/TG4 formulated the IEEE802.15.4 for low-rate wireless personal area network, i.e.,LR-WPAN. The standard gives priority to low-power, low-rate and low-cost.

In NetSim, the WSN part of the IOT Network runs 802.15.4 in MAC and PHY. The features implemented are:
Superframe

• Beacon enabled and beacon disabled mode.
• In beacon enabled mode NetSim supports slotted CSMA/CA with Active & Inactive Period (controlled by Beacon order and super-frame order parameters)
• GTS is not implemented.

Data Transfer Model

• Device to coordinator, coordinator to device and device to device (peer to peer topology)
• AckRequestFlag: If set the device acknowledges successful reception of the data frame by transmitting an ack frames

Frames

• Beacon
• Data
• Acknowledgement

CSMA / CA Mechanism

• Non-beacon mode uses unslotted CSMA/CA.
• Beacon mode uses slotted CSMA/CA.

Energy Model

• Energy sources: Main Line and Battery
• Energy Harvesting which uses recharging current to replenish battery energy.
• Consumption Modes: Transmit, Receive, Idle and Sleep

CSMA/CA Implementation in NetSim#

• In both Slotted and Unslotted CSMA/CA cases, the CSMA/CA algorithm is based on backoff periods, where one backoff period is equal to aUnitBackoffPeriod which is 20 symbols long.
• This is the basic time unit of the MAC protocol and the access to the channel can only occur at the boundary of the backoff periods. In slotted CSMA/CA the backoff period boundaries must be aligned with the super-frame slot boundaries whereas in unslotted CSMA/CA the backoff periods of one device are completely independent of the backoff periods of any other device in a PAN.
• The CSMA/CA mechanism uses three variables to schedule the access to the medium:

• NB is the number of times the CSMA/CA algorithm was required to backoff while attempting the access to the current channel. This value is initialized to zero before each new transmission attempt.
• CW is the contention windows length, which defines the number of backoff periods that need to be clear of channelactivity before starting transmission. CW is only used with the slotted CSMA/CA. This value is initialized to 2 before each transmission attempt and reset to 2 each time the channel is assessed to be busy.
• BE is the backoff exponent, which is related to how many backoff periods a device must wait before attempting to assess the channel activity.
• In beacon-enabled mode, each node employs two system parameters: $Beacon order (BO)$ and $Superframe Order (SO).$

• The parameter BO decides the length of beacon interval (BI), where $$𝐵𝐼=𝑎𝐵𝑎𝑠𝑒𝑆𝑢𝑝𝑒𝑟𝑓𝑟𝑎𝑚𝑒𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛\times2𝐵𝑂 symbols \ and \ \quad 0 ≤ 𝐵𝑂 ≤ 14;$$
while the parameter $SO$ decides the length of $superframe duration (SD)$,where $$𝑆𝐷 = 𝑎𝐵𝑎𝑠𝑒𝑆𝑢𝑝𝑒𝑟𝑓𝑟𝑎𝑚𝑒𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 × 2𝑆𝑂symbols \ and \ \quad 0 ≤ 𝑆𝑂 ≤ 𝐵𝑂 ≤ 14.$$
• The value of aBaseSuperframeDuration is fixed to 960 symbols. The format of the superframe is defined as shown in the following figure:

• Furthermore, the active portion of each Superframe consists of three parts: beacon, CAP, and CFP, which is divided into 16 equal length slots. The length of one slot is equal to $𝑎𝐵𝑎𝑠𝑒𝑆𝑙𝑜𝑡𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 × 2𝑆𝑂 symbols$, where $aBaseSlotDuration$ is equal to 60 symbols.

• In CAP, each node performs the CSMA/CA algorithm before transmitting data packet or control frame. Each node maintains three parameters: the number of backoffs (NB), contention window (CW), and backoff exponent (BE).
• The initial values of NB, CW, and BE are equal to 0, 2, and Min Backoff Expo, respectively, where $Min Backoff Expo$ is by default 3 and it can be set up to 8.
• For every backoff period, node takes a delay for random backoff between 0 and $2^{𝐵𝐸} − 1$ Unit backoff Time (UBT), where UBT is equal to 20 symbols (or 80 bits).
• A node performs clear channel assessment (CCA) to make sure whether the channel is idle or busy, when the number of random backoff periods is decreased to 0.
• The value of CW will be decreased by one if the channel is idle; and the second CCA will be performed if the value of CW is not equal to 0. If the value of CW is equal to 0, it means that the channel is idle; then the node starts data transmission.
• However, if the CCA is busy, the value of CW will be reset to 2; the value of NB is increased by 1; and the value of BE is increased by 1 up to the $maximum BE (Max Backoff Expo)$, where the value $Max Back off Expo$ is by default 5 and can be up to 8.
• The node will repeatedly take random delay if the value of NB is less than the value of Max CSMA BO $(macMaxCSMABackoff)$, where the value of Max CSMA BO is equal to 4; and the transmission attempt fails if the value of NB is greater than the value of Max CSMA BO.

Beacon Order and Super Framer Order#

Beacon frame is one of the management frames in IEEE 802.15.4 based WSNs and contains all the information about the network. A coordinator in a PAN can optionally bound its channel time using a Superframe structure which is bound by beacon frames and can have an active portion and an inactive portion. The coordinator enters a low-power (sleep) mode during the inactive portion.

The structure of this Superframe is described by the values of macBeaconOrder and macSuperframeOrder. The MAC PIB attribute macBeaconOrder, describes the interval at which the coordinator shall transmit its beacon frames. The value of macBeaconOrder, BO, and the beacon interval, BI, are related as follows: $$For \ 0 ≤ 𝐵𝑂 ≤ 14, 𝐵𝐼 = 𝑎𝐵𝑎𝑠𝑒𝑆𝑢𝑝𝑒𝑟𝑓𝑟𝑎𝑚𝑒𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 × 2𝐵𝑂 \ symbols$$

If BO = 15, the coordinator shall not transmit beacon frames except when requested to do so, such as on receipt of a beacon request command. The value of macSuperframeOrder, SO shall be ignored if BO = 15.

If SuperFrame Order (SO) is same as Beacon Order (BO) then there will be no inactive period and the entire SuperFrame can be used for packet transmissions. If BO=10, SO=9 half of the Superframe is inactive and so only half of Superframe duration is available for packet transmission. If BO=10, SO=8 then $(\frac{3}{4})^{th}$ of the Superframe is inactive and so nodes have only$(\frac{1}{4})^{th}$of the Superframe time for transmitting packets

Energy Models: Sources, Consumption and Harvesting#

Wireless nodes, especially sensors, possess limited processing capability, storage and energy resources. The life of the sensor nodes i.e., the energy consumption during its operation, is critical to the network performance. Therefore, researchers often need to study energy consumption at the devices and in the network.

NetSim has a dedicated energy models at sensor nodes (WSN/IoT networks) for modelling energy sources, energy consumption and energy harvesting.

The power model is user configurable and can be found in the ZigBee Interface properties of the Sensor nodes as shown below Figure. The default settings are as per Reference document 1.

The power source represents the source of energy. Each node has its own single source of power. Main line power source is assumed to have infinite energy while batteries have limited initial energy. When energy harvesting is turned on, it replenishes the battery energy. If the power of a node is completely depleted the node can no longer operate.

The different currents used in the Sensor Battery model calculations are:

• TransmitCurrent
• IdleModeCurrent
• SleepModeCurrent The energy consumed in each of these activities would be. $$𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝐸𝑛𝑒𝑟𝑔𝑦 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ∗ 𝑇𝑖𝑚𝑒 (𝑓𝑜𝑟\ 𝑤ℎ𝑖𝑐ℎ \ 𝑛𝑜𝑑𝑒 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑠 \ 𝑝𝑎𝑐𝑘𝑒𝑡𝑠)$$

$$𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝐸𝑛𝑒𝑟𝑔𝑦 = 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ∗ 𝑇𝑖𝑚𝑒 (𝑓𝑜𝑟 \ 𝑤ℎ𝑖𝑐ℎ\ 𝑛𝑜𝑑𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑠 \ 𝑝𝑎𝑐𝑘𝑒𝑡𝑠)$$ $$𝐼𝑑𝑙𝑒𝑀𝑜𝑑𝑒𝐸𝑛𝑒𝑟𝑔𝑦 = 𝐼𝑑𝑙𝑒𝑀𝑜𝑑𝑒𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ∗ 𝑇𝑖𝑚𝑒 (𝑖𝑛\ 𝐼𝑑𝑙𝑒\ 𝑚𝑜𝑑𝑒)$$

$$𝑆𝑙𝑒𝑒𝑝𝑀𝑜𝑑𝑒𝐸𝑛𝑒𝑟𝑔𝑦 = 𝑆𝑙𝑒𝑒𝑝𝑀𝑜𝑑𝑒𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ∗ 𝑇𝑖𝑚𝑒 (𝑖𝑛 𝑠𝑙𝑒𝑒𝑝 𝑚𝑜𝑑𝑒)$$ $$𝑇𝑜𝑡𝑎𝑙𝐸𝑛𝑒𝑟𝑔𝑦 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝐸𝑛𝑒𝑟𝑔𝑦 + 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝐸𝑛𝑒𝑟𝑔𝑦 +𝐼𝑑𝑙𝑒𝑀𝑜𝑑𝑒𝐸𝑛𝑒𝑟𝑔𝑦 + 𝑆𝑙𝑒𝑒𝑝𝑀𝑜𝑑𝑒𝐸𝑛𝑒𝑟𝑔𝑦$$ NetSim also has an Energy-Harvesting Model which is modelled as $$𝐸𝑛𝑒𝑟𝑔𝑦𝐻𝑎𝑟𝑣𝑒𝑠𝑡𝑒𝑑 = 𝑅𝑒𝑐ℎ𝑎𝑟𝑔𝑖𝑛𝑔𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ∗ 𝑇𝑖𝑚𝑒$$ Hence, $$𝐵𝑎𝑡𝑡𝑒𝑟𝑦𝐸𝑛𝑒𝑟𝑔𝑦 (𝑎𝑡 𝑎𝑛𝑦 𝑡𝑖𝑚𝑒) = 𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝐸𝑛𝑒𝑟𝑔𝑦 − 𝑇𝑜𝑡𝑎𝑙𝐸𝑛𝑒𝑟𝑔𝑦𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑑 + 𝐸𝑛𝑒𝑟𝑔𝑦𝐻𝑎𝑟𝑣𝑒𝑠𝑡𝑒𝑑$$ Energy consumption is calculated individually for each sensor node that is part of the network scenario. The sensors have various Radio States such as SLEEP, TRX_ON_BUSY, RX_ON_IDLE, RX_ON_BUSY, RX_OFF. As explained in the formulas above the energy consumed is proportional to the time for which the node is a particular state. For example, the time for which a node transmits a packet is equal to the time for which the node is in TRX_ON_BUSY state. This duration in turn depends on the protocol operation. Thus, the corelation between protocol operation and energy consumption.

The units in NetSim for current is mA, for Voltage is V and for Total-Energy-Consumed is 𝑚𝐽. The Unit for Initial-Energy is 𝑚𝐴𝐻 and this is converted to 𝑚𝐽 for calculations since the output metrics are in 𝑚𝐽. The Initial energy in 𝑚𝐴𝐻 is converted to 𝑚𝐽 using the formula: $$𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝐸𝑛𝑒𝑟𝑔𝑦 (𝑚𝐽) = 𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝐸𝑛𝑒𝑟𝑔𝑦 (𝑚𝐴𝐻) ∗ 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 (𝑉) ∗ 3600$$ For example, if we set $𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝑒𝑛𝑒𝑟𝑔𝑦 = 0.5𝑚𝐴𝐻$, and if the voltage in 1V then $$𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝐸𝑛𝑒𝑟𝑔𝑦 (𝑚𝐽) = 1 ∗ (0.5 × 3600) = 1800𝑚𝐽$$ Post simulation NetSim outputs an Energy Metrics table which provides energy consumption of each device with respect to Transmission, Reception, Idle Mode, and Sleep Mode as shown below Figure.

Energy Model source code#

The Energy consumed by the sensor devices are computed in the function battery_set_mode() present in the BatteryModel.c file which belongs to the BatteryModel project. This is called in the function fn_NetSim_Zigbee_ChangeRadioState() present in the ChangeRadioState.c file which belongs to ZigBee project. The protocol operations decide the time for which the radio is in a particular state. The energy calculation function then multiples this time by the current drawn and the voltage.

Users can implement energy aware protocols by accessing the information such as remaining energy of each node, when modifying the source code.

Sensor Application and how to model sensing interval?#

Agents and sensing range were used in earlier versions (before v11) of NetSim as an abstraction of physical phenomenon to trigger packet generation in the sensor nodes respectively. Sensor nodes generate packets whenever they sense an agent within the sensor range. From NetSim v11 onwards users have the facility to configure traffic in the sensor network using the application as shown Figure

In the application properties, the size of the packet can be set under packet size and the Inter_arrival time can be thought of as sensor interval.

Users can now configure traffic between sensor and sink node as well as between the sensor nodes.
Note that Agents, sensor interval, sensor range are deprecated in NetSim v11.

WSN/IOT File Based Placement#

File based placement, as the name suggests is an option that can be used to place devices in user defined locations based on the text file which is provided as the input.

Why do we need File Based Placement?

• File Based Placement gives completely a user-defined approach for device placementsduring the process of Network design.
• This feature allows the user to design a large network scenario comprising of various devices with ease.
• It allows device placements with precision and so on. Create a text file as per the following or use the file present in the Docs folder of NetSim Install Directory < C:\Program Files\NetSim Standard\Docs\Sample_Configuration\IOT>

Internet of Things#

The text file that we give as an input can be saved as follows: IOT_File_Based_Placement.txt
The general format to be followed while creating an IOT_File_Based_Placement.txt for all the devices used in it is given below:

<DEVICE_NAME>,<DEVICE_TYPE>,<X>,<Y>

where,
DEVICE_NAME represents the name of the device and can be user defined.
DEVICE_TYPE represents the type of device, and this info can be obtained from the "General Properties" of that particular device. X represents the X_Coordinate position of the device upon the grid.
Y represents the Y_Coordinate position of the device upon the grid.
Note: Once after we give a file-based input for device placement, an ad-hoc link will automatically be established connecting all the devices pertaining to it. And users need to manually connect the remaining devices using the Wired/Wireless links.

Must the IOT text file contain only IOT devices?
The IOT txt file can include all the devices that are present in the top ribbon/toolbar when we select Internet of Things from the home screen. This varies based on the network type. For e.g. WSN and MANETs network types support different devices comparatively.

IOT_File_based_placement.txt
Wireless_Sensor,IOT_Sensors,0,0
Wireless_Sensor,IOT_Sensors,10,10
Wireless_Sensor,IOT_Sensors,20,20
Wireless_Sensor,IOT_Sensors,30,30
Wireless_Sensor,IOT_Sensors,40,20
Low_Pan_Gateway,LOWPAN_Gateway,50,10
Router,IOT_ROUTER,60,20
Wired_Node,WIREDNODE,70,20

Open NetSim and click New Simulation $\rightarrow$ Internet Of Things. In the Fast Config window,
Choose the File Based Placement option under Automatic Placement and give the path of thetext file as shown below Figure

After giving the path, Click on OK. It will display the IOT network as shown below, where all devices are placed as per the positions given in the text file.

Wireless Sensor Networks#

Create a text file as per the following or use the file present in the Docs folder of NetSim Install Directory < C:\Program Files\NetSim Standard\Docs\Sample_Configuration\WSN>

WSN_File_based_placement.txt
Wireless_Sensor,Sensors,5,5
Wireless_Sensor,Sensors,10,10
Wireless_Sensor,Sensors,20,10
Wireless_Sensor,Sensors,5,10
WSN_Sink,SinkNode,10,15

Open NetSim and click New Simulation $\rightarrow$ Wireless Sensor Networks. Select File Based Placement option under Automatic Placement and give the path of the text file as shown below Figure

After giving the path, Click on OK. It will display the WSN network as shown below, where all devices are placed as per the positions given in the text file.

Model Limitations#

• NetSim currently supports only single root in RPL.
• NetSim GUI supports only one RPL instance. Multiple RPL instance can be created by manually editing the config file.
• DODAG Repair is not supported
• Nodes (sensors) in the NetSim retrieve time from the same (single) virtual clock that ticks virtual time within NetSim. As such, they can be considered as perfectly time synchronized. Real world clocks drift from a reference clock due to various reasons (heat, deficient oscillator, etc.,), resulting in an offset of a few milliseconds per day. In the COTS version of NetSim, clock drift is not available. This means that it is not possible to model clocks to run with different rates and/or offsets, in different nodes/sensors.
• Security in 802.15.4 is not implemented

IOT-WSN Experiments in NetSim#

Apart from examples, in-built experiments are also available in NetSim. Examples help the user understand the working of features in NetSim. Experiments are designed to help the user (usually students) learn networking concepts through simulation. The experiments contain objective, theory, set-up, results, and inference. The following experiments are available in the Experiments manual (pdf file).

Reference Documents#

[1] O. Landsiedel, K. Wehrle and S. Gotz, "Accurate Prediction of Power Consumption in Sensor Networks. University of Tubingen, Germany," 2005.
[2] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur and R. Alexander, "IETF RFC 6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks".
[3] "IEEE Standard 802.15.4-2011: Low-Rate Wireless Personal Area Networks (LR-WPANs)".

Latest FAQs#

Up to date FAQs on NetSim’s IoT/ WSN library is available at
https://tetcos.freshdesk.com/support/solutions/folders/14000105117