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
- Re: [Fwd: Re: [manet] Power Saving in 802.11] Jean Lorchat
- Re: [Fwd: Re: [manet] Power Saving in 802.11] Justin Lipman
- Re: [Fwd: Re: [manet] Power Saving in 802.11] Jean Lorchat
- Re: [Fwd: Re: [manet] Power Saving in 802.11] Peter Pham
- RE: [Fwd: Re: [manet] Power Saving in 802.11] dholmer
- RE: [Fwd: Re: [manet] Power Saving in 802.11] lorchat
- RE: [manet] Re: Power Saving in 802.11 dholmer
- Re: [Fwd: Re: [manet] Power Saving in 802.11] Miguel Sanchez
- RE: [Fwd: Re: [manet] Power Saving in 802.11] David Holmer