RE: [Fwd: Re: [manet] Power Saving in 802.11]

"dholmer" <dholmer@cs.jhu.edu> Fri, 07 November 2003 00:04 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09350 for <manet-archive@odin.ietf.org>; Thu, 6 Nov 2003 19:04:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu6r-0006ui-14 for manet-archive@odin.ietf.org; Thu, 06 Nov 2003 19:04:18 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA704HVa026573 for manet-archive@odin.ietf.org; Thu, 6 Nov 2003 19:04:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu6q-0006uW-TM for manet-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 19:04:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09338 for <manet-web-archive@ietf.org>; Thu, 6 Nov 2003 19:04:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHu6n-0003Ar-00 for manet-web-archive@ietf.org; Thu, 06 Nov 2003 19:04:13 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHu6n-0003Ao-00 for manet-web-archive@ietf.org; Thu, 06 Nov 2003 19:04:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu6b-0006tQ-NY; Thu, 06 Nov 2003 19:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu5p-0006sn-1z for manet@optimus.ietf.org; Thu, 06 Nov 2003 19:03:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09293 for <manet@ietf.org>; Thu, 6 Nov 2003 19:02:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHu5l-0003AR-00 for manet@ietf.org; Thu, 06 Nov 2003 19:03:09 -0500
Received: from blaze.cs.jhu.edu ([128.220.13.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHu5l-0003AO-00 for manet@ietf.org; Thu, 06 Nov 2003 19:03:09 -0500
Received: from Mercury (pelican.cs.jhu.edu [128.220.13.57]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id hA704HQQ016374; Thu, 6 Nov 2003 19:04:17 -0500 (EST)
Reply-To: dholmer@cs.jhu.edu
From: dholmer <dholmer@cs.jhu.edu>
To: manet@ietf.org, 'Peter Pham' <ppham@spri.levels.unisa.edu.au>
Subject: RE: [Fwd: Re: [manet] Power Saving in 802.11]
Date: Thu, 06 Nov 2003 19:03:08 -0500
Organization: Johns Hopkins University
Message-ID: <000901c3a4c2$8751edd0$e6dddc80@Mercury>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <3FA9AAEA.20104@spri.levels.unisa.edu.au>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The turnaround time from Tx to Rx cited in the 802.11 spec deals with a
somewhat different area than the power saving state transitions. A while
back I downloaded a document from Intersil called "PRISM Power
Management Modes" (application note AN9665) that was dated February
1997. This document details the power saving states of the original
PRISM chipset, current consumption, and most interestingly the time
needed to transition between these states. What I hadn't known before
reading this document, was that there isn't just one "sleep" mode, but a
number of different levels of power saving modes. Each mode corresponds
to deactivating a larger and larger fraction of the radio hardware. The
result of this is that "deeper" sleep modes consume less power, but take
more time to wake up from because more hardware must be reinitialized
and stabilized. Here is a basic summery of the operating modes they
described:

       Mode           Current  Recovery Time
Transmit (continuous)  488mA          NA
Receive  (continuous)  287mA          NA
Power Saving Mode 1    190mA        1 us
Power Saving Mode 2     70mA       25 us
Power Saving Mode 3     60mA     2000 us (2 ms)
Power Saving Mode 4     30mA     5000 us (5 ms)

Going from an active mode to a power saving mode takes essentially zero
time, but the time till fully active from a given power saving mode
takes the time listed in the table above. The wakeup process seems to
transition up through the power states, with some brief (10us) power
spikes when transitions are made. In other words, if you are in power
saving mode 4 (consuming 30mA) and are scheduled to be active at time T,
you begin by transitioning to power saving mode 3 at T minus 5000 us.
After a brief power spike, you'll be consuming 60 mA until T minus 2000
us when you transition to power saving mode 2. After another brief power
spike you consume 70 mA until T minus 25 us when you go to power saving
mode 1. Then you consume 190 mA until T minus 1 us when you make the
final transition to active mode. A graphical representation of this is
shown at the end of the document.

It seems that as long as we are setting sleep times for >5ms then the
turn on time isn't going to be much of a problem in actual
implementations. Obviously these numbers will be different for cards
with different chipsets, but the order of magnitude in timing should
probably be the same.

Now for your other question on how feasible is it to control the power
saving state of an actual NIC card. I haven't had that much experience
with attempting that yet. The real question is if that functionality is
available at the driver level, or if it is only a firmware controlled
feature. A quick search through the Linux open source orinoco driver
(which actually supports many types of cards) yielded no promising leads
for manual power control. However many options for enabling the default
802.11 PSM and tweaking its parameters were available. In a pinch, it
may be possible to switch the card in and out of PSM with very long
beacon intervals, but some in depth experimentation would be necessary
to test this out.

David Holmer

PS I had trouble locating a link to the Intersil application note. If it
has been removed, people can email me directly for a copy.

-----Original Message-----
From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of
Peter Pham
Sent: Wednesday, November 05, 2003 8:59 PM
To: Jean Lorchat; MANET
Subject: Re: [Fwd: Re: [manet] Power Saving in 802.11]

Hi

I am really interested in the time switch between the ``sleep'' state to

other state.

By the spec, the turn around time between Tx and Rx must be less than 
5micro sec. However it does not state this. I guess it should be in 
order of few microsec right ?

Although, it is easily modelled in ns2 or Glomosim, is it feasible in 
practice ?...What I mean is is that possible we can control the NIC card

as that easy ?. For example, can we change the Tx power as any level as 
we wish at anytime. Can we set the card to sleep mode and turn it back 
on at anytime as we wish.

Is there anyone has any info on this...I appreciate some ``real'' 
knowledge on this.

Cheers
Peter Pham

Jean Lorchat wrote:

> Hi Justin,
>
>> From your conclusion (quick read), it would seem that the first order

>> radio model I quoted is reasonably accurate in terms of reception and

>> transmission?
>
>
> Although these are not my conclusions (I'm not the author), that's 
> what it seems.
> However, I think that John is right when he states that we should 
> differenciate
> so-called idle mode corresponding to "discarding a packet not intended

> to us" and
> real sleep mode that 802.11 hardware is capable of (namely PSP in 
> infrastructures).
> But knowing this, you must also have a way to use it in adhoc mode 
> (and I don't know
> whether adhoc PSP is a good solution for manets...) ? or do you mean 
> MAC modifications ?
>
> Jean
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet