Contiki - User contributions [en]

EE 652 projects

2014-12-22T14:52:12Z

Jiahaoli:

EE 652 2014 Projects

== Scheduling algorithms for IEEE 802.15.4e networks - Pedro ==

'''Repository''': http://neptune.usc.edu:8081/pdasilva/tsch-schedulers/

'''Description''':

''How to compile'': gcc -std=gnu99 -o Scheduling util/*.c graphs/*.c mcc/*.c tasa/*.c main.c

''How to execute'': ./Scheduling <sink_id> <algorithm>

where: <sink_id> = Sink identification (starting at 0) and <algorithm> = 0 if MCC and 1 if TASA

''Output'': you will find files ext_schedule.h and topology.c, which should be used according to the project report

The execution will consider data/prr55.txt file as input for PRR statistics. You need to create the file with tree description before running TASA. You can easily do that first running MCC for a given sink id (e.g. 3) and then running TASA for the same sink id.

== Heat Diffusion Routing Algorithm Contiki Implementation - Pradipta ==
'''Repository''': http://neptune.usc.edu:8081/pradipta/heat-diffusion.git

'''Description''':
This is a contiki implementation of the Heat Diffusion algorithm proposed by Reza Banirazi, Edmond A. Jonckheere, Bhaskar Krishnamachari in '''“Heat-Diffusion: Pareto optimal dynamic routing for time-varying wireless networks“, International Conference on Computer Communications (INFOCOM), 2014'''. Heat Diffusion routing is a new multi-hop wireless network routing protocol which is similar to Back-Pressure routing based on concepts of heat diffusion in classical physics

== Backpressure Control Protocol on IPv6 stack of Contiki - Mrunal and Chhavi ==

'''Repository''': https://github.com/chhavikapoor/EE652_Final

Use the branch final_project from the repository.

Follow the README-BCP in the final_project repository to simulate the implementation of BCP on IPv6 stack in COOJA.

'''Description''':

BCP is an implementation of dynamic backpressure routing in which the routing and forwarding decisions are made on per packet basis that takes into consideration the backpressure weight of each of its neighbors. The ubiquitous use of TCP/IP protocol suite in web applications, peer to peer networking over the internet etc motivated us to implement the Backpressure Collection Protocol on the IPv6 Stack of Contiki. We implemented a functional version of BCP on the IPv6 stack of Contiki OS.
In our implementation, BCP Sink by default has the node_id = 1.

== Modifications to RPL for Mobility - Pratyush Deshpande, Gopi Marella and Abhilash Hegde ==

'''Repository''': https://github.com/pratyush18/contiki-new.git

'''Description''':

Routing Protocol for Low power and lossy networks (RPL) has been recently adopted IETF routing protocol standard for low power wireless sensor networks and Internet of Things applications. Originally RPL is designed for static networks with no support for mobility. But, several IoT applications involve mobile nodes and thus there is a need to modify RPL for supporting mobile node scenarios. In RPL, routing takes place by formationof Destination Oriented Acyclic Graph (DODAG). Several control messages like DODAG Information Objects (DIOs), DODAG Information Solicitation and DODAG Advertisement Objects (DAOs) are exchanged for the DODAG formation. These control messages propagate throughout the network and collaboratively work to form the DODAG. The
control messages in RPL are controlled by several timers. These control message timers need to be modified for mobile node scenarios. The timers need to be optimized based on mobility of nodes in the network. In this paper we have modified the existing implementation of RPL protocol in Contiki Operating system to improve its performance for scenarios where mobile nodes are involved. We have also developed a test-bed for simulating mobile nodes in COOJA simulator and evaluating performance metrics like Packet delivery ratio, Power consumption and Average latency per packet.

== LOADng for Contiki- Jiahao Liang, Zhikun Liu and Haimo Bai ==

'''Repository''': https://github.com/jiahaoliang/EE652_LOADng

'''Description''':

The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) is a routing protocol, derived from AODV and extended for use in Low power Lossy Networks (LLNs). A reactive protocol, the basic operations of LOAD include generation of Route Requests (RREQs) by a router (originator) for when discovering a route to a destination, forwarding of such RREQs until they reach the destination router, generation of Route Replies (RREPs) upon receipt of a RREQ by the destination, and forwarding of these RREPs towards the originator.

RPL UDP

2014-11-09T14:13:21Z

Jiahaoli: /* RPL Basics */

== 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:''''' You can refer to [[Cooja Simulator]] for an introduction to Cooja. 
*'''Run Cooja'''
Go to your Contiki folder(contiki-2.7) and then go to /tools/cooja directory Run the command sudo ant run to open up a cooja GUI. 
$ cd contiki-2.7/tools/cooja
$ 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".

RPL UDP

2014-11-09T14:09:46Z

Jiahaoli: Created page with "== 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..."

== 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 [RFC5867], [RFC5826], [RFC5673], and [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 [RFC4861] Prefix Information Option (PIO) and the [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 [RFC4191], [RFC4861], [RFC4862], and [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:''''' You can refer to [[Cooja Simulator]] for an introduction to Cooja. 
*'''Run Cooja'''
Go to your Contiki folder(contiki-2.7) and then go to /tools/cooja directory Run the command sudo ant run to open up a cooja GUI. 
$ cd contiki-2.7/tools/cooja
$ 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".

File:Udp client.png

2014-11-09T14:09:28Z

Jiahaoli:

File:Simioutput.png

2014-11-09T14:06:05Z

Jiahaoli:

File:Siminterface.png

2014-11-09T14:01:49Z

Jiahaoli:

File:Opensim.png

2014-11-09T13:50:33Z

Jiahaoli:

File:Udp server.jpg

2014-11-09T12:49:47Z

Jiahaoli:

File:Contiki stacks.jpg

2014-11-09T12:04:29Z

Jiahaoli:

Contiki tutorials

2014-10-22T22:51:35Z

Jiahaoli:

[[Main_Page | Back to Main Page]]

== List of Tutorials ==

Completed
# [[Installation]]
# [[Hello World]]
# [[Broadcast Example]]
# [[Collect View]]
# [[Contiki build system]]
# [[Interfacing with Python]]
# [[Sensor acquisition]] (light, temperature, humidity)

Need review
# [[Timers]] Tim, Leo
# [[CFS-Coffee]] Kevin

Starting
# [[Tutornet]] Pedro, Kwame
# [[Cooja Simulator]] (Getting started, debugging) Pedro
# [[Protocols stack]]
# [[CSMA]] Tim, Leo
# [[RSS measurement]]
# [[RPL objective function modification and simulation in cooja ]] Ashwini Telang
# [[RPL UDP]] Jiahao Liang



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