Amazing technological breakthrough possible @S-Logix pro@slogix.in

Office Address

  • #5, First Floor, 4th Street Dr. Subbarayan Nagar Kodambakkam, Chennai-600 024 Landmark : Samiyar Madam
  • pro@slogix.in
  • +91- 81240 01111

Social List

Contiki Cooja Simulator Source Code for Internet of Things (IoT) Projects

Contiki Cooja Source Code Samples for Internet of Things (IoT) Projects

Introduction to Contiki-Cooja Simulator Tutorials for IoT

       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. 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. Important features of Contiki are as follows.

    Memory and process management: Contiki provides a standard C programming memory allocation named malloc(). It provides Protothreads to support low system requirements and mitigates the overhead of the multithreading concept.

    Communication management: Contiki provides both IPv6 and IPV4 stack implementations.

    File system management: Every IoT device is limited to memory storage. The Contiki empowers such devices using the coffee file system, which provides an external flash memory chip.

    Cooja is the Contiki network simulator. The Cooja simulates large and small networks with different Contiki motes. The following features are important for the Cooja simulator in IoT implementation.

Working on Cooja Simulator

       A simulator user should click on File and then New Simulation to start Cooja. A new screen is returned. 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 type. 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 and the mote is added. This process should be repeated for both Sink and Sensor nodes.

Network Options for Cooja Simulator

    It is important to learn different network options available in the Cooja simulator before running the network test.
       • The Timeline window helps to show the events over a period of time. The list of events can be filtered using the drop-down menu, and the output can be saved to a file.
       • The Mote Output window is the output window, and it helps in displaying the operations from the motes. It assists the researchers in making fine-grained analysis of IoT implementation.
       • The Simulation Control window starts, pauses and stops the simulation. The simulation can also be completely reloaded by fusing the simulation control window.
       • The Network window displays the layout of the network motes, and it can be used to display various factors of the network and network traffic.
       • The View dropdown menu shows the various options, such as Mote relations and Mote IDs, which show each mote's number.
       • The rest of the options are detailed as follows:
       • Addresses: IP or Rime option: It helps in displaying the addresses.
       • Log output: printf()’s’ provides printf messages from the mote code.
       • ‘LEDs’: It helps observe the LED lights on the simulated motes.
       • ‘Radio Traffic’: It animates the network once the simulation runs. It can show the messages exchanged between nodes.
       • ‘Positions’: It provides the relative location of each node.
       • ‘Mote type’: It shows the difference between motes of different types.
       • ‘Mote attributes’: It can alter motes coloring and description.
       • ‘Radio environment (UDGM)’: It displays the transmission range of any particular mote.
       • ‘Code’: It displays the program.



Working with Script Editor and Sensor Collect on Contiki Cooja Simulator

       The Tools option from the dropdown menu and ‘Simulation Script Editor’ are clicked to start the script editor within Cooja. The Script Editor assists in displaying the messages and setting a timer on the simulation. Selecting the ‘File’ dropdown menu, ‘Load example script’, should be clicked. Moreover, Timeout time can be adjusted. However, this change is only applicable once the ‘Run’ dropdown 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. For data collection, there are two options.
      • Firstly, ‘Mote tools for Sky 1’ when clicking the right side of the sink mote, and then ‘Collect View’.
      • Alternatively, data collection is enabled when clicking the ‘Tools’ 16 dropdown menu, ‘Collect View’, and ‘Sky 1’.
    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

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

The Contiki Cooja Simulator Topics to Analyze and Improve the IoT MAC Protocols

       • Design and Evaluation of MAC Protocols for IoT
       • 6TiSCH Communication Architecture for IoT

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.

Contiki Cooja Simulator Support Important RPL Functions and Control Messages

       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.
       1.Grounded flag G - Application-defined goal.
       2.MOP - Mode of operation for downward routing.
       3.DTSN – It stores the sequence number.
       4.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 Working with Objective Functions

       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:
       1. Extending the DODAG structure towards the sink node
       2. Calculating Rank within the DODAG
       3. Computing the number of nodes in the DODAG as parents and an ordered list of parents
       4. 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 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.



Improving OFs and Trickle Algorithm in RPL Protocol using Contiki Cooja Simulator

       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 the Following Possibilities

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

Topics to be covered in improving the RPL protocol with Contiki Cooja Simulator

       • 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, and
       • IoT Privacy Preservation in Routing Protocols.

Transport Layer Protocols Support in Contiki Cooja Simulator

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

Working with Constrained Application Protocol (CoAP) using Contiki Cooja Simulator

       • 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

Performance Evaluation Metrics using Contiki Cooja Simulator for IoT

    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.

Contiki Cooja Simulator Sample Source Code for IoT