Net2WG/Notes/20081017
Contents
Meeting Notes 10/17/2008
Agenda
* 802.15.4 / Zigbee WG * TEP
Participants
* Om, USC * Martin, CrossBow * Razvan, JHU
Discussion Notes
802.15.4/Zigbee WG
Om: The 15.4 WG proposal says the following. Building a standard compliant implenetation of 15.4, beacon-enabled mode, some security features. And, providing some enhancements, for example, traffic differentiation, hidden-terminal avoidance. The proposed chair is Vlado.
Martin: It makes sense to combine the two WGs. Zigbee leverages 15.4. Generally, you want the network layer, the MAC layer, and the application layer to align with each other. So, there is synergy in technical work, and you want people to talk with each other.
Om: Also, we should ask why they are not the same group since the members are almost identical. And, Martin, you are interested, right?
Martin: Yes. To the extent that I like the idea of standard complicance, and I like the idea of focus on the 2007 PRO spec.
Om: They don't specify which spec they are going to follow, right?
Martin: There is also the 2004 spec, but it doesn't make sense to implement the old one.
Om: Here is the draft of net2's recommendation. Basically, we have a question whether there should be two groups, for both technical reason and people reason. It seems to make more sense to have a single group.
Martin: As far as the enhancements, I am actually the chair of low-power routing in the Zigbee group. We have been pushing an X-mac style low-power listening strategy. It is similar to the paper X-mac. It is like an MAC-layer overlay in the network layer. There are certain things, such as the getting rid of the initial back-off, and your listening time will be a little bit longer. But, it will be a standard kind of thing. So, you can put low-power routing as one enhencement.
TEP
Om: We need sheperd for two TEPs. One is the CTP protocol implementation, like the header format. Another one is LEEP that tells you the packet format if you want to change bi-directional link information. Like how to put the neighbor table in the packet.
Martin: Do you have data on that? Like how reliable it is, average yield, how many nodes you have tried?
Om: Mirage has about 70 ~ 80 nodes, but they are very close to each other as they are on one floor in the Intel Research lab. We got good data yield from couple-hour run. We have done a much longer test run on Tutornet, which has about 50 nodes. For that, we have done 40 ~ 50 hours or something like that. Each node sends about 1 packet every 8 seconds. We got the yield of a little bit over 99%. Razvan, you also had experience with CTP, right?
Razvan: We are running it at high speed, we get a lot of losses.
Om: Can you send me a short description of that project? I am starting to compile a list of projects and places where CTP is used. Or, you can update the Wiki with the project description.
Does Xbow have any collection protocol? What kind of yield do you get?
Martin: We mostly use the low-power version, and we get like 98%. But, we haven't tried with environmental disruptions, like bluetooth.
Om: We also have not tried it. Also, the thing is we use Trickle timer, so we don't really lose a packet. So, when you lose a node, the children will not receive an ACK, and they will immediately choose another parent. If you haven't received any ACK, you fit that info into the link estimator, and you pick another parent. But, we haven't looked into stuff like jamming.
Xbow is moving away from this kind of stuff, right?
Martin: Not really true. We have Eko, which is a completely vertical system. It has iris platform, XMesh, low-power listening. It is suitable for agriculture and environmental monitoring.
Om: It would be interesting to compare the different collection protocols (also the one from Arch Rock), and see why we arrive at different design. I heard from Phil that the collection design from net2 and Arch Rock are not too different. Would you be interested in looking at something like that? How much of your stuff are proprietary?
Martin: I think we will be willing to talk about our stuff.
Om: Razvan, you said you have comments for TEP.
Razvan: In TEP 123, a few comments. In section 3, I think the packet duplication is a little bit confusing. You say it is bad without giving additional information. For example, you don't mention when we drop the packet and how we are going to filter it. In section 4, about the routing pull, I am a little confused whether it can be overheard or not. It would be great to explicitly say that you don't. In section 6, it is not obvious that the routing frame is always broadcast. And, there is no mention about how frequently to broadcast. In section 6.1, it is not obvious how link estimation and routing frame are related.
