Amazing technological breakthrough possible @S-Logix
#5, First Floor, 4th Street
Dr. Subbarayan Nagar
Kodambakkam, Chennai-600 024
Landmark : Samiyar Madam
+91- 81240 01111
Contiki Cooja Simulator Source Code for Internet of Things (IoT) Projects
Tutorials for Contiki Cooja Simulator with Source Code for IoT Project Development
• The Internet of Things (IoT) represents interconnected smart devices that can transfer data over a network without human interaction.
• An IoT needs Operating System (OS) for its specific demands and specifications and it is crucial for network connectivity, security, management, storage, memory processing, and other IoT system needs.
• Contiki is an operating system for IoT, and it is specially designed to support small IoT devices with limited memory, bandwidth, and processing power.
• It explores minimalist design without missing important tools and protocols of modern operating systems.
• The base libraries are available in C programs which can be customized for Cooja simulator to enable the simulation of different network protocols and simulation models.
• IoT devices can be programmed, controlled, and monitored by modifying the back-end C programming files. The related header files can be identified, customized, and recompiled to get the appropriate network models and validate the desired results.
• Contiki offers good support for IPv4 as well as IPv6 networking protocols to integrate lightweight IoT routing and application layer protocols.
Working with Contiki Cooja Simulator for Creating the IoT Network Scenarios
• A user should click on File to start the new simulation on Cooja.
• It will show a new screen, and the initial simulation screen is opened by clicking the Create button.
• The simulation nodes are appended by clicking on Motes, Add motes, and Create a new mote.
• There are several motes in Cooja.The Sky mote is simple and widely used for IoT and provides initial configurations for IoT nodes, including sink and sensor nodes within a Cooja simulation.
• When Clicking the Create button, a box shall appear, and next, while clicking on Add motes, the mote is added. This process should be repeated for both Sink and Sensor nodes.
Options and Settings Available on the Cooja Simulator to Run the IoT Network Model
Network:The location of all wireless sensor (WSN) nodes can be seen in the network tool window. It is mainly meant for visualization purposes and to position the nodes. It will stay empty initially, but once we start loading nodes, we can see them in the network tool window. We can also see individual sensor transmission and detection ranges by enabling the radio environment features.
Simulation Control:It is used to Start, Stop or Reload any simulation. It also shows the Speed index of the simulation. A rule of thumb is higher the number of nodes, and the simulation will run slower. The simulation can also be completely reloaded by fusing the simulation control window.
Mote output:It shows detail of the Mote traced for every second. The network log files include the source, destination motes, and time. It helps to analyze overall activities performed during simulation. It assists the researchers in making fine-grained analyses of IoT implementation.
Timeline:The Timeline window helps to show the events over a period of time. The list of available events can be filtered using the drop-down menu, and the output can be saved to a file.
Radio messages:Log of radio messages and packets as they are generated. The generated data can be saved as a .pcap file so that we can debug the messages in Wireshark later.
Script editor: Developers can add their custom scripts which will interact or collect data from Motes and give advanced analytic data of the simulations.
Mote radio duty cycle (Powertrace):It is used to check the Mote-wise sleep cycle percentage (%) separated by transmission(Tx) time and Reception(Rx) Time and their average values.
Breakpoints: It sets up breakpoints in simulations to debug issues.
Step by Step Procedure for Working with Script Editor and Sensor Collect on Contiki Cooja Simulator
• Simulation Script Editor has to be clicked to start the script editor within Cooja.
• The Script Editor assists in displaying the messages and setting a timer on the simulation.
• After selecting the ‘File’ drop-down menu, ‘Load example script’ should be clicked.
• Timeout time can be adjusted, and this change is effective only when the ‘Run’ drop-down menu is clicked and ‘Activate’ is selected.
• The script cannot be changed until the same process is repeated. Moreover, Cooja explores different tools for data collection from motes, and the data collection can be enabled from the viewpoint of the sink.
• All the Script Editor and Sensor Data Collect actions are stored using the ‘File’ dropdown menu. Once the simulation is complete, a large amount of data is available from the Sensor Collect View. Finally, it helps in implementing and analyzing IoT traffic
Standard Protocols Supported by Contiki Cooja Simulator for IoT Projects
The software package contains UNIX style shell for OS interface and debugging. A network can be implemented with a package of different layers and corresponding protocols. Various OSI layers are given along with their protocols. • Application Layer (COAP, MQTT) • Transport Layer (TCP, UDP, DTLS, TLS) • Network Layer (RPL) • MAC and Adaptation Layer (IEEE 802.15.4, IETF 6TiSCH, and 6LoWPAN)
Contiki Cooja Simulator Exercise with Source Code for IoT
Contiki Cooja Simulator Support for MAC and Adaptation Layer in IoT
The Medium Access Layer (MAC) layer is present in the data link layer. It is responsible for identifying and correcting the errors that may occur during data transmission. Moreover, it helps in offering a collision-free transmission of frames using various protocols like IEEE 802.15.4 and the IETF 6TiSCH.
IEEE 802.15.4: Initially, IEEE 802.15.4 is developed to satisfy the requirements of Low Rate Wireless Personal Area Networks (WPANs). The IEEE 802.15.4 has a maximum transmission rate of 250 Kb/s and a maximum transmission unit of 127 bytes. However, the upper-layer protocol allows only up to 116 bytes. Moreover, it helps in offering a collision-free transmission of frames using various protocols like CSMA/CD or CSMA/CA. There are four types of MAC frames: frame of data, frame for a beacon, frame of acknowledgment, and frame for MAC commands.
IEEE 802.15.4e TSCH and IETF 6TiSCH: IEEE 802.15.4 CSMA/CA faces the issues of single-channel related unpredictability and resource-constrained nature of LLNs over multi-hop networks. The IEEE standard introduces the Time-slotted Channel Hopping (TSCH) mode, which combines the Time Division Multiple Access (TDMA) with the channel hopping. It helps in maintaining energy efficiency and communication reliability. The TDMA scheduling minimizes the contention and mitigates the effect of channel fading.
6LoWPAN protocol: An adaptation layer is placed between the network and data link layers in the 6LoWPAN protocol stack. It consists of three main functions: header compression and decompression, fragmentation, and routing. The first function helps in compressing the header files of IPv6 and UDP. The second function of the adaptation layer is fragmentation and the reassembly of packets. The third important function of this layer is routing. Routing is the main function in the network layer, but the adaptation layer can also handle the routing operations. The 6LoWPAN protocol is used as an adaptation layer protocol. The following points explain the adaptation layer protocol. • 6LoWPAN stands for IPv6 over Low-power Wireless Personal Area Networks. • 6LoWPAN is a simple, low-cost communication network. • Packet size is limited to 128 bytes. • The specification supports star or mesh topology structure, low-cost communication, scalable networks, node mobility, unreliability scenario, and long sleep time. • Frames in 6LoWPAN use four types of headers: No 6loWPAN header (00), Dispatch header (01), Mesh header (10), and Fragmentation header (11). In the No 6loWPAN header case, any frame that does not follow 6loWPAN specifications is discarded.
Contiki Cooja Simulator Support for RPL Routing Functions and Control Messages
Contiki Cooja Simulator Support for Routing Layer Protocols in IoT • The IoT and IPv6 over LoWPAN (6LoWPAN) networks implement the Routing protocol for low-power and lossy networks (RPLs) in the routing layer. The RPL protocol communicates among IoT devices through multi-hop paths to one or more root devices, and they collect and distribute the sensed data. The RPL accounts for the node attributes, link quality measurements, Objective Functions (OFs) to construct the Destination Oriented Directed Acyclic Graph (DODAG) to root devices separately, and trickle algorithm. Recent researchers mainly focus on the OFs and Trickle improvements to enhance routing layer protocol efficiency.
• RPL is a distance vector and a source routing protocol that operates on top of the network layer. The RPL is mostly implemented on sensor nodes and is responsible for periodic data transmission to a sink node.
DODAG Construction: The RPL forms network topology (DODAG) using control messages. To construct the routing paths between the root and all nodes separately, the RPL uses the concept of the destination-oriented directed acyclic graph (DODAG). The DODAG topology allows exchanging information between nodes in a simple way with better routing scalability and energy-efficient communication. The Trickle algorithm is used for the restricted DIO message propagation to reduce overhead without impacting the DODAG efficiency. The important operations of the RPL protocol are listed as follows. • The RPL organizes its network topology into DODAGs. • The DODAG identification is a combination of RPL Instance ID and DODAG ID. • The RPL considers rank as an important metric in the design of DODAG construction. The Rank metric of a node defines the quality of its communication links toward the sink node. • Several extension works have been developed for RPL. The topological distance as rank and others may calculate the Rank value using link metrics and other properties such as constraints. • As per the Rank value, the nodes select their parent node to connect with the DODAG Root. • Several control messages and RPL instances are used to construct the DODAG structure.
DIO: DODAG Information Object - The main aim of the DIO message transmission is to construct a DODAG rooted at the root node. The DIO message is responsible for identifying the current version of DODAG, RPLInstanceID, DODAG version number, and DODAG ID. Moreover, the DIO message incorporates the information of rank to construct the DODAG structure. Moreover, other fields in DIO and its explanation are given as follows. • Grounded flag G - Application-defined goal. • MOP - Mode of operation for downward routing. • DTSN – It stores the sequence number. • Option(s) - Possibility of extending the DIO message.
DIS: DODAG Information Solicitation- DIS message solicits a DIO from an RPL node, and a node normally sends after it joins s stable network.
DAO:Destination Advertisement Object- DAO message is used to construct routes from root nodes to sensors.
DAO-ACK: Destination Advertisement Object Acknowledgement: The DAO-ACK message is sent by a DAO recipient to respond to a unicast DAO message.
Contiki Cooja Simulator Support for Objective Functions in RPL Routing Protocol
According to the available information objects, an Objective Function (OF) denotes the process of selecting and optimizing the packet routes within an RPL instance. The OF processes are as follows: • Extending the DODAG structure towards the sink node • Calculating Rank within the DODAG • Computing the number of nodes in the DODAG as parents and an ordered list of parents • Routing the packets through DODAG to the Root node • Most of the research on RPL improves objective functions and trickle algorithms. Different OFs can be available, and those are discussed as follows.
• Objective Function Zero (OF0): It adopts the hop count as a routing metric and is the default OF for RPL implementation.
• Minimum Rank with Hysteresis Objective Function (MRHOF): The MRHOF constructs DODAG with minimum ETX, delay, and loss, which is additive along a route.
Working with Objective Functions and Trickle Algorithm in RPL Protocol using Contiki Cooja Simulator
Working with Trickle Algorithm using Contiki Cooja Simulator • Each node executes the Trickle algorithm to select the DIO update transmitting interval. The RPL uses the Trickle timer to transmit DIO updates only when inconsistencies are detected in the network. After receiving DIO updates, a node increases the redundancy counter. Over time, if the redundancy count is exceeded, the node does not transmit any updates. The listening period of a node is doubled. It is the basic concept of the Trickle algorithm.
• There are different limitations to be considered in improving the RPL functions, especially in rank estimation, and the limitations are listed as follows.
• Single Path Routing: All traffic is transmitted through a single preferred parent node. It tends to energy drain at parent nodes and loads imbalanced routing.
• Unspecified metric Composition: Some improved RPL protocols explore multiple metrics in rank estimation and DODAG construction. Because relying on one metric does not satisfy all the requirements of IoT applications. A limitation is the lack of guidelines for achieving such a combination to attain an efficient routing.
• Implicit Hop Count Impact: A path with a minimum number of hops may have low-quality communication links. It may reduce the DODAG efficiency.
• Node Storing Mode Memory Limitation: RPL needs to run the storing mode to maintain the DODAG structure and improve routing efficiency. However, it is not suitable for small devices with limited resources.
• Trickle Timer Limitations: Lack of adaptive redundancy Counter size for DIO suppression mechanism without affecting the DODAG efficiency.
• Lack of Security Metric: The basic RPL does not include any security-related metric in topology structure creation.
Contiki Cooja Simulator Support for Routing Operations • In addition to the Hop count, it is essential to incorporate multiple metrics in rank estimation, such as link quality (ETX), Hop length, and energy-related metrics.
• Incorporating security-related metrics in rank estimation, such as trust and the number of control messages.
• The composition of multiple routing and security metrics includes additive, multiplicative, and weight-based metric incorporation.
Contiki Cooja Simulator Topics for improving the RPL protocol in IoT Projects
• Design and Analysis of Routing Protocols for IoT
• Scalability and Mobility of Routing Protocols for IoT
• Objective Functions and Load Balancing for Routing Protocols in IoT
• QoS Management and Energy Efficiency of Routing Protocols in IoT
• Routing Attacks and Defense Mechanisms for IoT
• Trust and Reputation Mechanisms for Routing Protocols in IoT
• Machine Learning Models for Routing Attacks and Defense in IoT
• IoT Privacy Preservation in Routing Protocols.
IoT Transport Layer Protocols and Simulation models Supported by Contiki Cooja Simulator
Transport Layer Protocols • The transport layer is next to the application layer. It is responsible for receiving data packets from the Network layer, reassembling the segmented data, identifying the port number by reading its header and sending the message to the appropriate port in the Application layer. The main aims of the transport layer activities are to provide reliable communication, avoid network congestion, and guarantee the packet sequence during data transmission. The protocols used in the transport layer are TCP, UDP, and ICMP. The security protocols are TLS and DTLS. Some of the important features of transport layer protocols are discussed as follows.
Working with TCP Protocol using Contiki Cooja Simulator • Transmission Control Protocol (TCP) is a reliable and connection-oriented protocol. • It is suitable for reliable communication due to the presence of the acknowledgment concept. If the packet is sent via the TCP protocol, it makes sure the data is sent to the other end via acknowledgment packet. • The protocol operates in three phases: establishing the connection, data transfer, and close connection. • An internet socket manages a TCP connection • The packet overhead of TCP is high. TCP consumes more power from the devices and has a large overhead, so it is unsuitable for low-power devices with a constrained environment.
Working with UDP Protocol using Contiki Cooja Simulator • User Datagram Protocol is a connection-less protocol and is not reliable for guaranteed data transmission. • The UDP protocol returns better results when packet loss during data transmission can be afforded. • UDP protocol is a lightweight protocol and is suitable for tiny device communication.
Working with Transport Layer Security (TLS) Protocol using Contiki Cooja Simulator • Transport Layer Security (TLS) is a cryptographic protocol, and it offers end-to-end security of data sent between applications over the Internet. • TLS is built on TCP. • It can be used for several applications such as email, file transfers, video/audio conferencing, instant messaging, voice-over-IP, and Internet services. • The TLS handshake layer assumes that handshake messages are delivered reliably, and the connection is disconnected if messages get lost. Because its mission is to offer reliable communication and with end-to-end encryption via TCP, it can’t be used to secure unreliable datagram traffic.
Working with Datagram Transport Layer Security (DTLS) using Contiki Cooja Simulator • Datagram Transport Layer Security (DTLS) is a stream-oriented transport layer protocol. It is based on Transport Layer Security (TLS) protocol. • It is a security protocol designed against message forgery, tampering, and eavesdropping. • DTLS is built on UDP. • The main disadvantages of DTLS are large pocket size, pocket rearrangement, and loss of datagram. • DTLS is also designed to deliver authenticated and encrypted application data, enabling lower latency.
Working with MQTT Protocols using Contiki Cooja Simulator for IoT Projects
Application Layer Protocols using Contiki Cooja Simulator • The application layer acts as the interface between the IoT device and the network. It is responsible for data formatting and presentation. The application layer protocols that support IoT are COAP and MQTT.
Working with Message Queue Telemetry Transport Protocol (MQTT) using Contiki Cooja Simulator
MQTT is a publish/subscribe messaging protocol. The essential concepts of MQTT are discussed as follows. • Topic: The publisher is responsible for cataloging the messages on the topics. A topic denotes a group of similar messages. • Subscriber:MQTT subscribers connect with the broker, and they can subscribe to the interesting topics and publish the topic-related messages to the interested clients. • Broker: Instead of sending the messages from one client to another, the MQTT broker acts as an intermediate for forwarding the messages to publishers and subscribers.
Limitations and possibility for Improving MQTT in Contiki Cooja Simulator • MQTT uses TCP protocol, and it requires high energy consumption. • TCP uses a handshake protocol, and it increases the communication time. • Centralized broker increases security and privacy vulnerabilities.
Research Topics for MQTT Protocol in Contiki Cooja Simulator • Design and Analysis of MQTT Protocol • Security Mechanisms and Lightweight Cryptography for MQTT. • Lightweight Authentication scheme • Mitigating handshake messages and integrating the handshake activities in TCP messages.
Contiki Cooja Simulator Working Procedure for Constrained Application Protocol (CoAP) based IoT Projects
Constrained Application Protocol (CoAP) • Constrained Application Protocol is used in constrained networks and implemented over constrained nodes. • CoAP packets are much smaller than HTTP TCP flows. • CoAP runs over UDP, not TCP. Clients and servers communicate through connectionless datagrams, allowing UDP broadcast and multicast for addressing. • CoAP follows a client/server model. Clients make requests to servers, and servers send back responses. Clients may GET, PUT, POST, and DELETE resources. • Requests and response messages may be marked as confirmable or non-confirmable. The receiver must acknowledge confirmable messages with an acknowledgment packet. Non-confirmable messages are fire and forget.
Limitations and Improving CoAP using Contiki Cooja Simulator • UDP fails in providing reliable communication • It needs to acknowledge each message, and it increases the processing time • The default CoAP does not effectively perform group communication due to congestion control issues
Working on CoAP Congestion Control Mechanisms using Contiki Cooja Simulator • CoCo-RED: It explores a revised random early detection scheme, but it lacks in considering the dynamic network conditions. • CoCoA: It explores Round Trip Time (RTT) and the variable backoff concept. The limitation of CoCoA is the weak RTT estimation. • Adaptive Congestion Control: It is based on transmission count. However, it requires high energy consumption. • CoCOA+: It is an improved CoCoA for congestion control. Inaccurate RTT estimation under high traffic scenarios. • CACC uses state-based backoff logic, incorporating a poor RTO aging concept.
Contiki Cooja Simulator Research Topics for CoAP Protocol • Design and Analysis Congestion Control Mechanisms for CoAP according to the dynamic network conditions for IoT • Security Mechanisms and DTLS Security for CoAP • Lightweight Cryptography and Authentication for CoAP
Metrics for Performance Evaluation using Contiki Cooja Simulator for IoT Projects
Most of the applied protocols in various layers can be evaluated using the following metrics.
• Packet Delivery Ratio: The ratio between delivered data packets and the total number of transmitted data packets.
• Packet Loss:Total numbers of lost packets during data transmission.
• Throughput:Total number of bits delivered to the root node per second.
• Control Overhead:Total numbers of control packets used in the path construction and data transmission.
• Delay:It is the average time taken by a packet to travel through the network from its source to the root node.
• Energy Consumption:
It is the average energy consumed by a node for communication.
• Network Lifetime:The time of a first node that drains half of the energy in the network.
• Message Size Overhead:
It is defined as the total length of the header in the packets transmitted and measured in bytes.