Net2WG/Notes/20081212

From TinyOS Wiki
Revision as of 09:29, 1 August 2012 by Gnawali (talk | contribs) (New page: ---------- = Meeting Notes = ---------- = Agenda = ---------- * LPL API and Apps * IP Stack = Participants = ---------- * Mike, JHU * Razvan, JHU * Steve, UCB * Om, USC * Martin, ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Meeting Notes


Agenda


* LPL API and Apps
* IP Stack

Participants


* Mike, JHU
* Razvan, JHU
* Steve, UCB
* Om, USC
* Martin, Xbow
* Phil, Stanford


LPL API and Apps


Om - Should we have any app other than multihoposcilloscopelpl.

Phil - mvizlpl.

Om - Lets talk about the current API for LPL.

Phil - It allows different tx interval

Om - But what are the implications for receive?

Phil - Base station is the special case - you assume an always on base station.

Martin - A good API would be some default and per packet configuration. Could do #define.

Razvan - For my work on CTP+LPL, I have an LPL controller for global setting and LPLAMSender for per packet configuration.

Om - In my work using LPL, I used #define. Makefile.

Razvan - In the current API, an application does not know when the radio wakes up. This would be necessary if application wants to do something (send another packet) when the radio wakes up.

Phil - An example would be, CTP sends beacon, and dissemination could immediately send its beacon.

Razvan - Right. My low power controller has explicit event for radio wakeup.

Om - What you want is probably packet was sent instead.

Razvan - Sure. Signal it after the preamble.

Martin - SP message futures like mechanism?

Phil - It says how many packets you can send. send/senddone is pretty fast. The urgent bit is more interesting - it means don't queue it for a long time. It was built around rts/cts, not clear if it carries over to LPL.

Martin - Would be nice to be able to say, I was able to send to node 37 let me try to send again. Can't do that right now.

Razvan - I have been working on putting LPP and LPL in the same framework.

Om - Queueing will be more efficient - scan the list and transmit.

Phil - Why not just queue?

Om - This changes how send has always worked. It becomes push type sending model.

Phil - Why change how sending has always worked in ctp, dip, drip, ...?

Phil - Layer 3 protocol sends a pkt when it receives a pkt. how will this work with LPL?

Razvan - Awake call: eg. offtimer for lpl, signal at the end of the preamble. Probe from call. For example from 37 so that we can send to 37.

Martin - Timing for "everyone is awake" could be tricky.

Om - In the short term, default setting and being able to change per pkt.

Om - Razvan, did you look at eth lpl stack?

Razvan - It is a complete clone of CC2420. Keep track of neighbors when they are on. So when you send you wait until the destination is awake. So different from LPL.

Om - Pair-wise synchronous. At layer 3 not much different in semantics.

Razvan - Some weird things about interface names and semantics. Radio start with LPL means turn the radio off. radio start done means now the radio is off. We need to explore how to make these calls more intuitive.

Om - Agree. We need to make lpl use more intuitive and easy for protocols and applications to use.


IP Stack


Om - The decision is we will replace the current 6lowpan stack with Steve's. He now has the permission to commit.

Steve - I have Irises. Plan to change messaging and put it into core.

Om - We will do a pass over the TEP and send it to the list for discussion. We are still looking for a good name.

Steve - It has 6lowpan, routing, Collection, UDP, IPv6 neighbor discovery, point-to-point routing - send the pkt up to the edge router and then back down. It also uses a single phase send interface.