Native 802.11 Framework for IEEE 802.11 Networks - 1

Windows Platform Design Notes

Design Information for the Microsoft® Windows® Family of Operating Systems

Native 802.11 Framework for IEEE802.11 Networks

Abstract

This paper provides information to hardware vendors about a set of wireless services for the Microsoft® Windows® family of operating systems, including Windows CE and future versions of Windows.

Called Native 802.11, these services make it possible for a single network adapter to be dynamically configured as an access point or a station. Designed to reduce the long-term cost of goods and provide a superior end-user experience, Native 802.11 offers additional benefits to network adapter manufacturers, including new and enhanced support for quality of service (QoS), location awareness, roaming, and other features.

March 26, 2003

Contents

Introduction

IEEE 802.11 Standard

IEEE 802.11 Network Adapters and Native 802.11

Native 802.11 Miniport Driver Architecture

Native 802.11 Design Overview

Native 802.11 STA Design

Native 802.11 AP Design

Offloaded PHY and MAC Functions

PHY Layer Design

MAC Layer Design

NDIS Object Identifiers (OIDs)

Native 802.11 Benefits

Windows Logo Program Issues

Call to Action and Resources

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2003 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows NTare either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Introduction

Native 802.11 is an architecture for wireless local area networks (WLAN) that is integrated into the Microsoft® Windows® operating system. Native 802.11 is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification, which defines a shared WLAN standard using media access control (MAC) protocols that include carrier sense multiple access with collision avoidance (CSMA/CA).

A unified infrastructure, Native 802.11 allows a wireless network adapter to be configured into either a station (STA) or an access point (AP) mode through a user interface. By supporting Native 802.11 miniport driver interfaces, a network adapter can take advantage of all the Native 802.11 services, which include cooperative roaming, location awareness, power management, and more.

Through Native 802.11, a single network adapter can be configured and used to target both infrastructure networks, where an AP bridges wired and wireless LANs, as well as the adhoc networks. As a result, hardware vendors receive the following benefits by supporting Native 802.11:

  • Reduced development cycle. In the short term, implementing Native 802.11 represents an investment in development. In the long term, however, network adapter and driver/firmware requirements are reduced, as is ongoing maintenance in terms of development time and resource.
  • Reduced cost of goods. Native 802.11 mitigates the need for a microcontroller unit by providing IEEE 802.11 upper MAC functionality including MAC and physical layer management support and thereby reduces the cost of goods.
  • Greater usage. As hardware costs decrease, the adoption rate increases as the cell phone industry has aptly demonstrated.
  • Extensibility. Microsoft has defined the core infrastructure. The Native 802.11 framework includes versioning to ensure that future updates in standard specifications and additional features can be incorporated later while maintaining backward compatibility.

The information in this paper is intended primarily for network software developers and decision makers responsible for lower-level, network-related Network Driver Interface Specification (NDIS) device drivers for Windows operating systems.

IEEE 802.11 Standard

Windows operating systems support the IEEE 802.11 specification including solutions for the security, configuration, and management issues that arise when an enterprise considers deploying a wireless network.

IEEE 802.11 is a shared WLAN standard that allows for both direct sequence (DS) and frequency-hopping (FH) spread spectrum transmissions at the physical layer. The maximum data rate initially offered by this standard was 2 megabits per second. A higher-speed version with a physical layer definition under the IEEE 802.11b specification allows a data rate of up to 11 megabits per second using DS spread spectrum transmission. The IEEE standards committee has also defined physical layer criteria under the IEEE 802.11a and IEEE 802.11g specifications, which are based on orthogonal frequency-division multiplexing (OFDM) that permits data transfer rates up to 54 megabits per second.

IEEE 802.11 Network Adapters and Native 802.11

The adoption of IEEE 802.11, in both infrastructure and ad hoc network modes, can be greatly enhanced by having the network adapter perform functions that it is ideally suited for, such as lower MAC and physical layer functions. For example, the network adapter would perform time-critical functions, such as the transmission of IEEE 802.11 RTS/CTS. In this case, the Native 802.11 intermediate miniport (IM) driver would provide upper MAC functionality and management support for MAC and physical layer. The common Native 802.11 framework for network adapter management in either AP or STA operational modes ensures a unified and enhanced end-user experience.

Native 802.11 can configure the underlying network adapter into either STA or AP role assuming the network adapter supports the required STA and AP interface capabilities. The Native 802.11 service provides upper MAC functions in addition to management support for MAC and physical layers in the operating system. This ensures that base work at the Native 802.11 network adapter miniport driver level becomes much simpler leading to an improvement in the network adapter miniport driver quality and interoperability.

Native 802.11 defines the expected interaction sequence between the operating system and the following:

  • An IEEE 802.11 network adapter operating as a STA in infrastructure mode.
  • An IEEE 802.11 network adapter operating as a STA in Independent Basic Service Set (IBSS) mode.
  • An IEEE 802.11 network adapter operating as an AP.

Native 802.11 also specifies a network adapter’s expected operational behavior on query and set operations directed at the network adapter.

Native 802.11 Miniport Driver Architecture

The lowest layer in the system architecture of an IEEE 802.11 wireless infrastructure is a miniport driver, which performs the following tasks:

  • Forwards packets to the network adapter hardware for transmission.
  • Retrieves packets received from the network adapter hardware.
  • Handles interrupts.
  • Performs other control operations over the hardware.

Based on NDIS, Native 802.11 defines the way in which operations are uploaded and offloaded between the operating system and network adapter. A network adapter must support certain mandatory functions through this uploadand offload model, while Native 802.11 handles the transactions better accomplished through the operating system.

At the lower edge, an IEEE 802.11 network adapter miniport driver uses NDIS to communicate with the adapter hardware. At the upper edge, the miniport driver communicates with the Native 802.11 intermediate miniport driver, which in turn presents an interface to allow protocol drivers to configure the adapter and to send and receive packets over the network.

When operating in STA mode, decisions about when to roam, when media is available to the upper-layer stack, and so on, are all handled by the upper-level MAC functions, which reside in Native 802.11.

Native 802.11 also configures and initiates some lower-level MAC functions and handles PHY layer management. A portion of the lower-layer MAC and PHY functions, particularly time-sensitive functions, are handled by the network adapter. For example, encryption and decryption based on the Wired Equivalent Privacy (WEP) algorithm or Advanced Encryption Standard (AES) cipher are better negotiated in the hardware. However, to ensure continued data transmissions and receptions when keys are updated, Native 802.11 can optionally upload these functions into the operating system. Once the required key management functions are completed and the updated keys are handed off to the network adapter, Native 802.11 would offload these functions back to the network adapter.

Figure 1. Network Driver Configuration

Native 802.11 Design Overview

Native 802.11 is defined in terms of a software-based STA and software-based AP, which are merely logical entities used to clarify the behavior of a network adapter that can take on either the STA or AP role. As it is implemented in the Windows operating system, Native 802.11 is a unified infrastructure. The Native 802.11 functionality works for any Windows platform that includes a wireless network adapter supporting the required Native 802.11 framework and its interfaces.

Figure 2 shows STA and AP architectures side by side. The Native 802.11 configuration service configures an IEEE 802.11 network adapter for AP or STA operations.

Figure 2. Native 802.11 Architecture in Windows Operating Systems

Among other benefits, Native 802.11 makes layer 2 authentication (IEEE 802.1X) services available to the STA or AP. For example:

  • For a STA, enhanced security can be negotiated, such as through WiFi Protected Access (WPA), a subset of IEEE 802.11i, using TKIP-MIC or AES.
  • For an AP, authentication services can be integrated with a RADIUS client in an enterprise or a local SAM service or Passport server in a home or small office.

The sections below describe the Native 802.11 architecture in greater detail.

Native 802.11 STA Design

As Figure 3 illustrates, when an IEEE 802.11 physical network adapter is connected to a WLAN,the Native 802.11 miniport driver functions as follows:

  • Receive path.The Native 802.11 miniport driver passes relevant IEEE 802.11 packets received by the network adapter to Native 802.11 STA intermediate driver.
  • Send path.The Native 802.11 miniport driver receives IEEE 802.11 packets from the Native 802.11 STA intermediate driver and sends them out by means of the network adapter.
  • Hardware operations. TheNative 802.11 miniport driver subsumes some received IEEE 802.11 packets and generates some IEEE 802.11 packets on its own and sends them out by means of the network adapter.

The Native 802.11 STA intermediate driver acts as an IEEE 802.3 virtual miniport driver that handles IEEE 802.3-to-IEEE 802.11 packet conversion and vice-versa. The driver also handles IEEE 802.11 station operations, such as association and probe requests. The Native 802.11 STA intermediate driver functions as follows:

  • Receive path.It receives IEEE 802.11 packets from the Native 802.11 miniport driver. It then converts relevant IEEE 802.11 packets to IEEE 802.3 packets before passing them up to IEEE 802.3 protocols such as TCP/IP. It also passes IEEE 802.1X packets to the IEEE 802.1X supplicant by calling up to the Native 802.11 STA server.
  • Send path.It receives IEEE 802.3 packets from any IEEE 802.3 protocols. It then converts them to IEEE 802.11 packets before passing them to the Native 802.11 miniport driver. It also sends out IEEE 802.1X packets received from the IEEE 802.1X supplicant by means of the Native 802.11 STA server.
  • Other STA operation. It performs other IEEE 802.11 station operations in the software by potentially subsuming some IEEE 802.11 packets instead of passing them up. It also generates IEEE 802.11 packets on its own.

Figure 3. Native 802.11 STA Design

Native 802.11 STA User Mode Interactions

The Native 802.11 STA server configures an IEEE 802.11 network adapter into STA mode. Through the server, an IEEE 802.1X supplicant can send IEEE 802.1X packets to, and receive them from, an IEEE 802.1X authenticator. The Native 802.11 STA server acts as a conduit for all interested user-mode applications, including any IEEE 802.1X supplicants as well as the Native 802.11 manager/monitor utility, and permits communication with the Native 802.11 STA intermediate driver.

The Native 802.11 STA server exposes APIs to user-mode applications, which can then call down to the Native 802.11 STA intermediate driver. When a user-mode application registers with the Native 802.11 server, the application provides a function table. The server uses this function table to pass acall from the Native 802.11 STA intermediate driver to the destined user-mode application.

Local and remote clients can access the APIs that the server exposes through the Native 802.11 STA client-side DLL.

Native 802.11 AP Design

The architecture for Native 802.11 AP is similar to the Native 802.11 STA architecture with the addition of a bridge that coordinates data traffic coming from an IEEE 802.3 LAN. See Figure 4.

Figure 4. Native 802.11 AP Design

All IEEE 802.11 packets that an IEEE 802.11 network adapter receives are passed to the Native 802.11 AP intermediate driver. In effect, the network adapter acts like a transceiver, that is, it takes packets in and ships them out. For the physical network adapter connected to an IEEE 802.11 LAN, the Native 802.11 miniport driver functions as follows:

  • Receive path. Native 802.11 miniport driver passes some IEEE 802.11 packets to its protocol, the Native 802.11 AP intermediate driver.
  • Send path. Native 802.11 miniport driver receives IEEE 802.11 packets from the Native 802.11 AP intermediate driver and sends them out by means of the network adapter.
  • Hardware operations. Native 802.11 miniport driver subsumes some IEEE 802.11 packets instead of indicating them up and also generates some IEEE 802.11 packets on its own and sends them out by means of the network adapter.

The Native 802.11 AP intermediate driver is a virtual miniport driver that handles IEEE 802.3-to-IEEE 802.11 packet conversion and vice-versa. The driver also handles IEEE 802.11 AP operations, such as association. The Native 802.11 AP intermediate driver functions as follows:

  • Receive path.It receives IEEE 802.11 packets from the Native 802.11 miniport driver and converts some to IEEE 802.3 packets before passing them up to a bridge as needed. It also indicates IEEE 802.1X packets to the IEEE 802.1X authenticator through calls to the Native 802.11 AP configuration server.
  • Send path.It receives IEEE 802.3 packets from a bridge, converts them to IEEE 802.11 packets before passing them to the Native 802.11 miniport driver. It also sends the IEEE 802.1X packets received from the IEEE 802.1X authenticator by means of the Native 802.11 AP server.
  • Other AP operations. Performs other IEEE 802.11 AP operations in the software, such as managing association and authentication states, and can subsume some IEEE 802.11 packets instead of indicating them up. It also generates IEEE 802.11 packets on its own.

When connected to a wired LAN, a network bridge is the interface between an IEEE 802.3 physical network adapter and a Native 802.11 virtual miniport driver.

Native 802.11 AP User Mode Interactions

The Native 802.11 AP server configures a IEEE 802.11 network adapter into AP mode. Through the server, an IEEE 802.1X authenticator can send IEEE 802.1X packets to, and receive them from, an IEEE 802.1X supplicant. Optionally, in an AP-to-AP wireless range extension scenario, the IEEE 802.1X supplicant on the AP can also send IEEE 802.1X packets to, and receive them from, an IEEE 802.1X authenticator server on the peer AP that supports AP-to-AP wireless range extension.

The Native 802.11 AP server acts as a conduit for all interested user-mode applications, including the IEEE 802.1X Authenticator, IEEE 802.1X Supplicant, and the Native 802.11 Manager/Monitor utility, and it permits communication with the Native 802.11 AP intermediate driver. The server exposes APIs to user-mode applications, which can then call down to the Native 802.11 AP intermediate driver. When a user-mode application registers with the Native 802.11 server, the application provides a function table. The server then uses the function table to pass acall from the Native 802.11 AP intermediate driver to the destined user-mode application.

Local and remote clients can access the APIs that the server exposes through the Native 802.11 AP client-side DLL.

Offloaded PHY and MAC Functions

To support Native 802.11, vendors must provide an IEEE 802.11 offload engine with the following capabilities:

  • Offload capability object identifiers (OIDs).
  • Offload WEP encryption and decryption functions.
  • Offload fragmentation and defragmentation functions.

In addition, vendors should also support the out-of-band data specified for Native 802.11 miniport driver interfaces as follows:

  • Miniport driver send path out-of-band data.
  • Miniport driver receive path out-of-band data.

PHY Layer Design

Native 802.11 implements some PHY-level management functions and offloads others to the IEEE 802.11 network adapter. For example, a Native 802.11 STA assumes IBSS functions are supported, which are mandatory for a network adapter operating in STA mode.

Native 802.11 supports any of the following configurations for a network adapter with Native 802.11 miniport driver: