This class continued the theme of working towards picking the best 10 or so papers of the semester for a wireless sensor network "Hall of Fame". Over spring break we were asked to pick 5 favorites of the 27 the papers we've read so far. We started off the discussion by going over peoples picks and kicking off a new format for the class. The two top papers were TinyOS (ASPLOS'00) and the Radio interferometric localization. There were 4 papers that were in the running for the three remaining slots. Great Duck Island, NesC, Dozer, and Pixie. We decided to keep them in the running for now.
The topic for this class was programming models. As sensor networks mature, it's natural to think about interacting with them at a higher level. Our first paper for discussion was Tenet. Tenet argues for tiered sensor net deployments with simple leaf nodes interacting with more powerful master nodes. Programming the network is done through tasks, which are a linear combination of tasklets. Master nodes disseminate the tasks to the motes which perform the requested operation and send their results to an available master.
Some of the class liked the idea of specialized motes, as one size does not fit all, but wondered how easy is it to decide where to place these master nodes. Then discussion turned to would it be possible to build a mote that could switch from a low power mote to a high power master node, perhaps by using something like dynamic frequency scaling?
There was some concern that this model does not fit the idea of a scattered node deployment (think of nodes being tossed out of a plane), but this is a myth. Very often in real deployments, nodes are placed with some care, but Tenet does have an extra level of planning than some of the other systems we have looked at.
One of the advantages of Tenet is that global coordination is easer than other systems as tasks only come from the masters. Their main claim is the easy of management and usability, but they could do a better job of selling this. It seems like this could extend the lifetime, but no real energy evaluation was provided.
One disadvantage is that you have to code for two different platforms, the motes and the master nodes. They didn't make a convincing argument that it's easier to do this in the master. The usability of the system could be a big win, but the paper didn't convince some of us that it is easier. It seems like they are just pushing the complexity around in the system rather than reducing it.
There is a tension in systems between simplicity/reliability and capability. Tenet comes down on the side of simplicity but did they take advantage of this? They could have talked about all the complexity of the mote-peg as a straw man, and beat up on that a little. That would have been more more convincing. The class voted on the paper for the CS263 hall of fame: 3 weak accepts, 7 weak rejects and two strong rejects, so it didn't make it.
Our second paper was Declarative sensor network. They attempt to come up with a general-purpose, easy to use, efficient programming model for sensor networks. They created Snlog, a dialiect of Datalog to program the network. The application gets translated into a intermediary dataflow representation that uses chains of database operators that is then compiled as an executable for the nodes. They implemented several systems in datalog, such as multi-hop collection, tricke, a tracking app, and many others that they didn't have the room to describe.
The apps seem concise and all could fit on a power point slide, but that lead to our first point of discussion. Could a domain scientist get her application working and get up to speed quickly in such a system? Someone commented it's like writing your application in Haiku. This got a chuckle out of the class and led Matt to his own blog entry on the topic. The point is that maybe several pages of code that you can understand and reason about is better than a half page of code that you have little wiggle room to get wrong. Debugging sensor networks is hard, and these DSN models are tough for some people to wrap their heads around. Despite what the authors want you to believe, sensor networks are not databases.
What does using a DSN buy you? It gives the complier and runtime some flexibility in how to implement it. It's like having an automatic transmission in your car. But you still have to think about programming at the node level. You're basically writing a state machine for the node. The node specifiers are critical to programming the system. You need to pin down on the node the statement is running on, however you are only allowed to name one hop neighbors. There is implicit communication going on and commands are inducing communication in the network. It may be hard to get a handle on energy usage in this systems. As for nominations to the hall of fame there were 4 weak accepts 5 weak reject 3 strong rejects, so we were 0 for 2 with this class.
Wireless Sensor Networks - Spring 2009
