Contiki - User contributions [en]

Contiki tutorials

2016-11-04T19:10:15Z

Paisamar:

[[Main_Page | Back to Main Page]]

== List of Tutorials ==

'''<pre style="color: red">Disclaimer: Please note that the following tutorials are a work in progress. Use at your own risk.</pre>'''

Completed
# [[Installation]]
# [[Hello World]]
# [[Broadcast Example]]
# [[Collect View]]
# [[Contiki build system]]
# [[Interfacing with Python]]
# [[Sensor acquisition]]
# [[Timers]]
# [[CFS-Coffee]]
# [[Cooja Simulator]]
# [[Network Stack]]
# [[RPL UDP]]
# [[Contiki Shell]]

Need review
# [[RSS measurement]]
# [[Contiki Coffee File System]]

Starting
# [[RPL objective function & simulation using DGRM model in cooja]]
# [[MAC protocols in ContikiOS]]
# [[RPL Border Router]]
# [[REST example running on Cooja and Sky motes]]
# [[Trickle library]]
# [[Packetbuffer Basics]]
# [[Antelope(Database Management System) - Contiki]]
# [[Mobility of Nodes in Cooja]]
# [[Contiki Programming Guide]]
# [[Analyse of a real 6LoWPAN network using a Contiki-based sniffer module]]
# [[Build your own application in Contiki]]
# [[Processes]] Yash
# [[RPL objective function modification and simulation in cooja]]
# [[Collect-view Code Details]] Pradipta

<pre style="color: red">Be sure to include references in your tutorials, especially if you quote material from other sites!</pre>

RPL Border Router

2016-11-04T19:07:07Z

Paisamar:

[[Contiki_tutorials | Back to Contiki Tutorials]]

== Introduction: ==

Border routers are routers that can be found at the edge of a network. Their function is to connect one network to another. In this tutorial we will learn how to run a simulation using the border router in Contiki 2.7. In the example which we will discuss in the rest of this tutorial the border router will be used to route data between a WSN (RPL network) and an external IP network.

[[File:Diagram.png]]

== Objective ==

The objective of this tutorial is to give you an understanding of the RPL Border Router code in Contiki 2.7 OS and learn how to simulate a network with a border router on Cooja

At the end of the tutorial you would have learnt the following:

1. Understanding the working of the rpl border router code 
2. Starting a simulation on Cooja simulator. 
3. Observing and validating the results 

== Code building blocks. ==

We will be using the following files

1. border-router.c 
2. udp-server.c (udp-client.c can also be used) 
3. slip-bridge.c (It contains callback function for processing a SLIP connection request) 
4. httpd-simple.c (A simple web server forwarding page generation to a protothread) 

udp-server nodes will form a DAG with the border router set as the root. The border router will receive the prefix through a [SLIP][http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol] (Serial Line Interface Protocol) connection and it will be communicated to the rest of the nodes in the RPL network.

Refer to the following code snippets in the file border-router.c In this piece of code the node configured as the border router waits for the prefix to be set. Once it receives the prefix, the border router is set as the root of the DAG after which it sets the prefix of the rest of the nodes in the network.

/* Request prefix until it has been received */
while(!prefix_set) {
etimer_set(&et, CLOCK_SECOND);
request_prefix();
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));
}

dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t *)dag_id);
if(dag != NULL) {
rpl_set_prefix(dag, &prefix, 64);
PRINTF("created a new RPL dag\n");
}

By default the border router hosts a simple web page. However, this can be disabled by defining WEBSERVER as seen the code snippet below. This webpage is displayed when the IPv6 address of the border router is entered in the browser. Refer to the file httpd-simple.c for the following code snippet 

<pre>PROCESS(border_router_process, "Border router process");
#if WEBSERVER==0
/* No webserver */
AUTOSTART_PROCESSES(&border_router_process);
#elif WEBSERVER>1
/* Use an external webserver application */
#include "webserver-nogui.h"
AUTOSTART_PROCESSES(&border_router_process,&webserver_nogui_process); </pre>

== Compiling the code ==

The code for RPL border router can be found at /contiki-2.7/examples/ipv6/rpl-border-router. Use the following command to compile the code for the border router 
<pre>cd /contiki-2.7/examples/ipv6/rpl-border-router
make TARGET=sky. </pre>
Once this command has been successfully executed, a file named border-router.sky will be created. This file will be used to program one of the motes as the border router on Cooja.
For the purpose of this tutorial we will select TMote Sky as our target.

