Device.Network Requirements
Device.Network.DevFund
Network requirements
| Related Requirements |
Device.Network.DevFund.NdisVersion Device.Network.DevFund.NdisVersionLegacy Device.Network.DevFund.NPOS Device.Network.DevFund.SelectiveSuspend |
Device.Network.DevFund.NdisVersion
NDIS devices must conform to the NDIS 6.x requirements in the Windows Driver Kit
| Target Feature |
Device.Network.DevFund |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All NDIS device must conform to NDIS 6.x specified in the Windows Driver Kit.Design Notes:See the Windows Driver Kit, "NDIS."
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.DevFund.NdisVersionLegacy
NDIS devices must conform to the NDIS requirements in the Windows Driver Kit
| Target Feature |
Device.Network.DevFund |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 |
Description
All NDIS device must conform to NDIS specified in the Windows Driver Kit.Design Notes:See the Windows Driver Kit, "NDIS."
Additional Information
| Exceptions |
Devices targeted for OS s that don t support NDIS 6.x will be exempted. 10/100 Ethernet devices targeted for legacy OS s will be exempted. |
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.DevFund.NPOS
Network Devices must support No Pause On Suspend (NPOS)
| Target Feature |
Device.Network.DevFund |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
NDIS miniport drivers must support No Pause On Suspend (NPOS) on client SKUs (feature support on server SKUs is optional).Design Notes:See the No Pause On Suspend Specification.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.DevFund.SelectiveSuspend
NDIS devices must meet Selective Suspend requirements
| Target Feature |
Device.Network.DevFund |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
NDIS devices must meet Selective Suspend requirements.Design Notes:
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.Base
LAN requirements
| Related Requirements |
Device.Network.LAN.Base.100MbOrGreater Device.Network.LAN.Base.32MulticastAddresses Device.Network.LAN.Base.AdvProperties Device.Network.LAN.Base.AnyBoundary Device.Network.LAN.Base.IPv4AndIPv6OffloadParity Device.Network.LAN.Base.NDISCalls Device.Network.LAN.Base.NDISRequirements Device.Network.LAN.Base.PacketFiltering Device.Network.LAN.Base.PreserveOSServices Device.Network.LAN.Base.PriorityVLAN Device.Network.LAN.Base.ShortPacketPadding Device.Network.LAN.Base.SupportIEEEE8023 |
Device.Network.LAN.Base.100MbOrGreater
Ethernet devices must support 100-Mb or greater link speeds
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Devices must be able to link at 100 Mb or higher speeds.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.32MulticastAddresses
Ethernet devices must support filtering for at least 32 multicast addresses
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
An Ethernet device must support filtering of 32 or more multicast addresses. Design Notes:See the Windows Driver Kit, "multicast."See the Windows Driver Kit, "NdisReadNetworkAddress" and "MAC Address."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.AdvProperties
Ethernet devices must safeguard advanced properties and provide complete configurability through advanced properties.
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices must adhere to the standardized registry keywords for controlling advanced features as documented on MSDN. Devices must also safeguard both Microsoft standardized and private keywords from malicious values.
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.Base.AnyBoundary
Ethernet devices must be able to transmit packets from buffers aligned on any boundary
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Buffer alignment refers to whether a buffer begins on an odd-byte, word, double-word, or other boundary. Devices must be able to transmit packets with any of the packets fragments beginning on an odd-byte boundary. For performance reasons, packets must be received into contiguous buffers on a double-word boundary.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.IPv4AndIPv6OffloadParity
Ethernet Devices that implement offloads must do so consistently for both IPv4 and IPv6
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Network offloads implemented by Ethernet devices need to operate consistently, irrespective of the IP protocol used. Having offload parity allows Windows customers to have a consistent and predictable experience across both IPv4 and IPv6.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Network.LAN.Base.NDISCalls
Ethernet devices must make only NDIS library or WDF system calls
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
A driver for an Ethernet device must make only NDIS or WDF calls. Any calls to other kernel mode components are not allowed.Design Notes:See the Windows Driver Kit, "NDIS" and "WDF."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.NDISRequirements
Ethernet devices must conform to the NDIS requirements in the Windows Driver Kit
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All Ethernet device drivers must conform to NDIS specified in the Windows Driver Kit.Design Notes:See the Windows Driver Kit, "NDIS."
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.Base.PacketFiltering
Ethernet devices must support packet filtering
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The miniport driver must support all filter types in the Windows Driver Kit.Note: Filtering should be performed in Hardware/Firmware.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.PreserveOSServices
Ethernet devices Miniport Driver/Driver Software must not disable OS services
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices Miniport Driver/Driver Software must not disable OS services. Some devices tend to shutoff services such as the Base Filtering Engine (BFE). This leaves the system vulnerable to attack due to lack of security capabilities.Design Notes:
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.Base.PriorityVLAN
Ethernet devices that implement link speeds of gigabit or greater must implement Priority & VLAN tagging according to the IEEE 802.1q specification
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement link speeds of gigabit or greater. If the Ethernet device does not implement link speeds of gigabit or greater than this requirement does not apply.Ethernet device & driver must support inserting and removing of priority and VLAN tags.
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.Base.ShortPacketPadding
Ethernet devices must pad short packets with constant data
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Padding that is added to short Ethernet packets to bring that packet size to the minimum IEEE 802.3, Section4.2.3.3, packet size must be initialized to either zeros or an 8-bit repeating pattern before the packets are transmitted. The 802.3 Ethernet specification requires packets that are shorter than the minimum packet size to be padded up to the minimum size before the packets are transmitted onto the wire. The 802.3 Ethernet specification does not specify the padding content; however, Microsoft requires the padding to be zeros or another constant value to address security concerns. Some drivers pad the packets with data from previously sent packets; this practice is not acceptable.Design Notes:New solutions are recommended to implement a padding of zeros. However, some devices that implement the padding in hardware use 0xffs, which addresses the security concern
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.Base.SupportIEEEE8023
Ethernet devices must comply with IEEE 802.3
| Target Feature |
Device.Network.LAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All 802.3 Ethernet devices must implement and comply with the IEEE 802.3 specification.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.ChecksumOffload
Network requirements
| Related Requirements |
Device.Network.LAN.ChecksumOffload.ChecksumOffload |
Device.Network.LAN.ChecksumOffload.ChecksumOffload
Ethernet devices implement Checksum Offloads
| Target Feature |
Device.Network.LAN.ChecksumOffload |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Send and Receive TCP Checksum Offload for IPv4 and IPv6
Send and Receive IP Checksum Offload for IPv4
Send and Receive UDP Checksum offload for IPv4 and IPv6
Support for TCP Checksum Standardized Keywords is mandatory.
Ethernet devices implement Checksum Offloads must expose the NDIS Enumeration Keywords.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.CS
A connected standby capable computer (also known as a platform) supports a low power active state, and advertises support of that state to the OS using the appropriate ACPI flag (LOW_POWER_S0_IDLE_CAPABLE) in FADT. It is also expected to meet all the Windows certification requirements for a connected standby platform. This section specifies the connected standby requirements for Wired LAN (Ethernet).
| Related Requirements |
Device.Network.LAN.CS.NetworkWake Device.Network.LAN.CS.PresenceOffload Device.Network.LAN.CS.ReliableCSConnectivity Device.Network.LAN.CS.WakeEvents Device.Network.LAN.CS.WakeReasonDetection |
Device.Network.LAN.CS.NetworkWake
Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support network wake patterns
| Target Feature |
Device.Network.LAN.CS |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The specific requirements are listed below:
Wake on LAN Patterns:
Wired LAN devices and their drivers are required support at least thirty-two (32) bitmap patterns of a minimum of 128 byte size. This pattern type refers to flexible bitmap patterns (NDIS_PM_WOL_PACKET.NdisPMWoLPacketBitmapPattern) and not other pattern types.
Wake on Magic Packet:
Wired LAN devices and their drivers must support magic packet wake. Support for this wake packet type is required and is not included in the 32 bitmap pattern requirement.
Wake Packet Indication:
Wired LAN devices and their drivers are required to support Wake Packet Indication for all network wake packets and be capable of caching and indicating the complete network packet causing the wake. Note that this supersedes the Device.Network.LAN.PM.WakePacket requirement for Connected Standby-capable devices.
Design Notes:
See the Power Management specification on MSDN.
Additional Information
| Exceptions |
If the Wired LAN device has implemented sixteen (16) bitmap patterns of a minimum of 128 byte size and this pattern type refers to flexible bitmap patterns (NDIS_PM_WOL_PACKET.NdisPMWoLPacketBitmapPattern) and not other pattern types, there will be an exception granted until June, 2014. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.LAN.CS.PresenceOffload
Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support network presence offload.
| Target Feature |
Device.Network.LAN.CS |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Support of this feature is required. The specific requirements are listed below:
ARP Protocol Offload:
Wired LAN devices must implement ARP offload as it is defined in the Power Management specification on MSDN. Specifically, the offload must respond to an ARP Request (operation = 1) by responding with an ARP Reply (operation = 2) as defined in RFC 826 (http://tools.ietf.org/html/rfc826).
NS Protocol Offload:
Wired LAN devices must implement IPv6 NS offload as it is defined in Power Management specification on the MSDN. Specifically, the offload must respond to a Neighbor Solicitation (operation = 135) by responding with an NS Advertisement (operation = 136) as defined in RFC 4861 (http://tools.ietf.org/html/rfc4861). We require support for at least 2 ND offload requests. Each request can have 2 target addresses. The value they should advertise in NDIS_PM_CAPABILITIES::NumNSOffloadIPv6Addresses is the NUMBER OF REQUESTS, not number of addresses. So if they support the minimum 2 requests, they should advertise 2. The name of the field is wrong and will be fixed in the next NDIS release.
The miniport must implement the said protocol in accordance to RFCs describing Neighbor Discovery and Neighbor Solicitation Protocol for IPv6.
Additional Information
| Exceptions |
None for LAN. Only WiFi/MBB IHVs implemented connected standby capable NICs in Windows 8. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.LAN.CS.ReliableCSConnectivity
LAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby
| Target Feature |
Device.Network.LAN.CS |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The wired LAN device seamlessly transitions between working power state D0 and low power state D2/D3 while in Connected Standby (CS). The wired LAN device maintains OSI layer 2 link connectivity while in CS. The wired LAN device wakes up on matching wake patterns only. There are no spurious wakes while in CS. Wake packets are delivered without delay or buffering. Lock screen apps stay connected with Control Channel or Push Notification triggers over IPv4 and IPv6 in CS.
The exact D-value in low power state depends on the underlying bus type. For example, network adapters on USB or SDIO buses use D2 as their low power state, while network adapters on PCI or PCIe buses use D3 state.
Additional Information
| Exceptions |
Does not apply to non-AOAC capable devices |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.LAN.CS.WakeEvents
Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support various wake triggers
| Target Feature |
Device.Network.LAN.CS |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The specific requirements are listed below:Wake on Media Connect:Wired Ethernet devices must advertise and support wake on media connect as defined in the specification on MSDN.Wake on Media Disconnect:Wired Ethernet devices must advertise and support wake on media disconnect as defined in the specification on MSDN.Design Notes:See the Power Management specification on MSDN.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Network.LAN.CS.WakeReasonDetection
Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support wake reason detection
| Target Feature |
Device.Network.LAN.CS |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The specific requirements are listed below:Wake Reason support: Wired Ethernet devices must include Wake Reason support in compliance with the NDIS_STATUS_PM_WAKE_REASON documentation on MSDN. When the wake is caused by an incoming network packet, the NIC is required to capture and indicate the entire packet causing the wake to the operating system.Design Notes:See the Power Management specification on MSDN.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Network.LAN.DCB
LAN requirements
| Related Requirements |
Device.Network.LAN.DCB.DCB |
Device.Network.LAN.DCB.DCB
Ethernet devices that implement Data Center Bridging (DCB) must comply with the DCB Specification.
| Target Feature |
Device.Network.LAN.DCB |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that support Data Center Bridging (DCB).
Ethernet devices that implement Data Center Bridging (DCB) must comply with the following requirements:
MaxNumTrafficClasses must be between 3 and 8 inclusive.
MaxNumEtsCapableTrafficClasses must be at least 2.
MaxNumPfcEnabeldTrafficClasses must be at least 1.
ETS Must be supported.
PFC Must be supported.
Strict Priority Must be supported.
iSCSI CNAs must support classification element for iSCSI traffic (TCP ports 860 and 3260, both src and dest port).
FCoE CNAs must support classification element for FCoE traffic (Ethertype of 0x8906).
Design Notes
See the Data Center Bridging Specification at https://msdn.microsoft.com/library/windows/hardware/hh451635(v=vs.85).aspx
Additional Information
| Enforcement Date |
Aug. 01, 2012 |
Device.Network.LAN.GRE
LAN requirements
| Related Requirements |
Device.Network.LAN.GRE.GREPacketTaskOffloads |
Device.Network.LAN.GRE.GREPacketTaskOffloads
Ethernet Devices that implement GRE Encapsulated Packet Task Offloads must comply with the specification
| Target Feature |
Device.Network.LAN.GRE |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement GRE encapsulated packet task offloads. Ethernet devices that implement GRE encapsulated packet task offloads must comply with the specification and support the following encapsulated offload tasks for all combinations of inner/outer IPv4/IPv6 headers:
Send checksum (IPv4, TCP, UDP)
Receive checksum (IPv4, TCP, UDP)
LSOv2
VMQ
Additional Information
| Enforcement Date |
Aug. 01, 2012 |
Device.Network.LAN.IPsec
LAN requirements
| Related Requirements |
Device.Network.LAN.IPsec.IPsec |
Device.Network.LAN.IPsec.IPsec
Ethernet devices that implement IPsec task offload must support required modes and protocols
| Target Feature |
Device.Network.LAN.IPsec |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices that support IPsec task offload must support the following: Version: IPsec Task offload v2 NDIS version: 6.1, 6.20, 6.30Ethernet devices that support IPsec task offload for Windows 8 must use NDIS 6.30.Mode: - IPv4 and IPv6 Transport - IPv4 and IPv6 TunnelProtocol: ESPCrypto Algorithm: - Must implement: AES-GCM (128 or higher) - May implement additional algorithms as stated in https://technet.microsoft.com/library/dd125380(v=WS.10).aspxCoexistence: Ethernet devices that support IPsec task offload and any the following offload technologies: - Large Send Offload- Receive Side Scaling - CheckSum offload.Must implement them in a coexisting manner, such that the use of IPsec task offload does not preclude the use of the other offload technologies implemented for each IPsec mode.
Additional Information
| Enforcement Date |
Feb. 27, 2008 |
Device.Network.LAN.KRDMA
LAN requirements
| Related Requirements |
Device.Network.LAN.KRDMA.KRDMA |
Device.Network.LAN.KRDMA.KRDMA
Devices that implement the NetworkDirect Kernel Mode Interface (NDKPI) (a.k.a., Kernel-mode RDMA, kRDMA) must comply with the Network Direct Kernel Mode Interface (NDKPI) Specification.
| Target Feature |
Device.Network.LAN.KRDMA |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement the Network Direct Kernel Mode Interface (NDKPI) Specification. Devices that implement Network Direct Kernel Mode Interface (NDKPI) (a.k.a., Kernel-mode RDMA) must comply with the Network Direct Kernel Mode Interface (NDKPI) Specification, version 1.2.
Design Notes
See the Network Direct Kernel Mode Interface (NDKPI) Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.LAN.LargeSendOffload
Network requirements
| Related Requirements |
Device.Network.LAN.LargeSendOffload.LargeSendOffload |
Device.Network.LAN.LargeSendOffload.LargeSendOffload
Ethernet devices must implement large send offloads
| Target Feature |
Device.Network.LAN.LargeSendOffload |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices must support the following task offloads:
Large Send Offload version 2 for IPv4 and IPv6.
Design Notes:See the Windows Driver Kit, "NDIS."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.PM
LAN requirements
| Related Requirements |
Device.Network.LAN.PM.PowMgmtNDIS Device.Network.LAN.PM.WakeOnLANPatterns Device.Network.LAN.PM.WakePacket |
Device.Network.LAN.PM.PowMgmtNDIS
Ethernet devices that implement network presence offloads must conform to the Power Management specification on the NDIS Program
| Target Feature |
Device.Network.LAN.PM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices must implement ARP offload as defined in the Power Management specification on MSDN. Specifically, the offload must respond to an ARP Request (operation = 1) by responding with an ARP Reply (operation = 2) as defined in RFC 826.
Ethernet devices must implement IPv6 NS offload as defined in the Power Management specification on MSDN. Specifically, the offload must respond to an Neighbor Solicitation (operation = 135) by responding with an NS Advertisement (operation = 136) as defined in RFC 4861. Devices must support at least 2 NS offloads, each with up to 2 target IPv6 addresses.
Design Notes
See the Power Management specification on MSDN.
See RFC 826 at https://go.microsoft.com/fwlink/?LinkId=108718
Additional Information
| Exceptions |
Exceptions to this requirement include: PC Card, CardBus devices and for external USB network devices operating on bus power. Devices with transmission speeds in excess of 1 gigabit. Devices with fiber optic medium |
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.PM.WakeOnLANPatterns
Ethernet devices must implement Wake on LAN patterns according to the specification
| Target Feature |
Device.Network.LAN.PM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Implementation must comply with Network Device Class Power Management Reference Specification. Ethernet devices and drivers are required support at least eight (8) bitmap patterns since Windows uses up to eight patterns.Magic packet wake support is required and is not included in the 8 bitmap pattern requirement.Design Notes:Implementation details are in the Power Management specification on MSDN.
Additional Information
| Exceptions |
Exceptions to this requirement include: PC Card, CardBus devices and for external USB network devices operating on bus power.Devices with transmission speeds in excess of 1 gigabitDevices with fiber optic mediumNote: If the device implement Wake on LAN - it must implement it correctly based on this requirement regardless whether the device is on the exception list or not. |
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.PM.WakePacket
Ethernet devices that implement Wake Packet Detection must comply with Network Device Class Power Management Reference Specification.
| Target Feature |
Device.Network.LAN.PM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices that implement Wake Packet Detection must comply with Network Device Class Power Management Reference Specification. Implementation must comply with Network Device Class Power Management Reference Specification discussed in the Windows WDK. The NIC is required to capture at least the first 128 bytes of the packet causing the network wake and generate a status indication to the operating system.Design Notes:See the WDK, Network Device Class Power Management Reference Specification.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.RSC
LAN requirements
| Related Requirements |
Device.Network.LAN.RSC.RSC |
Device.Network.LAN.RSC.RSC
Ethernet devices that implement Receive Segment Coalescing (RSC) must comply with the RSC Specification.
| Target Feature |
Device.Network.LAN.RSC |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Ethernet devices that implement Receive Segment Coalescing (RSC) must comply with the RSC Specification and require both IPv4 and IPv6 support.Design Notes: NDIS version: 6.30
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.RSS
LAN requirements
| Related Requirements |
Device.Network.LAN.RSS.RSS Device.Network.LAN.RSS.SetHashFunctionTypeAndValue Device.Network.LAN.RSS.SupportIndirectionTablesSizes Device.Network.LAN.RSS.SupportToeplitzHashFunction Device.Network.LAN.RSS.SupportUpdatesToRSSInfo |
Device.Network.LAN.RSS.RSS
Ethernet devices that implement RSS
| Target Feature |
Device.Network.LAN.RSS |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
RSS support is required on server SKUs for all devices except for SR-IOV VF drivers.
RSS support is optional on client SKUs.
Ethernet devices that implement RSS must support:
Hash types:IPv4, TCP IPv4, IPv6, and TCP IPv6
Multiple processor groups (for miniports of NDIS version 6.20 and above)
Number of queues (depending on link speed):
Less than 10 gigabit: 2
10 gigabit or greater: 8
SR-IOV VF driver (independent of link speed): 2
Indirection table size (depending on link speed):
Less than 10 gigabit: 64
10 gigabit or greater: 128
SR-IOV VF driver (independent of link speed): 16
SR-IOV PF driver (independent of link speed): 64
Implement all RSS standardized keywords
*RSS
*NumRSSQueues
Message Signaled Interrupts Extended (MSI-X) as defined in the PCI v3.0 specification. For devices with a link speed of less than 10 gigabit, the device must have 1 MSI-X vector with support for 2 RSS hardware queues. For devices 10 gigabit or greater, the device must have an MSI-X vector for each RSS hardware queue. For example if the device has a link speed of 10 gigabits and advertises support for 8 RSS hardware queues then it must have at least 8 MSI-X vectors in the hardware.
Design Notes
See RSS Standardized Keywords Specification https://msdn.microsoft.com/library/windows/hardware/ff570864(v=vs.85).aspx.
In addition the device must allocate as many MSI-X table entries as there are CPUs in the system. See the NDIS documentation section on MSI-X for more details https://msdn.microsoft.com/library/windows/hardware/ff566491.aspx.
Additional Information
| Enforcement Date |
Jun. 1, 2009 |
Device.Network.LAN.RSS.SetHashFunctionTypeAndValue
Ethernet devices that implement RSS must set the hash function, hash type, and hash value on each indicated packet
| Target Feature |
Device.Network.LAN.RSS |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement RSS. If the Ethernet device does not implement RSS then this requirement does not apply.If the network device supports RSS, all packets for which the RSS implementation was able to calculate the hash the RSS implementation must return the full 32-bit hash value, the hash function, and the hash type, for each received packet it indicates. For any packets it received without error for which it was not able to generate the hash function, it must clear the hash type. Macros NET_BUFFER_LIST_SET_HASH_TYPE,NET_BUFFER_LIST_SET_HASH_FUNCTION, and NET_BUFFER_LIST_SET_HASH_VALUE must be used to set the associated values.Design Notes:See the MSDN page for more information: https://msdn.microsoft.com/library/windows/hardware/ff570726(v=vs.85).aspxSee the Windows Driver Kit, "Indicating RSS Receive Data."
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.RSS.SupportIndirectionTablesSizes
Ethernet devices that implement RSS must support specific Indirection Table sizes
| Target Feature |
Device.Network.LAN.RSS |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement RSS. If the Ethernet device does not implement RSS then this requirement does not apply.If the network device supports RSS, the RSS implementation must support indirection table sizes for each power of 2 up to the maximum indirection table size supported. Example: if 128 is the maximum indirection table size, then the miniport must accept indirection tables of sizes 2, 4, 8, 16, 32, 64, or 128.The lookup into the Indirection Table to find the destination CPU must be accomplished by using only the least significant bits as specified by the last value set in the OID_GEN_RECEIVE_SCALE_PARAMETERS, NumberOfLsbs variable. An RSS implementation must support the host protocol stack setting NumberOfLsbs to any value between 1 and 7, inclusive.Design Notes:See the Windows Driver Kit, "OID_GEN_RECEIVE_SCALE_PARAMETERS."
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.RSS.SupportToeplitzHashFunction
Ethernet devices that implement RSS must support the Toeplitz hash function
| Target Feature |
Device.Network.LAN.RSS |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement RSS. If the Ethernet device does not implement RSS then this requirement does not apply.If the network device supports RSS, the RSS implementation must at least support the Toeplitz hash function for the types of packets for which it advertised as being able to generate the hash (as specified in OID_GEN_RECEIVE_SCALE_CAPABILITIES). This includes support for the HashSecretKey length of 40 bytes. Design Notes:See Windows Driver Kit, "RSS Hashing Functions." Also, refer to MSDN for more information https://msdn.microsoft.com/library/windows/hardware/ff570725(v=vs.85).aspx
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.RSS.SupportUpdatesToRSSInfo
Ethernet devices that implement RSS must support updates to RSS information at any time
| Target Feature |
Device.Network.LAN.RSS |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement RSS. If the Ethernet device does not implement RSS then this requirement does not apply.At any time a network device that supports RSS, must support setting OID_GEN_RECEIVE_SCALE_PARAMETERS, including updating the Indirection Table, NumberOfLsbs, SecretKey, and HashInformation (hash function and hash type). The RSS implementation can post packets out of order during the transition from the prior state to the new state and can perform a hardware reset if the HashInformation, SecretKey, or NumberOfLsbs changed. It must not perform a hardware reset if only the Indirection Table contents are changed.Design Notes:See the Windows Driver Kit, "OID_GEN_RECEIVE_SCALE_PARAMETERS."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Network.LAN.SRIOV
Network requirements
| Related Requirements |
Device.Network.LAN.SRIOV.SRIOV |
Device.Network.LAN.SRIOV.SRIOV
Ethernet devices that implement Single Root I/O Virtualization (SR-IOV) must support required functionalities
| Target Feature |
Device.Network.LAN.SRIOV |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Driver must use MS software back-channel to PF for VF driver PCIe configuration space requests.
The default initial switch configuration must be in the INF file.
The PF INF must set the UpperRange to "ndis5" and LowerRange to "ethernet"
The INF must not include the *SriovPreferred keyword
Coalesced filters must be set in NDIS_REECIVED_FILTER_CAPABILITIES
SR-IOV NIC must include a Virtual Ethernet Bridge (VEB)
If RSS is supported for VF miniports, the NIC must be able to support an independent RSS hash for each function, physical or virtual
Both the PF and VF miniport drivers must be able to pass the LAN logo tests
The default vPort cannot be deleted; non-default vPorts on a VF can be deleted
If SRIOV is disabled, the NIC and miniport must function as a standard Ethernet NIC
An SRIOV NIC must also advertise and implement VMQ. Queue pair not allocated to IOV are to be available for VMQ
On report of media connected, he VF miniport must be ready to accept traffic
A VF miniport must specify an UpperRange of "ndisvf" and a LowerRange of "iovvf"
Design Notes: See the Single Root I/O Virtualization Specification.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Network.LAN.SRIOV.VF
Network requirements
| Related Requirements |
Device.Network.LAN.SRIOV.VF.VF |
Device.Network.LAN.SRIOV.VF.VF
Ethernet devices that implement Single Root I/O Virtualization (SR-IOV) must support required functionalities
| Target Feature |
Device.Network.LAN.SRIOV.VF |
| Applies to |
Windows 8 Client x64 Windows 8.1 Client x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Requirements for an SRIOV VF Adapter
Driver must use MS software back-channel to PF for VF driver PCIe configuration space requests.
If RSS is supported for VF miniports, the NIC must be able to support the same number of RSS as it can on PFs
All NDIS device must conform to NDIS 6.x specified in the Windows Driver Kit so should the VF devices.
A VF miniport must specify an UpperRange of "ndisvf" and a LowerRange of "iovvf"
If the VF miniport implements Receive Segment Coalescing (RSC) it must comply with the RSC Specification and require both IPv4 and IPv6 support.
On report of media connected, the VF miniport must be ready to accept traffic
Design Notes:See the Single Root I/O Virtualization Specification.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Network.LAN.TCPChimney
TCP Chimney requirements
| Related Requirements |
Device.Network.LAN.TCPChimney.ComplyWithNDIS Device.Network.LAN.TCPChimney.ComplyWithTCPIPProtocol Device.Network.LAN.TCPChimney.HandlesOutOfOrderData Device.Network.LAN.TCPChimney.ImplementSufficientlyGranularTimers Device.Network.LAN.TCPChimney.NeighborStateObjTimestampsComplyWithWDK Device.Network.LAN.TCPChimney.Support1024Connections Device.Network.LAN.TCPChimney.Support64bitAddresses |
Device.Network.LAN.TCPChimney.ComplyWithNDIS
Ethernet devices that implement TCP Chimney must comply with the latest NDIS miniport driver model
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement TCP Chimney. If the Ethernet device does not implement TCP Chimney then this requirement does not apply.The TCP Chimney portion of the device must comply with the TCP Chimney specification on Connect.Ethernet devices that implement TCP Chimney must comply with NDIS 6.0 for Vista.Ethernet devices that implement TCP Chimney must comply with NDIS 6.1 for WS2008.Ethernet devices that implement TCP Chimney must comply with NDIS 6.2 for Win7.Design Notes:See Windows Driver Kit, "Network Devices and Protocols."
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.TCPChimney.ComplyWithTCPIPProtocol
Ethernet devices that implement TCP Chimney must comply with the IETF standard RFCs for the TCP/IP protocol family and behaves as the Microsoft Windows (host) TCP/IP protocol implementation
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement TCP Chimney. If the Ethernet device does not implement TCP Chimney then this requirement does not apply.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this requirement are to be interpreted as described RFC 2119.A TCP chimney NIC MUST implement the TCP/IP protocol family such that:1. The TCP/IP protocol implementation conforms to the IETF standard RFCs and2. The TCP/IP protocol implementation behaves in the same way as the Microsoft Windows TCP/IP protocol implementationThis requirement specifies which RFCs must be implemented by the TCP chimney NIC and clarifies the expected behavior in cases where an RFC is ambiguous.Table 1 lists the RFCs that a TCP Chimney NIC must implement.
Descriptive name
Specification
Transmission Control Protocol RFCs
RFC 793 - Transmission Control ProtocolRFC 813 - Window and Acknowledgment Strategy in TCPRFC 1122* - Requirements for Internet Hosts - Communication Layers - entire section 4.2RFC 1323 - TCP Extensions for High PerformanceRFC 2923* -TCP Problems with Path MTU DiscoveryRFC 2988* - Computing TCP's RTORFC 3465* - Appropriate Byte Counting
TCP congestion control
RFC 2581* - TCP Congestion Control RFC 2582* - NewReno Modification to TCP's Fast Recovery Alg.RFC 3042 - Limited Transmit
TCP loss recovery
RFC 2018* - TCP Selective Acknowledgment Options RFC 3517* - Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
TCP security
RFC tcpm-tcpsecure-09* - Improving TCP's Robustness to Blind In-Window Attacks
Internet Protocol v4 RFCs**
RFC 791RFC 894RFC 1042RFC 1191RFC 1122 - entire section 3.2
Internet Protocol v6 RFCs**
RFC 1752RFC 1981RFC 2374RFC 2460RFC 2461RFC 2675RFC 2711RFC 3122RFC 3513
* - There are associated clarifications for the RFC which must be followed. They are outlined below.** - TCP Chimney NICs MUST NOT implement the entire set of IP related RFCs. Instead the TCP Chimney Driver Kit guidelines for the Internet Protocol RFC implementation must be followed.
Table 1 - Lists of RFCs that a TCP Chimney NIC must implementRFC ClarificationsThe following clarifications must be followed by the TCP/IP implementation in the TCP Chimney NIC.RFC 11221. Section 4.2.3.4 specifies that the Nagle algorithm SHOULD be implemented as a method to avoid the Silly Window Syndrome. The TCP chimney NIC MUST implement the Nagle algorithm and the implementation must follow this pseudo code:a. When sending a segment the first stage of SWS avoidance MUST be implemented as:Send(){..If (BytesToSend > MSS ||BytesToSend > MaxSndWnd /2 ||BytesToSend >= BytesInCurReq ||ForceOutput){BeginSend();}else{StartSwsTimer();} ... ...BytesToSend Number of available Bytes that can be sent as allowed by the current send windowMSS Maximum Segment SizeMaxSndWnd Maximum receive window that the TCP peer ever advertisedBytesInCurReq Bytes left in the current send requestForceOutput Variable that determines if the segment MUST be sent, due to SWS timer expiring as an example.The line in red specifies the deviation from the SWS avoidance that MUST be implemented. Note: This pseudo code defines the behavior at the time of sending, not at the time when the send request is offloaded by the host TCP/IP stack. b. The reason why the MS TCPIP stack deviates from the SWS algorithm in the way described above is:1. CWND can grow in Bytes. More precisely, CWND is not constrained to grow or shrink in multiples of MSS or PUSH boundaries. Because the TCP implementation in Windows implements Appropriate Byte Counting (RFC 3465) this point is strengthened even further.2. The PUSH boundary is determined by the TCP application posting data to be sent so it is not guaranteed to be aligned with the MSS size.3. Because of #1 and #2 it is very likely for the TCP state machine to reach a point at which one MSS has been placed on the wire and there is a sub-MSS segment which, if sent, will complete the block of data up to the PUSH boundary.a. In this case it is favorable for TCP to send this one sub-MSS segment in order to complete the transmission of the app's buffer up to the PUSH boundary. The reason why it is favorable to do this is because the data will be delivered to the receiving application faster than if the SWS algorithm was followed to the letter. At the same time the deviation does not re-introduce any of the problems SWS addressed in the first place.2. As described in section 4.2.2.17 a TCP Chimney NIC MUST use the connection RTT as a trigger to send a zero window probe and then exponentially increase the interval between successive probes. In addition, the probe MUST contain 1 new Byte of data.3. TCP Chimney NIC MUST support filling at least two reassembly holes.RFC 20181. The TCP Chimney NIC MAY implement RFC 2018. If a TCP Chimney NIC implements RFC 2018 then it MUST also implement RFC 3517.2. A TCP Chimney NIC that DOES NOT implement RFC 2018 MUST properly process pure ACK packets, which contain SACK blocks, as described in section 3 of RFC 793.RFC 25811. The TCP Chimney NIC MUST be able to transition from using the slow-start algorithm to using the congestion avoidance algorithm as specified in Section 3.1. In addition it MUST implement Congestion Window (cwnd) = Slow Start Threshold (ssthresh) instead of Congestion Window > Slow Start Threshold.RFC 25821. The TCP Chimney NIC MUST use the following equation instead of the one described in RFC 2582, section 3 - point 1:SsThresh = max(2*mss, min(cwnd,window_advertised_by_peer)/2)RFC 29231. The TCP Chimney NIC is NOT required to implement the recommendations outlined in RFC 2923. Instead, the TCP Chimney NIC must upload the TCP connection to allow the host stack to execute the black hole detection state machine. See the Windows Driver Kit for details.RFC 29881. See RFC 1122 section 4.2.3.1 and RFC 2988 for background information. TCP Chimney NIC MUST implement RTO calculation using the following algorithm, which is the same as RFC 2988 with minor exceptions that are qualified below:function CalculateRto (first, byRef srtt, byRef rttvar, m)rttSample = Minimum (m, 30s)if first thenrttvar = m/2srtt = melse' notice that rttvar is calculated first, using the old ' value of srttrttvar = (3/4) * rttvar + (1/4) * abs(srtt - rttSample)srtt = (7/8)*srtt + (1/8) * rttSampleend ifCalculateRto = srtt + 4 * rttvarCalculateRto = Minimum (CalculateRto, 60s)CalculateRto = Maximum (CalculateRto, 300ms)The two lines in red capture the deviation from the RFC. Specifically, it is expected that the TCP Chimney NIC has an upper bound when calculating the RTT value.RFC 34651. Section 2.1 describes the changes to CWND during congestion avoidance. A TCP Chimney NIC MUST use the following formula to calculate CWND during congestion avoidance:// L is 4CWnd += max((MaxMss * min(MaxMss * L, BytesAcked)) /CWnd, 1)Note that if BytesAcked is always 1 the above equation becomes max((MaxMss, MaxMss)/Cwnd, 1)which is equivalent to equation 2 in RFC 2581. 2. Section 2.3 in RFC 3465 discusses the limit, L, chosen for the CWND increase during slow start and congestion avoidance, which controls the aggressiveness of the algorithm. A TCP Chimney NIC MUST use a value of 4 for L in order for it to exhibit the same behavior as the Windows TCP/IP protocol implementation.RFC tcpm-tcpsecure-091. TCP Chimney NICs MUST follow the security guidelines outlined in sections 3, 4, and 5 of the 'TCP Security' internet draft RFC (http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure-12). 2. TCP Chimney NICSs SHOULD follow the Windows specific implementation details described in the WDK.Design Notes:See the full text of the RFCs at https://go.microsoft.com/fwlink/?LinkId=36702.
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.TCPChimney.HandlesOutOfOrderData
Ethernet devices that implement TCP Chimney must properly handle the Out Of Order data scenarios
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Ethernet devices that implement TCP Chimney must properly handle Out Of Order data scenarios describe below: 1. If anything is placed in the reassembly queue after an inorder FIN then the reassembly queue MUST be flushed by discarding all of its contents. 2. If a TCP Chimney NIC stores an OOO FIN in the reassembly queue, then it MUST not store OOO data or OOO FIN beyond another OOO FIN in the reassembly queue. If it receives OOO data or OOO FIN segment that would lead to such a conflict, then the TCP Chimney NIC MUST drop that segment and flush the reassembly queue by discarding all of its contents.
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Network.LAN.TCPChimney.ImplementSufficientlyGranularTimers
Ethernet devices that implement TCP Chimney must implement sufficiently granular timers
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement TCP Chimney. If the Ethernet device does not implement TCP Chimney then this requirement does not apply.The TCP chimney NIC must have access to timers (implemented on the NIC's hardware) with precise enough granularity and skew such that it can drive the TCP/IP state machine correctly. The timer granularity must be 10 milliseconds or better (lower than 10 ms) and the timer skew must be as good as what general purpose CPU timer provides
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.TCPChimney.NeighborStateObjTimestampsComplyWithWDK
Neighbor state object timestamps are implemented according to details in the Windows Driver Kit
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
A network device that implements TCP Chimney must ensure that TCP Chimney maintains a timestamp for each neighbor state object and perform checks against the timestamp on each incoming and outgoing packet.Design Notes:See the Windows Driver Kit, "OID_TCP_OFFLOAD.
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.TCPChimney.Support1024Connections
Ethernet devices that implement TCP Chimney must support at least 1024 connections and not advertise more offload capacity than what the HW can support
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement TCP Chimney. If the Ethernet device does not implement TCP Chimney then this requirement does not apply.Ethernet devices that implement TCP Chimney must support at least 1024 connections and not advertise more offload capacity than what the HW can support.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.LAN.TCPChimney.Support64bitAddresses
Ethernet devices that implement TCP Chimney must support 64-bit addresses
| Target Feature |
Device.Network.LAN.TCPChimney |
| Applies to |
Windows Server 2012 R2 x64 Windows Server 2008 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement only applies to Ethernet devices that implement TCP Chimney. If the Ethernet device does not implement TCP Chimney then this requirement does not apply.If the device uses PCI, it must support 64-bit addresses; 64-bit data support is not required
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Network.LAN.VMQ
LAN requirements
| Related Requirements |
Device.Network.LAN.VMQ.VirtualMachineQueues |
Device.Network.LAN.VMQ.VirtualMachineQueues
Ethernet devices that implement Virtual Machine Queues comply with specification
| Target Feature |
Device.Network.LAN.VMQ |
| Applies to |
Windows 8 Client x64 Windows 8.1 Client x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Implementation must comply with Programmable Machine Queues Reference Specification.
At least four queues with filters must be supported. Support for at least 16 queues with filters is recommended. The number of queues required will be 16 by December 1, 2009 for 10 Gigabit parts. The number of queues required is inclusive of the default queue.
MSI-X Support (NDIS_RECEIVE_FILTER_MSI_X_SUPPORTED) is mandatory:
| Queues |
MSI-X to Queues Ratio |
| 1 to 16 |
1:1 |
| 17-64 |
1:2 (Min 16) |
| 65-unlimited |
1:16 (Min 32) |
Filtering:
Support for VLAN filtering in HW (NDIS_RECEIVE_FILTER_MAC_HEADER_VLAN_ID_SUPPORTED) is optional. If implemented, VLANs per VM Queue (NumVlansPerVMQueue) must be >= 1
Support for MAC filtering in HW (NDIS_RECEIVE_FILTER_MAC_HEADER_DEST_ADDR_SUPPORTED) is mandatory.
Support for NDIS_RECEIVE_FILTER_TEST_HEADER_EQUAL_SUPPORTED is mandatory
The maximum number of MAC header filters(MaxMacHeaderFilters) must be >= Number of queues
Total MAC addresses (NumTotalMacAddresses)must be >= Number of queues
MAC addresses per VM Queue(NumMacAddressesPerVMQueue) must be >= 1
Per-queue receive indication must be supported (NDIS_RECEIVE_QUEUE_PARAMETERS_PER_QUEUE_RECEIVE_INDICATION)
Look-ahead split NDIS_RECEIVE_FILTER_LOOKAHEAD_SPILT_SUPPORTED) support is optional. If implemented, implementations MUST split the incoming packet in hardware and DMA the lookahead portion of the packet to the lookahead buffer and post-lookahead portion of the packet to the post-lookahead buffer. It is acceptable for the device to DMA the lookahead portion of the packet to the backfill portion of the post-lookahead buffer and also DMA it to the lookahead buffer.
If present, must support MinLookAheadSplitSize <= 128 bytes, MaxLookAheadSplitSize >= 14
Post December 1, 2009 support is mandatory for new hardware.
Dynamic VMQ support is required for Windows Server 2012 only.
Design Notes
Implementation details are in the ProgrammableMachine Queues specification, on the NDIS Program, Connect site https://msdn.microsoft.com/library/windows/hardware/ff571034(v=vs.85).aspx
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Network.MobileBroadband.CDMA
Mobile Broadband
| Related Requirements |
Device.Network.MobileBroadband.CDMA.ComplyWithBaseReq Device.Network.MobileBroadband.CDMA.FWComplyWithMBSpec Device.Network.MobileBroadband.CDMA.IdentityMorphing Device.Network.MobileBroadband.CDMA.ImplementSMS Device.Network.MobileBroadband.CDMA.Loopback Device.Network.MobileBroadband.CDMA.MultiCarrierFunctionality Device.Network.MobileBroadband.CDMA.ReliableCSConnectivity Device.Network.MobileBroadband.CDMA.SupportUSBSelectiveSuspend Device.Network.MobileBroadband.CDMA.SupportWakeOnMB |
Device.Network.MobileBroadband.CDMA.ComplyWithBaseReq
Mobile Broadband devices must comply with the following base requirements
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices must comply with the following base requirements:
MUST conform to NDIS 6.30 and Microsoft Mobile Broadband Driver Model Specification requirements in the Windows Driver Kit.
MUST comply with power management specifications.
MUST meet the performance target for various operation specified for various class of devices in the Mobile Broadband Driver Model Specification
Mobile Broadband device driver must implement and conform to the NDIS 6.30 and Microsoft Mobile Broadband Driver Model Specifications. All recommended implementation specified in the Mobile Broadband Driver Model Specifications needs to be implemented. Note that Microsoft's MB class driver is compliant to above requirements.Mobile Broadband Device must support the Power Management Policy as outline in the Network Device Class Power Management Reference Specification, Version 2.0. Device must be functional after various OS Power Management operations.Device must meet the performance targets describe in the Mobile Broadband Driver Model Specification.Design Notes: Helpful links:Mobile Broadband Driver Model Specifications https://msdn.microsoft.com/library/ff560543(v=VS.85).aspxNetwork Device Class Power Management Reference Specificationhttps://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/netpmspc.rtf
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Network.MobileBroadband.CDMA.FWComplyWithMBSpec
USB interface based CDMA class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband Interface Model Specification.
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
USB interface based CDMA class of Mobile Broadband device firmware implementation must comply with the USB-IF's Mobile Broadband Interface Model (MBIM) Specification. No additional IHV drivers are needed for the functionality of the device and the device must work with Microsoft's Mobile Broadband (MB) class driver implementation.
Device firmware must also comply with the MBIM Errata* in addition to the MBIM 1.0 specification. In specific, the following items in MBIM Errata need to be compliant with:
MEFD (MB Extended Functional Descriptor): Devices with Operator specific firmware must report the correct MTU size as required by the Mobile Network Operator for carrier certified devices.
*USB-IF Link that is accessible only to NCM DWG members. This errata will be published once it gets approved.
Additional Details:
Mobile Broadband Interface Model Specification: https://www.usb.org/developers/devclass\_docs/MBIM10.zip
Mobile Broadband Driver Model Specification: https://msdn.microsoft.com/library/windows/hardware/ff560543(v=VS.85).aspx.
Additional Information
| Exceptions |
For MBIM Errata: MBIM 1.0 Devices that have passed Windows 8 Hardware Certification Kit and have received their certifications are exempted from MBIM Errata device firmware requirement. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.IdentityMorphing
Mobile Broadband Devices MUST support Identity Morphing.
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices based on USB protocol must support Identity Morphing. Implementing this requirement in the device firmware enables the device manufacturers to take advantage of Microsoft's inbox MB Class Driver in Windows 8 and the flexibility of using their own driver for previous generations of Windows operating systems version 7 and below. Links to the relevant specifications are provided in the Additional Information section below.Additional Information:Identity Morphing Specification: See MSDN.
Additional Information
| Exceptions |
- Embedded modules do not require supporting this capability. - External USB devices that are targeted only for Windows 8 do not need to implement this requirement. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.ImplementSMS
CMDA class of Mobile Broadband devices must implement all SMS functionality as defined in the Microsoft Mobile Broadband Driver Model Specification.
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Driver must support the all the SMS OIDs defined in the Microsoft Mobile Broadband Driver Model Specification. Design Notes: Here is the link to the Mobile Broadband Driver Model Specification https://msdn.microsoft.com/library/ff560543(v=VS.85).aspx
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.Loopback
Mobile Broadband Devices based on USB protocol MUST implement loopback functionality for performance and payload conformance testing..
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices based on USB protocol must implement a loopback functionality as detailed in the specification in the device firmware. Note that Loopback functionality is only tested for the data packet as it is the one in the performance critical path. Devices must pass the loopback test for performance requirements defined below:
Devices must be able to support combined throughput of 100Mbps (50Mbps uplink / 50Mbps downlink) or above and up to 5% loss rate.
Links to the relevant specifications are provided in the Additional Information section below.
Additional Information:
Loopback implementation guide for device firmware: https://msdn.microsoft.com/library/windows/hardware/hh975390.aspx
MB Miniport Driver Performance Requirements: https://msdn.microsoft.com/library/windows/hardware/ff557193(v=vs.85).aspx .
Additional Information
| Business Justification |
On Windows 8, users are assured of the right performance subject to network conditions. Since this is a loopback test that terminates at the device firmware, there is no dependency to the network and/or air interfaces. This test ensures that the link between host and device is tested for the guaranteed performance. A successful pass of this test, by the device, assures that neither the OS stack nor the device firmware is going to be the bottleneck for throughput when the network conditions are right. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.MultiCarrierFunctionality
Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality.
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality and should also do the following:
Must meet the multi-carrier performance requirements available in the Mobile Broadband Driver Model Specification.
Must stay on the bus when changing home providers.
Must successfully pass all applicable logo tests covering all the different cellular class technologies that the device is capable of connecting to.
Mobile Broadband devices supporting multi-carrier feature must meet the multi-carrier performance requirements specified in mobile broadband driver model specification.Mobile Broadband devices that support multi-carrier feature must not do a bus / device re-enumeration or power reset the device resulting in PnP re-enumeration to the Windows when changing the home providers.If the device is capable of supporting GSM and CDMA cellular class technologies, then the device must execute both GSM as well as CDMA logo tests. For this to be covered correctly, the location of logo test execution must be in the coverage area of at least one GSM and one CDMA cellular class technologies.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.ReliableCSConnectivity
Wireless WAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, ARM (Windows RT) Windows 8.1 Client x86, ARM (Windows RT 8.1) |
Description
The device seamlessly transitions between D0 and D3 warm states while in Connected Standby (CS). The device maintains both L2 & L3 connectivity while in CS. The device wakes up on matching wake patterns only. There are no spurious wakes while in CS. The wake packets are delivered without delay or buffering. RealTimeCommunication apps stay connected in CS over IPv4 and IPv6.
Additional Information
| Business Justification |
Connected standby is a new Windows 8 feature on AOAC(Always On Always Connected) capable tablets that allows the Windows8 applications that use RealTimeCommunication API s to stay connected while the system is consuming very low power. Ensuring reliability of the RealTimeCommunication behavior is a key customer promise for Windows 8. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.SupportUSBSelectiveSuspend
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No alternate USB SS implementation is allowed.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.CDMA.SupportWakeOnMB
Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities
| Target Feature |
Device.Network.MobileBroadband.CDMA |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities.
Devices MUST support 32 bitmap wake patterns of 128 byte each.
Devices MUST wake the system on register state change.
Devices MUST wake the system on media connect.
Devices MUST wake the system on media disconnect.
GSM and CDMA class of Devices MUST wake the system on receiving an incoming SMS message.
Devices that support USSD MUST wake the system on receiving USSD message.
Devices MUST support wake packet indication. NIC should cache the packet causing the wake on hardware and pass it up when the OS is ready for receives.
Mobile Broadband class of devices must support wake on mobile broadband. Device should wake the system on above mentioned events. Note that wake on USSD is mandatory only if the device reports that it supports USSD, else it is optional. See the following MSDN documentation for more information on the SMS and register state wake events.
1.NDIS_STATUS_WWAN_REGISTER_STATE
2.NDIS_STATUS_WWAN_SMS_RECEIVE
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.FirmwareUpdater
Mobile Broadband
| Related Requirements |
Device.Network.MobileBroadband.FirmwareUpdater.FirmwareUpgrade |
Device.Network.MobileBroadband.FirmwareUpdater.FirmwareUpgrade
USB interface based GSM and CDMA class of Mobile Broadband devices that comply with Microsoft's firmware update platform must implement Firmware ID Device Service and an UMDF based firmware update driver for the firmware payload update to the device.
| Target Feature |
Device.Network.MobileBroadband.FirmwareUpdater |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
USB interface based GSM and CDMA class of Mobile Broadband Devices that comply with Microsoft's firmware update platform must implement Firmware ID Device Service (to be published soon on MSDN) and an UMDF based firmware update driver (guidelines and sample to be published soon on MSDN) for the firmware payload update to the device.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM
Mobile Broadband
| Related Requirements |
Device.Network.MobileBroadband.GSM.ComplyWithBaseReq Device.Network.MobileBroadband.GSM.EAPSIM Device.Network.MobileBroadband.GSM.FWComplyWithMBSpec Device.Network.MobileBroadband.GSM.IdentityMorphing Device.Network.MobileBroadband.GSM.ImplementSMS Device.Network.MobileBroadband.GSM.Loopback Device.Network.MobileBroadband.GSM.MultiCarrierFunctionality Device.Network.MobileBroadband.GSM.MultiplePDPContext Device.Network.MobileBroadband.GSM.ReliableCSConnectivity Device.Network.MobileBroadband.GSM.SupportFastDormancy Device.Network.MobileBroadband.GSM.SupportUSBSelectiveSuspend Device.Network.MobileBroadband.GSM.SupportWakeOnMB Device.Network.MobileBroadband.GSM.USSD |
Device.Network.MobileBroadband.GSM.ComplyWithBaseReq
Mobile Broadband devices must comply with the following base requirements
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices must comply with the following base requirements:
MUST conform to NDIS 6.30 and Microsoft Mobile Broadband Driver Model Specification requirements in the Windows Driver Kit.
MUST comply with power management specifications.
MUST meet the performance target for various operation specified for various class of devices in the Mobile Broadband Driver Model Specification
Mobile Broadband device driver must implement and conform to the NDIS 6.30 and Microsoft Mobile Broadband Driver Model Specifications. All recommended implementation specified in the Mobile Broadband Driver Model Specifications needs to be implemented. Note that Microsoft's MB class driver is compliant to above requirements.Mobile Broadband Device must support the Power Management Policy as outline in the Network Device Class Power Management Reference Specification, Version 2.0. Device must be functional after various OS Power Management operations.Device must meet the performance targets describe in the Mobile Broadband Driver Model Specification.Design Notes: Helpful links:Mobile Broadband Driver Model Specifications https://msdn.microsoft.com/library/ff560543(v=VS.85).aspxNetwork Device Class Power Management Reference Specificationhttps://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/netpmspc.rtf
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Network.MobileBroadband.GSM.EAPSIM
GSM class of Mobile Broadband devices that support extensible authentication protocol method for GSM Subscriber Identity Module (EAP-SIM) must support EAP-SIM defined in RFC 4186.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
GSM devices that support EAP-SIM must support EAP-SIM defined in RFC 4186.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.FWComplyWithMBSpec
USB interface based GSM class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband Interface Model Specification.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
USB interface based GSM class of Mobile Broadband device firmware implementation must comply with the USB-IF's Mobile Broadband Interface Model (MBIM) Specification. No additional IHV drivers are needed for the functionality of the device and the device must work with Microsoft's Mobile Broadband (MB) class driver implementation.
Device firmware must also comply with the MBIM Errata* in addition to the MBIM 1.0 specification. In specific, the following items in MBIM Errata need to be compliant with:
MEFD (MB Extended Functional Descriptor): Devices with Operator specific firmware must report the correct MTU size as required by the Mobile Network Operator for carrier certified devices.
*USB-IF Link that is accessible only to NCM DWG members. This errata will be published once it gets approved.
Additional Details:
Mobile Broadband Interface Model Specification: https://www.usb.org/developers/devclass\_docs/MBIM10.zip
Mobile Broadband Driver Model Specification: https://msdn.microsoft.com/library/windows/hardware/ff560543(v=VS.85).aspx.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.IdentityMorphing
Mobile Broadband Devices MUST support Identity Morphing.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices based on USB protocol must support Identity Morphing. Implementing this requirement in the device firmware enables the device manufacturers to take advantage of Microsoft's inbox MB Class Driver in Windows 8 and the flexibility of using their own driver for previous generations of Windows operating systems version 7 and below. Links to the relevant specifications are provided in the Additional Information section below.Additional Information:Identity Morphing Specification: See MSDN.
Additional Information
| Exceptions |
- Embedded modules do not require supporting this capability. - External USB devices that are targeted only for Windows 8 do not need to implement this requirement. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.ImplementSMS
GSM class of Mobile Broadband devices must implement all SMS functionality as defined in the Microsoft Mobile Broadband Driver Model Specification.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Driver must support the all the SMS OIDs defined in the Microsoft Mobile Broadband Driver Model Specification. Design Notes: Here is the link to the Mobile Broadband Driver Model Specification https://msdn.microsoft.com/library/ff560543(v=VS.85).aspx
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.Loopback
Mobile Broadband Devices based on USB protocol MUST implement loopback functionality for performance and payload conformance testing..
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices based on USB protocol must implement a loopback functionality as detailed in the specification in the device firmware. Note that Loopback functionality is only tested for the data packet as it is the one in the performance critical path. Devices must pass the loopback test for performance requirements defined below:
Devices must be able to support combined throughput of 100Mbps (50Mbps uplink / 50Mbps downlink) or above and upto 5% loss rate.
Links to the relevant specifications are provided in the Additional Information section below.
Additional Information:
Loopback implementation guide for device firmware: https://msdn.microsoft.com/library/windows/hardware/hh975390.aspx
MB Miniport Driver Performance Requirements: https://msdn.microsoft.com/library/windows/hardware/ff557193(v=vs.85).aspx .
Additional Information
| Business Justification |
On Windows 8, users are assured of the right performance subject to network conditions. Since this is a loopback test that terminates at the device firmware, there is no dependency to the network and/or air interfaces. This test ensures that the link between host and device is tested for the guaranteed performance. A successful pass of this test, by the device, assures that neither the OS stack nor the device firmware is going to be the bottleneck for throughput when the network conditions are right. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.MultiCarrierFunctionality
Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality and should also do the following:
Must meet the multi-carrier performance requirements available in the Mobile Broadband Driver Model Specification.
Must stay on the bus when changing home providers.
Must successfully pass all applicable logo tests covering all the different cellular class technologies that the device is capable of connecting to.
Mobile Broadband devices supporting multi-carrier feature must meet the multi-carrier performance requirements specified in mobile broadband driver model specification.Mobile Broadband devices that support multi-carrier feature must not do a bus / device re-enumeration or power reset the device resulting in PnP re-enumeration to the Windows when changing the home providers.If the device is capable of supporting GSM and CDMA cellular class technologies, then the device must execute both GSM as well as CDMA logo tests. For this to be covered correctly, the location of logo test execution must be in the coverage area of at least one GSM and one CDMA cellular class technologies.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.MultiplePDPContext
Multiple PDP context support
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
With this feature, Windows Apps can communicate over different PDP contexts (virtual channels) in mobile networks. Mobile Operators use different PDP Context to create the differentiated experiences and innovative services. Third Party App developers can use this feature to build great quality VOIP and video streaming experiences partnering with mobile operators.
Device firmware capable of multiple PDP contexts need to comply with MBIM specification. Specifically,
Device firmware should support multiple IP data streams as detailed in section 10.5.12.1 in MBIM specification. This includes supporting all the control implementation of CIDs and IP data streams for full support of multiple PDP contexts.
Device firmware must support a total of 8 dual bearer (IPv4 & IPv6) PDP contexts for usage by Windows.
This includes 1 for internet connectivity and 7 additional for Operator Apps.
Devices are not required to expose their internal, firmware managed PDP contexts used for SMS and any other administration context to Windows
Device firmware should be able to leverage host OS request for a PDP context that is already device managed internally in its firmware to be handled gracefully.
Device firmware should continue to abstract SMS PDP contexts and route them through the SMS CIDs regardless of the bearer used underneath.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.ReliableCSConnectivity
Wireless WAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, ARM (Windows RT) Windows 8.1 Client x86, ARM (Windows RT 8.1) |
Description
The device seamlessly transitions between D0 and D3 warm states while in Connected Standby (CS). The device maintains both L2 & L3 connectivity while in CS. The device wakes up on matching wake patterns only. There are no spurious wakes while in CS. The wake packets are delivered without delay or buffering. RealTimeCommunication apps stay connected in CS over IPv4 and IPv6.
Additional Information
| Business Justification |
Connected standby is a new Windows 8 feature on AOAC(Always On Always Connected) capable tablets that allows the Windows8 applications that use RealTimeCommunication API s to stay connected while the system is consuming very low power. Ensuring reliability of the RealTimeCommunication behavior is a key customer promise for Windows 8. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.SupportFastDormancy
GSM class of Mobile Broadband devices MUST support Fast Dormancy mechanism defined by 3GPP in release 8.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband devices must implement fast dormancy mechanism defined by 3GPP in revision 8. Fast Dormancy is a battery life savings mechanism for UE (User Equipment) devices that allows the devices to request the network to put them in a low power channel. UE sends a SIGNALLING CONNECTION RELEASE INDICATION (SCRI) message (sent by the UE to the network) with the IE "Signaling Connection Release Indication Cause" present and set to "UE Requested PS Data session end".
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.SupportUSBSelectiveSuspend
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No alternate USB SS implementation is allowed.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.SupportWakeOnMB
Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities.
Devices MUST support 32 bitmap wake patterns of 128 byte each.
Devices MUST wake the system on register state change.
Devices MUST wake the system on media connect.
Devices MUST wake the system on media disconnect.
GSM and CDMA class of Devices MUST wake the system on receiving an incoming SMS message.
Devices that support USSD MUST wake the system on receiving USSD message.
Devices MUST support wake packet indication. NIC should cache the packet causing the wake on hardware and pass it up when the OS is ready for receives.
Mobile Broadband class of devices must support wake on mobile broadband. Device should wake the system on above mentioned events. Note that wake on USSD is mandatory only if the device reports that it supports USSD, else it is optional. See the following MSDN documentation for more information on the SMS and register state wake events.
1.NDIS_STATUS_WWAN_REGISTER_STATE
2.NDIS_STATUS_WWAN_SMS_RECEIVE
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.MobileBroadband.GSM.USSD
GSM class of Mobile Broadband devices that implement Unstructured Supplementary Service Data (USSD) must support USSD based on Mobile Broadband Driver Model.
| Target Feature |
Device.Network.MobileBroadband.GSM |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Windows Mobile Broadband Driver Model is updated to include the full support of sending and receiving USSD messages. Devices that implement USSD must support USSD based on Mobile Broadband Driver Model.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router
Feature required to be a router
| Related Requirements |
Device.Network.Router.BasicCompatibility Device.Network.Router.BasicPerf Device.Network.Router.ConeOrRestrictedNAT Device.Network.Router.GetTotalBytesPerf Device.Network.Router.GetTotalBytesSupport Device.Network.Router.NATLoopback Device.Network.Router.PresentationURLPnPProperty Device.Network.Router.UPnPIGD Device.Network.Router.UPnPPortMappings Device.Network.Router.WCNDynamicPIN Device.Network.Router.WFACertified Device.Network.Router.WPSVer2 Device.Network.Router.WPSVer2PushButton |
Device.Network.Router.BasicCompatibility
Routers must meet basic Microsoft product compatibility requirements
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A router must meet basic Microsoft product compatibility requirements. These include the following:
MTU size: The maximum transmission unit (MTU) size must not exceed 1365.
ICMP echo: The router must avoid resetting port mappings if an Internet Control Message Protocol (ICMP) Echo message fails or times out. The router must support correct responses to ICMP Destination Unreachable and Port Unreachable messages.
DHCP lease: A Dynamic Host Configuration Protocol (DHCP) client behind the routing device can receive the same IP address with a lease duration of longer than five minutes when an IP address is renewed repeatedly.
UDP packet handling: UDP packets from separate WAN-side IP addresses must be able to traverse the network address translation (NAT) component of the router. For session policy, devices must keep a UDP port association open when the only traffic that the router receives is the keep-alive traffic that is generated through UDP.
TCP sockets: The router must be able to download packets on TCP ports 80 and 307.4
FIN segment response: For the TCP finish (FIN) segment response, the device must keep a TCP socket association open until a download is complete, even after an internal client sends a TCP FIN packet.
Windows Scaling
ECN
Teredo
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.BasicPerf
Wireless router must meet basic wireless performance requirements.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A wireless router must meet be able to sustain a minimum wireless throughput of 18 megabits per second (Mbps) (for 11g routers) and 60 Mbps (for 11n routers) over a Wi-Fi Protected Access version 2 (WPA2) Advanced Encryption Standard (AES) pre-shared key (PSK) secured connection based on the following test requirements and metrics:
The test range is at least 10 feet.
The test duration is one hour.
The packet loss during the test is 1% or less.
The test environment is open air, or non-chamber.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.ConeOrRestrictedNAT
Routers must implement a cone or restricted NAT type
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
Routers must not use a symmetric NAT type. After traversal, the NAT must store mappings between the private address and port pair and the public address and port pair. After the NAT translation table entry is established, inbound traffic to an external address and port pair is allowed from any source address and port pair.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.GetTotalBytesPerf
Routers must respond to the GetTotalBytesSent and GetTotalBytesReceived actions within 1000ms
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
When the WAN port of the device is saturated, or under 95% load of rated port speed, the device must respond to GetTotalBytesSent and GetTotalBytesReceived queries within 1000 milliseconds (ms). The device must be able to respond to five simultaneous requests without reporting any errors. The total time to process the requests is cumulative. Five simultaneous requests may take 1000 ms x 5, or 5000 ms, to complete. These actions are contained within the UPnP Internet Gateway Device (IGD) device control protocol (DCP). These actions must be turned on and enabled by default. See requirement Network-0080.Design Notes: See the UPnP IGD Specification revision1.0 at https://go.microsoft.com/fwlink/?LinkId=58381
Additional Information
| Business Justification |
Background Intelligent Transfer Service (BITS) is used by Windows Update, Microsoft Update, Systems Management Server (SMS), MOM, and many other applications to distribute and maintain software on Windows systems. Many of these computers are found in homes, small businesses, and branch offices behind low-cost gateway devices. These computers must be maintained without interrupting normal business operations or home users who are playing video games or listening to music. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.GetTotalBytesSupport
Routers must support GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
All routers must correctly implement the GetTotalBytesSent and GetTotalBytesReceived actions of the urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1 <element> as defined in the UPnP IGD 1.0 specification. According to the standard, the counters must be an unsigned 32-bit number. The counters must also correctly handle values that are larger than 2 gigabytes (GB).Design Notes: See the UPnP IGD Specification Revision 1.0 at https://go.microsoft.com/fwlink/?LinkId=58381
Additional Information
| Business Justification |
Background Intelligent Transfer Service (BITS) is used by Windows Update, Microsoft Update, Systems Management Server (SMS), MOM, and many other applications to distribute and maintain software on Windows systems. Many of these computers are found in homes, small businesses, and branch offices behind low-cost gateway devices. These computers must be maintained without interrupting normal business operations or home users who are playing video games or listening to music. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.NATLoopback
Router must support NAT Loopback.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A NAT device must support hairpin or loopback functionality. This means the NAT must carry out a "Twice-NAT" translation of addresses for local systems, allowing them to communicate with one another. When a host on the private side of a NAT device attempts to connect with another host behind the same NAT device by using the public address of the target host, the NAT device must perform the equivalent of a "Twice-NAT" translation on the packet. The originating host's private endpoint must be translated into its assigned public endpoint and the target host's public endpoint must be translated into its private endpoint, before the packet is forwarded to the target host
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.UPnPIGD
Router must implement UPnP IGD v1.0 and ship with UPnP IGD enabled (turned on) by default.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
The device must implement UPnP Internet Gateway Device (IGD) 1.0 or greater. Device must have passed all UPnP Implementers Corporation tests for IGD. UPnP IGD must be on (enabled) by default, that is, in the factory-shipping state and following a physical (reset to factory conditions) reset.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.UPnPPortMappings
Router must support at least 25 UPnP port mappings.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A router must support at least 25 individual port mappings that can be configured remotely via UPnP.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.WCNDynamicPIN
Router that implements a display must generate a dynamic WCN PIN and display it correctly.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A wireless router that implements a display (ex. OLED or LCD) that can support a 4 or 8 digit WCN PIN must generate a dynamic WCN PIN and displaying it on the screen correctly.The device must indicate support for display in the WPS configuration methods.Design Notes: See the WCN Specification at https://go.microsoft.com/fwlink/?LinkId=50323.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.WFACertified
A wireless router must be WFA (Wi-Fi Alliance) certified.
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A wireless router must be WFA (Wi-Fi Alliance) certified for:
All IEEE radio standards supported in the device: 802.11a, 802.11b, 802.11g, and 802.11n
Wi-Fi wireless network security - WPA (Wi-Fi Protected Access ) and WPA2 (Wi-Fi Protected Access 2)
WiFi Protected Setup (WPS PIN and WPS PBC)
WiFi Multimedia QoS (WMM)
The WiFi Certification ID for the device is required to verify these requirements.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.WPSVer2
Routers must support WPS-Version 2
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A wireless router must support the Wi-Fi Protected Setup Specification version 2.0 from the Wi-Fi Alliance. The router must also pass the Wi-Fi Alliance certification program.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Router.WPSVer2PushButton
Wireless routers must support a hardware push-button for WPS Version 2
| Target Feature |
Device.Network.Router |
| Applies to |
Windows 7 Client x86 Windows 8 Client x86 Windows 8.1 Client x86 |
Description
A wireless router must have a hardware push button that the user can clearly identify as the push button for setting up wireless security. The push button must comply with the WCN specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.Switch.DAL-TOR
The DAL-TOR feature in Windows is a feature that allows end-users to manage datacenter devices in a uniform and industry-standard way. DAL-TOR specifically deals with Top-of-Rack switches
| Related Requirements |
Device.Network.Switch.DAL-TOR.Manageability |
Device.Network.Switch.DAL-TOR.Manageability
Device.Network.Switch.DAL-TOR.Manageability
| Target Feature |
Device.Network.Switch.DAL-TOR |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The switch shall implement the DMTF-DAL-TOR schema and has the ability to perform the following management operations via implemented CIM classes remotely over WS-Man
a.Get, Enable and Disable Switch Features
b.Get, Enable and Disable Ports
c.Set Port to Access or Trunk mode
d.Get, Set Port Description
e.Get a list of VLANs for a Trunk Port
f.Get the VLAN for an Access Port
g.Add/Remove a VLAN to/from a Trunk Port
h.Get a list of VLANs
i.Enable/Disable a VLAN
j.Create/Delete a VLAN
k.Change VLAN Name
l.Get, Set IP Address assigned to the management port
m.Shutdown/Restart Switch
n.Get, Set Switch Host Name
o.Get Firmware Version Info
p.Get, Set Banner for login
Additional Information
| Business Justification |
Compatibility of Top-of-Rack switch with DAL-TOR management feature in Windows 8.1 allows end-users of Windows 8.1 to manage TORs in a uniform and standard way reducing complexity involved in managing TORs from different manufacturers and improving the overall management experience. This will be one of the differentiating factors for Windows 8.1 as compared to competitors in the Cloud OS Platform arena. Having this requirement as part of the Windows Certification program encourages TOR IHVs to implement manageability in an industry-standard. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base
Wireless LAN
| Related Requirements |
Device.Network.WLAN.Base.BootTimeAndHibernate Device.Network.WLAN.Base.ConformToNDIS Device.Network.WLAN.Base.HighThroughputLowLatency Device.Network.WLAN.Base.ImplementD0PacketCoalescing Device.Network.WLAN.Base.ImplementIEEE802.11ac Device.Network.WLAN.Base.ImplementVoicePersonalWMMPowerSave Device.Network.WLAN.Base.MeetPerformanceReq Device.Network.WLAN.Base.MeetScanAndConnReq Device.Network.WLAN.Base.MinimizeCPUUtilization Device.Network.WLAN.Base.OnlyWDFOrNDIS630Calls Device.Network.WLAN.Base.PassWiFiAllianceCertification Device.Network.WLAN.Base.PermitIEToRequestAndResponseAF Device.Network.WLAN.Base.SupportFiltering32MulticastAddresses Device.Network.WLAN.Base.SupportIEEE80211w Device.Network.WLAN.Base.SupportMultiDeviceInstances Device.Network.WLAN.Base.SupportPromiscuousAndMulticastPacketFiltering Device.Network.WLAN.Base.SupportSeparateBeaconAndProbeIE Device.Network.WLAN.Base.SupportVirtualWiFi Device.Network.WLAN.Base.SupportWiFiAutoSaveMode Device.Network.WLAN.Base.TransmitPacketsOnAnyBoundary |
Device.Network.WLAN.Base.BootTimeAndHibernate
Boot time and Hibernation requirements for WLAN devices
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
WLAN devices must meet the following requirements during boot time and resume from hibernate.
Device must not fall off the bus as part of its initial (boot time) firmware download process or while going to hibernate state.
Device must complete the MiniportInitializeEx routine within 1 second. Time is measured between when NDIS calls MiniportInitializeEx function as part of a system PnP operation and NDIS_STATUS_SUCCESS is returned.
The requirement is applicable to all WLAN devices across all bus types.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.ConformToNDIS
WLAN devices MUST conform to NDIS requirements in the Windows Driver Kit.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All WLAN device drivers MUST conform to NDIS 6.30 and the Native Wi-Fi driver model specified in the Windows Driver Kit.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.HighThroughputLowLatency
High Throughput Low Latency Requirements for WLAN devices
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
This requirement is mandatory for all WLAN devices.
WLAN devices must be able to support high throughput, low latency applications/scenarios such as Wi-Fi Display/Lync/Skype. WLAN device must support the following:
-WMM must be supported on all ports including virtualized ports ExtSTA, Wi-Fi Direct Role Port (Group Owner), and Wi-Fi Direct Role Port (Client).
-The NIC should be capable of supporting prioritization across two ports (ExtSTA & one Wi-Fi Direct Role Port) at the same time.
-Prioritize traffic based on 802.11e Access Category (AC) tagging.
-When the NIC is virtualized with Concurrency in single channel, it must be able to prioritize transmit traffic across different virtual ports based on WMM & Media Streaming indication.
-When the NIC is virtualized with Concurrency across multiple channels, it must be able to prioritize transmit traffic across different virtual ports based on WMM and Media Streaming Indication and receiving traffic is serviced across the concurrent channels.
When WMM prioritization is used with AC_VI or AC_VO (Voice/Video), WLAN device should meet the following latency and packet loss requirements.
| ExSTA |
Wi-Fi Direct Role Port |
Max. One Way Latency at UDP for AC_VI/AC_VO Traffic |
Packet Loss for AC_VI/AC_VO Traffic |
|
| ExSTA Only |
AC_VI/AC_VO |
NA |
30ms |
0.5%, not more that 3 consequetive packets |
| ExSTA + Wi-Fi Direct in Single Channel Concurrency |
AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
|
| AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
||
| AC_VI/AC_VO |
AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
|
| ExSTA + Wi-Fi Direct in Multi Channel Concurrency |
AC_VI/AC_VO |
40ms |
0.5%, not more that 3 consequetive packets |
|
| AC_VI/AC_VO |
40ms |
0.5%, not more that 3 consequetive packets |
||
| AC_VI/AC_VO |
AC_VI/AC_VO |
50ms |
0.5%, not more that 3 consequetive packets |
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.ImplementD0PacketCoalescing
WLAN devices that implement D0 Packet Coalescing MUST support D0 Packet Coalescing.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Windows will optimize the networking power efficiency by allowing the device to aggregate and delay certain network protocols. The device that implements D0 Packet Coalescing is expected to queue packets and indicate to the OS on a periodic basis.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.ImplementIEEE802.11ac
IEEE 802.11ac implementation for WLAN devices
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
This requirement applies only to WLAN devices that implement IEEE 802.11ac. Note that 802.11ac Phy Type support is optional for WLAN devices.
WLAN devices that implement IEEE P802.11ac must meet the following requirements:
1)Devices must pass the Wi-Fi Alliance certification for IEEE 802.11 ac on Windows platform.
2)Device must report 802.11ac PHY type 8 (dot11_phy_type_vht) in the Supported PhyAttributes structure of NDIS_MINIPORT_ADAPTER_NATIVE_802_11_ATTRIBUTES structure during miniport initialization.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.MeetPerformanceReq
WLAN devices MUST meet performance requirements.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
All 802.11 devices MUST meet the following performance requirements:
Radio Management: WLAN devices must be able to change the state of the radio within 2 sec. Time will be measured between when set request is send through OID_DOT11_NIC_POWER_STATE and when miniport indicates NDIS_STATUS_DOT11_PHY_STATE_CHANGED back.
Throughput With Concuuent Operation: The 802.11 devices MUST NOT have more than 20% aggregate throughput degradation when data flow is divided among 3 ports (with and without Multi-Channel/Band operation) namely ExtSTA, Wi-Fi Direct Role Port (GO) and Wi-Fi Direct Role Port (Client) compared with aggregate throughput when only one Wi-Fi port is connected.
Throughput :
This requirement for throughput is applicable to all types of ports [ExtSTA, Wi-Fi Direct Role Port (GO) and Wi-Fi Direct Role Port (Client)] individually.
Device must be capable of supporting the following throughput numbers over a TCP connection for a particular combination of Phy type, number of streams and channel width. Throughput is measured at the application layer using NTTTCP perf measurement tool built into Windows hardware certification kit.
If WLAN device supports 802.11ac Phy Type (Note that 802.11ac Phy Type support is optional for WLAN devices. 802.11ac devices will also be tested for 802.11n operations)
802.11ac combinations will be tested on 5 Ghz band only.
Both transmit and receive side throughput will be tested. Device is expected to meet same throughput number (listed below) for a particular combination on both transmission and reception side.
Max supported spatial stream by the NIC will be tested. E.g., if the NIC supports 3 spatial streams, combinations with spatial stream 3 will be tested.
Channel Width
20 Mhz
40 Mhz
80 Mhz
# of Spatial Streams
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
1 Stream
86
18
200
42
433
90
2 Stream
173
38
400
88
866
191
3 Stream or higher*
258
47
600
110
1300
237
All speeds are in Mbps.
* Combinations not required for SDIO and USB 2.0 Bus Type devices. These devices with support for more than 2 streams must be able to attain values listed for 2 streams. Note that USB 3.0 devices are not excluded.
802.11n WLAN devices (Note that 802.11n Phy Type support is mandatory for WLAN devices)
802.11n combinations will be tested over both 2.4 Ghz and 5 Ghz bands if both bands are supported on the device.
Both transmit and receive side throughput will be tested. Device is expected to meet same throughput number (listed below) for a particular combination on both transmission and reception side.
Max supported spatial streams by the NIC will be tested. E.g., if the NIC supports 3 spatial streams, combinations with spatial streams 3 will be tested.
Channel Width
20 Mhz
40 Mhz
# of Spatial Streams
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
1 Stream
72
15
150
31
2 Stream
144
32
300
66
3 Stream or higher*
216
40
450
82
All speeds are in Mbps.
*Combinations not required for SDIO Bus Type devices. SDIO devices with support for more than 2 streams must be able to attain values listed for 2 streams.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.MeetScanAndConnReq
WLAN devices MUST meet scanning and connection requirements.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Preferred channels set: When supported and permitted by the regulatory domain, the miniport driver MUST prefer the following channels when scanning for available networks or roaming to find a candidate access point:
2.4 Ghz channels: 1 to 14
5GHz U-NII Low channels: 36, 40, 44, 48
5GHz U-NII Mid channels: 52, 56, 60,64
5GHz U-NII Worldwide channels: 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
5GHz U-NII Upper channels: 149, 153, 157, 161,165
The driver should report support for these and any other channels it supports through OID_DOT11_SUPPORTED_DSSS_CHANNEL_LIST and OID_DOT11_SUPPORTED_OFDM_FREQUENCY_LIST.Association Time: On WPA2-PSK networks, WLAN devices should finish the association within 200ms. It is measured as the time between the events when OS issues an OID "OID_DOT11_CONNECT_REQUEST" and miniport sends an "NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION" indication to the OS. General Scanning: WLAN device should start scanning when it receives OID "OID_DOT11_SCAN_REQUEST" from OS or the device resumes to D0 state from low power state and reply back with an indication "NDIS_STATUS_DOT11_SCAN_CONFIRM" to the OS as soon as it completes the scan. In case of active scanning, miniport is expected to send the active wildcard probes to the network channels to meet the scanning goals. In case of passive scanning, miniport is not expected to send any probes to the network channels. Following priority order should be followed for scanning.
NLO channel hints
Preferred channels
Any remaining channels
The timings listed below will be measured from the time stamp when the device receives OID "OID_DOT11_SCAN_REQUEST" from OS to the time stamp when the respective indication is provided to the OS by the miniport.
If the Network list offload hints are available, the device should leverage the network list offload hints to optimize scanning behavior and return "NDIS_STATUS_DOT11_OFFLOAD_NETWORK_STATE_CHANGED" indication when a matching profile is found within the following timings:
Scanning a network were active scanning is allowed - 20ms/channel
Scanning a network were only passive scanning is allowed - 120ms/channel
If there is no match found using Network List Offload hints, WLAN device should next scan the preferred channels in the list above. For scanning the channels in the preferred channel list, WLAN device should not take more than 3.5 seconds (time includes scanning for both active and passive channels). The newly created list of surrounding BSS entries should be returned on the next BSS list query from the OS.
If there is no match found in above 2 cases, WLAN device should next scan any remaining channels. WLAN device should not take more than 4 sec for the entire scan operation.
Resume from Sleep/Screen Off: When resuming from sleep/screen off, the WLAN device is expected to reconnect to the same AP that it was connected to before going to sleep, if it is available. WLAN devices should meet the following timings for detecting its presence:
Reconnecting to a channel were active scanning is allowed - 50ms
Reconnecting to a channel were only Passive scanning is allowed - 120ms
If the last connected network is not found, WLAN device should scan for networks in the priority order listed below.
NLO channel hints
Preferred channels
Any remaining channels
WLAN device should follow the similar timing constraints as defined above in the general scanning section. The timings will be measured from the time stamp when the device reports as being in D0 state (protocol driver reporting "NetDeviceStateD0" through "NetEventSetPower" PnP event) to the time stamp when the respective indication is provided to the OS by the miniport. Roaming: Driver MUST detect and indicate the loss of AP (no beacons) within 20 beacon intervals.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.MinimizeCPUUtilization
WLAN devices MUST minimize CPU utilization.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
The Wi-Fi device should conform to the following requirements for minimizing CPU utilization.
While in EXTSTA mode and in D0 state, WLAN devices must not interrupt OS more than 1 time per data packet (non D0 coalesced packets only. If WLAN device supports D0 packet coalescing, WLAN device should comply with the D0 packet coalescing spec for D0 coalesced packets). Note that if WLAN device is using SDIO bus interface, interrupts generated by SDIO host controller per data packet are exempted from this requirement. Non data packet-related interrupts, if needed, must not exceed an average of 3 interrupts per second when measured over a 2 minute period. Also, as a best practice, in active state (when there is data traffic), the non-data packet related interrupts should be issued within 1 millisecond of a valid packet-related interrupt.
In D0 state, all (if any) miniport specific periodic maintenance timers must be specified using an available "timer coalescing" API, with a minimum 2 second period and 1 second tolerance. This requirement will be tested in a long running connected state when there is no change in connectivity. All such timers must be cancelled in D3 state. Note that this requirement doesn't apply to timers defined in IEEE 802.11 specification e.g., connection timers such as association timers, roaming timers etc.
An individual DPC (Deferred Procedural Call) duration MUST not exceed 2 milliseconds. Accumulated DPC duration should be less than 4 milliseconds over any 10 millisecond window.
In low power states, if the device is not Wake on Wireless capable, WLAN device must not interrupt the CPU. If the device is Wake on Wireless capable, WLAN device must not interrupt the CPU except on wake triggers indicated by NDIS for Wake on Wireless LAN. All interrupts not related to wake triggers must be cancelled.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.OnlyWDFOrNDIS630Calls
WLAN devices MUST make only NDIS 6.30 or WDF system calls.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Network device drivers must make only Network Driver Interface Specification (NDIS) 6.30 or Windows Driver Foundation (WDF) calls. Any calls to kernel mode components are not allowed.See the "NDIS" and "WDF" topics in the Windows Driver Kit.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.PassWiFiAllianceCertification
WLAN Device MUST successfully pass the current Wi-Fi Alliance certification for 802.11/WPA2/WPA, 802.11n, WMM (STA), and Protected Management Frames (PMF).
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
WLAN Device must successfully pass the current Wi-Fi Alliance (WFA) certification for 802.11/WPA2/WPA, 802.11n, WMM (STA), and Protected Management Frames (PMF). 802.11a-only implementations are not permitted.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.PermitIEToRequestAndResponseAF
WLAN devices MUST permit addition of Information Elements to request and response association frames.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All 802.11 devices MUST permit Information Elements to be added to association frames, both requests and responses. This includes adding currently specified Information Elements, such as Wi-Fi Protected Setup as well as other vendor extended Information Elements.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportFiltering32MulticastAddresses
WLAN devices MUST support filtering for at least 32 multicast addresses on each port.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WLAN hardware MUST support at least 32 multicast addresses on each port. Both STA and Wi-Fi-Direct ports need to support filtering 32 multicast addresses separately.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportIEEE80211w
WLAN devices MUST Support IEEE 802.11w standard for protected management frames.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
IEEE 802.11w is an addition to IEEE 802.11 suite of standards to enhance the security of management frames. All WLAN devices must support the IEEE 802.11w standard.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportMultiDeviceInstances
WLAN devices MUST support multiple device instances.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Plug and Play can support multiple instances of a device. Multiple instances of the device can exist and function in the same system at the same instance. For network communications devices, the Plug and Play IDs and resource support MUST be sufficient to allow multiple network communications devices to be added automatically to the system. This requirement implies that all device resources MUST be set and read through the standard interfaces provided by the bus on which the device resides. For PCI devices, this interface is the PCI configuration space. Also, device parameter settings MUST be stored in the registry.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportPromiscuousAndMulticastPacketFiltering
WLAN devices MUST support promiscuous and multicast packet filtering.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WLAN device and driver MUST support promiscuous and multicast packet filtering. The miniport driver MUST support all filter types identified in the Windows Driver Kit. By default, multicast promiscuous mode is not enabled.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportSeparateBeaconAndProbeIE
WLAN devices MUST support separate beacon and probe Information Elements.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All 802.11 devices MUST separately indicate the Wi-Fi Protected Setup IEs that are received in Beacon frames and probe-response frames. If the device has received both a beacon frame and a probe-response frame from a particular BSSID, then it MUST provide two instances of the IE, where one instance is the most recently received WPS IE from the Beacon and one instance is the most recently received WPS IE from the probe response.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportVirtualWiFi
WLAN devices MUST support Virtual Wi-Fi.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All 802.11 devices MUST support Virtual Wi-Fi and enable simultaneous infrastructure STA connection and Soft AP hosting OR infrastructural STA and Wi-Fi Direct ports. The Virtual Wi-Fi interface is specified in the Extensible WLAN driver specification document.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.SupportWiFiAutoSaveMode
WLAN devices MUST Support Wi-Fi Auto Power Save Mode.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
The Wi-Fi driver is required to perform detection and negotiation of proper Wi-Fi Power Save Mode (PSM) between the device and the Wi-Fi Access Point and report it in driver capability during initialization in DOT11_EXTSTA_ATTRIBUTES. If the driver reports that it supports PSM detection, WLAN service will delegate the PSM decision to the driver by default. If the driver supports the AUTO-PSM capability the Wi-Fi service will no longer set the broadcast management filter to receive beacons from the miniport and will instead set an OID to turn on Auto-PSM in the driver. When in Auto-PSM, the driver should always negotiate PSM mode when it detects that the AP supports it and manage the use of PSM between the device and the Wi-Fi Access Point to ensure optimal connectivity while using the least amount of power.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.Base.TransmitPacketsOnAnyBoundary
WLAN devices MUST be able to transmit packets from buffers aligned on any boundary.
| Target Feature |
Device.Network.WLAN.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Buffer alignment refers to whether a buffer begins on an odd-byte, word, double-word, or other boundary. Devices MUST be able to transmit packets with any of the packets fragments beginning on an odd-byte boundary. For performance reasons, packets MUST be received into contiguous buffers on a double-word boundary.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase
Wireless LAN
| Related Requirements |
Device.Network.WLAN.CSBBase.BootTimeAndHibernate Device.Network.WLAN.CSBBase.ConformToNDIS Device.Network.WLAN.CSBBase.HighThroughputLowLatency Device.Network.WLAN.CSBBase.ImplementIEEE802.11ac Device.Network.WLAN.CSBBase.ImplementVoicePersonalWMMPowerSave Device.Network.WLAN.CSBBase.MeetPerformanceReq Device.Network.WLAN.CSBBase.MeetScanAndConnReq Device.Network.WLAN.CSBBase.MinimizeCPUUtilization Device.Network.WLAN.CSBBase.MustSupportD0PacketCoalescing Device.Network.WLAN.CSBBase.OnlyWDFOrNDIS630Calls Device.Network.WLAN.CSBBase.PassWiFiAllianceCertification Device.Network.WLAN.CSBBase.PermitIEToRequestAndResponseAF Device.Network.WLAN.CSBBase.ReliableCSConnectivity Device.Network.WLAN.CSBBase.SupportFiltering32MulticastAddresses Device.Network.WLAN.CSBBase.SupportIEEE80211w Device.Network.WLAN.CSBBase.SupportPromiscuousAndMulticastPacketFiltering Device.Network.WLAN.CSBBase.SupportSeparateBeaconAndProbeIE Device.Network.WLAN.CSBBase.SupportVirtualWiFi Device.Network.WLAN.CSBBase.SupportWiFiAutoSaveMode Device.Network.WLAN.CSBBase.TransmitPacketsOnAnyBoundary |
Device.Network.WLAN.CSBBase.BootTimeAndHibernate
BootTimeAndHibernate
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The requirement is applicable to all WLAN devices across all bus types.
WLAN devices that go into systems that support connected standby must meet the following requirements during boot time and resume from hibernate.
-Device must not fall off the bus as part of its initial (boot time) firmware download process or while going to hibernate state.
-Device must complete the MiniportInitializeEx routine within 1 second. Time is measured between when NDIS calls MiniportInitializeEx function as part of a system PnP operation and NDIS_STATUS_SUCCESS is returned.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.ConformToNDIS
WLAN devices that go into systems that support connected standby MUST conform to NDIS requirements in the Windows Driver Kit.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All WLAN devices that go into systems that support connected standby MUST conform to NDIS 6.30 and the Native Wi-Fi driver model specified in the Windows Driver Kit.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.HighThroughputLowLatency
HighThroughputLowLatency
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
This requirement is mandatory for all WLAN devices.
WLAN devices that go into systems that support connected standby must be able to support high throughput, low latency applications/scenarios such as Wi-Fi Display/Lync/Skype. In order to do that, WLAN device must support the following:
-WMM must be supported on all ports including virtualized ports ExtSTA, Wi-Fi Direct Role Port (Group Owner), and Wi-Fi Direct Role Port (Client).
-The NIC should be capable of supporting prioritization across two ports (ExtSTA & one Wi-Fi Direct Role Port) at the same time.
-Prioritize traffic based on 802.11e Access Category (AC) tagging.
-When the NIC is virtualized with Concurrency in single channel, it must be able to prioritize transmit traffic across different virtual ports based on WMM & Media Streaming indication.
-When the NIC is virtualized with Concurrency across multiple channels, it must be able to prioritize transmit traffic across different virtual ports based on WMM & Media Streaming indication and receiving traffic is serviced across the concurrent channels.
When WMM prioritization is used with AC_VI or AC_VO (Voice/Video), WLAN device should meet the following latency and packet loss requirements.
| ExSTA |
Wi-Fi Direct Role Port |
Max. One Way Latency at UDP for AC_VI/AC_VO Traffic |
Packet Loss for AC_VI/AC_VO Traffic |
|
| ExSTA Only |
AC_VI/AC_VO |
NA |
30ms |
0.5%, not more that 3 consequetive packets |
| ExSTA + Wi-Fi Direct in Single Channel Concurrency |
AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
|
| AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
||
| AC_VI/AC_VO |
AC_VI/AC_VO |
30ms |
0.5%, not more that 3 consequetive packets |
|
| ExSTA + Wi-Fi Direct in Multi Channel Concurrency |
AC_VI/AC_VO |
40ms |
0.5%, not more that 3 consequetive packets |
|
| AC_VI/AC_VO |
40ms |
0.5%, not more that 3 consequetive packets |
||
| AC_VI/AC_VO |
AC_VI/AC_VO |
50ms |
0.5%, not more that 3 consequetive packets |
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.ImplementIEEE802.11ac
ImplementIEEE802.11ac
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
This requirement applies only to WLAN devices that implement IEEE 802.11ac. Note that 802.11ac Phy Type support is optional for WLAN devices.
WLAN devices that go into systems that support connected standby and that implement IEEE P802.11ac must meet the following requirements:
1)Devices must pass the Wi-Fi Alliance certification for IEEE 802.11 ac on Windows platform.
2)Device must report 802.11ac PHY type 8 (dot11_phy_type_vht) in the Supported PhyAttributes structure of NDIS_MINIPORT_ADAPTER_NATIVE_802_11_ATTRIBUTES structure during miniport initialization.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.MeetPerformanceReq
WLAN devices that go into systems that support connected standby MUST meet performance requirements.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
All 802.11 devices MUST meet the following performance requirements:
Radio Management: WLAN devices must be able to change the state of the radio within 2 sec. Time will be measured between when set request is send through OID_DOT11_NIC_POWER_STATE and when miniport indicates NDIS_STATUS_DOT11_PHY_STATE_CHANGED back.
Throughput With Concurrent Operations: The 802.11 devices MUST NOT have more than 20% aggregate throughput degradation when data flow is divided among 3 ports(with and without Multi-Channel/Band operation) namely ExtSTA, Wi-Fi Direct Role Port (GO) and Wi-Fi Direct Role Port (Client) compared with aggregate throughput when only one Wi-Fi port is connected.
Throughput :
This requirement for throughput is applicable to all types of ports [ExtSTA, Wi-Fi Direct Role Port (GO) and Wi-Fi Direct Role Port (Client)] individually.
Device must be capable of supporting the following throughput numbers over a TCP connection for a particular combination of Phy type, number of streams and channel width. Throughput is measured at the application layer using NTTTCP perf measurement tool built into Windows hardware certification kit.
If WLAN device supports 802.11ac Phy Type (Note that 802.11ac Phy Type support is optional for WLAN devices. 802.11ac devices will also be tested for 802.11n operations)
802.11ac combinations will be tested on 5 Ghz band only.
Both transmit and receive side throughput will be tested. Device is expected to meet same throughput number (listed below) for a particular combination on both transmission and reception side.
Max supported spatial streams by the NIC will be tested. E.g., if the NIC supports 3 spatial streams, combinations with spatial streams 3 will be tested.
Channel Width
20 Mhz
40 Mhz
80 Mhz
# of Spatial Streams
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
1 Stream
86
18
200
42
433
90
2 Stream
173
38
400
88
866
191
3 Stream or higher*
258
47
600
110
1300
237
All speeds are in Mbps.
* Combinations not required for SDIO Bus and USB 2.0 Type devices. These devices with support for more than 2 streams must be able to attain values listed for 2 streams. Note that USB 3.0 devices are not excluded.
802.11n WLAN devices (Note that 802.11n Phy Type support is mandatory for WLAN devices)
802.11n combinations will be tested over both 2.4 Ghz and 5 Ghz bands.
Both transmit and receive side throughput will be tested. Device is expected to meet same throughput number (listed below) for a particular combination on both transmission and reception side.
Max supported spatial streams by the NIC will be tested. E.g., if the NIC supports 3 spatial streams, spatial stream 3 will be tested.
Channel Width
20 Mhz
40 Mhz
# of Spatial Streams
Max Phy rate (100%)
Throughput expected by Windows Certification
Max Phy rate (100%)
Throughput expected by Windows Certification
1 Stream
72
15
150
31
2 Stream
144
32
300
66
3 Stream*
216
40
450
82
All speeds are in Mbps.
*Combinations not required for SDIO Bus Type devices. SDIO devices with support for more than 2 streams must be able to attain values listed for 2 streams.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.MeetScanAndConnReq
WLAN devices that go into systems that support connected standby MUST meet scanning and connection requirements.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
Preferred channels set: When supported and permitted by the regulatory domain, the miniport driver MUST prefer the following channels when scanning for available networks or roaming to find a candidate access point:
2.4 Ghz channels: 1 to 14
5GHz U-NII Low channels: 36, 40, 44, 48
5GHz U-NII Mid channels: 52, 56, 60,64
5GHz U-NII Worldwide channels: 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
5GHz U-NII Upper channels: 149, 153, 157, 161,165
The driver should report support for these and any other channels it supports through OID_DOT11_SUPPORTED_DSSS_CHANNEL_LIST and OID_DOT11_SUPPORTED_OFDM_FREQUENCY_LIST.Association Time: On WPA2-PSK networks, WLAN devices should finish the association within 200ms. It is measured as the time between the events when OS issues an OID "OID_DOT11_CONNECT_REQUEST" and miniport sends an "NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION" indication to the OS. General Scanning: WLAN device should start scanning when it receives OID "OID_DOT11_SCAN_REQUEST" from OS or the device resumes to D0 state from low power state and reply back with an indication "NDIS_STATUS_DOT11_SCAN_CONFIRM" to the OS as soon as it completes the scan. In case of active scanning, miniport is expected to send the active wildcard probes to the network channels to meet the scanning goals. In case of passive scanning, miniport is not expected to send any probes to the network channels. Following priority order should be followed for scanning.
NLO channel hints
Preferred channels
Any remaining channels
The timings listed below will be measured from the time stamp when the device receives OID "OID_DOT11_SCAN_REQUEST" from OS to the time stamp when the respective indication is provided to the OS by the miniport.
If the Network list offload hints are available, the device should leverage the network list offload hints to optimize scanning behavior and return "NDIS_STATUS_DOT11_OFFLOAD_NETWORK_STATE_CHANGED" indication when a matching profile is found within the following timings:
Scanning a channel were active scanning is allowed - 20ms/channel
Scanning a channel were only passive scanning is allowed - 120ms/channel
If there is no match found using Network List Offload hints, WLAN device should next scan the preferred channels in the list above. For scanning the channels in the preferred channel list, WLAN device should not take more than 3.5 seconds (time includes scanning for both active and passive channels). The newly created list of surrounding BSS entries should be returned on the next BSS list query from the OS.
If there is no match found in above 2 cases, WLAN device should next scan any remaining channels. WLAN device should not take more than 4 sec for the entire scan operation.
Resume from Sleep/Screen Off: When resuming from sleep/screen off, the WLAN device is expected to reconnect to the same AP that it was connected to before going to sleep, if it is available. WLAN devices should meet the following timings for detecting its presence:
Reconnecting to a channel were active scanning is allowed - 50ms
Reconnecting to a channel were only Passive scanning is allowed - 120ms
If the last connected network is not found, the WLAN device should scan for networks in the priority order listed below.
NLO channel hints
Preferred channels
Any remaining channels
WLAN device should follow the similar timing constraints as defined above in the general scanning section. The timings in this case will be measured from the time stamp when the device reports as being in D0 state (protocol driver reporting "NetDeviceStateD0" through "NetEventSetPower" PnP event) to the time stamp when the respective indication is provided to the OS by the miniport. Roaming: Driver MUST detect and indicate the loss of AP (no beacons) within 20 beacon intervals.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.MinimizeCPUUtilization
WLAN devices that go into systems that support connected standby MUST minimize CPU utilization.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
The Wi-Fi device should conform to the following requirements for minimizing CPU utilization.
While in EXTSTA mode and in D0 state, WLAN devices must not interrupt OS more than 1 time per data packet (non D0 coalesced packets only. WLAN device should comply with the D0 packet coalescing spec for D0 coalesced packets). Note that if WLAN device is using SDIO bus interface, interrupts generated by SDIO host controller per data packet are exempted from this requirement. Non data packet related interrupts must not interrupt the CPU and should be handled by the device.
In D0 state, all (if any) miniport specific periodic maintenance timers must be specified using an available "timer coalescing" API, with a minimum 5 second period and 10 second tolerance. This requirement will be tested in a long running connected state when there is no change in connectivity. All such timers must be cancelled in D3 state. Note that this requirement doesn't apply to timers defined in IEEE 802.11 specification e.g., connection timers such as association timers, roaming timers etc.
While in ExtSTA mode and in D0 state, WLAN device must not indicate beacons to OS unless configured to do so by the OS.
An individual DPC (Deferred Procedural Call) duration MUST not exceed 2 milliseconds. Accumulated DPC duration should be less than 4 milliseconds over any 10 millisecond window.
In low power states when the device is armed for Wake, WLAN device must not interrupt the CPU except on the wake triggers indicated by NDIS for Wake on Wireless LAN. All interrupts not related to wake triggers must be cancelled.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.MustSupportD0PacketCoalescing
WLAN devices that go into systems that support connected standby MUST support D0 Packet Coalescing.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
Windows will optimize the networking power efficiency by allowing the device to aggregate and delay certain network protocols. The device is expected to queue packets and indicate to the OS on a periodic basis.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.OnlyWDFOrNDIS630Calls
WLAN devices that go into systems that support connected standby MUST make only NDIS 6.30 or WDF system calls.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
Network device drivers must make only Network Driver Interface Specification (NDIS) 6.30 or Windows Driver Foundation (WDF) calls. Any calls to kernel mode components are not allowed.See the "NDIS" and "WDF" topics in the Windows Driver Kit.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.PassWiFiAllianceCertification
WLAN Devices that go into systems that support connected standby MUST successfully pass the current Wi-Fi Alliance certification for 802.11/WPA2/WPA, 802.11n, WMM (STA), and Protected Management Frames (PMF).
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8.1 Client ARM (Windows RT 8.1) |
Description
WLAN Device must successfully pass the current Wi-Fi Alliance (WFA) certification for 802.11/WPA2/WPA, 802.11n, WMM (STA), and Protected Management Frames (PMF). 802.11a-only implementations are not permitted.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.PermitIEToRequestAndResponseAF
WLAN devices that go into systems that support connected standby MUST permit addition of Information Elements to request and response association frames.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All 802.11 devices MUST permit Information Elements to be added to association frames, both requests and responses. This includes adding currently specified Information Elements, such as Wi-Fi Protected Setup as well as other vendor extended Information Elements.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.ReliableCSConnectivity
Wireless LAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
WLAN device must meet the following requirements:
-The device must seamlessly transitions between D0 and D2 states while in Connected Standby (CS).
-The device must maintain L2 connectivity while in CS.
-The device must wakes up only on the supported wake methods described in WoWLAN requirement. There should be no spurious wakes while in CS.
-The wake packets must not be delayed or buffered for initiating wake operation.
-WLAN device must reliably stay connected in CS over IPv4 and IPv6 protocol if the device is in range of connected SSID.
-WLAN device must reliably stay connected as the device roams from one Wi-Fi access point to another with same SSID while in CS.
Additional Information
| Business Justification |
Connected standby is a new Windows 8 feature on AOAC (Always on Always Connected) capable tablets that allows the Windows8 applications that use RealTimeCommunication API s to stay connected while the system is consuming very low power. Ensuring reliability of the RealTimeCommunication behavior is a key customer promise for Windows8 and it can only be achieved if the devices meet the above requirements. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportFiltering32MulticastAddresses
WLAN devices that go into systems that support connected standby MUST support filtering for at least 32 multicast addresses on each port.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
WLAN hardware MUST support at least 32 multicast addresses on each port. Both STA and Wi-Fi-Direct ports need to support filtering 32 multicast addresses separately.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportIEEE80211w
WLAN devices that go into systems that support connected standby MUST Support IEEE 802.11w standard for protected management frames.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
IEEE 802.11w is an addition to IEEE 802.11 suite of standards to enhance the security of management frames. All WLAN devices must support the IEEE 802.11w standard.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportPromiscuousAndMulticastPacketFiltering
WLAN devices that go into systems that support connected standby MUST support promiscuous and multicast packet filtering.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
WLAN device and driver MUST support promiscuous and multicast packet filtering. The miniport driver MUST support all filter types identified in the Windows Driver Kit. By default, multicast promiscuous mode is not enabled.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportSeparateBeaconAndProbeIE
WLAN devices that go into systems that support connected standby MUST support separate beacon and probe Information Elements.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All 802.11 devices MUST separately indicate the Wi-Fi Protected Setup IEs that are received in Beacon frames and probe-response frames. If the device has received both a beacon frame and a probe-response frame from a particular BSSID, then it MUST provide two instances of the IE, where one instance is the most recently received WPS IE from the Beacon and one instance is the most recently received WPS IE from the probe response.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportVirtualWiFi
WLAN devices that go into systems that support connected standby MUST support Virtual Wi-Fi.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All 802.11 devices MUST support Virtual Wi-Fi and enable simultaneous infrastructure STA connection and Soft AP hosting OR simultaneous infrastructure STA connection and Wi-Fi Direct ports. The Virtual Wi-Fi interface is specified in the Extensible WLAN driver specification document.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.SupportWiFiAutoSaveMode
WLAN devices that go into systems that support connected standby MUST Support Wi-Fi Auto Power Save Mode.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
The Wi-Fi driver is required to perform detection and negotiation of proper Wi-Fi Power Save Mode (PSM) between the device and the Wi-Fi Access Point and report it in driver capability during initialization in DOT11_EXTSTA_ATTRIBUTES. If the driver reports that it supports PSM detection, WLAN service will delegate the PSM decision to the driver by default. If the driver supports the AUTO-PSM capability the Wi-Fi service will no longer set the broadcast management filter to receive beacons from the miniport and will instead set an OID to turn on Auto-PSM in the driver. When in Auto-PSM, the driver should always negotiate PSM mode when it detects that the AP supports it and manage the use of PSM between the device and the Wi-Fi Access Point to ensure optimal connectivity while using the least amount of power.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBBase.TransmitPacketsOnAnyBoundary
WLAN devices that go into systems that support connected standby MUST be able to transmit packets from buffers aligned on any boundary.
| Target Feature |
Device.Network.WLAN.CSBBase |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
Buffer alignment refers to whether a buffer begins on an odd-byte, word, double-word, or other boundary. Devices MUST be able to transmit packets with any of the packets fragments beginning on an odd-byte boundary. For performance reasons, packets MUST be received into contiguous buffers on a double-word boundary.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBNLO
| Related Requirements |
Device.Network.WLAN.CSBNLO.SupportNetworkListOffload |
Device.Network.WLAN.CSBNLO.SupportNetworkListOffload
WLAN devices that go into systems that support connected standby MUST support Network List Offloads.
| Target Feature |
Device.Network.WLAN.CSBNLO |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
WLAN devices MUST support 10 offloaded BSSID profiles. Wi-Fi profiles that are marked auto-connect will be offloaded by the OS to the device. Wi-Fi profiles that are marked auto-connect will be offloaded by the OS to the device. The device should not indicate any new networks to the OS unless it matches the offloaded profiles. The device should also use the network list offload as a hint to optimize scan behaviors and return "NDIS_STATUS_DOT11_OFFLOAD_NETWORK_STATE_CHANGED" indication when a matching profile is found.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBSoftAP
Wireless LAN
| Related Requirements |
Device.Network.WLAN.CSBSoftAP.SupportSoftAP |
Device.Network.WLAN.CSBSoftAP.SupportSoftAP
WLAN devices that go into systems that support connected standby MUST support Soft AP.
| Target Feature |
Device.Network.WLAN.CSBSoftAP |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All 802.11 devices MUST support the Soft AP application with 8 simultaneously associated stations using security (WPA2). All 802.11 devices MUST support the Soft AP by permitting extension of Information Elements in Beacon and Probe Response frames. This includes adding currently specified Information Elements, such as Wi-Fi Protected Setup as well as other vendor extended Information Elements. All 802.11 devices MUST support the Soft AP by permitting stations associated to the Soft AP to utilize power save and providing them with beacon notification to wake up and receive waiting data.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBWiFiDirect
Wireless LAN
| Related Requirements |
Device.Network.WLAN.CSBWiFiDirect.SupportAtLeast2WiFiDirectPortsConcurrently Device.Network.WLAN.CSBWiFiDirect.SupportAtLeast4Clients |
Device.Network.WLAN.CSBWiFiDirect.SupportAtLeast2WiFiDirectPortsConcurrently
WLAN Devices that go into systems that support connected standby MUST support at least 2 Wi-Fi Direct role ports concurrently.
| Target Feature |
Device.Network.WLAN.CSBWiFiDirect |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
LAN Device must be capable of supporting at least 2 Wi-Fi Direct role ports concurrently in the following configurations in addition to the Wi-Fi Direct device port:
A Group Owner (GO) on one Wi-Fi Direct port and Client on the other Wi-Fi Direct port(s) concurrently.
A Client on each Wi-Fi Direct Port concurrently.
These ports must be supported concurrently with Infrastructure connectivity on different channels across different bands (2.4/5 Ghz)- Maximum of two concurrent channels.
Device must be able to concurrently support following combinations:
If WLAN device supports 802.11ac
ExTSTA Port
Wi-Fi Direct Role Port 1
Wi-Fi Direct Role Port 2
Case #
802.11n
802.11ac
802.11n
802.11ac
802.11n
802.11ac
2.4 Ghz
5 Ghz
5 GHz
2.4 Ghz
5 Ghz
5 GHz
2.4 Ghz
5 Ghz
5 GHz
1
STA
x
x
GO
x
x
x
x
x
2
STA
x
x
Client
x
x
x
x
x
4
STA
x
x
x
Client
x
x
x
x
6
STA
x
x
x
x
Client
x
x
x
7
STA
x
x
GO
x
x
Client
x
x
8
STA
x
x
Client
x
x
Client
x
x
9
STA
x
x
GO
x
x
x
Client
x
10
STA
x
x
Client
x
x
x
Client
x
11
STA
x
x
GO
x
x
x
x
Client
12
STA
x
x
Client
x
x
x
x
Client
14
STA
x
x
x
Client
x
x
Client
x
16
STA
x
x
x
Client
x
x
x
Client
18
STA
x
x
x
x
Client
x
x
Client
19
x
STA
x
GO
x
x
x
x
x
20
x
STA
x
Client
x
x
x
x
x
21
x
STA
x
x
GO
x
x
x
x
22
x
STA
x
x
Client
x
x
x
x
23
x
STA
x
x
x
GO
x
x
x
24
x
STA
x
x
x
Client
x
x
x
25
x
STA
x
GO
x
x
Client
x
x
26
x
STA
x
Client
x
x
Client
x
x
27
x
STA
x
GO
x
x
x
Client
x
28
x
STA
x
Client
x
x
x
Client
x
29
x
STA
x
GO
x
x
x
x
Client
30
x
STA
x
Client
x
x
x
x
Client
31
x
STA
x
x
GO
x
x
Client
x
32
x
STA
x
x
Client
x
x
Client
x
33
x
STA
x
x
GO
x
x
x
Client
34
x
STA
x
x
Client
x
x
x
Client
35
x
STA
x
x
x
GO
x
x
Client
36
x
STA
x
x
x
Client
x
x
Client
37
x
x
STA
GO
x
x
x
x
x
38
x
x
STA
Client
x
x
x
x
x
39
x
x
STA
x
GO
x
x
x
x
40
x
x
STA
x
Client
x
x
x
x
41
x
x
STA
x
x
GO
x
x
x
42
x
x
STA
x
x
Client
x
x
x
43
x
x
STA
GO
x
x
Client
x
x
44
x
x
STA
Client
x
x
Client
x
x
45
x
x
STA
GO
x
x
x
Client
x
46
x
x
STA
Client
x
x
x
Client
x
47
x
x
STA
GO
x
x
x
x
Client
48
x
x
STA
Client
x
x
x
x
Client
49
x
x
STA
x
GO
x
x
Client
x
50
x
x
STA
x
Client
x
x
Client
x
51
x
x
STA
x
GO
x
x
x
Client
52
x
x
STA
x
Client
x
x
x
Client
53
x
x
STA
x
x
GO
x
x
Client
54
x
x
STA
x
x
Client
x
x
Client
55
x
x
x
GO
x
x
Client
x
x
56
x
x
x
Client
x
x
Client
x
x
57
x
x
x
GO
x
x
x
Client
x
58
x
x
x
Client
x
x
x
Client
x
59
x
x
x
GO
x
x
x
x
Client
60
x
x
x
Client
x
x
x
x
Client
62
x
x
x
x
Client
x
x
Client
x
63
x
x
x
x
GO
x
x
x
Client
64
x
x
x
x
Client
x
x
x
Client
66
x
x
x
x
x
Client
x
x
Client
If WLAN device does not support 802.11ac [Following concurrency matrix is required for 802.11n].
Case #
Infra Port
WFD Port 1
WFD Port 2
2.4 Ghz
5 Ghz
2.4 Ghz
5 Ghz
2.4 Ghz
5 Ghz
1
STA
x
GO
x
x
X
2
STA
x
Client
x
x
X
4
STA
x
x
Client
x
X
5
STA
x
GO
x
Client
X
6
STA
x
Client
x
Client
X
7
STA
x
GO
x
x
Client
8
STA
x
Client
x
x
Client
10
STA
x
x
Client
x
Client
11
x
STA
GO
x
x
x
12
x
STA
Client
x
x
x
13
x
STA
x
GO
x
x
14
x
STA
x
Client
x
x
15
x
STA
GO
x
Client
x
16
x
STA
Client
x
Client
x
17
x
STA
GO
x
x
Client
18
x
STA
Client
x
x
Client
19
x
STA
x
GO
x
Client
20
x
STA
x
Client
x
Client
21
x
x
GO
x
Client
x
22
x
x
Client
x
Client
x
23
x
x
GO
x
x
Client
24
x
x
Client
x
x
Client
26
x
x
x
Client
x
Client
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBWiFiDirect.SupportAtLeast4Clients
WLAN Devices that go into systems that support connected standby MUST support at-least 4 clients being connected simultaneously to the Wi-Fi Direct Group Owner on the Device.
| Target Feature |
Device.Network.WLAN.CSBWiFiDirect |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
WLAN Device must be able to support at-least 4 clients being connected simultaneously to the running Wi-Fi Direct Group Owner on the Device.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.CSBWoWLAN
Wireless LAN
| Related Requirements |
Device.Network.WLAN.CSBWoWLAN.MustSupportWakeOnWLAN |
Device.Network.WLAN.CSBWoWLAN.MustSupportWakeOnWLAN
WLAN devices that go into systems that support connected standby MUST support all the features related to Wake on Wireless LAN.
| Target Feature |
Device.Network.WLAN.CSBWoWLAN |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
WLAN devices must support Wake on Wireless LAN (WoWLAN) capability. Partial wake implementations (subset of below list) will not be considered for certification. WLAN devices should do the following:
Must indicate the specific Wake on Wireless LAN (WoWLAN) capability that is supported.
Must support at least 22 WoWLAN bitmap wake-up patterns of 128 byte each.
Must be able to perform GTK (WPA/WPA2) and IGTK refresh (WPA2) while in the D2 state.
Must support wake on GTK and IGTK handshake error.
MUST support wake when 802.1x EAP-Request/Identity Packet is received.
Must support wake when four way handshake requests is received.
Must support wake on association lost with current AP.
Must support wake when a network matches NLO (Network list offload) hints.
MUST support wake packet indication. NIC should cache the packet causing the wake on hardware and pass it up when the OS is ready for receive.
Must support ARP and NS offloads to ensure link local network discovery. WLAN device should be able to respond to ARP and NS requests without interrupting the CPU when the device is in low power (D2) state. Devices must support at least 1 ARP offload and at least 2 NS offloads (each NS offload with up to 2 target IPv6 addresses).
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.NLO
| Related Requirements |
Device.Network.WLAN.NLO.SupportNetworkListOffload |
Device.Network.WLAN.NLO.SupportNetworkListOffload
WLAN devices MUST support Network List Offload.
| Target Feature |
Device.Network.WLAN.NLO |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WLAN devices MUST support 10 offloaded BSSID profiles. It is recommended to implement this feature in firmware, but if the device is incapable of supporting it in firmware, it's ok to support it in driver. Wi-Fi profiles that are marked auto-connect will be offloaded by the OS to the device/driver. The device should use the network list offload as a hint to optimize scanning behavior and return "NDIS_STATUS_DOT11_OFFLOAD_NETWORK_STATE_CHANGED" indication when a matching profile is found.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.SoftAP
Wireless LAN
| Related Requirements |
Device.Network.WLAN.SoftAP.SupportSoftAP |
Device.Network.WLAN.SoftAP.SupportSoftAP
WLAN devices MUST support Soft AP.
| Target Feature |
Device.Network.WLAN.SoftAP |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All 802.11 devices MUST support the Soft AP application with 8 simultaneously associated stations using security (WPA2). All 802.11 devices MUST support the Soft AP by permitting extension of Information Elements in Beacon and Probe Response frames. This includes adding currently specified Information Elements, such as Wi-Fi Protected Setup as well as other vendor extended Information Elements. All 802.11 devices MUST support the Soft AP by permitting stations associated to the Soft AP to utilize power save and providing them with beacon notification to wake up and receive waiting data.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.WiFiDirect
Wireless LAN
| Related Requirements |
Device.Network.WLAN.WiFiDirect.SupportAtLeast2WiFiDirectPortsConcurrently Device.Network.WLAN.WiFiDirect.SupportAtLeast4Clients |
Device.Network.WLAN.WiFiDirect.SupportAtLeast2WiFiDirectPortsConcurrently
WLAN Devices MUST support at least 2 Wi-Fi Direct role ports concurrently
| Target Feature |
Device.Network.WLAN.WiFiDirect |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
WLAN Device must be capable of supporting at least 2 Wi-Fi Direct role ports concurrently in the following configurations in addition to the Wi-Fi Direct device port:
A Group Owner (GO) on one Wi-Fi Direct port and Client on the other Wi-Fi Direct port(s) concurrently.
A Client on each Wi-Fi Direct Port concurrently.
These ports must be supported concurrently with Infrastructure connectivity on different channels across different bands (2.4/5 Ghz). Maximum of two concurrent channels.
Device must be able to concurrently support following combinations:
If WLAN device supports 802.11ac
ExTSTA Port
Wi-Fi Direct Role Port 1
Wi-Fi Direct Role Port 2
Case #
802.11n
802.11ac
802.11n
802.11ac
802.11n
802.11ac
2.4 Ghz
5 Ghz
5 GHz
2.4 Ghz
5 Ghz
5 GHz
2.4 Ghz
5 Ghz
5 GHz
1
STA
x
x
GO
x
x
x
x
x
2
STA
x
x
Client
x
x
x
x
x
4
STA
x
x
x
Client
x
x
x
x
6
STA
x
x
x
x
Client
x
x
x
7
STA
x
x
GO
x
x
Client
x
x
8
STA
x
x
Client
x
x
Client
x
x
9
STA
x
x
GO
x
x
x
Client
x
10
STA
x
x
Client
x
x
x
Client
x
11
STA
x
x
GO
x
x
x
x
Client
12
STA
x
x
Client
x
x
x
x
Client
14
STA
x
x
x
Client
x
x
Client
x
16
STA
x
x
x
Client
x
x
x
Client
18
STA
x
x
x
x
Client
x
x
Client
19
x
STA
x
GO
x
x
x
x
x
20
x
STA
x
Client
x
x
x
x
x
21
x
STA
x
x
GO
x
x
x
x
22
x
STA
x
x
Client
x
x
x
x
23
x
STA
x
x
x
GO
x
x
x
24
x
STA
x
x
x
Client
x
x
x
25
x
STA
x
GO
x
x
Client
x
x
26
x
STA
x
Client
x
x
Client
x
x
27
x
STA
x
GO
x
x
x
Client
x
28
x
STA
x
Client
x
x
x
Client
x
29
x
STA
x
GO
x
x
x
x
Client
30
x
STA
x
Client
x
x
x
x
Client
31
x
STA
x
x
GO
x
x
Client
x
32
x
STA
x
x
Client
x
x
Client
x
33
x
STA
x
x
GO
x
x
x
Client
34
x
STA
x
x
Client
x
x
x
Client
35
x
STA
x
x
x
GO
x
x
Client
36
x
STA
x
x
x
Client
x
x
Client
37
x
x
STA
GO
x
x
x
x
x
38
x
x
STA
Client
x
x
x
x
x
39
x
x
STA
x
GO
x
x
x
x
40
x
x
STA
x
Client
x
x
x
x
41
x
x
STA
x
x
GO
x
x
x
42
x
x
STA
x
x
Client
x
x
x
43
x
x
STA
GO
x
x
Client
x
x
44
x
x
STA
Client
x
x
Client
x
x
45
x
x
STA
GO
x
x
x
Client
x
46
x
x
STA
Client
x
x
x
Client
x
47
x
x
STA
GO
x
x
x
x
Client
48
x
x
STA
Client
x
x
x
x
Client
49
x
x
STA
x
GO
x
x
Client
x
50
x
x
STA
x
Client
x
x
Client
x
51
x
x
STA
x
GO
x
x
x
Client
52
x
x
STA
x
Client
x
x
x
Client
53
x
x
STA
x
x
GO
x
x
Client
54
x
x
STA
x
x
Client
x
x
Client
55
x
x
x
GO
x
x
Client
x
x
56
x
x
x
Client
x
x
Client
x
x
57
x
x
x
GO
x
x
x
Client
x
58
x
x
x
Client
x
x
x
Client
x
59
x
x
x
GO
x
x
x
x
Client
60
x
x
x
Client
x
x
x
x
Client
62
x
x
x
x
Client
x
x
Client
x
63
x
x
x
x
GO
x
x
x
Client
64
x
x
x
x
Client
x
x
x
Client
65
x
x
x
x
x
GO
x
x
Client
66
x
x
x
x
x
Client
x
x
Client
If WLAN device does not support 802.11ac [Following concurrency matrix is required for 802.11n].
Case #
Infra Port
WFD Port 1
WFD Port 2
2.4 Ghz
5 Ghz
2.4 Ghz
5 Ghz
2.4 Ghz
5 Ghz
1
STA
x
GO
x
x
X
2
STA
x
Client
x
x
X
4
STA
x
x
Client
x
X
5
STA
x
GO
x
Client
X
6
STA
x
Client
x
Client
X
7
STA
x
GO
x
x
Client
8
STA
x
Client
x
x
Client
10
STA
x
x
Client
x
Client
11
x
STA
GO
x
x
x
12
x
STA
Client
x
x
x
13
x
STA
x
GO
x
x
14
x
STA
x
Client
x
x
15
x
STA
GO
x
Client
x
16
x
STA
Client
x
Client
x
17
x
STA
GO
x
x
Client
18
x
STA
Client
x
x
Client
19
x
STA
x
GO
x
Client
20
x
STA
x
Client
x
Client
21
x
x
GO
x
Client
x
22
x
x
Client
x
Client
x
23
x
x
GO
x
x
Client
24
x
x
Client
x
x
Client
26
x
x
x
Client
x
Client
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.WiFiDirect.SupportAtLeast4Clients
WLAN Devices MUST support at-least 4 clients being connected simultaneously to each Wi-Fi Direct Group Owner on the Device.
| Target Feature |
Device.Network.WLAN.WiFiDirect |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WLAN Device must be able to support at-least 4 clients being connected simultaneously to each running Wi-Fi Direct Group Owner on the Device.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Network.WLAN.WoWLAN
Wireless LAN
| Related Requirements |
Device.Network.WLAN.WoWLAN.ImplementWakeOnWLAN |
Device.Network.WLAN.WoWLAN.ImplementWakeOnWLAN
WLAN devices that implement Wake on Wireless LAN MUST support Wake on Wireless LAN.
| Target Feature |
Device.Network.WLAN.WoWLAN |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
WLAN devices that implement WoWLAN (Wake on Wireless LAN) must support all the features related to WoWLAN capability. Implementation of subset of below features will not be considered for certification. WLAN devices should do the following:
Must indicate the specific Wake on Wireless LAN (WoWLAN) capability that is supported.
Must support at least 22 WoWLAN bitmap wake-up patterns of 128 byte each.
Must be able to perform GTK (WPA/WPA2) and IGTK refresh (WPA2) while in the D3 state.
Must support wake on GTK and IGTK handshake error.
MUST support wake when 802.1x EAP-Request/Identity Packet is received.
Must support wake when four way handshake requests is received.
Must support wake on association lost with current AP.
Must support wake when a network matches NLO (Network list offload) hints.
MUST support wake packet indication. NIC should cache the packet causing the wake on hardware and pass it up when the OS is ready for receive.
Must support ARP and NS offloads to ensure link local network discovery. WLAN device should be able to respond to ARP and NS requests without interrupting the CPU when the device is in low power (D3) state. Devices must support at least 1 ARP offload and at least 2 NS offloads (each NS offload with up to 2 target IPv6 addresses).
Additional Information
| Enforcement Date |
Jun. 26, 2013 |