Freigeben über

802.11 WLAN WiFi : Power Mini FAQ - Windows CE

  • Artikel

Mini Frequently Asked Questions related to WLAN, Power, and Windows CE.

Why is it important?

  1. WLAN can use significantly more power than other wireless technologies. For this higer battery consumption, you may get much higher performance. WLAN is not inherently poorer performer with regard to power; many times it is the use case that needs to be refined.
  2. WLAN is being used in small battery powered devices. High power usage and small battery leads to poor battery life.
  3. WLAN is being used for new scenarios beyond web browsing. This introduced assumptions and problems not previosuly anticipated in the original use case.

How much power does WLAN use on CE?

  1. While associated to an Access Point, it can use between 5-250 mA.
  2. The power consumption is (current X duration).
  3. It is useful, but sometimes difficult to isolate WLAN from the CE host processor.

Why is there such a range in power consumption?

  1. WLAN can be in several modes, those modes correspond to what the user would like the WLAN to do next.
  2. The use cases can be very complex; recall wireless does not necessitate mobility. WLAN also operated in a unlicensed frequency band.
  3. On the lower range, the WLAN chip, while associated, stationary, and in 802.11 Power Save Mode, with certain DTIM settings can be extremely power efficient.

What are the power modes for WLAN?

  1. There are multiple modes across different vendors but we can assume 4 modes - Active Mode, Low Power Mode, Unconnected Mode, and Off.
  2. The names may differ but the functionality is similar.

 Can you describe Active Mode?

  1. Active mode consumes the most power.
  2. Active mode is generally used when connected to an AP.
  3. Active mode provides the lowest latency.
  4. Active mode provides the best performance.
  5. Active mode is useful for transfering data.
  6. Active Mode (w.r.t. Power) may be used for Scanning

Can you describe Low Power Mode?

  1. Low Power Mode consumes significantly less power than Active Mode.
  2. Low Power Mode can used when connected to an AP.
  3. Low Power Mode may introduce more latency.
  4. Low Power Mode will reduce performance.
  5. Low Power Mode is useful for timer based operations - when you know when you need to wake up again.
  6. Low Power Mode is useful for associated, idle, and in 802.11 Power Save Mode.
  7. Low Power Mode is a good state to be in when not transferring data.

Can you describe Unconnected Mode?

  1. Unconnected Mode consumes significantly less power than Low Power Mode.
  2. Unconnected Mode is when you are unconnected and not trying to connect.
  3. Unconnected Mode needs to be woken up by another process -- not timer based.
  4. Unconnected Mode does not enable a timer.
  5. Unconnected Mode can not be used to SCAN.
  6. Unconnected Mode can not be used to CONNECT.
  7. Unconnected Mode provides some power to the WLAN NIC.
  8. Unconnected Mode provides minimal difference over OFF.

Can you describe Off?

  1. Off implies the WLAN NIC is not powered.
  2. Off means the WLAN is not connected.
  3. Off implies the operating system may not see/notice the device.
  4. Off is the lowest power consumption.

Also See Diagram in blog titled:

"Simplified WLAN (WiFi) Power States"

Comments

  • Anonymous
    December 18, 2006
    Imagine that - exactly the subject I'm interested in, posted just this week.  Unfortunately, I still have a question: I have a CE5.0 (Pocket PC) device whose WiFi I'd like to programmatically force to be up permanently.  It seems to be powering itself down periodically when not attached to an access point.  Subsequent accessing of the WM5.0 Comm Mgr shows that WiFi has been disabled; clicking brings it back up again, but not for long.  The drop times don't seem to be correlated with the 10-minute timeout on the WiFi Settings/Power page.  I've used SetDevicePower to force it to D0 and queries against GetDevicePower before & after suggest that the API is working and performs as expected, but it doesn't solve the problem. Is this not a power-related issue at all (i.e. there's some other disabling timer at work)?  Is the system lying to me about the API's efficacy in usermode (i.e. I need to shift my calls into a driver)?  Is there a separate API that would suit me better? Thanks - IR

