Net2WG/Notes/20080502
Contents
Meeting Notes
Agenda
* Collection TEP * AM ID allocation * Problems with CTP with LPL
Participants
* Phil, Stanford * Om, USC * Razvan, JHU
Discussion Notes
Collection TEP
Om: I sent an email 5 minutes ago, I'll update with the latest signature of the LinkEstimator and stuff... and I think that's the only thing we need to change.
Phil: OK.
Om: The process is to send it to the steering committee. Should we bottleneck on it?
Phil: Core sent TEP 125 a month and haven't heard back. We should just find and external reviewer.
Om: Ok, I'll CC David Culler and send it to Andreas.
Phil: Sounds good.
AM ID allocation
Om: I think we had enough discussion and convergence about this. Let's hear from Razvan. The idea is that net2 will reserve the AM IDs between 128-255 and it will a subset for its own protocols and also coordinate the allocation for other protocols from core that might need AM IDs. That's the basic proposal. The reason is that an application can uses a low AM ID will note have to worry about conflicting and the other reason is to build a repository of the way the AM IDs are used.
Razvan: Sounds fine. One question: why not use 0 to 127?
Om: That's a good question. Phil do you have any comments? One reason is that most people will pick small numbers. That's my guess.
Phil: Yeah. In general when you develop protocols you start with lower numbers. There was another reason...
Om: Something else: Matus sent and email asking if this has any impact on 6lowpan.
Phil: No. This was TEP 125. What it does is specify the format of 802.15.4 in TinyOS. It basically says that TinyOS frames must support 16-bit addresses and there are two types of frames: T-frames and I-frames. T-frames are frames as they are today while I-frames will indicate that they are not 6lowpan packets.
Om: OK, so this doesn't have anything to do with this.
Phil: Yes, this is something outside the net2's worries.
Om: Any other questions?
Razvan: The examples from the apps directory, do they need to use this high AM IDs?
Phil: The idea is that all the things in tos directory needs to be 128-255.
Razvan: Thanks. That's all.
Om: OK, I'll send an email on devel about this and then will set up a wiki page were we list all the AM IDs.
Phil: That's a good question: should it be a wiki page or a TEP. Like a TEP that never exists the draft state. That's because the wiki is outside the tree. It make sense to have it documented in a TEP.
Om: Yeah. It would not be hard to do a TEP and as you said it will always be a draft.
Phil: OK.
Om: There is only one thing to discuss about this. Should we be as contiguous as possible?
Phil: It would be probably good to be contiguous.
Om: Maybe we'll start with 240 and make all 240s dissemination and all 250s collection.
Phil: Yeah. One thing you might want to do is to structure in hexadecimal instead of decimal. So all Fs will be collection type, all Es will be dissemination type and so on.
CTP with LPL
Om: There seem to be some problems. I'm offering to do some testing on Tutornet.
Phil: That's what we need: in depth testing. We also need to do it on Mirage. I chat a little with David Moss over email and he says that b-mac style of modulation might be better then x-mac style. There was a mac in TinyOS 2.0.1 that did that so I ask him about that but he's really busy.
Om: We have a slightly modified version: on the root we have a 30 second periodic beacon. When we do LPL with CTP with this we get about 90-95% reception rate.
Phil: What is the duty-cycle? 50%?
Om: Yeah. It was very high but we've tried sleep intervals up to 2 second.
Phil: When you send a packet each 8 seconds you don't have a feasible LPL. If you have the nodes sending packets every 8 minutes, do a little bit of buffering and then try with LPL. And also change the beacon intervals to something like 8 minutes. Then check the duty-cycle.
Om: Yeah. I'm trying to prove that the conception that CTP with LPL is broken is wrong. We haven't started to optimize the duty-cycle yet.
Phil: Their version of CTP might also be different than the one you use and other stuff. They also do mobility.
Om: Yeah. I'll do a test though and we'll have the logs.
Phil: Cool. That's a great idea, to have a detailed log.
Om: That's net2 for now then.
