Technical Considerations for Intel® AMT in a Wireless Environment


Support for wireless connectivity in Intel® Active Management Technology (Intel® AMT) provides new functionality for makers of network management software. Because of inherent differences in the needs of wireless and wired connectivity, developers and IT organizations working with these capabilities are faced with a new set of considerations. This article introduces some of the key issues.


Intel® Active Management Technology (Intel® AMT), a component of Intel® vPro™ and Intel® Centrino® Pro processor technology, enables network management applications to access client computers when those computers are in a powered-off state or when they have a non-operational OS. This technology resides in firmware that is built into the chipset, providing an out-of-band communication channel that shares the physical network connection with the conventional network interface. Intel vPro processor technology is being rapidly deployed on business desktops, making support for it a key consideration for makers of management software.

With the introduction of Intel Centrino Pro processor technology, which incorporates functionality based on Intel AMT 2.5 that is similar in scope to Intel vPro processor technology, Intel extends that advanced manageability to wireless mobile computing. This addition brings another set of capabilities and considerations to the development of support for the technology. Because of the continuing increase in laptops being deployed as business PCs, support for wireless Intel AMT connectivity is an important feature set for management applications.

This paper introduces key issues associated with the technology, including the capabilities and limitations of wireless Intel AMT connectivity, specific guidance with regard to the development process, and where to go to get more information. The primary audience is the software development community, although members of IT organizations considering the deployment of wireless platforms that support Intel AMT will also benefit from it. For information that more specifically targets the IT community, please see "Enterprise Considerations for Deploying Wireless Intel® AMT Support" and "SMB Considerations for Deploying Wireless Intel® AMT Support."

Because the setup and configuration of Intel AMT on the whole is more automated for enterprise environments than for Small and Medium Business (SMB) environments, application support for wireless Intel AMT connectivity is necessarily more germane to the enterprise environment. For more information on the capabilities of Intel AMT and the differences between its use in enterprises and SMB networks, see the Intel® Manageability Developer Community. This set of resources includes tool downloads, technical documentation, use cases, discussion forums, and special software partner opportunities. A comprehensive technical description of Intel AMT is available from the Architecture Guide on that site.

Preliminary Considerations for Wireless Intel AMT Support

Though the addition of wireless Intel AMT support into a management application is not a major undertaking, the Intel AMT interface is logically separate from the network interface, and wireless profiles must be programmed directly into the firmware. The Intel AMT management engine (ME) is a small, low-power device that cannot synchronize directly with the host-resident set of wireless profiles.

Loading network profile information into the firmware brings up the issue of entering security information, such as network keys and other authentication information. Thus, management applications that support the configuration of the wireless Intel AMT interface must address the variety of security topologies employed by their customers' wireless networks. Note that the Intel AMT wireless management interface does not support open wireless networks, nor does it support Wireless Equivalency Protocol (WEP). Use of Intel AMT wireless connectivity typically requires the use of security included in or related to related to the 802.11i specification, such as Wi-Fi Protected Access (WPA) or Robust Security Network (RSN). It also optionally supports 802.1x authentication. Contact your Intel supplier for additional details about support for specific security protocols.

Note that, when the wireless Intel AMT interface is initially accessed for setup and configuration, it will by definition not yet have any wireless security profiles configured on it. For this reason, initial setup and configuration of the wireless Intel AMT interface must be accomplished by a wired, rather than a wireless connection. The wireless management interface is configured in the enterprise environment by Intel® Setup and Configuration Services 3.0 (Intel® SCS).

Further, consider that one of the key usage models for Intel AMT is that it allows management applications to access client computers when they are in a powered-off state, but the radio in a wireless network interface card (NIC) is not operational in power states other than S0. Thus, no Intel AMT functionality is available when laptops are powered down or in low-power modes (sleep, hibernate, etc.). While this may seem to be an undesirable limitation, it is also necessary, since otherwise laptops could be powered on at inopportune times, such as when they are being stored in carrying cases with inadequate ventilation or when their battery levels are very low.

Key Differences Between Wired and Wireless Intel AMT Support

While on a general level, the functionality of Intel AMT for network management applications is similar for wired and wireless connectivity, application design must consider a number of important technical differences:

  • Multiple, distinct management interfaces. System Defense policies are applied independently, with independent priority on wired and wireless interfaces. 802.1x profiles are applied independently on wired and wireless interfaces, and there is no facility to align host-based 802.1x profiles with Intel AMT. Wired and wireless management interfaces can not be on the same subnet concurrently.
  • Microsoft Active Directory* integration. 802.1x requires Active Directory integration with Intel SCS. This requirement is sp ecific to wireless implementation.
  • Link-sensitive flows. The redirection functionality of Intel AMT-Serial-over LAN (SOL) and IDE Redirection (IDE-R)-is not supported by the wireless interface when it is under the control of the host OS (transitions between host and ME control of the wireless NIC are discussed below). For these flows to be supported, control of the wireless network interface card (NIC) must shift to the Intel AMT ME, which interrupts the flow of other host traffic across the wireless NIC. Both SOL and IDE-R are supported in the wired context, simultaneously with host network traffic.
  • Power-state sensitivity. As mentioned above, the wireless Intel AMT interface, like the host wireless interface, is powered down when the host is in low-power states. Thus, the key value of wireless Intel AMT connectivity pertains to its ability to connect to machines with non-functioning operating systems, as well as to isolate malware-infected systems from the rest of the network. The wired management interface remains enabled in all power states, as long as the host machine is plugged into a power source.
  • DHCP dependence. The wireless management interface requires DHCP and does not support static IP addresses. In the wired context, Intel AMT supports both DHCP and static IP.
  • Wireless management interface disabled by default. The wireless management interface is always initially disabled, even if valid wireless profiles are configured in the ME and Intel AMT is enabled. Wired Intel AMT interfaces can be enabled by default at the point of manufacture.

In addition to these issues being relevant to the software-design process, they are also important factors for software makers to communicate to their customers, in order to provide a clear understanding of how wireless support for Intel AMT fits into the larger network and management frameworks.

Software Design Recommendations

Software makers enabling their applications for wireless Intel AMT support can benefit by taking into account a few special programming considerations. System architecture, form factor, mobility, power efficiency, and other factors all need to be considered during application development. The following recommendations are useful in product design and planning, to help ensure that wireless Intel AMT support is straightforward and successful:

  • A management application should not make assumptions about the amount of 3rd Party Data Storage it can allocate. Instead, the application should always examine the return code after calling ISVS_AllocateBlock() and use ISVS_GetBytesAvailable() to determine the number of bytes currently available for it to allocate. For more information about these functions, see the Intel® Active Management Technology Storage Design Guide.
  • Depending on its goals and scope, a management console can optionally provide the capability to manage wireless profiles and mobile power policy packages on Intel AMT-enabled mobile systems. Functionality within Intel SCS can help to simplify this process.
  • A management console should be capable of managing a system and policies associated with it on more than one network interface (including both wired and wireless interfaces).
  • To minimize impact on battery life, developers should expect Intel AMT features to be disabled when the system is in power states other than S0 (referred to here as SX power states) and running on battery power. When powered by AC power, System Defense will be disabled in SX states. This issue is particularly relevant with regard to the ability to gather statistics information from System Defense in all power states. On the wireless interface, Intel AMT will be disabled in SX states, whether it is powered by AC or battery.
  • When the client system is operating outside the corporate domain, critical events can be logged. The management console should retrieve these logs at a later time for examination.


The host Developers should also consider the shared use of and responsibility for the wireless NIC between the Host OS and the ME. When the host OS is functioning in a healthy state, Intel AMT traffic passes through the host wireless interface. When the OS is non-functional, so that the host OS wireless interface driver is unavailable, the Intel AMT wireless management interface continues to operate, taking control of the wireless NIC. Thus, so long as power is available to the NIC, Intel AMT management functionality can continue to operate.

