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

[Joe Polastre]

Hi Kevin,

  Some comments based on my philosophy which you can choose to
agree/disagree with:

> Another issue is how to separate components within each of the
> strategies so that implementations of a B-MAC like protocol, for
> example, could use the same CSMA strategy as B-MAC but implement some
> variation of Low Power Listening without having to reimplement both pieces.

Although this would be great in an ideal world, I just don't see the
point.  If you don't want the LPL part of B-MAC, then you don't enable
it.  But trying to tease B-MAC apart into separate pieces so that
someone can use the CSMA strategy (and even harder yet, in a
platform/radio independent manner) just doesn't seem to be a huge
overall win.

In general, is innovation occurring at the link layer?  For the most
part, no.  I think that if someone (ie, you) is willing to put in the
effort to do this for all the standard radios, then it may be worth
consideration.

> If this CSMA component were to be radio indepenedent, however, a radio
> HIL would have to be developed that allowed the CSMA component to
> control some of the radios settings, such as txPower, switching between
> the tx state, rx state, and idle state, etc..  Maybe by thinking about
> all of these issues we will actually be able to come up with a RadioHIL
> (at least for a subset of the radio's control features... obviously not
> yet accounting for the differences between packet and byte radios in
> terms of sending data).

You need to clear up your terminology.  Up to this point, radios in
TinyOS have included their MAC protocol within the radio code.  What I
recommend is a different structuring of the radio stacks, one where
the packet send and receive mechanisms are the radio "driver" and then
the MAC protocol is built on top of that.  S-MAC employed this method
a few years ago, and I think it is the right way to go.  Then you
build your MAC protocols above the radio packet driver.

This gets to my next point: what is the HIL of the radio and can one
even exist?  In other words, is the HIL the interface to the radio
driver or to the MAC?  I argue that an HIL for either cannot possibly
exist.

Providing platform/radio independent access at the physical layer to
link layers is extremely tricky to do in a power efficient manner.

> Back to the of idea of creating the CSMA component for use by the radio
> power management strategies......
>  From what I've seen from the current implementations of the CC1000 and
> CC2420 radios for tinyOS-2.0, having such a separation could be realised
> quite easily.  As of right now, the radios are broken into a B-Mac
> component and a send/receive component.  If these could be further
> separated in a clean manner, then it would be a start at realizing the
> organization of the comonents described above.

Not necessarily true.  Jason and I have implemented other mechanisms
for performing the LPL channel that does not perform the full CSMA
that occurs when trying to transmit a packet.  This change is to
optimize the start time of the radio and return to sleep after using
minimal power.  Because the LPL sample needs to minimize its power
consumption, the CCA can't be broken away from it in a general
component.

Anyway, none of this really has anything to do with non-MCU power management

-Joe

_______________________________________________
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