There are devices which implement a "in-activity timer" which turn off the WLAN adapter; these devices would explain your behavior. The main reason is power efficiency -- if you left it on and you went out of range (e.g. drive home), it would continue to try to connect. If this is the behavior you want the battery can be quickly exhausted if appropriate WiFi coverage (e.g. configured and visible) is not quickly found. To overcome this behavior, there are often device-specific settings which relate to power and or WLAN. In one device, if you leave it on "Highest Performance" and change other "Leave WiFi on" flags to be true, the WLAN would stay on. You are trading off "automatic connect" with "power costs". Under certain assumptions, you win under others you lose.

  • Anonymous
    January 07, 2007
    Greets, How can I set programatically the power state of an SDIO WLAN driver? Thanks.

There are several aspects of power: Host, Miniport, firmware. The host power notification can be controlled via the registry and how a miniport adapter re-acts to changes in response to the notifications. WLAN is NDIS power aware and can be controlled using this system-level notifications. For example, a WLAN miniport may want to stay up (D0) when the host is in standby. See: http://msdn2.microsoft.com/en-us/library/aa923906.aspx At a miniport level, the NDIS OID's provide finer granularity via: http://msdn.microsoft.com/library/en-us/NetXP_r/hh/NetXP_r/217wirelessoid_bca9862e-feea-406f-b11d-ea01859bfbd3.xml.asp Also use OID's like Ndis802_11PowerModeMAX_PSP, Ndis802_11PowerModeFast_PSP to control miniport driver behavior. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/NetXP_r/hh/NetXP_r/217wirelessoid_fa28e557-cdb3-475b-b8e7-294dba46a9ab.xml.asp Finally for firmware, a WLAN NIC can also do IHV specific calls to the firmware to tune chip-specific aspects of the NIC. Obviously these vary by IHV.  

  • Anonymous
    January 16, 2007
    The comment has been removed

  • Anonymous
    January 17, 2007
    Usually #1 -- when no activity is seen by the driver in a certain interval. The implementation can be using a higher level application or iphelper api's.For #2, the assumption is WLAN is used for browsing and the backlight is a good proxy for when to turn off the WLAN. If the user does not reset backlight for 'n' seconds after a backlight off, it may be a good hint to turn off the WLAN.When to turn off WLAN should be decided by the usage case; if it is only used for browsing the usage case is quite simple. Other situations are more complex to model.

  • Anonymous
    January 18, 2007
    Thanks Cenet for your response, Due to timing reasons, I will be implementing #1 at the application level, I will create an application that will get the WLAN card stats over a user defined interval, and if there is not activity it will turn off the WLAN card However it seems there is no standard IOCTL that will allow me to get the WLAN card stats, the IOCTL "OID_802_11_STATISTICS"  will return a pointer to a ""NDIS_802_11_STATISTICS " structure However this structure has two data members that can be useful “ReceivedFragmentCoun” and “TransmittedFragmentCount” but these two stats Include the # of Data/Management bytes that have been transmitted/received and I am only interested in Data Bytes (because they correspond to real WLAN activity, real data transfer I think ), I assume "Management Bytes" include the "Beacon" that the WLAN card send to the Access point saying "I am connected" so it keeps the connection alive. So is there is another way to do this or to separate the Data/Management bytes in the IOCTL call above? Also, what is the optimal way to power off/on the WLAN card, I tried using “SetPowerRequirement()”, the call succeeds (handle is valid ptr) but nothing happens (card LED still flashing and I am still connected to the Access point //NDL1 is the name of the WLAN card that I have      HANDLE handle=SetPowerRequirement(TEXT("NDL1:"),D3,POWER_FORCE|POWER_NAME, NULL, 0); //I have tried D4 as well I even tried using IOCTL_POWER_SET on the WLAN driver but it fails (DeviceIoControl () returns False with GetLastError() returning "0: Error_Success" afterwards and LED still flashing and I am still connected I don’t understand how the DeviceIoControl () call fails and GetLastError() says Error_Success Below is my code //g_pszAdapterName = TEXT("IPN21281") the is the name of my WLAN card adapter hDriver = ::CreateFile(g_pszDriverName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, 0, NULL); if (INVALID_HANDLE_VALUE != hDriver) { CEDEVICE_POWER_STATE ps; ps=D4; bRes = ::DeviceIoControl(hDriver, IOCTL_POWER_SET, NULL, 0, &ps, sizeof(ps), &dwBytesOut, NULL); //bRes is false here, so i call GetLastError() If(!bRes) dwError=GetLastError(); //dwError is 0, 0 is defined in Winerror.h as "ERROR_SUCCESS" Thanks for Your help

  • Anonymous
    January 23, 2007

  1. IPHelper API is suitable for User Data statistics. http://msdn2.microsoft.com/en-us/library/ms907329.aspx
  2. Turn off NIC via OID_PNP_SET_POWER (D0 .. D4) // this is the NIC Turn off Radio using OID_802_11_DISASSOCIATE  // this is the RADIO A RADIO is part of a WLAN NIC. If the RADIO is OFF the NIC can not be used but it can be SEEN by the OS. If the NIC is OFF, the device driver is typically unbound and device/interface is not seen by the OS. Depending on how long you are turning off the WLAN, you can either turn off the RADIO or the NIC. In many cases, if you are out of range for a long period, turning off the NIC is optimal. Depending on your scenario, your driver can do either. Turning off the RADIO (at some firmware level) usually reduces power by > 95% versus ACTIVE MODE. Turning off the NIC usually reduces power by > 99 % versus ACTIVE MODE. Take measurement to confirm trade-offs; there are power and timing costs of going in and out of different power states. Typically these power savings benefit outweigh the other costs.

  • Anonymous
    February 27, 2007
    Hello and thanks for your answers In my application i register for NDIS connection status changes (so when WLAN is removed i terminate some of my app threads and release recources, etc) the way i am registering for NDIS status change is below (the code<> section) the problem is that i get  "NDISUIO_NOTIFICATION_UNBIND" when Active Sync cable is unplugged or WLAN card is removed, imy question is there is any way to determine the differenece between the 2 events another question, when i power off the WLAN card via the SetDevicePower API below SetDevicePower(g_szDeviceName, POWER_NAME, D4)) is it necessary to issue "IOCTL_NDIS_UNBIND_ADAPTER" IOCTL call to NDIS? when i power back the WLAN card, i issue "IOCTL_NDIS_REBIND_ADAPTER" IOCTL call and this cause NDIS to get "NDISUIO_NOTIFICATION_UNBIND" state change <code> NDISUIO_REQUEST_NOTIFICATION ndisRequestNotification = {0}; NDISUIO_DEVICE_NOTIFICATION     sDeviceNotification; hMsgQueue = CreateMsgQueue( NULL, &msgQueueOptions); ndisRequestNotification.hMsgQueue       = hMsgQueue; ndisRequestNotification.dwNotificationTypes = NDISUIO_NOTIFICATION_MEDIA_CONNECT | NDISUIO_NOTIFICATION_UNBIND; //issue command to NDIS to register for NDIS state notification changes if (!DeviceIoControl( g_hNdisDriverHandle,IOCTL_NDISUIO_REQUEST_NOTIFICATION, &ndisRequestNotification,sizeof(NDISUIO_REQUEST_NOTIFICATION), NULL, 0, NULL, NULL)) while (WAIT_OBJECT_0 == WaitForSingleObject(hMsgQueue,INFINITE)) { while (ReadMsgQueue( hMsgQueue, &sDeviceNotification, sizeof(NDISUIO_DEVICE_NOTIFICATION), &dwBytesReturned, 1, &dwFlags)) switch(sDeviceNotification.dwNotificationType) { case NDISUIO_NOTIFICATION_MEDIA_CONNECT:  // break; case NDISUIO_NOTIFICATION_UNBIND: // break; </code>

  • Anonymous
    March 01, 2007
    We are moving a little off WLAN power...This may be better as general WLAN.NDISUIO notifications:1) Use IOCTL_NDISUIO_QUERY_BINDING to get the names of all miniport adapters bound to NDISUIO.2) Query OID_GEN_PHYSICAL_MEDIUM on each of such miniport adapter to find out if it supports NdisPhysicalMediumWirelessLan, if it does then its wifi card. This way one can know the name of wifi adapter. Currently we have RNDISFN1 as name of interface representing RNDIS over USB.3) When application gets NDISUIO_DEVICE_NOTIFICATION & event is NDISUIO_NOTIFICATION_UNBIND then it can look into ptcDeviceName to find out the name of miniport interface.4) If interface is RNDISFN1 then it is because somebody pulled out USB cable (ActiveSync over RNDIS) or somebody did unbind on RNDISFN1.5) If ptcDeviceName indicates name of wifi miniport interface then its wifi interface getting unbound.Re: NDIS UNBIND of WLAN cardNo. In fact we would recommend not doing unbind, so that Microsoft Wireless Manager can keep showing WiFi in its list.