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

[Kevin Klues]

Regarding the non-cpu Power Management discussion for tomorrow.......

It seems like there are a variety of strategies out there for doing 
power management of the radio...
1) Sleep Scheduling
    -- Periodic vs. Aperiodic
    -- B-MACs low power listening
    -- S-MACs
    -- T-MACs adjustment of sleep schedule times
    -- WashU's aperiodic sleep schedule protocol -- ESSAT
2) Backbone Routing with Sleep Scheduling
    -- uses a sleep scheduling strategie and chooses nodes to stay awake 
and go to sleep
    -- SPAN
    -- WashU's Backbone routing protocol -- MASP
3) Tx Power Control
    -- Topology Control
    -- Power Aware Routing
    -- WashU's Real-Time Power Control Protocol (RTPC) -- BOOST
4) Integrated schemes
    -- Try to exploit advantages of all schemes
    -- WashU's MPCP protocol

Ideally, the interfaces for each of the radio power-management 
strategies should be the same, so that intergrated schemes can simply 
use a variety of the prexisting components to implement its protocols.  
Coming up with these interfaces could be one issue for discussion.

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.

Maybe a common interface to some Csma component could exist underneath 
all of these strategies that may or may not be radio dependent (haven't 
thought enough about this).  This component would provide the 
CSMAControl and CSMABackoff interfaces for that radio, while all of the 
components above it could be implemented platform independently and 
simply interface to this chip dependent component. 

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). 

Actually... to go off on a tangent for a second if I may....
A HIL interface for data transmission for packet radios could be created 
that is aligned with the current HAL for the CC2420 and similar radios.  
A HIL interface for byte radios could then be developed with platform 
indpendent components implemented on top of it that are built up in such 
a way as to make it match the packet radio HIL.  (I actually started 
working on this at Berlin befor I left, but I guess the work never got 
exposed to the group).  Just something to consider since it has never 
been adressed within the group yet.....

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.

I guess the botton line in all of this is that components exisiting 
above the CSMA layer only need to tell it two things in terms of 
producing sleep shcedules. 1) That they no longer require the use of the 
radio, and 2) At what time they will need it again in the future.  The 
CSMA layer can then use this information to put the radio to sleep and 
wake it back up again as required.  With an interface like this a 
multitude of protocols can  be implemented  using the organizational 
structure outlined above.

For Tx Power Control Protocols, they would simply need to tell the CSMA 
compoennt (or the radio directly) which power setting to set the radio 
to. The CSMA protocol in this case would never put the radio to sleep, 
it would only perform its normal Csma functions for deciding when to 
send a packet.

Integrated schemes could then easily use both of these interface to the 
CSMA component for managing power in both ways. 

By organizing the components that implement each of the power control 
strategies in the way described above, it will make it easier for common 
components between each strategy to be reused, as well as make it easier 
for new protocols and power managment strategies to be developed. 

How to align this with other non-cpu Power Management strategies I 
haven't thought about yet..... but it should follow the same principle.  
Each component should somehow announce when it will require the use of 
some other component.  And some intermidiary component should exist 
between them that makes sure that the component being requested is up 
and running by that time and turned off whenever nobody  wants to use it.

Kevin


Philip Levis wrote:

>On Tue, 2005-10-04 at 17:07 -0700, Jonathan W Hui wrote:
>  
>
>>We've pretty much covered the SPI offline. Summary of it was that it's important to 
>>capture both syncrhonous short transactions and asynchronous long transactions. So 
>>the interface supports both.
>>    
>>
>
>Yeah, there were a few weird edge cases that I hadn't thought of, but it
>turns out the current interfaces (and implementations) I put together
>for the CC2420 support them just fine.
>
>The one thing that was brought up which we didn't cover was power
>management, hence the agenda for this week. Given there's a Resource
>interface and startup times are negligible, having a StdControl
>interface seems unnecessary.
>
>Phil
>
>
>_______________________________________________
>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
>
>
>  
>

_______________________________________________
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