WDI Miniport Driver Design Guide

Important

WiFiCx is the new Wi-Fi driver model released in Windows 11. We recommend that you use WiFiCx to take advantage of the latest features. The WDI driver model is now in maintenance mode and will only receive high priority fixes.

WLAN Device Driver Interface (WDI) is the new Universal Windows driver model for Wi-Fi drivers, for both Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows 10 Mobile. The WLAN device manufacturer writes a WDI miniport driver to work with the Windows 10 OS implementation. WDI enables device manufacturers to write less code than the previous Native WLAN driver model. All new WLAN features introduced in Windows 10 require WDI-based drivers.

Vendor-supplied native WLAN drivers continue to work in Windows 10, but functionality is limited to the version of Windows for which they were developed.

The WDI requirements and interface specification are documented in this design guide. The key goals for the new model are:

• Improve the quality and reliability of Windows WLAN drivers.
• Reduce the complexity of the current driver model, which in turn reduces the complexity of the IHV driver and reduces the overall cost of IHV driver development.

The focus of this documentation is to specify the flow and behavior of Wi-Fi operations between Windows and the IHV driver component. It does not cover software interface signature (for example, the device driver interface model) and details about how the IHV component is loaded in Windows.

Design principles

The following principles guided the overall model and design of this protocol.

1. Minimize the chattiness of the traffic between the host component and the IHV component/device. This is particularly important for implementations on buses such as SDIO, which is inherently chatty.
2. Wi-Fi functionality (especially functionality that must be performed with low latency) is expected to be handled by the device.
3. All regulatory related functionality resides in the IHV component and is controlled by the IHV.
4. The Windows experience is controlled by the host component and the Windows operating system.
5. Windows has the ability to resurrect hung devices. It has enough state to reprogram the IHV component and recover within 10 seconds.
6. Operations that require lot of system memory or fast processors and are not vendor specific are handled by the host.

Definitions

Term	Description
Device	The entire piece of hardware that connects to the bus. A device can have multiple radios in it (notably Wi-Fi and Bluetooth).
Wi-Fi adapter	The specific part of the device that implements Wi-Fi functionality as described in this specification.
Port	An object that represents a MAC and PHY state for a particular connection.
IHV component	The IHV-developed software component that represents the Wi-Fi Adapter/Device to the host.
Host	The host-side Microsoft/operating system software that interacts with the IHV component using the interfaces described in this specification.
Upper Edge Driver (UE)	UE refers to the WdiWiFi driver, called WDI in this documentation. The UE and the Lower Edge (LE) IHV driver combine into a complete NDIS miniport driver. The UE implements the core Wi-Fi logic.
Lower Edge Driver (LE)	LE refers to the IHV driver at the lower edge. The LE and UE combine into a complete NDIS miniport driver. The LE implements bus and hardware specific functions.
Functional Level Reset (FLR)	Functional Level Reset, as in the PCIe specification. This term refers to the reset of a function, versus a reset of the complete device which may have a composite function. The reset of such scope does not impair the other functions on the same device.
Platform Level Reset (PLR)	Platform Level Reset. This reset method impacts all functions on a device. It is very popular to build multiple functions on a device to reduce the cost and footprint. For example, Bluetooth is typically built with Wi-Fi on a chip. However, such a reset method resets all function units on the device.
Reset Recovery (RR)	RR refers to the event sequence of Reset and Recovery. For FLR, this includes: The request to NDIS, which forwards the request to the bus to reset the Wi-Fi function. Recovery of firmware context by the driver. Reconnection to the access point if it was connected before the reset. For PLR, this includes: The request to NDIS, which forwards the request to the bus. The bus interacts with PnP to surprise-remove the device. Re-enumeration of the device. Re-establishing the device stack. Wi-Fi is restarted and reconnects.
WDI commands	The UE sends WDI OIDs and calls LE callbacks. All of these are called WDI commands.
MAC Address Randomization	In order to improve the privacy of Windows 10 users, configured Wi-Fi MAC addresses are used in some circumstances, such as before connecting to a particular Wi-Fi network or when initiating scans in specific conditions. This only applies to the station port. The system ensures that randomization is used appropriately, so important connectivity scenarios are not broken. The system manages changes of addresses by issuing OID_WDI_TASK_DOT11_RESET commands prior to issuing a scan or connect command. The reset command parameters include an optional MAC address argument. If the argument is present, the MAC address is reset to the specified value. If it is absent, the MAC address is left to the current value. When configuring randomized MAC addresses, the operating system uses the "locally administered" format defined for IEEE802 addresses.
ECSA	Extended Channel Switch Announcement.

Related topics

WDI Miniport Driver Reference