[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Bridge, agenda for TinyOS 2.x 10/5

[David Gay]

On 10/5/05, Kevin Klues <klueska at cs.wustl.edu> wrote:
> In the casse of B-MAC, the integrated component I refer to that
> determines when the radio should sleep or not would be the LPL portion
> of B-MAC, while the power management interface that this connects to
> could be implemented inside the CSMA component.   All code determining
> when the radio should be on or off would be determined by the LPL
> component (i.e. set through the LowPowerListening interface) and this
> information would simply be passed on to the CSMA component through the
> PowerMangamnet interface.  With this information, the CSMA compoennt
> could then decide whther to turn off the radio at the exact moment that
> the LPL releases it, or if it happens to be using the radio for some
> operation, putting the radio into sleep mode once it has completed.
> When the LPL component wants the radio to turn back on, it simply
> notifies the CSMA component through the PowerManagemnt interface, and
> the radio is immediately turned on.

There's two obvious reasons why this isn't that appealing:
- The B-MAC LPL scheduling code isn't complex enough to be worth
separating (there's not much complexity in "every N ms" ;-)). And
where it is more complex, it's tied to sending or receiving states
(e.g., if no message is received within X ms of apparent channel
activity, go back to sleep).
- the LPL code needs to know the radio's sending/receiving/etc state -
LPL-checks are only performed if the radio is idle.

To summarise, the interactions between LPL, carrier sensing, preamble
detection and noise floor estimation are complex enough that it's not
clear that trying to break them apart is fruitful.

David

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg