Net2WG/Notes/20080509

From TinyOS Wiki
Revision as of 10:35, 1 August 2012 by Gnawali (talk | contribs) (New page: ---------- = Meeting Notes = ---------- = Agenda = ---------- * TYMO problems * CTP Debugging and Documentation * TEP 4 review * ZigBee status = Participants = ---------- * Phil, St...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Meeting Notes


Agenda


* TYMO problems
* CTP Debugging and Documentation
* TEP 4 review
* ZigBee status

Participants


* Phil, Stanford
* Om, USC
* Razvan, JHU

Discussion Notes


TYMO problems

Om: Phil, why don't you tell me what it is and we'll put in the notes and encourage Romain to look at them.

Phil: I think Brano contacted Romain. Or he said he will. Basically what he found was that the TYMO implementation was really limited and he had to do a lot of changes to really got it to work. The kind of tests Romain has done was linear type topologies with a single route. That was the kind of extend it worked. Brano had to hack it to support mobility because there was no route discovery in it. There is no adaptation. Brano's plan was to contact Romain about it.

Om: Right, because Romain is the official maintainer. I'll ping both of them if I don't hear anything in a few days.

CTP Debugging and Documentation

Om: This is related to what Phil said last week about getting ready for 2.1. One this is to make the perl script that parses the debug messages available. That's the minimum. I think the Java person has disappeared.

Phi: What?

Om: There was a guy that offer to provide a Java program to look at the debug messages. It's fine. We should at least provide the perl script.

Phil: Uhm.

Om: Let's talk about documentation a little bit. My observation from the recent, and not-so-recent emails, from the help list, is that a lot of people want to do simulations. I think it would be very-very effective and it will avoid a lot of discussion if we'll have a section on simulation CTP.

Phil: OK. A CTP tutorial then.

Om: Yes. Phil, can you do it? You already did a lot of simulations, right?

Phil: It's not going to happen soon but I'll happen in time. It would be also nice to have the scripts that generate performance figures.

Om: Right. The tool we have right now is probably not very appropriate in the form it is right now.

Phil: If you do that I'm happy to do a good tutorial for simulation.

Om: What is the schedule?

Phil: Code freeze by mid June. We'll discuss on the next core call.

Om: Will the code freeze also include these scripts?

Phil: Yeah.

Om: OK, that's fine, we have a month.

TEP 4 review

Om: I was looking at TEP125 and it says that NALP (Not a LoWPAN frame) code has to be from 192 to 255. That is irrelevant, right? Or is talking about AM type?

Phil: To be complaint with 6lowpan the first byte after the 802.15.4 header needs to be in a particular range. It turns out to be 0 to 63. I'll update the TEP. So the I-frames need to chose a value there. The trick is you need to reserve that AM type so that it is invalid because a mote programmed with T-frames will parse them incorrectly.

Om: OK, so that AM type should never be sent.

Phil: Yes. You need to reserve an AM type according to NALP range.

[ re-explanation ]

Om: I understand now.

Phil: So you need to pick a value and reserver an AM ID. That's all. I just tossed 63 but it could be something else. The question is: if this value is in 0-127 shouldn't be that one reserved by net2. If we keep 63 we'll have to say in TEP4 that applications should use AM IDs in range 0-127 with the exception of 63.

Om: That's terrible.

Phil: YES! So what do we do?

Om: Maybe provide a smaller range?

Phil: So we'll tell applications to only use between 0 and 62? That would be kind of annoying.

Om: Yes. We cannot change the 0-63 range though...

Phil: We can pick 0 and tell them to use 1-127. We can also tell them to pick in the 128-255 range...

Om: That's sound better to me. How about you?

Phil: OK.

Om: OK, I'll swap the reserve and non-reserve ranges. We should put some explanation about this though.

Phil: Yeah.

Om: And that will be the rationale of why we picked that range.

Phil: you also need to go over the repository and change all the AM IDs.

Om: Yeah. I'll have to do that. Razvan, do you have any comments?

Razvan: My only comment is that I need to look into what AM ids I use in Deluge T2.

ZigBee status

Om: ZigBee current status is that we don't have an official maintainer. I've gotten Mario and Jan to talk to one another, they're both doing 15.4. So we will have a temporary maintainer, so we decide if we need two implementations, but if not we should do interop. So that's the status.

P: Is there a maintainer?

Om: IPP (school in Portugal) will send a name of who will maintain it. They will decide in two weeks if they can develop this or not. So that's the status on ZigBee.

Om: I am also going to follow up on opportunistic reception in CTP. One last thing. Should we write a tutorial page for Deluge?

Razvan: What would you like to be in there?

Om: I'm not saying we should get rid of the manual. Just that we might want something simple, how to use it. And then you can say, if you want more, here's the manual.

Razvan: I would like to do the full thing then the short thing.

Phil: I would recommend you do the short then the long. "HOw to use" will get people using it.

Om: At the minimum, you can get started with something small. I.e., "if you want to add deluge, do this." One of the things in 2.1 is a lot more documentation, that kind of thing. We'll have TYMO, that kind of thing.