Lab 3 Routing in Sensor Networks

Lab 3Routing in Sensor Networks Based on slides from Andreas Larsson 2013

Part 1Sensor Networks

What is a sensor network?

Wide Range of Sensor Nodes Table from CY Chong, SP Kumar, BA Hamilton - Proceedings of the IEEE, 2003

Deployment

Setting up the network

MicaZ Sensor Node

Usage patterns • Sleeping • The Main Task • Data gathering • Data aggregation • Data communication • Auxiliary Tasks • Synchronization • Security

Examples of uses COMMONSense • Utility • Structural health monitoring • Agriculture • Parking space guidance/monitoring • Research • Volcanos • Permafrost • Animal behavior Permasense

Part 2 TinyOS and nesCProgramming Selected slides from: Wireless Sensor NetworksHardware/SoftwareTiny OS & NesC Programming borrowed from TurgayKorkmaz

What is TinyOS? • Operating system developed by UC Berkeley • Open Source development environment • System, library and applications written in nesC • nesC (network embedded system C) a component-based C • Event-driven architecture • Single shared stack • NO kernel, process/memory management

Programming Model • Basic concept behind nesC: • Separation of construction and composition • Programs are built out of components

provides Timer StdControl Timer Component Clock uses Components • A component is a black box specified by interface(s) • Interfaces define a set of logically related I/O functions called commands and events • Components use and provide interfaces • Components are statically wired together based on their interfaces StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Clock.nc interface Clock { command result_t setRate( char interval, char scale); event result_t fire(); }

provides Timer StdControl Timer Component Clock uses Component Commands Events Provide Must implement Can signal Use Can call Must implement Components (cont’d)‏ • A component • Processes Commands • Throws Events • Has a Frame for local state • Uses Tasks for concurrency • Components must implement • the events they use and • the commands they provide

Commands and Events { ... status =callCmdName(args)‏ ... } • Commands • deposit request parameters into the frame • are non-blocking • need to return status • postpone time consuming work by posting a task • can call lower level commands • Events • can call commands, signal events, post tasks • can Not be signaled by commands • preempt tasks, not vice-versa • interrupt trigger the lowest level events • deposit the information into the frame commandCmdName(args) { ... return status; } event EvtName(args) { ... return status; } { ... status =signalEvtName(args)‏ ... }

Component Hierarchy • Components are wired together by connecting users with providers • Commands: • Flow downwards • Control returns to caller • Events: • Flow upwards • Control returns to signaler

Types of Components • There are two types of components: • Modules: provide code that implements one or more interfaces and internal behavior • Configurations: Wires/links components together to yield a new component • A component does not care if another component is a module or configuration • A component may be composed of other components

uses provides CommControl ReceiveMsg StdControl SendMsg ForwarderM Leds Component Syntax - Module moduleForwarderM { provides { interfaceStdControl; } uses { interfaceStdControl as CommControl; interfaceReceiveMsg; interfaceSendMsg; interfaceLeds; } } implementation { code implementing all provided commands used events, and tasks } interfaceStdControl { commandresult_tinit(); commandresult_t start(); commandresult_t stop(); } interfaceSendMsg{ commandresult_t send(uint16_t address, uint8_t length, TOS_MsgPtrmsg); eventresult_tsendDone(TOS_MsgPtrmsg, result_t success); }

Component Implementation uses provides CommControl ReceiveMsg StdControl SendMsg ForwarderM Leds moduleForwarderM { //interface declaration } implementation { commandresult_tStdControl.init() { callCommControl.init(); call Leds.init(); return SUCCESS; } commandresult_tStdControl.start() {…} commandresult_tStdControl.stop() {…} eventTOS_MsgPtrReceiveMsg.receive(TOS_MsgPtr m) { callLeds.yellowToggle(); callSendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } eventresult_tSendMsg.sendDone(TOS_MsgPtrmsg, bool success) { callLeds.greenToggle(); return success; } } Command imp. (interface provided)‏ Event imp. (interface used)‏

provides uses StdControl CommControl ReceiveMsg GenericComm ReceiveMsg Main StdControl StdControl SendMsg SendMsg ForwarderM Leds LedsC Leds Component Syntax - Configuration configuration Forwarder { } implementation { components Main, LedsC; componentsGenericComm as Comm; componentsForwarderM; Main.StdControl->ForwarderM.StdControl; ForwarderM.CommControl->Comm; ForwarderM.SendMsg->Comm.SendMsg[AM_INTMSG]; ForwarderM.ReceiveMsg->Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.Leds->LedsC; } Component Selection Wiring the Components together Forwarder

Part 3Lab 3: Routing in sensor networks DSII: Group Comm.

Lab 3 • The lab is done on the computer: • dark.cs.chalmers.se • You will receive a username and password in pingpong. • TinyOS with all sources for libraries and everything is installed at /opt/tinyos-2.1.0 • Unpack Rout.tar.gz into your home directory (at the server) and do the assignment from there. • Compile the program by executing: make micaz sim • Run the simulation by executing: ./simulation.py <topology file> • Build topologies using buildtopo.py to get a grid and then remove some nodes to get some interesting formation

Part 1 – improve the basic routing • Implement something better than the basic routing algorithm. • The battery level is something that is known to a node, so feel free to use that in your algorithm. Sink • Messages: • Announcement • Content

Part 2 – Clustered data aggregation • Aggregate information and send it to the sink. • Many nodes in an area send their information to a cluster head • The cluster head sends the aggregate message to the sink. • A simple algorithm to choose cluster head: • for every node with a certain probability announces itself to be a cluster head. • Choose the parameters you like: battery level of the node, battery level of neighbors, etc. • A cluster head should not store content for more than 1 round.

Report and Presentation • Report: • Part 1: • Discuss the idea behind your algorithm. • Present results from comparing your algorithm to the original algorithm. • Discuss failed improvements. • Part 2: • Discuss the idea behind your algorithm. • Present results from comparing your algorithm to your algorithm in part one. • Discuss failed improvements. • Presentation: • Each group gives a 10 min presentation of their algorithm. • March 6, 13:15-17:00, Room: EL42.

Lab 3 Routing in Sensor Networks