Introduction

This is a hands-on assignment to give you experience dealing with deeply emebedded networked systems. You should have received a Telos "kit" in class consisting of four Telos nodes. You can do this assignment in teams of two, but be sure each of you work through the tutorial and have your hands on the code. No "you code, I think". Both think, both code, both debug. The insights are often in figuring out what goes wrong.

Moteiv's support page has instructions on getting started programming Telos motes. You want to refer to page nine of the Quick Start guide, which presents the steps you need to go through to install the necessary software.

While working on this assignment, keep all of your components in an application directory. Your handin will be a tarball of that directory.

Part 1: Neighborhood Discovery

In class we observered that neighborhood management was fundamental. You'll get some experience with that. The first step is to have each node determine how many distinct neighbors it has and to render this number on the LEDs. This is built up from more or less a combination of CntToLedsandRfms and RfmToLEDs. The first step I would make is to eliminate the IntOutput layer and instead interface directly to GenericComm. This will allow you to define your own packet buffer, since you will need to send more than an int. (Alternatively, you can generalize IntOutput.) You will need to build up a neighborhood table data structure within a component and periodically display the number of unique entries in this table. You will need some kind of announcement to let neighbors knwo that you exist. You will also have to deal with nodes going away. How do you age them? As you turn on nodes, all the counts should go up. As you turn them off or take them away, it should go down, perhaps after a small delay. You will probably want to write and debug this and the remainder under TOSSIM.

Part 2: Slotted Ring

Now that you have announcements and a neighbor table you can do more with it. We'll build a simple slotted ring protocol. You can think of placing the nodes as numbers on a clock - although the number of ticks in a day depends on the size of the neighborhood. They need to agree on the order, the period of the tick, and the phase of the top of the clock.

The first step is to modify your solution from part 2 so that it displays the position of each node in the neighbor list, rather than the count. For a single fully connected cell, they should all agree on the list and their position in the list.

Make the tick a variable so that you can adjust it later, Start with say 1/4 second. Now we need to figure out the phase. A reasonable start would be that the lowest number node is the top of the clock and sets the phase by its periodic announcement. The other nodes can set their clocks to this, perhaps after adjusting for the send/receive delay. Alternatively, you could have all the announcements carry a timestamp and perform a more uniform resolution algorithm to bring the clocks into agreement. Once a node has figured out its slot in the ring, it can put out its announcement in its slot. This is the other major approach to media access control - build higher level structures that eliminate, or at least greatly reduce, the contention.

Part 3: Maintenance

We haven't yet dealt with nodes joining and leaving. You will need a way to age nodes (you stop hearing messages from them) much as you did for neighbor count. Joining is a bit more subtle. By listening the joiner can learn about the other nodes in the neighborhood. However, they wont hear about it unless it announces itself - and it doesn't have a slot in the ring. Intially they are all in that situation.

When you pull this together, the nodes should toggle their red LEDs in unison (or very nearly so). Turn on the green LED when ending a message in your timeslot. If you put them in a ring, it should go round and round. When a node is searching to determine its slot it should turn on its yellow led. In steady state, the yellow LEDs all go off.

Handing In

When you've completed the assignment, make a compressed tarball of a clean application directory (make clean in it before you tar it), and email it to Phil. If you worked in a group, each of you should hand in your code independently.