As shown in Figure 1, specific events will cause control of the wireless NIC to transition between the host OS and the ME. In the Pipe state, where the host driver controls the NIC, management traffic passes through the wireless host interface (i.e., the ME 'pipes' management traffic to the host interface). In the Operational state, where the ME controls the NIC, management traffic passes through the wireless Intel AMT interface (i.e., the management interface is 'operational'). The transition of NIC control passes from the host driver to the ME only as a result of that transition being explicitly required.

For example, if the host driver for the wireless NIC is disabled, corrupted, or missing, if the OS crashes, or if ME control is required to support 'link sensitive flows' (i.e., SOL or IDE-R), the system triggers the transition from pipe state to operational state, and the Intel AMT device takes control of the NIC. Once the condition that caused that control shift is resolved (e.g., the host driver is enabled, repaired, or replaced, or the host OS is restored), control shifts back to pipe state, and the host driver takes back control of the NIC. The design of management software that supports wireless Intel AMT must anticipate and accommodate these control shifts, while providing for an unbroken monitoring session during the transitions.

Figure 1. Wireless NIC control states and transitions under Intel AMT

Development Support from Intel

Configuring wireless profiles in the ME is facilitated by the Wireless Configuration Interface APIs within the larger programmatic interface provided by Intel, which is fully documented in the Intel® Active Management Technology Network Interface Guide. Briefly, this interface as a whole allows access to Intel AMT features from a remote host, which allows network management software to perform actions such as the following:

  • Perform administrative operations.
  • Access the event log and manipulate the event filters.
  • Power off, power on, reboot, or wake up the PC.
  • Read hardware asset management information.
  • Read/write unformatted data to the public area of the non-volatile store.

The Wireless Configuration Interface provides a remote API based on SOAP and HTML that supports the creation and manipulation of up to 16 wireless profiles, as well as reading general wireless configuration settings. The Interface provides the following methods:

  • AddWirelessProfile – Adds a new wireless profile to the Intel AMT device
  • GetWirelessProfile – Retrieves a wireless profile based on the profile name
  • RemoveWirelessProfile – Deletes a wireless profile
  • UpdateWirelessProfile – Modifies the settings of an existing wireless profile
  • EnumerateWirelessProfiles – Retrieves the names of the defined wireless profiles
  • GetWirelessCapabilities – Returns the 802.11 subparagraph capabilities of the wireless interface
  • GetWirelessSettings – Identifies the active wireless profile and whether the wireless interface is active


The Intel AMT Software Development Kit (SDK), which provides low-level programming capabilities related to Intel AMT, documents the interface changes and provides sample code for wireless configuration. The SDK is available from the Intel Manageability Community.


With the increased deployment of client computers in the business environment based on Intel vPro processor technology, software makers in the network management market segment have an opportunity to distinguish their products by adding robust support for Intel AMT. As desktop systems with Intel vPro processor technology are joined by the laptop computers based on Intel Centrino Pro processor technology, those applications should also accommodate wireless connectivity to the Intel AMT firmware-based management device.

The addition of wireless support to network management applications carries with it some additional considerations that may not be immediately apparent, such as the need to configure wireless profiles into the firmware and the need to accommodate low power states where the wireless NIC is not active. Intel has anticipated key challenges to developers of these applications, and many of these are addressed by Intel-provided APIs, the Intel AMT SDK, and the material outlined in this paper.

By incorporating wireless AMT support into their management applications now, software makers are positioned to take advantage of the growing number of Intel AMT-enabled laptop computers that have begun to be deployed in the business PC market. By taking advantage of resources provided by Intel for that purpose, software vendors stand to be early to market with those solutions.

Additional Resources

The following materials provide a point of departure for further research on this topic:


For more complete information about compiler optimizations, see our Optimization Notice.

1 comment

Alder Lopez's picture

nice work, this information is very useful

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.