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

[Kevin Klues]

The reason I guess that I brought all this up is because I imagined the 
power management component for external devices all having the same 
interface, with an implementation specific to that particular device.  
This interface would be similar to the RefVolt interface for the 
MSP430.  Any number of components could connect to it, but once all 
components had released it, it would be able to go to sleep.  In the 
case of the radio, there are a large number of factors that come into 
play when deciding when exactly you want to put the radio hardware into 
some low power mode i.e. sleep/idle mode.  Instead of thinking about 
telling the radio when exactly to go to sleep and when to wake up, the 
idea would be to have some integrated component determining when the 
radio should be on or off and simply telling the radios power management 
component what to do. 

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.

I guess the idea behind this is to keep all code that actually deals 
with power managment of the radio (i.e. determing the sleep schedule in 
LPL in the case of B-MAC) separate from the code that simply turns the 
radio on and off. 

Having this separation is motivated by the fact that sleep schedulers 
exist in theory that are not tied to any particular CSMA/TDMA scheme for 
determing when data should be sent over the radio. They only know about 
their sleep schedules and when they think the radio should be turned off 
and turned on.  the CSMA/TDMA implementation might decide to leave the 
radio on if they are in the middle of using it to send some data or 
doing CCA, but they will then put the radio to sleep depending on what 
the sleep scheduler has told it.   It would be nice to have some 
architecture in place to be able to implement these types of sleep 
scheduling policies so that their performance can be evaluated.  For 
these types of sleep schedulers, the CSMA scheme that B-MAC uses would 
be perfectly reasonalbe to use and therefore gives some merit to 
actually performing this split now while implementations of the radio 
stack are still not completely stable.

Kevin

Joe Polastre wrote:

>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