In order to demonstrate the functionality of the border router we will create a network of nodes with the border router as the root. For creating such a network we will user the udp-server.c code.
This code can be found at /contiki-2.7/examples/ipv6/rpl-udp . Use the following command to compile the code for rpl-udp
<pre>cd /contiki-2.7/examples/ipv6/rpl-udp
make TARGET=sky </pre>

Once this command has been successfully executed a file named udp-server.sky will be created. This file will be used to program the remaining nodes in Cooja simulator. These nodes will form a DAG with the rpl border router as the root.

== Testing on Cooja ==

Upon the successful completion of the above mentioned steps we are ready to create a simulation in Cooja.
Start the Cooja simulator using the following command

<pre>cd /contiki-2.7/tools/cooja
ant run</pre>

When the GUI launches execute the following steps to create a simulation. 

1. From 'File' select 'New Simulation'. Select 'UDGM', enter the name of the simulation and click on 'create'. 
2. Click on 'Motes'. From the drop down menu select 'Add New Motes' followed by 'Create new motes' and select the mote type as 'Sky'. 
3. Browse to the location '/contiki-2.7/examples/ipv6/rpl-border-router' and select the file rpl-border-router.sky. Click on 'Create'. Add one mote of this type. 
4. Repeat step 2 and 3 but this time browse to the location /contiki-2.7/examples/ipv6/rpl-udp' and select the file udp-server.sky. Add 3 - 4 motes of the type udp-server 
5. Once the motes have been added you can position the motes.

[[File:Cooja_motes.png]]

Select the options under View as shown below. These will help you creating a topology of your choice. 
[[File:Motes_view.png]]

6. Now, we need to create a bridge between the RPL network simulated on Cooja and the local machine. This can be done by right clicking on the mote which is programmed as the border router. Select 'More tools for border router' and then select 'Serial Socket (SERVER)'. You will get the following message on the successful completion of this step.Note that the message says 'Listening on port 60001'

[[File:Serial_Socket.png]]

7. Now start the simulation by clicking on Start

== Tunslip utility ==

As mentioned in the introduction a border router helps in connecting one network to another. In this example the border router is used to route data between an RPL network and an external network. Till now we have only created the RPL network. Now we need to simulate the scenario in which this RPL network is connected to an external network. For this purpose we will use the Tunslip utility provided in Contiki. In this example tunslip creates a bridge between the RPL network and the local machine.
tunslip6.c can be found in /contiki-2.7/tools
Compile the tunslip6 code.
<pre>make tunslip6 </pre>
Make a connection between the RPL network and your local machine.
<pre>sudo ./tunslip6 -a 127.0.0.1 aaaa::1/64</pre>
On the successful execution this command the following output will be printed on the terminal.

<pre>slip connected to ``127.0.0.1:60001''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add aaaa::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.1.1 P-t-P:127.0.1.1 Mask:255.255.255.255
inet6 addr: fe80::1/64 Scope:Link
inet6 addr: aaaa::1/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Rime started with address 0.18.116.1.0.1.1.1
MAC 00:12:74:01:00:01:01:01 Contiki 2.7 started. Node id is set to 1.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:0212:7401:0001:0101
Starting 'Border router process' 'Web server'
*** Address:aaaa::1 => aaaa:0000:0000:0000
Got configuration message of type P
Setting prefix aaaa::
Server IPv6 addresses:
aaaa::212:7401:1:101
fe80::212:7401:1:101

</pre>
Go back to the Cooja simulator GUI and look at the dialogue box. The message has now changed to 'Client connected: /127.0.0.1' 
[[File:Client_Connected.png]]

== Verifying Results ==

You can verify that the address of the border router has been set by using the ping command.

<pre>user@instant-contiki:~/contiki-2.7$ ping6 aaaa::212:7401:1:101
PING aaaa::212:7401:1:101(aaaa::212:7401:1:101) 56 data bytes
64 bytes from aaaa::212:7401:1:101: icmp_seq=1 ttl=64 time=86.0 ms
64 bytes from aaaa::212:7401:1:101: icmp_seq=2 ttl=64 time=33.6 ms
64 bytes from aaaa::212:7401:1:101: icmp_seq=3 ttl=64 time=82.3 ms
64 bytes from aaaa::212:7401:1:101: icmp_seq=4 ttl=64 time=43.3 ms
64 bytes from aaaa::212:7401:1:101: icmp_seq=5 ttl=64 time=70.1 ms
^C
--- aaaa::212:7401:1:101 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 33.669/63.090/86.015/20.985 ms
</pre>

You can also ping one of the other nodes in the network. Here we are pinging node 4

<pre> user@instant-contiki:~/contiki-2.7$ ping6 aaaa::212:7404:4:404
PING aaaa::212:7404:4:404(aaaa::212:7404:4:404) 56 data bytes
64 bytes from aaaa::212:7404:4:404: icmp_seq=1 ttl=63 time=670 ms
64 bytes from aaaa::212:7404:4:404: icmp_seq=2 ttl=63 time=703 ms
64 bytes from aaaa::212:7404:4:404: icmp_seq=3 ttl=63 time=746 ms
64 bytes from aaaa::212:7404:4:404: icmp_seq=4 ttl=63 time=674 ms
^C
--- aaaa::212:7404:4:404 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4001ms
rtt min/avg/max/mdev = 670.230/698.666/746.619/30.514 ms
user@instant-contiki:~/contiki-2.7$
</pre>

The IPv6 address of a node can be checked from the log screen on Cooja. Filter the nodes by their ID 
[[File:Node_Address.png]]

You can enter the address of the border router in the web browser. The border router hosts a page which will be displayed on the browser as shown below. 
[[File:RPL_Browser.png]]

== Common Issues ==

1. Make sure that you enter the IPv6 address properly in the command sudo ./tunslip6 -a 127.0.0.1 aaaa::1/64 . There should be no spaces in aaaa::1/64. Otherwise the code will give unexpected behavior. 
2. When you pause the simulation the SLIP connection is lost. It might not work properly on resuming the simulation. In such cases reload the simulation. Create a fresh SLIP connection and then run the simulation again.

== References ==
[https://github.com/njh/contiki/blob/master/cpu/mc1322x/doc/rpl-tutorial.md] https://github.com/njh/contiki/blob/master/cpu/mc1322x/doc/rpl-tutorial.md 
[http://cnds.eecs.jacobs-university.de/courses/iotlab-2013/cooja.pdf] Using the Contiki Cooja Simulator - Anuj Sehgal

[[Contiki_tutorials | Back to Contiki Tutorials]]

Contiki Programming Guide

2016-11-04T19:05:36Z

Paisamar:

[[Contiki_tutorials | Back to Contiki Tutorials]]

== Introduction ==
• Contiki is developed by a group of developers from industry and academia lead by '''Adam Dunkels''' from the Swedish Institute of Computer Science. The Contiki team currently consists of tens of developers from '''SICS, SAP AG, Cisco, Atmel, NewAE and TU Munich(Technical University of Munich).'''
----
• Contiki is '''multi-tasking''' operating system, especially designed for microcontrollers with small '''amount of memory'''(35KB of ROM and around 3K of RAM), which are used in networked embedded systems and wireless sensor networks.
----
• Contiki is written in the C programming language.
----
• It is freely available as open source under a '''BSD-style license'''.
----
• Contiki was the '''first''' OS which introduced IP communication in low-power sensor networks

== You will learn ==
Understand the idea of threads and Events for Contiki

== Code Review for Protothreads and Events ==
Define system processes
<source lang="c">
procinit(&etimer_process, &mac_process, &tcpip_process);
#define PROCINIT(...)
const struct process *prooinit[] = {__VA_ARGS__, NULL}
void procinit_init(void){
int i;
for(i = 0; procinit[i] != NULL; ++i){
process_start((struct process *)procinit[i], NULL);
}
}

int main(void){
/*initialize hardware*/
intit_lowlevel();
clock_init();
process_init();
procinit_init();
autostart_start(autostart_processes);
printf("*****************BOOTING CONTIKI****************\n");
while(1){
process_run();
}
return 0;
}
</source>
The process thread in this part
<source lang="c">
PROCESS_THREAD(tcpip_process, ev, data);
PROCESS_THREAD(mac_process, ev, data);
PROCESS_THREAD(etimer_process, ev, data){
struct etimer *t, *u;
PROCESS_BEGIN();
timerlist = NULL;
while(1){
PROCESS_YIELD();
}
}
</source>
Start system processes
<source lang="c">
void
process_start(struct process *p, cnst char *arg){
struct process *q;
/*first make sure that we do not try to start a process that is already running*/
for(q = process_list; q != p && q != NULL; q = q->next);
/*If we found the process on the process list, we will bail out*/
if(q == p){
return;
}
/*Put on the process list*/
p->next = process_list;
process_list = p;
p->state = PROCESS_STATE_RUNNING;
PT_INIT(&p->pt);

printf("process: starting '%s'\n", p->name);
/*Post a synchronous initialization event to the process*/
process_post_synch(p, PROCESS_EVENT_INIT, (process_data_t)arg);
}
/*----------------------------------------------------------------------------------*/
/* PROCESS_POST_SYNCH will execute code between PROCESS_BEGIN(); and PROCESS_YIELD();*/
PROCESS_THREAD(etimer_process, ev, data){
struct etimer *t, *u;
PROCESS_BEGIN();
timerlist = NULL;
while(1){
PROCESS_YIELD();
if(ev == PROCESS_EVENT_EXITED){
struct process *p = data;
while(timerlist != NULL && timerlist -> p == p){
timerlist = timerlist -> next;
}
if(timerlist != NULL){
t = timerlist;
while(t -> next != NULL){
t = timerlist -> next;
}
}
}
}
}
</source>
Start user processes
<source lang="c">
/*PROCINIT(&etimer_process, &mac_process, &tcpip_process);*/
/*follow by define system processes main function*/
AUTOSTART_PROCESSES(&temp_measure_cmd_sender, &serial_cmd_process){
int i;
for(i = 0; processes[i] != NULL; ++i){
process_start(processes[i], NULL);
PRINTF("autostart_start: starting process '%s'\n", processes[i]->name);
}
}
</source>
The process thread in this part
<source lang="c">
PROCESS_THREAD(temp_measure_cmd_sender, ev, data);
PROCESS_THREAD(serial_cmd_process, ev, data){
PROCESS_BEGIN();
while(1){
PROCESS_WAIT_EVEN();
if(ev = SERIAL_CMD){
process_post(&temp_measure_cmd_sender, TEMP_CMD, 0);
}
}
PROCESS_END();
}
</source>
Main scheduler loop
<source lang="c">
/*loop until poll_requested == 1 || nevents > 0*/
int process_run(void){
/*process poll events*/
if(pull_requested){
do_poll();
}
/*Process one event from the queue*/
do_event();

return nevents + poll_requested;
}

static void do_event(void){
/*
if there are any events in the queue, take the first one and walk through the
list of processes to see if the event should be delivered to any of them. If
so, we call the event handler function for the process. We only process one
event at a time and call the poll handlers inbetween.
*/
if(nevents >0){
...
call_process(receiver, ev, data);
}
}
</source>
Method: POLL
<source lang="c">
ISR(AVR_OUTPUT_COMPARE_INT){
++count;
if(etimer_pending()){
etimer_request_poll();
}
}
void etimer_request_poll(void){
process_poll(&etimer_process);
}
void process_poll(struct process *p){
if(p != NULL){
if(p->state == PROCESS_STATE_RUNNING ||
p->state == PROCESS_STATE_CALLED){
p->needspoll = 1;
poll_requested = 1;
}
}
}
int process_run(void){
/*process poll events*/
if(poll_requested){
do_poll();
}
/*Process one event from the queue*/
do_event();
return nevents + poll_requested;
}
static void do_poll(void){
struct process *p;
poll_requested = 0;
/*Call the processes that needs to be polled*/
for(p = process_list; p != NULL; p = p->next){
if(p->needspoll){
p->state = PROCESS_STATE_RUNNING;
p->needspoll = 0;
call_process(p, PROCESS_EVENT_POLL, NULL);
}
}
}
</source>
Method: POST
<source lang="c">
PROCESS_THREAD(etimer_process, ev, data){
...
for(t = timerlist; t != NULL; t = t->next){
if(timer_expired(&t->timer)){
if(process_post(t->p, PROCESS_EVENT_TIMER, t) == PROCESS_ERR_OK)
...
}
}
}
int process_post(struct process *p, process_event_t ev, process_data_t data){
...
anum = (fevent + nevents) % PROCESS_CONF_NUMEVENTS;
events[snum].ev = ev;
events[snum].data = data;
events[snum].p = p;
++ nevents;
...
}
int process_run(void){
/*Process poll events*/
if(poll_requested){
do_poll();
}
/*Process one event from the queue*/
do_event();
return nevents + poll_requested;
}
static void do_event(void){
...
/*
if there are any events in the queue, take the first one and walk through the
list of processes to see if the event should be delivered to any of them. If
so, we call the event handler function for the process. We only process one
event at a time and call the poll handlers inbetween.
*/
if(nevents > 0){
...
call_process(reveiver, ev, data);
}
}
</source>
It is clear to see according to the figure 1
----
[[File:1.jpg]]
figure 1

----
Code Style: Names in Contiki
In Contiki, all names are prefixed with the module name
(example: process_start(), rime_init(), clock_time(), memb_alloc(), list_add()...)
Prefix makes it possible to mentally locate all function calls
All code must abide by this:
There are a few exceptions in the current code, but those are to be removed in the future

----
Code Style: What to avoid
-noCamelCase()
-No_Capital_letters()
-#define EXCEPT_FOR_MACROS()
----
Code Sytle: File names
Contiki uses hyphenated-file-names rather than underscore_in_file_names

== The Motivation – Safe Tiny OS ==

The Safe Tiny OS tool chain is shown in Figure 2. The most immediate benefit of Safe TinyOS was that during its development 4 severe bugs in TinyOS could be found out and were corrected.
----
[[File:2.png]]
figure 2
----
Building A Safe Application

To build an application Safe, we have to provide the parameter ‘safe’ in the command line of ‘make’.
<source lang="c">
cd $TOSROOT/apps/Blink
make micaz safe
</source>
----
== Making Safety Optional ==
=== Implementation Overview ===
The source code of Contiki consists of nearly 1200 files, including both the OS core and the applications. The OS core itself consists of around 300 files. The work comprises of annotating each pointer access in all these files and recompiling with Deputy. Once the core is free of Safety errors, we can go for the Safety of applications. After this step, we set Deputy as the default compiler of Contiki. Programmers will have to adapt to the Annotations of Deputy, which are very simple and easy to learn.
----
The flow graph of Safe Contiki development is given in Figure 3
----
[[File:3.jpg]]
figure 3
----

=== Modifying the Makefiles ===
The implementation was started by editing the makefiles associated with the ‘native’ processor. The Makefile.native mainly contains definitions for the C compiler used for the native processor. The file is located in contiki-2.x/cpu/native/ directory. The current contents of the 6th and 7th lines are
- CC = gcc
- LD = gcc
----
which indicates that for the native CPU, the compiler and the linker are the same, the gcc. We replaced this with
- CC = deputy
- LD = deputy

=== A New Argument To Make ===
As an illustration of how the SAFETY argument is used, the following commands will create the Safe version of the ‘hello-world’ program for the ‘native’ platform.
<source lang="c">
cd /home/user/contiki-2.x/examples/hello-world/
make TARGET=native SAFETY=yes
</source>
Safety is an optional feature; programs are made Unsafe, by default. The following command makes the program without Safety features, for the ‘native’ platform.
<source lang="c">
make TARGET=native
</source>

=== Conditional Making And The gcc -D Flag ===
In order to make ‘making’ conditional, depending on the value of the variable SAFETY, we further modified the Makefile.native file in the contiki-2.x/cpu/native/ directory.
Makefile.native is shown below
<source lang="c">
ifeq ($(SAFETY),yes)
CC = deputy
LD = deputy
else
CC = gcc
LD = gcc
CFLAGS += -DNTS='' -DSAFE='' \
-DCOUNT$x$='' \
-DTC$x$=x -DBOUND$x,y$='' \
-DTRUSTED='' -DNTDROP$x$=x \
-DNTEXPAND$x$=x
endif
</source>

== Reference ==
[1]The Safe TinyOS, 2008. http://docs.tinyos.net/index.php/Safe_TinyOS
[2]The Contiki OS, http://www.sics.se/contiki/
[2]Contiki Programming, 2011. http://wenku.baidu.com/view/

[[Contiki_tutorials | Back to Contiki Tutorials]]

2016-09-10T00:06:03Z

Paisamar:

[[Contiki_tutorials | Back to Contiki Tutorials]]

__TOC__

Contiki provides us with three network stacks,

1. IPv4 
2. IPv6 
3. Rime 

The uIP TCP/IP stack, which provides us with IPv4 networking, the uIPv6 stack, which provides IPv6 networking, and the Rime stack, which is a set of custom lightweight networking protocols designed for low-power wireless networks.

== Contiki Netstack ==

Contiki's Network Protocol stack (NETSTACK) organizes the network modules into a complete protocol stack covering all traditional OSI Layers.

[[File:Contikinetstack.png|center|frame|Contiki Network Stack]]

=== Netstack Concepts ===

'''Four Layers''' 
1. Network layer - NETSTACK_NETWORK 
2. MAC (Medium Access Control) layer - NETSTACK_MAC 
3. RDC (Radio Duty Cycling) layer - NETSTACK_RDC 
4. Radio layer - NETSTACK_RADIO 

'''The packet buffer - packetbuf''' 
* One buffer, holds a single packet. 
* All layers of the netstack operate on the packetbuf. 
* Large enough to hold a single radio packet - PACKETBUF_CONF_LEN 

'''Queue buffers - queuebuf''' 
* The packetbuf only holds the current packet. 
* To store packets on queues, use a queuebuf. 
* Use a list to keep track of them. 

'''uIP packet buffer - uip_buf''' 

'''Framers - NETSTACK_FRAMER''' 
* The framer module converts link-layer headers to packet attributes - '''parse()''' 
* And packet attributes to link-layer headers - '''create()''' 

== Network & Routing Layer ==

* Contiki automatically forms a wireless IPv6 network with the help of routing protocol called RPL (Routing Protocol for Low-power and Lossy Networks (LLNs)). 
* RPL forms routing graph from root node or AP (Access Point). It builds acyclic graph from root node called DODAG (Destination Oriented Directed Acyclic Graph). 
[[File:RPLDODAG.png|center|frame|RPL DODAG]] 
* DIO (DODAG Information Object) messages are broadcast by all nodes starting from the root node. It includes the node's rank, ETX, DAG version number etc. 
[[File:NF1.png|center|frame|5 nodes Network]] 
[[File:NF2.png|center|frame|DIO message sent by root node]] 
[[File:NF3.png|center|frame|DIO message broadcasted by receiving nodes]] 
[[File:NF4.png|center|frame|DIO message broadcasted by receiving nodes]] 
[[File:NF5.png|center|frame|Rank of the nodes with respect to the root]] 
* The node selects a parent based on the received DIO messages and calculates its rank. 

== Adaptation Layer ==

The network layer contains two sublayers, the upper IPv6 layer and the lower adaption layer.

The Adaptation Layer provides IPv6 and UDP header compression and fragmentation to transport IPv6 packets with a maximum transmission (MTU) of 1280 bytes over IEEE 802.15.4 with a MTU of 127 byte.

== MAC Layer ==
* The simplest layer in the IoT/IP stack. 
* Avoid collisions, back-off if there is traffic. 
* CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance 
:+ Sense the medium before sending. 
:+ Back-off if someone else is sending. 
:+ Timing depends on RDC layer. 
:+ Network layer decided number of transmissions. 
* nullmac: Forwards packets from the upper layer to the radio driver and vice versa. 

== RDC Layer ==

Radio Duty Cycling layer saves energy by allowing a node to keep its radio transceiver off most of the time.

Contiki has three duty cycling mechanisms: ContikiMAC, X-MAC and LPP. ContikiMAC is a protocol based on the principles behind low-power listening but with better power efficiency. Contiki's X-MAC is based on the original X-MAC protocol, but has been enhanced to reduce power consumption and maintain good network conditions. Contiki's LPP is based on the Low-Power Probing (LPP) protocol but with enhancements that improve power consumption as well as provide mechanisms for sending broadcast data.

== Radio Layer ==

Radio Layer is the lowest layer in the Contiki Netstack. Here, the data arrives in bytes or as a full packet via interrupt handlers. The input data is read out into the buffer, packetbuf and the process is polled. This polling process will cause the process to be sent to the special event and passed to the upper layers.

== References ==
http://www.slideshare.net/ADunkels/building-day-2-upload-building-the-internet-of-things-with-thingsquare-and-contiki-day-2-part-3 
http://www.slideshare.net/ADunkels/building-the-internet-of-things-with-thingsquare-and-contiki-day-1-part-2?related=1 
https://tools.ietf.org/html/rfc6550 
http://www.slideshare.net/ADunkels/building-day-2-upload-1?next_slideshow=1 
http://www.slideshare.net/ADunkels/advanced-internet-of-things-firmware-engineering-with-thingsquare-and-contiki-day-1-part-2 
http://contiki.sourceforge.net/docs/2.6/a01793.html#_details 
https://github.com/contiki-os/contiki/wiki/Radio-duty-cycling 
https://github.com/hso-esk/emb6/wiki/The-emb6-Network-Stack 

[[Contiki_tutorials | Back to Contiki Tutorials]]

Edited by: Mugdhe, Samarth Pai

2016-09-07T00:08:02Z

Paisamar: /* UDP Server */

[[Contiki_tutorials | Back to Contiki Tutorials]]

== Introduction ==

RPL is the IPv6 Routing Protocol for Low-power and Lossy Networks (LLNs). LLNs are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy. RPL provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.

In this example, UDP is implemented on top of RPL. A LLN is comprised of a UDP server, which accepts available packets, and several UDP clients, which send packets periodically to server through single-hop or multi-hops.

== You Will Learn ==

Through this tutorial, you will learn the basic idea of RPL and operate UDP communications with ease without manipulating lower layer functions.

== Source Code ==

~/contiki-2.7/examples/ipv6/rpl-udp/udp-server.c

~/contiki-2.7/examples/ipv6/rpl-udp/udp-client.c

~/contiki-2.7/core/net/tcpip.c

~/contiki-2.7/core/net/tcpip.h

== RPL Basics ==

[[File:contiki_stacks.jpg|200px|right|frame|Contiki Layers]]

RPL was designed with the objective to meet the requirements spelled out in [https://tools.ietf.org/html/rfc5867 RFC5867], [https://tools.ietf.org/html/rfc5826 RFC5826], [https://tools.ietf.org/html/rfc5673 RFC5673], and [https://tools.ietf.org/html/rfc5548 RFC5548].

In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives includes minimizing energy, minimizing latency, or satisfying constraints. A RPL implementation, in support of a particular LLN application, will include the necessary Objective Function(s) as required by the application.

RPL operations require bidirectional links. In some LLN scenarios, those links may exhibit asymmetric properties. It is required that the reachability of a router be verified before the router can be used as a parent. RPL expects an external mechanism to be triggered during the parent selection phase in order to verify link properties and neighbor reachability.

RPL also expects an external mechanism to access and transport some control information, referred to as the "RPL Packet Information", in data packets. RPL provides a mechanism to disseminate information over the dynamically formed network topology. This dissemination enables minimal configuration in the nodes, allowing nodes to operate mostly autonomously.

In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) information such as the [https://tools.ietf.org/html/rfc4861 RFC4861] Prefix Information Option (PIO) and the [https://tools.ietf.org/html/rfc4191 RFC4191] Route Information Option (RIO). ND information that is disseminated by RPL conserves all its original semantics for router to host, with limited extensions for router to router, though it is not to be confused with routing advertisements and it is never to be directly redistributed in another routing protocol. A RPL node often combines host and router behaviors. As a host, it will process the options as specified in [https://tools.ietf.org/html/rfc4191 RFC4191], [https://tools.ietf.org/html/rfc4861 RFC4861], [https://tools.ietf.org/html/rfc4862 RFC4862], and [https://tools.ietf.org/html/rfc6275 RFC6275]. As a router, the RPL node may advertise the information from the options as required for the specific link.

For further information, please refer to [https://tools.ietf.org/html/rfc6550 '''RFC 6550'''], "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks".

== UDP Server ==
[[File:udp_server.jpg|200px|right|thumb|Flow chart for UDP server]]
In the example, UDP server does three tasks primarily.

1. Initializes RPL DAG;

2. Sets up UPD connection;

3. Waits for packets from client, receives and print them on stdout.

=== Initialize RPL DAG===
<source lang="c">
// check whether the ADDR_MANUAL was set succefuly or not
uip_ds6_addr_add(&ipaddr, 0, ADDR_MANUAL);
root_if = uip_ds6_addr_lookup(&ipaddr);
if(root_if != NULL) {
rpl_dag_t *dag;
//set the ip adress of server as the root of initial DAG
dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t *)&ipaddr);
uip_ip6addr(&ipaddr, 0xaaaa, 0, 0, 0, 0, 0, 0, 0);
rpl_set_prefix(dag, &ipaddr, 64);
PRINTF("created a new RPL dag\n");
} else {
PRINTF("failed to create a new RPL DAG\n");
}
</source>

===create UDP connection ===
<source lang="c">
//create new UDP connection to client's port
server_conn = udp_new(NULL, UIP_HTONS(UDP_CLIENT_PORT), NULL);
if(server_conn == NULL) {
PRINTF("No UDP connection available, exiting the process!\n");
PROCESS_EXIT();
}
//bing the connection to server's local port
udp_bind(server_conn, UIP_HTONS(UDP_SERVER_PORT));

PRINTF("Created a server connection with remote address ");
PRINT6ADDR(&server_conn->ripaddr);
PRINTF(" local/remote port %u/%u\n", UIP_HTONS(server_conn->lport),
UIP_HTONS(server_conn->rport));
</source>

===receives and processes incoming packet ===
<source lang="c">
while(1) {
PROCESS_YIELD();
//if there is packet available
if(ev == tcpip_event) {
tcpip_handler();
} else if (ev == sensors_event && data == &button_sensor) {
PRINTF("Initiaing global repair\n");
rpl_repair_root(RPL_DEFAULT_INSTANCE);
}
}
</source>

<source lang="c">
//call this function if packet available
static void
tcpip_handler(void)
{
char *appdata;

if(uip_newdata()) {
appdata = (char *)uip_appdata;
appdata[uip_datalen()] = 0;
//print the data of packet
PRINTF("DATA recv '%s' from ", appdata);
PRINTF("%d",
UIP_IP_BUF->srcipaddr.u8[sizeof(UIP_IP_BUF->srcipaddr.u8) - 1]);
PRINTF("\n");
}
</source>

== UDP Client ==

[[File:udp_client.png|200px|right|thumb|Flow chart for UDP client]]
In the example, UDP server does two tasks primarily.

1. Sets up UPD connection;

2. Sends packet to UDP server periodically.

=== Sets up UPD connection ===
<source lang="c">
/* new connection with remote host */
client_conn = udp_new(NULL, UIP_HTONS(UDP_SERVER_PORT), NULL);
if(client_conn == NULL) {
PRINTF("No UDP connection available, exiting the process!\n");
PROCESS_EXIT();
}
udp_bind(client_conn, UIP_HTONS(UDP_CLIENT_PORT));

PRINTF("Created a connection with the server ");
PRINT6ADDR(&client_conn->ripaddr);
PRINTF(" local/remote port %u/%u\n",
UIP_HTONS(client_conn->lport), UIP_HTONS(client_conn->rport));
</source>

=== Sends packet ===
<source lang="c">
//set time interval by SEND_INTERVAL
etimer_set(&periodic, SEND_INTERVAL);
while(1) {
PROCESS_YIELD();
if(ev == tcpip_event) {
tcpip_handler();
}
//send packet every SEND_INTERVAL
if(etimer_expired(&periodic)) {
etimer_reset(&periodic);
ctimer_set(&backoff_timer, SEND_TIME, send_packet, NULL);
</source>

<source lang="c">
static void
send_packet(void *ptr)
{
static int seq_id;
char buf[MAX_PAYLOAD_LEN];

seq_id++;
PRINTF("DATA send to %d 'Hello %d'\n",
server_ipaddr.u8[sizeof(server_ipaddr.u8) - 1], seq_id);
sprintf(buf, "Hello %d from the client", seq_id);
//send packet through client_conn to UDP server
uip_udp_packet_sendto(client_conn, buf, strlen(buf),
&server_ipaddr, UIP_HTONS(UDP_SERVER_PORT));
}
</source>

== Cooja Simulation ==

The DGRM model is used.

The following are the steps to form a new simulation:

'''''Note:''''' Please refer to the [[Cooja Simulator]] tutorial page for an introduction and detailed description on how to use the simulator.

*'''Start Cooja'''

To start the simulator, Go to Contiki folder and navigate to /tools/cooja directory and run "ant" to start the simulator

sudo ant run

*'''Open an existing simulation file'''

In the GUI, select File->Open simulation->Browse..

After the dialogue shows up, Open home/contiki-2.7/examples/ipv6/rpl-udp/rpl-udp.csc

'''''Note''''': If compile error shows up, please run
$ cd contiki-2.7/examples/ipv6/rpl-udp
$ make

[[File:opensim.png|center|border|500px|Open an existing simulation]]

You are suppose to see the simulation showing up like this.

[[File:siminterface.png|center|border|500px|Simulation interface]]
*'''Run Simulation'''
Run the simulation by using the ''Start'' option in the ''Simulation Control'' window. This will initiate the motes and allocate all with a new Rime address and other initialization processes. 

*'''Watch Output'''
The motes output and debug messages can be seen in the ''Motes Output'' window. You can filter the output based on the node ''ID:node_id'' to watch a particular node. You can also watch particular debug messages by filtering them. The other useful functions of the ''Motes Output'' are ''File, Edit'' and ''View''. The ''File'' option helps in saving the output to a file. The ''Edit'' has the option of copying the output - either full or a particular selected messages. You can also clear the messages using the ''Clear all messages'' option. 
You can use these messages saved in file to make observations and plot graphs according to the objective of your experiment. 

[[File:simioutput.png|center|border|500px|Simulation output]]

== Further Reading ==

*[https://tools.ietf.org/html/rfc6550 '''RFC 6550'''], "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks".

[[Contiki_tutorials | Back to Contiki Tutorials]]