However, WoWLAN is an interesting case study as more organizations move toward a mobile workforce where wireless networking is their primary connection. It provides insight into what technical hurdles must be crossed to achieve "Green IT" in a wireless world, provides lessons learned for organizations considering the "all-wireless" jump, and hopefully will compel large organizations to apply pressure to industry manufacturers to develop a suitable replacement technology.
Similar to Wake-on-LAN (WoL), Wake on Wireless LAN (WoWLAN) is a technology that allows remote wake-up of workstations from a standby power state to facilitate device management. WoWLAN is based on the well-established WoL standard used over wired Ethernet networks, and can provide similar functionality and benefits.
However, functionality is not entirely equivalent to WoL and there are a few serious limitations that may prevent organizations from considering WoWLAN a viable technology.
The ability to place workstations into a low-power mode provides one primary benefit to the organization, reduced facilities operational expenses. Green IT initiatives are pushing most organizations to find operational areas where energy consumption can be reduced, either through process improvement, equipment consolidation, or virtualization.
One primary method organizations are achieving these savings are through smarter workstation power management practices. Purchasing Energy Star certified equipment and minimizing device power draw during off-hours allow organizations to save a considerable amount of money.
Consider that desktops consume between 100 - 250 Watts when powered on, and around 2 - 6 Watts when in sleep/standby. On the other hand, laptops require between 15 - 60 Watts of electricity to run when active, but only around 1-2 Watts when in sleep mode. That difference can translate into a large amount of savings just by placing devices into sleep/standby mode when no one is using them. Assuming the typical office worker is using the workstation for only 8-10 hours/day, most organizations could safely place the machines into sleep mode for 14-16 hours.
Let's take an example using a laptop, since that will be the primary use-case for WoWLAN. We'll use a Dell Latitude D630, a common corporate laptop for the masses. This particular model consumes 46.87 Watts active, and 2.04 Watts in standby mode. Let's also assume that this is a large organization with an inventory of 5,000 laptops and is paying $0.10 / kW-hour.
Prior to implementing the standby mode policy, energy consumption would have been:
( 46.87 W * 24 hours * 365 days / 1,000 W/kW ) * $0.10 * 5,000 laptops = $205,290/year
After implementing the policy, assuming a 9 hour work day, laptops will be placed in standby mode for 15 hours each day:
[ ( 46.87 W * 9 hours) + (2.04 W * 15 hours ) ] * 365 days / 1,000 W/kW * $0.10 * 5,000 laptops = $82,568/year
Net Savings = $122,722/year (roughly 59% reduction in energy expense)
So, why not just implement our laptop standby policy, claim the expense reduction, pat ourselves on the back, and be done with it? Because most invasive IT processes run overnight when there is no user to impact. Just leaving a device in standby mode will cause all sorts of processes to break in almost any organization, big or small.
Some of the functional requirements for implementing Wake on Wireless LAN solutions include the following:
- Security Patching - typically scheduled for installation after business hours to reduce the impact to employees, security patching is one of those functions that needs to happen. Period. Running updates during the day is a quick way to frustrate and de-motivate employees. Even worse is scheduling it overnight, only to have a contradictory policy placing all workstations in standby every night preventing the patches from installing until the next morning when the employee returns to work and powers it back up. That's a quick way to make the IT department look incompetent and a major pain in the rear!
- Remote Desktop Access - some organizations support remote access for employees through a home computer with limited access to internal resources. Broader access can be granted by giving employees the ability to remote desktop into their corporate owned workstation sitting at work. This allows more functional access while maintaining close control over data exposure. In order to remote into the system, a method to wake it back up must be provided and reliably executed.
- All-Wireless Network - many organizations are now purchasing laptops rather than desktops for their employees for a variety of benefits, including mobility and productivity. This is shifting network traffic from wired to wireless networks, and thus places additional requirements on wireless solutions than previously existed. Deploying an "all-wireless" office is reasonably possible using Wi-Fi networks today, requiring equivalent functionality of a wired network.
How it Works
Wake on Wireless LAN works very similarly to traditional WoL solutions. Components include a network management application software suite that provides workstation inventory and central policy controls, a master workstation on each broadcast domain (subnet) which is selected by the management suite, and the use of broadcast "magic" packets used to wake up the remote system.
Here is a sample wireless magic packet (download for reference):
Although the example above shows an unencrypted magic packet, the security of the frame will be dictated by the network policy attached to the wireless network. Therefore, broadcast frames including magic packets will be encrypted using the GTK (Group Temporal Key). Therefore, wireless workstations in standby mode need to remain associated to the BSS in order to properly receive the magic packet. Although subtle at first, this requirement has a pronounced effect on workstation behavior while in standby mode, forcing the wireless NIC to come out of power-save mode in order to send traffic and maintain status in the BSS at regular intervals. A "listen-only" approach is no longer sufficient. This behavior also impacts the power consumption of the workstation, and although not large amounts of power are required, over a period of time such as several hours this could drain a laptop batter dry (especially an old battery).
In order to support WoWLAN, the wireless infrastructure will need to be configured to allow broadcast wireless frames to traverse the network. Newer enterprise class wireless networks typically have advanced features that filter broadcast frames by default to improve performance of the network. That feature will need to be disabled to allow WoWLAN to function properly.
Enterprise class systems generally integrate well with DNS for workstation resolutions and wake-up, rather than relying on users to identify workstations by MAC addresses. This enables usability of the solution for employees.
Typically a wired workstation will be selected in the broadcast domain to serve as the master workstation due to preference for higher bandwidth workstations, especially if connected via gigabit Ethernet.
Configuration of the workstation's wireless adapter is required in order to allow the adapter to wake the system from a standby or low-power state. This is accomplished on Windows machines through the adapter properties dialog:
To wake up a machine, the employee logs into the web portal, enters the workstation DNS name or selects it from a list and confirms the selection. On the back-end, the management workstation queries the device in DNS and within it's inventory to discover it's current IP subnet and stored MAC address. The master workstation for the subnet is then contacted to begin transmitting the magic packet for a pre-determined interval. The packet is sent out the wireless LAN during the next DTIM period, during which the wireless workstation awakes from power-save mode upon seeing queued broadcast traffic indicated in the DTIM beacon and receives the magic packet instructing the workstation to fully wake from standby.
Having tested this setup, I can say this process works successfully.
Although functional, WoWLAN does have some serious practical limitations. These limitations are fairly significant, and will likely prevent many organizations from deploying WoWLAN.
- Integrated Adapters Required - The wireless adapter is required to be integrated onto the motherboard in order to control the power state of the workstation (this category also includes mini-PCI and mini-PCIe adapters). Newer motherboards and plug-in wireless adapters do not have the required power connector and cable as some older systems provided. Therefore, external adapters that are not integrated into the motherboard will not be able to control the power circuity and thus cannot support WoWLAN.
- Limited On-Board Adapter Support - Notably, I have found that Intel adapters are the only ones which support WoWLAN. I am unaware of any other chipset manufacturer currently providing support for this feature. This is easily identified on Windows machines by checking for the presence of the power management tab and settings within the wireless adapter properties.
- Standby Mode Only - Because wireless clients must remain connected to the BSS at all times, standby mode is the lowest power state supported. Hibernation or full power off states will not work because no power is provided to the wireless NIC to maintain network association.
- AC Power State - During testing, one curious behavior seemingly played tricks on me for quite some time. It appears that power control of laptops by wireless adapters is quite sensitive to the AC power state. Wake-up from standby only appears to work when the laptop is placed into standby mode while connected to an AC electrical source and remains connected to that source until woken. If the laptop is removed from AC power while in standby, or initially placed into standby mode while on battery power, WoWLAN is ineffective. After thinking about this one, it is fairly logical to conclude that WoWLAN requires a certain amount of power draw by the wireless NIC to remain associated, possibly prompting concerns over battery life and integrity if WoWLAN were allowed to function while on battery power alone. Whatever the case, AC power is required at standby initiation and throughout the duration of low-power state.
- Negative Performance Impact - Allowing broadcast wireless frames across the wireless network will reduce network performance. This is an unfortunate side effect, but one that cannot be avoided. However, through proper architecture the negative impact can be greatly minimized. This includes blocking wireless client to client communication and isolating wireless clients on their own broadcast domain to minimize potential broadcast packets to the default gateway and potentially one wired master workstation for the subnet (strategically deployed by an administrator of course).
While technically feasible, Wake on Wireless LAN is saddled with severe limitations and lack of industry support. It is doubtful that most organizations could even consider a WoWLAN deployment unless running an environment composed entirely of Intel wireless adapters.
However, it appears that Intel has used its WoWLAN experiences and is bundling comparable functionality into its vPro feature line. Newer adapters that are vPro compatible (such as the Intel 6200 and 6300 models) claim to offer wireless system manageability and remote repair even when the system is in a completely powered off state. I suggest reading the vPro whitepaper linked above. It also clearly identifies the AC power state is still required to remotely wake a wireless client.
WoWLAN appears to have been a technology that missed wide adoption, but lives on through the learnings it provided. vPro stands ready to fill the gap, but requires newer hardware. I guess it's time to diligently update workstation requirements and purchase accordingly moving forward.
Intel WoWLAN Technical Brief (Sorry for the 3rd party website link. Intel seems to have pulled this tech brief off their website. Not a good sign!)
P.S. - If any has any WoWLAN experiences, I would love to hear about it. Please share your testing, results, and success / failures with this feature.