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

[Philip Levis]

On Tue, 2005-10-04 at 21:01 -0500, Kevin Klues wrote:
> 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

These are all good points, and we should keep them in mind. I think it's
important to start at the bottom, though. All of the things you list
above are  policies for how/when you turn off the radio. There's a more
basic question (and the one TinyOS has to answer first): what is the
mechanism for turning off the radio and how does that interact with the
rest of the system.

The approach until now has been that components have StdControl, stop()
powers them down (deep semantics) and start() powers them up (deep
semantics). There are big issues with these deep semantics: the recent
exchange on tinyos-help about "Why does the flash stop working when I
turn off the radio?" is a good example.

I think that, at the low levels of the system, we want mechanisms that

1) Work reliably and deterministically
2) Are very inexpensive (RAM and CPU)
3) Do not push expense to higher layers

Current deep semantics fail 1) and 3). The trick is solving those
without sacrificing 2).

One thing that's come up (which David G. commented on briefly) is how
you power manage shared resources. On one hand, you could go the
StdControl route with something OSKI-like. I think this solves 1) and
3), but sacrifices 2) somewhat (in terms of code and RAM). OSKI is
intended to be something high-level, after all. However, the fact that
we have the Resource interface means we might be able to leverage its
information to achieve 1) and 2) and 3).

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