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.

Graphical user interface Description automatically generated

Figure 1‑1: A typical IOT scenario in NetSim

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

Graphical user interface, application, table, Excel Description automatically generated

Figure 1‑2: The Result dashboard and Plot window shown in NetSim after completion of simulation

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.

Figure 1‑3: A typical application scenario that can be modeled in NetSim. Sensors can generate (measurement) packets that get queued in its packet buffer. These are then transmitted - directly or via hops - over a wireless link to a gateway that then forwards the packet via the internet to a server. Wireless links support various propagation models and ad hoc routing is supported for multi-hop communication. The MAC/PHY layer protocol supported is 802.15.4.

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 Wireless Sensor Networks as shown Figure 2‑1.

Graphical user interface, application Description automatically generated

Figure 2‑1: NetSim Home Screen

Create Scenario#

Fast Configuration#

Figure 2‑2: Fast Configuration window

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 parameters associated 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: 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

  2. BRIDGE_WIREDNODE

  3. BRIDGE_WIRELESSNODE

  4. WIREDNODE

  5. ROUTER

  6. 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

Table 2‑1: Fast Configuration window support different networks

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 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, Ad hoc link are used to connect the Sensors 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.

Figure 2‑3: Network layout of a WSN. The sensors communication with each other and to the sink via an “Adhoc 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.

Figure 2‑4: Internet of Things

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 internetworks (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.

Table 2‑2: Differences between IoT and WSN in NetSim

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).

Figure 2‑5: General Properties window for Sensor

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.

Figure 2‑6: Network Layer Properties Window - DSR Protocol

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.

Figure 2‑7: Network Layer Properties Window - ZRP Protocol

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.

DATALINK LAYER

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.

Figure 2‑8: Datalink layer properties window for sinknode

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 retries is 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 duration is 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 (d0) is known as the reference distance and the value of d0 is usually defined in the pathloss model or in the standard. PLdo is the pathloss at reference distance. In 805.15.4, the standard defines d0 = 8m and PLd0 = 58.5 dB. 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 energy calculations. 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 _Type LINK_LAYER_ACK
Data link layer
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) 0.5
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

Table 2‑3: MAC and PHY layer properties of sensor

  • 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.

Graphical user interface Description automatically generated

Figure 2‑9: Datalink layer properties window for sensor

Figure 2‑10: PHY layer properties window for sensor

Figure 2‑11: Battery Model for Sensor

  • 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.

Figure 2‑12: Application icon present on top ribbon

  • Set the values according to requirement and click OK.

Figure 2‑13: Application Configuration window

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.

Figure 2‑14: Static Route configuration window

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.

Graphical user interface, application Description automatically generated

Figure 2‑15: Enable Packet Trace, Event Trace & Plots options on top ribbon

Run Simulation#

Click on Run Simulation icon on the top toolbar.

Graphical user interface, application Description automatically generated

Figure 2‑16: Run Simulation options on top ribbon

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().

$$L_{q} = \left( 1 - \left( \frac{p}{rs} \right)\ \right)\ $$

where p = Received power (dBm) and rs = Receiver sensitivity (dBm)

And Final  

$$Link\ Quality = \frac{Sending\ Link\ Quality + Receving\ Link\ Quality}{2}$$

The rank calculations are done in Neighbour.c in RPL project and is.

Rank = (MaxincrementMinincrement) × (1−Lq)2 + Minincrement

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.

Figure 3‑1: Exchange DIO/DIS Control message for Sensor and Lowpan gateway

  • 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 3‑2.

Graphical user interface, application, table, Excel Description automatically generated

Figure 3‑2: Results dashboard window

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:

  • Go to NetSim Home page and click on Your work.

  • 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:

Figure 3‑3: Visual Studio

  • 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 3‑4.

Figure 3‑4: RPL Log file

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.

Figure 3‑5: Node 5 choses its “Parent as Node 6 - New Rank = 17

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.

Figure 3‑6: Node 1 choses its “Parent as Node 6 - New Rank = 17

Step 3:

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

Figure 3‑7: Node 6 receives as DAO message from Node 1

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 have any siblings.

Figure 3‑8: Node 2 choses its “Parent as Node 6 - New Rank = 33

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 3‑9.

Graphical user interface, application, table, Excel Description automatically generated

Figure 3‑9: Wireshark captures RPL control messages such as DAO, DIO etc.

Following is a screenshot of a DIO message where the Rank information is highlighted as shown Figure 3‑10.

Figure 3‑10: DIO message with Rank information in Wireshark

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:

  • PHY rate is fixed at 250 Kbps; it does not vary per the received SNR.

  • Receive sensitivity is a GUI parameter modifiable by users; the default value is -85 dBm

  • 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 frame.

  • 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 channel activity 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 > BI= aBaseSuperframeDuration × 2BO > symbols and 0 ≤ BO ≤ 14; while the parameter SO decides the > length of superframe duration (SD),

where SD = aBaseSuperframeDuration × 2SO symbols and 0 ≤ SO ≤ BO ≤ 14.

  • The value of aBaseSuperframeDuration is fixed to 960 symbols. The > format of the superframe is defined as shown in the following > figure:

ㇽ瞕콒쉁

Figure 3‑11: The format of the Superframe structure

  • 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 aBaseSlotDuration × 2SO 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 2BE − 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 > Backoff 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 ≤ BO ≤ 14, BI = aBaseSuperframeDuration × 2BO 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 $\left( \frac{3}{4} \right)^{th}$ of the Superframe is inactive and so nodes have only $\left( \frac{1}{4} \right)^{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 3‑12. The default settings are as per Reference document [1].

Figure 3‑12: Power model properties window

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

  • ReceiveCurrent

  • IdleModeCurrent

  • SleepModeCurrent

The energy consumed in each of these activities would be.

TransmitEnergy = TransmitCurrent× Voltage× Time (for which node transmits packets)

ReceiveEnergy = ReceiveCurrent × Voltage× Time  (for which node receives packets)

IdleModeEnergy = IdleModeCurrent × Voltage× Time (in Idle mode)

SleepModeEnergy = SleepModeCurrent × Voltage× Time (in sleep mode)

TotalEnergy = TransmitEnergy + ReceiveEnergy  + IdleModeEnergy + SleepModeEnergy

NetSim also has an Energy-Harvesting Model which is modelled as

EnergyHarvested = RechargingCurrent× Voltage× Time

Hence,

BatteryEnergy (at any time) = InitialEnergy − TotalEnergyConsumed + EnergyHarvested

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 mJ. The Unit for Initial-Energy is mAH and this is converted to mJ for calculations since the output metrics are in mJ. The Initial energy in mAH is converted to mJ using the formula:

Initial Energy (mJ)= Initial Energy (mAH)× Voltage (V)× 3600

For example, if we set Initial energy = 0.5mAH, and if the voltage in 1V then Initial Energy (mJ)= 1 × (0.5×3600) = 1800mJ

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 3‑13.

Table Description automatically generated

Figure 3‑13: Battery model Table in result window showing various categories of energy consumption for each device. The categories are Initial energy, consumed energy, remaining energy, transmitting energy, receiving energy, idle energy and sleep energy.

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 3‑14.

Figure 3‑14: Application window

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 placements during 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 Internet Of Things. In the Fast Config window, Choose the File Based Placement option under Automatic Placement and give the path of the text file as shown below Figure 3‑15.

Figure 3‑15: Device placement Strategy to File based Placement in IOT

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.

Figure 3‑16: Network Topology in IOT

Connect Low_Pan_Gateway to Router and Router to Wired node. Configure application and run simulation.

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 Wireless Sensor Networks. Select File Based Placement option under Automatic Placement and give the path of the text file as shown below Figure 3‑17.

Figure 3‑17: Device placement Strategy to File based Placement in WSN

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.

Figure 3‑18: Network Topology in WSN

Note: Please refer section “2.1 Fast configuration” for more information.

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).

  1. Cyber physical systems (CPS) and IoT – An Introduction

  2. One Hop IoT Network over IEEE 802.15.4

  3. IoT – Multi-Hop Sensor-Sink Path

  4. Performance Evaluation of a Star Topology IoT Network

  5. Study the 802.15.4 Superframe Structure and analyze the effect of Superframe order on throughput.

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