Net2WG/Notes/20071130
Contents
Net2WG/Notes/20071130 Meeting Notes
Agenda
* 4-bit LE feedbacks from HotNets * Directory structure for 6lowpan * plans for DIP
Participants
* Om, USC * Phil, Stanford * Rodrigo, UCB * Matus, ETH * Razvan, JHU * Mike, JHU
Discussion Notes
4-bit feedback
Om: There was one comment. Why not make the physical layer export information other than just one bit. They were not totally convinced that that is the minimum information only provided.
Phil: Kyle said the presentation went really well. However, he felt that there is a clear seperation between EGP and wireless people in network.
6lowpan folder directory structure
Matus: On the PC, you need something that reads from the USB port and uses the TUN interface. This is a daemon.
Phil: Since it uses the TUN device, does it work under Linux, cygwin, and so on?
Matus: I have only tried Linux, and the TUN device could be a problem on Windows.
Rodrigo: There is a project at Berkeley called Ocala, which is meant to bridge different overlay networks. And they have successfully used a TUN device on Windows.
Phil: More people are using Cygwin than Linux. However, we don't need to support Cygwin before putting the code in repository. Having said that, getting it to work on Cygwin is pretty important.
Matus: And all mote code should be under net/6lowpan?
Phil: Yes. Protocols generally have subdirectory, and interface and general components are in the top-level net directory.
Matus: what the PC daemon code?
Phil: I think under Support. Support code are code you need to support TinyOS.
Matus: Should I put it under a different directory in support/sdk/c? 6lowpan?
Phil: Sure.
Matus: I will put the command line interface tool in apps. It is mote code that allows a mote to listen to UDP port.
DIP
Phil: It is a completely different implementation of all disseminations.
Om: Can you use the same interface for DIP?
Phil: Yes.
Om: Then, we will just create a new directory under dissemination for DIP.
Phil: Maybe it is useful to motivate why this is useful. Essentially, Trickle exchages version numbers. So, as the number of items increases, you have a linear increase in the overhead. The current TinyOS dissemination uses a parallel scheme where each item has a trickle. DIP introduces a order of log d cost to actually figure out which item is different, through maintaining a hash tree. And, nodes just exchange hash values. As you have a large number of items, even if you have a few items, say 8, DIP is more efficient.
Om: What is the code size?
Phil: 3K of program code. The cost is that there is an additinal byte per item.
Om: Any application on the horizon?
Phil: This is completely a scalability argument. I think a management system where you want to maintain a number of parameters. It would be good to find common case today.
Going Forward
Phil: Going forward, 6lowpan and DIP code will be in. And, there are some CTP issues to address. However, what is on the horizon? OpenZigBee implementation?
Om: Andrea actually ported OpenZigBee implementation to TinyOS 2 now. However, he is not ready to commit yet, and he is trying to figure out how to develop under two different version control systems.
