Network Layer

Contiki-NG relies on an IPv6 stack. All TCP/UDP sockets in Contiki-NG use uIP (uip.h and uip6.c from <contiki-ng>/os/net/ipv6), which implements for IP, UDP, and TCP protocols in minimized models.

Currently, the network layer contains two sublayers, the upper IPv6 layer and the lower adaptation layer. These sublayers run on the top of IEEE 802.15.4 with Time-Slotted Channel Hopping (TSCH).

Regarding routing, Contiki-NG applies RPL (Routing Protocol for Low-power and Lossy Networks (LLNs)), which adopts the RFC standard, RFC 6550. RPL develops a routing graph from the root node or AP (Access Point). If the routing graph has a form as cyclic graph and is built from a root node, it is called a DODAG (Destination Oriented Directed Acyclic Graph). A DODAG routing graph form can be seen in Figure 6-3.

For RPL implementation, Contiki-NG provides RPL classic and RPL lite. RPL classic is the original Contiki RPL implementation, called ContikiRPL. I recommend you read the ContikiRPL paper on this site: http://www.diva-portal.org/smash/get/diva2:1042739/FULLTEXT01.pdf .

You can find code implementations for both RPL classic and RPL lite in Contiki-NG. RPL classic can be found at /net/rpl-classic and RPL lite at /net/rpl-lite from the Contiki-NG code root. See them in Figure 6-4.

The nullnet library from Contiki-NG can be used to test your packet from upper to lower layers. This library can be found at <contiki-ng>/os/net/nullnet.

MAC Layer

The MAC layer is designed to address collisions in packet traffic and to apply back-off if there is traffic. Contiki-NG applies CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) for MAC layer implementation. Contiki-NG uses CSMA/CA on the IEEE 802.15.4 protocol. You can see program implementation in the <contiki-ng>/os/net/mac folder.

In the CSMA/CA algorithm, a mote will sense the medium before sending packets. If another mote is sending a packet, the mote will apply back-off with a certain value depending on the RDC layer. If the medium is free, the mote will send packets that have been prepared by the network layer.

Contiki-NG also provides nullmac for testing that is a part of nullnet from the network layer. nullmac will forward packets from the upper layer to the radio driver and vice versa.

RDC Layer

The Radio Duty Cycling (RDC) layer saves energy by allowing a node to keep its radio transceiver off most of the time. Contiki-NG supports the ContikiMAC protocol based on the principles behind low-power listening. ContikiMAC uses Time Slotted Channel Hopping (TSCH) that is a part of the MAC layer of the IEEE 802.15.4e-2012 amendment.

Radio Layer

The radio layer is the lowest layer in the Contiki-NG NETSTACK. The radio layer is handled by radio module from the Contiki-NG mote. Most radio layers work on the IEEE 802.15.4 protocol mechanism.

Creating Simulation Project

The first step is to create a simulation project using COOJA. From your platform Terminal, you can run the COOJA tool. For instance, I run it from Ubuntu Linux. You can type these commands:

After it has executed, you should get the COOJA application that is shown in Figure 6-5.

To start a new simulation, you can click File ➤ New simulation, shown in Figure 6-6.

Then, you should get the dialog that is shown in Figure 6-7. Fill in the simulation name with default settings on the Advanced Settings panel. For instance, I fill in the simulation name with My simulation.

If done, you can click the Create button to create the simulation.

After that, COOJA will create a new simulation for you. Figure 6-8 shows a simulation dashboard from COOJA. Now you are ready to configure the simulation.

In the next section, we will add a UDP server mote to our simulation.

Adding UDP Server Mote

In this section, we will add a mote as the UDP server. This mote will listen to incoming messages. Once a message is received from a client, the UDP server will reply by sending that message. For the demo, we will use a mote with the Sky platform type.

To add a new mote on COOJA, go to Add Motes ➤ Create a mote type ➤ Sky mote. You can see this menu in Figure 6-9.

You will get the dialog shown in Figure 6-10. You can fill in the description of the mote. Then, set the Contiki firmware from the UDP server, udp-server.c. You can find udp-server.c in the <contiki-ng>/examples/rpl-udp/ folder. Click the Browse button and navigate to the udp-server.c file.

After selecting the udp-server.c file, you can compile this file to ensure there are no errors in the program. Click the Compile button to compile the program. If it succeeds, you should see the successful compilation on the Compilation Output tab, shown in Figure 6-11.

If you have compiled the program, you can click the Create button. Then, you should get the dialog that is shown in Figure 6-12.

In this scenario, we only add one mote for the UDP server. You can fill in 1 for the “Number of new motes” field and select Random positioning for the “Positioning” dropdown.

If done, you can click the Add Motes button. You should see this mote on the Network panel in the simulation dashboard. You can see it in Figure 6-13.

Next, we will add some motes for the UDP client. We will perform this task in the next section.

Adding UDP Client Motes

After we have created one UDP server mote, we can create some UDP client motes. For this demo, we will add five motes. To add a new mote, you perform this task as in the previous section.

For a UDP client mote, you can put udp-client.c as the Contiki firmware. You can find it in the <contiki-ng>/examples/rpl-udp/ folder. You can see the UDP client program in Figure 6-14.

Then, you should compile the UDP client firmware to ensure there are no errors in the program. You can click the Compile button. You can see my successful compilation from the UDP client in Figure 6-15.

You can add motes to the Network panel by clicking the Create button in the dialog shown in Figure 6-15. After clicking, you should get the dialog that is shown in Figure 6-16. For this demo, fill in 5 in the “Number of new motes” field. All fields are default values.

After filling in the number of motes, you can click the Add Motes button. Then, you should see five UDP client motes in the Network panel in the simulation dashboard. Now you have six motes in the simulation, shown in Figure 6-17.

Running a Simulation

Once we have added the UDP server and client motes into the COOJA simulation, we can run the simulation. To do so, click the Start button on the Simulation Control dialog, as shown in Figure 6-18. If you don’t see this dialog, you can open it by going to Simulation ➤ Control panel.

After clicking the Start button, you should see the packet network and graphic simulation on COOJA. You can see it in Figure 6-19.

If the distance between motes is far, some motes probably won’t connect or receive UDP messages. You can change the mote location so each mote can be connected.

Now you can run the simulation again. You should see a graphic simulation on COOJA. A sample of the simulation can be seen in Figure 6-20.

Introducing Basic Routing

We already know that routing is applied to address how the packet is delivered from one point to another. Consider the paths depicted in Figure 6-23. For instance, we want to send a packet from A to D. Which path do you want to take?

Figure 6-23 shows a number of path options to send a packet from A to D. We can take one of three path options: A-B-D, A-D, and A-C-D. Which one is the best path? This is a challenge.

When selecting a path, you must consider what your goal is and what your success criteria are. We can define a cost for each path. Then, we can select the best path with the lowest cost. Battery usage can be one of the cost parameters when you want to perform a certain routing algorithm.

That is one routing issue. Unfortunately, this book does not focus on routing algorithms. I recommend you read about routing topics in textbooks or technical articles. We will use the current routing algorithms that are applied in Contiki-NG.

Single-Hop and Multi-Hop Networking

When a packet is transferred from the source to the final destination, it probably goes through a number of network devices. In networking, we will find a term called a hop. Hop is a term used to describe the different network devices a packet has to go through to reach its final destination point.

We can categorize networking models by the number of hops, such as single-hop and multi-hop networks. To better understand these network models, see the network topology depicted in Figure 6-24. A single-hop network would be pointed to the A-D path. The packet is sent from A to D through a single router.

Multi-hop networks send a packet through two or more networks to reach its final destination address. From Figure 6-24, we can see that the E-F path is considered a multi-hop network.

The Contiki-NG platform supports both single-hop and multi-hop networks. Depending on your network design, your Contiki-NG program should be aware of single-hop and multi-hop networks.

Routing on Contiki-NG

Currently, Contiki-NG supports two RPL routing methods: RPL classic and RPL lite. RPL classic is the original Contiki’s RPL implementation, called ContikiRPL. If you want to read further about ContikiRPL, I recommend you read this paper: http://www.diva-portal.org/smash/get/diva2:1042739/FULLTEXT01.pdf . Otherwise, Contiki-NG applies RPL lite for default RPL implementation.

Since Contiki-NG applies RPL lite by default, we test RPL. For instance, we have two motes for testing. Enable NG shell on your program. You can use the hello-world program with NG shell enabled. Flash this program to all motes.

Now you can access the Contiki-NG motes via NG shell. First, test an RPL root on the first mote. You can type this command:

Then, you can check the RPL status using this command:

You also can check the RPL route table that is applied on this mote. Type this command:

You can see my program output that has performed those tasks in Figure 6-25.

Next, you also can check the RPL status and its routes on another mote. You can type these commands in the NG shell:

A sample of the program output is shown in Figure 6-26.

A Brief Introduction

6LoWPAN is a network standard used to enable WSN motes to communicate with external networks, such as Internet networks. 6LoWPAN uses IPv6 as the identity for all motes. A 6LoWPAN network is shown in Figure 6-31.

WSN networks apply IPv6 for all communication. Each mote can communicate with the other motes. If one mote wants to communicate with an external system, such as a server, computer, or any legacy application in a different network, the mote just sends a message as usual. The 6LoWPAN router will take responsibility for communication between internal and external networks.

A 6LoWPAN router will record all addresses from motes and other network devices that are connected to the 6LoWPAN router. If an external system such as a server sends a message to one of the WSN motes in the WSN network, the 6LoWPAN router will forward the message to the mote. Otherwise, 6LoWPAN will inform the requester of failure.

In a network-stack view, we can compare a 6LoWPAN network to a WiFi network from the OSI layer side. You can see this comparison in Figure 6-32.

As you can see in Figure 6-32, 6LoWPAN works on the data-link layer in the OSI model. This standard uses IEEE 802.15.4 for physical layer implementation. In the upper layer of the 6LoWPAN, this standard applies IPv6 on RPL.

In the next section, we will try to implement 6LoWPAN on Contiki-NG.

Implementing a 6LoWPAN Network on Contiki-NG

Contiki-NG implements the 6LoWPAN network stack via an RPL border router that acts as a 6LoWPAN router. You can see a network diagram in Figure 6-33 for implementing 6LoWPAN on the Contiki-NG platform. You can put the RPL border router on a computer or a Raspberry Pi or any network device.

How do you implement an RPL border router in Contiki-NG?

Basically, you need a Contiki-NG mote as the RPL border router mote. This mote will work as a bridge to serve all requests from motes in the WSN network or network devices from an external network. To create an RPL border router mote, you should add the rpl-border-router library into your project. You can add this script to your Makefile file:

Then, run a program, called tunslip6, from Contiki-NG. You can find it in the <contiki-ng>/tools/ folder. This tool will communicate with a mote that has already been deployed as an RPL border router via serial port. You can type this command:

<prefic> is a prefix from the IPv6 address that will assign to all motes on the RPL border router application. <serial_port> is a serial port from the mote running the RPL border router program.

For this demo, we can run a program sample from the <contiki-ng>/examples/rpl-border-router/ folder. This project includes an RPL border router and web server modules. We need at least two motes to simulate the 6LoWPAN router and its communication.

Compile this project and flash it to one of the Contiki-NG motes. After it has been deployed to the mote, you can work remotely on the non–border router mote to see the assigned IPv6 address.

Last, you should run the tunslip6 program on the computer/Raspberry Pi to which the RPL border router mote was attached. You can run this command on the rpl-border-router project:

After being executed, that command will run tunslip6 with a default port. You should probably change the values for the target mote platform and its serial port.

By default, the RPL border router has an IPv6 address of fd00::1/64. You can change it in your Makefile. For instance, if you define the prefix of your IPv6 address as fd00::1/64, all motes within the WSN network will be assigned as fd00::xxxx. In this demo, my mote is assigned as fd00::212::4b00::d77::6fd2.

Now you can ping the mote using the assigned IPv6 address from your computer. For instance, type this command:

This program will get a response from the target mote because this mote can communicate with the computer through the RPL border router. You can see the program output in Figure 6-34. I ping my mote from Linux Ubuntu. It shows my computer can contact the Contiki-NG mote.

If you do not see a list of IPv6 addresses from your motes, you can restart your RPL border router application, tunslip6. Then, see the list of IPv6 addresses from the motes.

If you use a program sample from <contiki-ng>/examples/rpl-border-router/, you should get the web server within the program. You can test by opening a browser and navigating to http://[ip6_address_from_mote]. You can see my browser output in Figure 6-35.

If you have another mote, you can upload the Contiki-NG firmware to that mote. Then, the RPL border router will detect it. If you open a browser and navigate to the IPv6 address from the RPL border router mote, you should show its neighbor. You should see the IPv6 address from that mote. For instance, you can see it in Figure 6-36.

You can also test it by performing a ping. For instance, the target mote is fd00::212:4b00:6083. We can perform a ping as follows:

You should get a response from that mote. You can see it in Figure 6-37.

Sometimes you don’t see the IPv6 address from a new mote in your browser (Figure 6-36), but you know the local IPv6 address of the new mote. You can verify it by remoting into the mote with the local IPv6 address. For instance, the IPv6 address is fe80::212:4b00:6083. Now, change the prefix to fd00::xxx. The new IPv6 address shows fd00::212:4b00:6083. Try to ping it.

If you still have problems in which motes are not detected by the RPL border router, you probably need to restart the RPL border router mote.

6LoWPAN Implementation using COOJA

In the previous section, we learned how to implement 6LoWPAN on a physical device from a Contiki-NG mote. In this section, we want to implement 6LoWPAN on a simulation platform through the COOJA tool.

For this demo, we will use the program sample from the <contiki-ng>/examples/rpl-border-router/ folder. First, you can run the COOJA application. Create a new simulation project.

Next, you should add a new mote with the Sky platform. You can set <contiki-ng>/examples/rpl-border-router/border-router.c for the Contiki firmware, shown in Figure 6-38.

You can compile this Contiki firmware. If there is no error, you can click the Create button. In this demo, you will create one mote.

The next step is to add the serial socket tool to the mote. You can do this by right-clicking on the mote. Then, you will see the context menu shown in Figure 6-39. Select Mote tools for Sky 1 ➤ Serial Socket (SERVER).

You should now see the dialog shown in Figure 6-40. You can run it by clicking the Start button. We use the default listen port, 60001.

Next, you should run tunslip6 from the <contiki-ng>/tools/ folder. You can open Terminal and navigate to <contiki-ng>/tools/. Then, you can run this command:

Tunslip6 will run and connect to the RPL border router from a mote within the COOJA application. You can see the program output from tunslip6 in Figure 6-41.

Once tunslip6 is running, you can run the simulation on COOJA. This makes the mote run. You can see the IPv6 translator of the mote from tunslip6 in Figure 6-42.

You should see the IPv6 address of the COOJA mote in Terminal. For instance, my mote IPv6 address is aaaa::212:7401:1:101. Now, you can open a new Terminal. Then, try to perform ping6.

You can type this command:

You should get responses from your COOJA mote. You can see my ping6 response in Figure 6-43.

To get more practice, you can run a web server program on a new mote in COOJA. Then, you can access that web server from a browser on a local computer.

Preparation

First, we should have two mote devices. One mote will be used for the 6LoWPAN router. The rest will be applied for WebSense node implementation.

Since our RESTful server uses Node.js, your computer should install Node.js runtime. You should install all required libraries to run Node.js. Type these commands:

We will use Node.js LTS version. For instance, I use Node.js LTS 6.x. You can install it by typing these commands:

The next step is to develop a program for the project. We will do so in the next section.

Implementing the Demo

We will implement the WebSense project as shown in Figure 6-45. It is a physical design from our demo. We deploy the RPL border router into one of the motes. This mote will be attached to a computer that will deploy Node.js too. This project will use real mote devices. You can also use COOJA for testing.

Computers and server machines should be connected to a network in order to simulate sensor data visualization.

Each task will be presented in the following sections.

Writing a Program for WebSense Node

In this section, we will develop a program for the WebSense node. The goal of this program is to serve all requests for sensor data. Technically, the program will run a mini web server and serve HTTP requests. Once the RESTful server requests sensor data, this node will send it. To simplify this demo, the program will generate a random value for sensor data.

You can see the project structure in Figure 6-46. You can create a folder, called websense. We put some files in it, such as Makefile, project-conf.h, and websense.c. For web server implementation, we use the httpd-simple module from Contiki-NG.

The application will serve requests for sensor data. This task will be handled in websense.c in generate_routes() function. You can write this code as follows:

static

PT_THREAD(generate_routes(struct httpd_state *s))

{

  char buff[15];

  PSOCK_BEGIN(&s->sout);

  int temperature = 15 + rand() % 25;

  sprintf(buff,"{"temp":%u}", temperature);

  printf("send json to requester ");

  SEND_STRING(&s->sout, buff);

  PSOCK_END(&s->sout);

}

We also need to modify httpd-simple.c in order to cover JSON requests. We declare http_content_type_json for JSON content. Then, we pass it into the HTTP header as follows:

const char http_content_type_json[] = "Content-type: application/json ";

static

PT_THREAD(send_headers(struct httpd_state *s, const char *statushdr))

{

  /* char *ptr; */

  PSOCK_BEGIN(&s->sout);

  SEND_STRING(&s->sout, statushdr);

  SEND_STRING(&s->sout, http_content_type_json);

  PSOCK_END(&s->sout);

}

Writing a Program for RESTful Server

A RESTful server will run a web server on top of Node.js. We build the project structure that is shown in Figure 6-47. To visualize sensor data, we apply jQuery ( https://jquery.com ) and Flot ( http://www.flotcharts.org ) libraries for JavaScript. Download those files. Then, you can put those files into the <project>/public/js folder.

The application runs with the Node.js runtime. Make sure you have already installed it. Next, we install required the libraries for the RESTful server. We will use Express ( http://expressjs.com ) for the web framework and Socket.io ( https://socket.io ) for WebSocket implementation for Node.js.

First, create a package.json file inside the project folder. You can type these scripts:

{

  "name": "sensor",

  "version": "1.0.0",

  "description": "visualizing real-time sensor",

  "main": "index.js",

  "scripts": {

    "test": "echo "Error: no test specified" && exit 1"

  },

  "author": "Agus Kurniawan",

  "dependencies": {

    "express": "^4.15.2",

    "socket.io": "^2.0.4",

    "request": "latest"

  }

}

If done, save this file. Now, you can install all required libraries. You can type this command in the project folder. Make sure your computer is connected to the Internet:

$ npm install

Now you can write index.js for the application. This program will open a port 3000 to listen for HTTP requests. The program also requests sensor data from the WebSense node every three seconds. You can type these scripts for index.js:

var express = require('express');

var request = require('request');

var app = express();

var http = require('http').Server(app);

var io = require('socket.io')(http);

app.use(express.static('public'));

app.get('/', function(req, res){

    res.sendFile(__dirname + '/index.html');

});

io.on('connection', function(socket) {

    var dataPusher = setInterval(function () {

        request.get('http://[fd00::212:4b00:797:6083]/',function(err,res,body){

            if(err){

                console.log(err);

                return;

            }

            var obj = JSON.parse(body);

            socket.broadcast.emit('data', obj.temp);

        });

    }, 3000);

    socket.on('disconnect', function() {

        console.log('closing');

    });

});

http.listen(3000, function(){

    console.log('listening on *:3000');

});

You should change the IPv6 address of the WebSense node.

Next, we create index.html in the <project>/public folder. This program will communicate with the RESTful server though JSON communication. If the program receives sensor data, it will be stored into an array.

Then, the program will create a graphic for visualizing sensor data. You can type theses scripts for index.html:

<html>

<head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <title>Visualizing Real-Time Sensor Data</title>

    <script language="javascript" type="text/javascript" src="/js/jquery-3.2.1.js"></script>

    <script language="javascript" type="text/javascript" src="/js/jquery.flot.js"></script>

    <script src="/socket.io/socket.io.js"></script>

    <script language="javascript" type="text/javascript">

        var socket = io.connect();

        var items = [];

        var counter = 0;

        socket.on('data', function (data) {

            items.push([counter, data]);

            counter = counter + 1;

            if (items.length > 20)

                items.shift();

            $.plot($("#placeholder"), [items]);

        });

    </script>

</head>

<body>

<h1>Real-Time Sensor Data Visualization</h1>

<br>

<div id="placeholder" style="width:600px;height:300px;"></div>

</body>

</html>

Testing the Demo

Ensure the programs for the motes are already deployed. Now you can run the RESTful server by typing this command:

Firstly, we open a browser and navigate to the IPv6 address of the 6LoWPAN router. You should see the IPv6 addresses from the motes as shown in Figure 6-48.

After the RESTful server is running, you can test it by opening a browser. Navigate to the RESTful server’s IP address with port 3000. For instance, you can open a browser on your local server and navigate to http://localhost:3000. You should see sensor data visualization. You can see this in Figure 6-49.

What’s next?

You can create more sensor sources in different sensor types from several motes. Then, you can modify sensor data visualization to cover multiple sensor types.