[CUWiN-Dev] Re: Solar powered nodes, sleep-wakeup scheduling & WSN(Wireless Sensor Network)s

[Stephen Ronan]

That looks like a terrific project. This may be of related interest:
http://green-wifi.org
esp. the last paragraph here
http://green-wifi.org/projects/gw/concept.html
- Steve

Sascha Meinrath wrote:

> Hi Ashish,
>
> I'm out of town for the next couple weeks, but the CUWiN offices are 
> (217)278-3933 x30.  I know Dan just got back to town after a long week 
> working on a CUWiN installation -- you can try calling the offices to 
> get in contact with him.  It would be fantastic to see additional 
> features integrated into the CUWiN feature-set -- having nodes be more 
> energy efficient would be extremely useful.  Could you send in an 
> updated timeline/benchmark schedule for what you plan to do?
>
> --Sascha
>
> ashish makani wrote:
>
>> Hi Dave,Sacha, Dan & the other folks
>>
>> Let me introduce myself ...am ashish makani, & my background is 
>> WSN(Wireless Sensor Network) s.
>>
>> Let me give a brief background on WSNs here...WSNs are a network of 
>> multiple nodes called motes. Motes are basically wireless sensors + a 
>> processor, in a match-box form factor .
>>
>> So motes are devices, which esentially combine 3things : a processor, 
>> a wireless radio(usually zigbee 802.15.4) & 1/more sensors, & 
>> typicall run of 2AA batteries.
>> The motes (usually) run a lightweight os c/d TinyOS developed @ 
>> UCBerkeley
>>
>> The beauty of WSNs is that these nodes(or "motes" as they are called 
>> in the WSN commuity) run a mesh routing protocol...so if i have 5 of 
>> these motes, i power them on, each mote determines, there are other 4 
>> others around it, and each automatically detrmines routes to others. 
>> So motes enable "out-of-the-box" networking
>>
>> so basically mote = processor+radio+sensor...with the proc running 
>> some wireless mesh routing protocol stack
>>
>> WSN research has been going on for a a long time, and sleep-wakeup 
>> scheduling is a very well studied problem in WSNs ...as the radio 
>> consumes quite some power & if the motes were to remain "awake" all 
>> the time, the battery powering the mote, would run out in a matter of 
>> days.
>>
>> So in WSN deployment allmost all of which are in the field, where 
>> there is no wired power, it is critical to conserve power by 
>> intelligently scheduling so that only a small subset of all the nodes 
>> in a n/w are "awake" at any given time & the rest are put to "sleep", 
>> with the overall goal of maximizing total network lifetime.
>> "sleep" here does not mean zero energy/power consumption but one 
>> which is an extremely low Power state in which all mote 
>> subsystems(processor,radio,sensor) go to their 
>> lowest-energy-consuming state
>>
>> But the important difference in the power scheduling of WSNs & CUWiN 
>> is that, in WSNs, nodes/motes wakeup when an "interesting event" 
>> happens(WSNs are very application specific...popular applications are 
>> defence like surveillance,vehicle/person tracking, industrial 
>> monitoring & control,etc. & the application defines what an 
>> "interesting event" is)
>>
>> While in CUWIN,
>> the objective of a sleep/wakeup scheduling algo would be to ensure 
>> that any time, there are a min.no <http://min.no>. of nodes awake to 
>> ensure that the overall CUWIN policy goals/throughput/other QoS 
>> parameters are met.
>>
>> As mentioned by Dave below, this would necessiate modifiying/atering 
>> the core CUWIN routing protocol, which (i think) is HSLS, to make 
>> sure that it figures out, in real time, the shortest paths/routes 
>> over CUWIN nodes(routers) that are awake at that instant.
>>
>> Quoting Dave,
>>  I think it is an interesting question, how do you modify a linkstate
>>  > routing algorithm so that it spits out both a wake/sleep schedule for
>>  > every node, and shortest paths over the routers that are presently 
>> awake?
>>  > Also, is it very much more difficult to do this if your routers are
>>  > hazy-sighted?  There may already be answers in the literature.
>>
>>
>> I browsed through Prof. Doug Jones(mentioned by Wendy) publications, 
>> & found this paper
>>
>> http://www.ifp.uiuc.edu/~jones/pubs/AppadIEEEJSAC2005.pdf 
>> <http://www.ifp.uiuc.edu/~jones/pubs/AppadIEEEJSAC2005.pdf>
>>
>> For the benefit of folks who might be interested in WSN literature 
>> for papers related to sleep-wakeup scheduling & other topics, I am 
>> mentioning some of the more popular sensor network bibliographic 
>> references below:
>>
>> 1.  http://ceng.usc.edu/~bkrishna/teaching/SensorNetBib.html
>> 2. ** 
>> <http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Fwww.research.rutgers.edu%2F%7Emini%2Fsensornetworks.html&ei=bHOrRKa_CqvEaPDJ3ZEI&sig2=2S-0RNAzFNdJSDdj18Ze3Q>http://www.research.rutgers.edu/~mini/sensornetworks.html 
>>
>> 3. http://appsrv.cse.cuhk.edu.hk/~yfzhou/sensor.html
>> 4. http://w3.antd.nist.gov/wctg/manet/manet_bibliog.html
>>
>> I (personally ) would be very happy to work on the modifications 
>> needed to HSLS, to enable nodes to sleep...and would want to discuss 
>> this with Dave/Sascha/Dan, off the list in greater detail.
>>  
>> cheers
>> ashish
>>
>> p.s. Dave/Sascha/Dan..what would be a good time to chat with u guys 
>> on gtalk/some other IM...am in bangalore which is GMT +0530...Let me 
>> know what would be a good time for you to chat & then we can fix up a 
>> mutually convenient time
>>
>> I tried calling OJC Tech office several(7-8) times@ 217- 278-3933, & 
>> tried to reach extensions 15 & 24(which are daves& sascha's 
>> extensions @ OJC tech but was not able to ....could not even speak to 
>> the operator....
>>
>>     Date: Wed, 28 Jun 2006 23:11:34 -0500
>>     From: "dan blah" <dan.blah at gmail.com <mailto:dan.blah at gmail.com>>
>>     Subject: Re: [CUWiN-Dev] Node power
>>     To: cu-wireless-dev at lists.cuwireless.net
>>     <mailto:cu-wireless-dev at lists.cuwireless.net>
>>     Message-ID:
>>             <a210c29f0606282111s1d6ad605h2b4f2d4b0a37c20c at mail.gmail.com
>>     
>> <mailto:a210c29f0606282111s1d6ad605h2b4f2d4b0a37c20c at mail.gmail.com>>
>>     Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>     sounds like something we talked about at the summit... sneaker net?
>>     not nearly as cool as your idea, one of the tdv nodes is running off
>>     an inverter run into a solar cell.
>>
>>     On 6/26/06, David Young < dyoung at pobox.com
>>     <mailto:dyoung at pobox.com>> wrote:
>>      > On Mon, Jun 26, 2006 at 01:48:10PM -0500, Wendy Edwards wrote:
>>      > > One night when I was having dinner with some CS/ECE friends,
>>      > > someone mentioned that Doug Jones (an ECE professor) may have
>>      > > done some research related to solar-powered network nodes.
>>      > > Has anyone from CU-Win been in touch with him?  If not, I'd be
>>      > > happy to send him an email.
>>      >
>>      > Wendy,
>>      >
>>      > Solar-powered nodes are interesting to me.  ISTR a few years ago,
>>     when
>>      > I spec'd the power requirements for one of our Soekris-based
>>     nodes, it
>>      > would have doubled the price of a node to add to it a solar cell,
>>     battery,
>>      > and regulator that would keep it alive through even a few days of
>>     clouds.
>>      >
>>      > These days, there are alternatives to the Soekris boards that
>>     draw about
>>      > 1/3rd the power.
>>      >
>>      > A neat wireless network would consist of oodles of cheap nodes
>>     powered
>>      > by small solar cells; the nodes would sleep (to recharge) and 
>> wake
>>      > on a schedule that guaranteed the network stayed connected.  
>> No node
>>      > would have to stay on all the time, so the solar cells could be
>>     small.
>>      > Deploying such a network would be easy: you would lob the nodes,
>>     which
>>      > would be wholly self-contained, onto rooftops.  I read about
>>     somebody's
>>      > study on this kind of solar-powered network somewhere, I just
>>     forget who
>>      > and where.  I think they were concerned with powering "sensor
>>     networks."
>>      >
>>      > I think it is an interesting question, how do you modify a 
>> linkstate
>>      > routing algorithm so that it spits out both a wake/sleep schedule
>>     for
>>      > every node, and shortest paths over the routers that are
>>     presently awake?
>>      > Also, is it very much more difficult to do this if your 
>> routers are
>>      > hazy-sighted?  There may already be answers in the literature.
>>      >
>>      > Dave
>
>