Difference between revisions of "EE 652 projects"
(→= Heat Diffusion Routing Algorithm Contiki Implementation - Pradipta) |
|||
| Line 44: | Line 44: | ||
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 | 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. | 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. | ||
Revision as of 07:52, 22 December 2014
EE 652 2014 Projects
Contents
- 1 Scheduling algorithms for IEEE 802.15.4e networks - Pedro
- 2 Heat Diffusion Routing Algorithm Contiki Implementation - Pradipta
- 3 Backpressure Control Protocol on IPv6 stack of Contiki - Mrunal and Chhavi
- 4 Modifications to RPL for Mobility - Pratyush Deshpande, Gopi Marella and Abhilash Hegde
- 5 LOADng for Contiki- Jiahao Liang, Zhikun Liu and Haimo Bai
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.
