Intel® vPro™ Technology

Mobile Manageability in Low-Power and Operating-System-Absent States

Manageability’s Handling of Mobile Characteristics Before the Advent of Intel® vPro™ Technology

In this section we examine how each of the differences between mobile and desktop computers, mentioned in the previous section, could be handled without Intel® vPro™ technology, according to the spirit of the ASF specification.

Dynamic IP
In a dynamic IP environment, when the DHCP lease expires and the computer is in an S0, OS-present state, the manageability logic could depend on some logic within the host OS to both renew the DHCP lease when needed and to push the provided IP down to the manageability logic.

However, in an S0, OS-absent state (for example, when the OS cannot boot), the DHCP lease could not be renewed in this way or else it would require BIOS support.

In an Sx state, the renewal operation would require that the manageability logic turn on the computer and boot the OS, in order to receive a new IP address from the host OS, and then return the computer to an Sx state.

Re-Associating with WLAN Access Points
When the computer is in an S0, OS-present state and the computer moves between WLAN networks (that is, loses connection to one AP but is in range of another AP), the manageability logic could depend on some logic within the host OS (for example, the host’s WLAN Connection Manager) to renew the association when needed, and push the associated AP’s profile down to the manageability logic.

However, in an S0, OS-absent state (for example, when the OS cannot boot), the association could not be renewed in this way.

In an Sx state, the re-association operation would require that the manageability logic turn on the computer and boot the OS, in order to receive a new WLAN profile from the host OS, and then return the computer to an Sx state.

802.1x Networks
802.1x networks are aware of the computers that are granted access on the network. Periodically, 802.1x switches may send a challenge to each computer, requiring the platform to provide an authentication response. If a computer fails to answer the challenge, it is excluded from the network.

If a computer receives an 802.1x challenge while it is in an S0, OS-present state, the manageability logic could depend on some logic within the host OS (for example, 802.1x supplicant) to respond to the authentication challenge when needed, or to actively request a challenge in case of link loss and renewal (as a challenge could have been sent while the platform’s link was down).

However, in an S0, OS-absent state (for example, when the OS cannot boot), this response mechanism would not work.

In an Sx state, in order to authenticate the computer with the 802.1x network, the authentication initiation operation would require that the manageability logic turn on the computer and boot the OS, in order to authenticate the computer with the 802.1x network, and then return the computer to an Sx state.

Computers Behind Security-Enabled Networks Outside the Control of IT Departments
When a computer is located in some security-enabled network (for example, one with a firewall or NAT) and the computer is in an S0, OS-present state, the manageability logic could depend on some logic within the host OS to initiate a client connection that would traverse the secured network, allowing the IT’s management console to respond and access the computer.

However, in an S0, OS-absent state (for example, when the OS cannot boot), a client connection could not be initiated.

In an Sx state, in order to open up a communication channel, the client connection would require that the manageability logic turn on the computer and boot the OS, in order to open up a communications channel, and then return the computer to an Sx state.

Switching Between AC and DC Power Sources
Original Equipment Manufacturers (OEMs) of mobile computers that contain Intel vPro technology generally accept manageability’s value in S0 states, even when the mobile computer is operating on DC power (that is, S0/DC state). In contrast, as of 2008, OEMs do not consider manageability to be valuable enough in Sx/DC states to warrant the extra drain on battery life. In addition, OEMs are concerned that IT personnel may explicitly decide to wake the computer remotely, bring it up from an Sx/DC state to an S0/DC state while the computer and its hard drive are tilted at an angle, or while the computer is located within a thermally constrained location (both cases being relevant to when the computer is located inside an end-user’s carry bag). Still, manageability does operate on Sx/AC states, just as it does on desktop computers.

Another point to consider is that manageability draws power from more than just the processor running the manageability program. In terms of power consumption, additional components are turned on when manageability is active, such as all manageability-supporting network adapters on the system.

The implication of this is that the manageability logic and all its associated components need to be switched on in Sx/AC states and switched off in Sx/DC states, even on direct Sx/AC to Sx/DC and Sx/DC to Sx/AC transitions.

In the past, the manageability components offered no support for receiving such dynamic powering decisions in these transitions:

• If the components were powered on in an Sx/AC state, they would remain on after they were transitioned to an Sx/DC state (wasting precious battery power).
• Conversely, if the components were powered off in an Sx/DC state, they would remain off after they were transitioned to an Sx/AC state (causing a denial of service for manageability in Sx/AC states).

There existed two possible methods to provide support for such dynamic decisions:

• The OEM’s platform logic could receive autonomic decisions about turning off or turning on the power to manageability’s logic and components. However, that could be problematic, because the OEM’s platform logic does not have direct knowledge of the IT department’s policy in powering the manageability components. (It is possible that an IT department may decide not to employ manageability in Sx states at all in order to save power.) In addition, in Sx states, the OEM’s platform logic has a limited view of why components are powered in a certain way. For example, if an OEM’s platform logic sees a LAN adapter that is powered, it may not know if the LAN adapter is on because of manageability’s powering requirements or because of other requirements of the host.
• Alternatively, dedicated hardware logic could wake up the platform and boot the OS on every transition from Sx/AC to Sx/DC and from Sx/DC to Sx/AC, just so the OS operating logic could power up or power down the manageability logic and associated components on the subsequent return to Sx/DC or Sx/AC states, respectively.

Why Relying on the Host OS to Handle Mobile Characteristics is Problematic
While technically feasible, reliance on a transition to an S0 state and waking the host OS to handle the characteristics of the mobile world poses a few problems:

• Using the host OS assumes that a working OS exists in the computer. However, one of the most valuable uses of manageability is that of remediation: an OS is broken and a new OS needs to be installed. If manageability cannot be used in this scenario because of loss of connectivity, manageability’s value to a corporation is greatly reduced.
• Frequently waking a computer poses the risk of creating unexpected side-effects. For example, waking a laptop while it is physically docked may sometimes cause the laptop’s hardware and BIOS to engage in a logical docking operation, even if the end-user meant to physically undock the laptop, or actually performed a software-undock of the laptop.
• When a laptop is woken, it may not be in its usual position. For example, a laptop may be in a tilted position, and powering it up may cause the hard disk drive’s heads to start spinning (an action that may damage the integrity of the data on the hard disk drive).
• Waking the OS from an Sx state when the platform is operating on a DC power source, as mentioned earlier in this article, will waste battery power (note that waking the OS itself takes time).

In general, all of these scenarios are examples of why a smaller manageability footprint on the system is a desirable direction, and why WoL evolved to ASF in the first place.

Back to Top