Net2WG/Notes/20070215
Meeting Notes for Feb 15th, 2007
Present: Rodrigo, Phil, Om
Notes: Rodrigo
P: Report on the meeting at Sun, with the group doing the SUN Sun SPOTS. They are interested, but we were a bit hung up on the packet format issue. Let me step back and talk about what's going on in Core, about packet formats. The [[1]] working group had an RFC on a packet format to do many things, which evolved over many discussions, and became complicated. ArchRock (David Culler and Jonathan Hui) made a simpler proposal that uses chained headers identified by a single byte, that allow extensible and composable headers. You look at the byte, tell what header is there. Details not important here, but this is going forward, and there should be an RFC in mid march.
In any case the first byte is a dispatch field that immediately follows the 802.15.4 header. 6lowpan reserved 192 of those values, and the remaining 64 values are not 6lowpan. So to interoperate with a 6lowpan network, TinyOS needs one of those 64 values as the first byte, and then a normal packet follows. This is an I-Frame (interoperable frame). A normal TinyOS frame is called a T-Frame, and does not have this byte.
There is some discussion in the Core working group as to which type of frame is going to be the default, etc.
So Sun was wondering if we are coming up with a different set of standards. I said that no, this is a research platform and a research protocol, and it could even be implemented on a 6lowpan network, although it would be weird as it would be an overlay on top of a single-hop IP layer.
Otherwise there was a lot of interest. They also were concerned that this was not a complete solution, as there is no reverse route information. If we are already collecting and generating this ETX information, that could inform better ways of getting from a basestation to the individual nodes.
Om: What do we expect from them?
P: They will have to change their link layer, which currently uses 64-bit identifiers, and implement CTP in Java. We can also do an implementation of a modified TinyOS link layer, using their packet format, and show that CTP runs well in that scenario as well. We'd like to be able to drop a SPOT node amidst a TinyOS network running CTP and have it generate data, and vice versa.
R: How different are the two Link Layers?
P: I don't know all the details, I know they have different ID lengths. We could get someone from Sun to help with the specs.
Om: The way to look at this is that we are using CTP with something other than TinyOS.
P: Right. We can mention that it's possible, for example, to use the SPOT as a CTP basestation transparently, since it's a more powerful node. They have a 36uA sleep current. It's an ARM processor, they run Java. They have an ATMega processor that wakes up the ARM.
O: Another platform is the LEAP platform, Low Power Aware Processor, by Bill Kaiser's group. They have a daughter board with an MSP430, a CC2420, and a PXA255 processor.
P: We can check that, but showing it for one different enough platform is already very powerful.
R: Going back to one of their concerns, it's not exactly trivial to do reverse routing in CTP, because the trees are quite fluid, and there are consistency issues in storing the reverse path.
P: We didn't get deeply into that, but it was more like: you have this ETX gradient, maybe it's possible to use it to guide or scope the floods.
[Some results on MultiHopLQI, MintRoute on T2]
P: One interesting thing in CTP is that the beacon rate is coupled with the data rate. One way to look at it is that Beaconing is a neighbor discovery process that tries to also estimate link qualities. It guesses, and tells you which links are really good, which links are really bad, and so forth. The data path is then used to give the ground truth.
O: We should also look at finalizing the TEPs, pushing them to community review.
P: They haven't changed much with the implementation. Jay at Berkeley was looking at TEP 119, and it references interfaces that don't exist anymore.
O: We should also revisit the link estimation part, since there is now the LEEP TEP.
R: Somewhere in the TEPs we should also generalize the modularity we adopted, in the flavor of the paper 'A Network Layer Architecture for Sensor Networks'.
P: This is a good point. After this push to finish CTP, we should go back and refactor the code, and make the modules more generic. The CTP Forwarding Engine has 26 interfaces!
P: The TTX is in Cambridge, right after IPSN. It would be great if we had TEP 119, 118, 123, and 124 all solidified, sent to the steering committee.
P: The last question is whether we want to spawn a CTP working group, with a definite limited lifetime, that of its task. The Net2WG has effectively become the CTP Working group, and it's time to see if people want to make it cover a broader set of topics.
R & O: Isn't that a bit late, to make CTP into its own group?
P: There is still some things to be done, refactoring the code, some software engineering.
O: I will send out an email to the members, polling what they want to work on.
R: Asking more broadly what people want out of TinyOS networking.
O: Why would someone want a protocol to be part of Net2, for example?
P: Well, take person X, who wrote protocol X. You have a group of people with experience in building protocols, who will lend a hand, review and discuss. Your protocol will end up in the distribution, and be taken to the next level, of robustness, interoperability. I am sure some people would be interested.
