Device.Network Requirements

NDIS devices must conform to the NDIS 6.x requirements in the Windows Driver Kit

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

NDIS devices must conform to the NDIS requirements in the Windows Driver Kit

Description

All NDIS device must conform to NDIS specified in the Windows Driver Kit.Design Notes:See the Windows Driver Kit, "NDIS."

Additional Information

Network Devices must support No Pause On Suspend (NPOS)

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

NDIS devices must meet Selective Suspend requirements

Description

NDIS devices must meet Selective Suspend requirements.Design Notes:

Additional Information

Ethernet devices must support 100-Mb or greater link speeds

Description

Devices must be able to link at 100 Mb or higher speeds.

Additional Information

Ethernet devices must support filtering for at least 32 multicast addresses

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

Ethernet devices must safeguard advanced properties and provide complete configurability through advanced properties.

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

Ethernet devices must be able to transmit packets from buffers aligned on any boundary

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

Ethernet Devices that implement offloads must do so consistently for both IPv4 and IPv6

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

Ethernet devices must make only NDIS library or WDF system calls

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

Ethernet devices must conform to the NDIS requirements in the Windows Driver Kit

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

Ethernet devices must support packet filtering

Description

The miniport driver must support all filter types in the Windows Driver Kit.Note: Filtering should be performed in Hardware/Firmware.

Additional Information

Ethernet devices Miniport Driver/Driver Software must not disable OS services

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

Ethernet devices that implement link speeds of gigabit or greater must implement Priority & VLAN tagging according to the IEEE 802.1q specification

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

Ethernet devices must pad short packets with constant data

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

Ethernet devices must comply with IEEE 802.3

Description

All 802.3 Ethernet devices must implement and comply with the IEEE 802.3 specification.

Additional Information

Ethernet devices implement Checksum Offloads

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

Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support network wake patterns

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

Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support network presence offload.

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

LAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby

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

Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support various wake triggers

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

Wired LAN (Ethernet) devices integrated into Connected Standby systems or docks shipped with the system must support wake reason detection

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 at least the first 128 bytes of the packet and indicate them in the status indication to the operating system.Design Notes:See the Power Management specification on MSDN.

Additional Information

Ethernet devices that implement Data Center Bridging (DCB) must comply with the DCB Specification.

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 http://msdn.microsoft.com/en-us/library/windows/hardware/hh451635(v=vs.85).aspx

Additional Information

Ethernet Devices that implement GRE Encapsulated Packet Task Offloads must comply with the specification

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

Ethernet devices that implement IPsec task offload must support required modes and protocols

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 http://technet.microsoft.com/en-us/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

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.

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

Ethernet devices must implement large send offloads

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

Ethernet devices that implement network presence offloads must conform to the Power Management specification on the NDIS Program

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 http://go.microsoft.com/fwlink/?LinkId=108718

Additional Information

Ethernet devices must implement Wake on LAN patterns according to the specification

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

Ethernet devices that implement Wake Packet Detection must comply with Network Device Class Power Management Reference Specification.

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

Ethernet devices that implement Receive Segment Coalescing (RSC) must comply with the RSC Specification.

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

Ethernet devices that implement RSS

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 http://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 http://msdn.microsoft.com/library/windows/hardware/ff566491.aspx.

Additional Information

Ethernet devices that implement RSS must set the hash function, hash type, and hash value on each indicated packet

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: http://msdn.microsoft.com/en-us/library/windows/hardware/ff570726(v=vs.85).aspxSee the Windows Driver Kit, "Indicating RSS Receive Data."

Additional Information

Ethernet devices that implement RSS must support specific Indirection Table sizes

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

Ethernet devices that implement RSS must support the Toeplitz hash function

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 http://msdn.microsoft.com/en-us/library/windows/hardware/ff570725(v=vs.85).aspx

Additional Information

Ethernet devices that implement RSS must support updates to RSS information at any time

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

Ethernet devices that implement Single Root I/O Virtualization (SR-IOV) must support required functionalities

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

Ethernet devices that implement Single Root I/O Virtualization (SR-IOV) must support required functionalities

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

Ethernet devices that implement TCP Chimney must comply with the latest NDIS miniport driver model

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

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

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.

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 http://go.microsoft.com/fwlink/?LinkId=36702.

Additional Information

Ethernet devices that implement TCP Chimney must properly handle the Out Of Order data scenarios

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

Ethernet devices that implement TCP Chimney must implement sufficiently granular timers

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

Neighbor state object timestamps are implemented according to details in the Windows Driver Kit

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

Ethernet devices that implement TCP Chimney must support at least 1024 connections and not advertise more offload capacity than what the HW can support

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

Ethernet devices that implement TCP Chimney must support 64-bit addresses

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

Ethernet devices that implement Virtual Machine Queues comply with specification

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:

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 http://msdn.microsoft.com/en-us/library/windows/hardware/ff571034(v=vs.85).aspx

Additional Information

Mobile Broadband devices must comply with the following base requirements

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 http://msdn.microsoft.com/en-us/library/ff560543(v=VS.85).aspxNetwork Device Class Power Management Reference Specificationhttp://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/netpmspc.rtf

Additional Information

USB interface based CDMA class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband Interface Model Specification.

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: http://www.usb.org/developers/devclass_docs/MBIM10.zip

Mobile Broadband Driver Model Specification: http://msdn.microsoft.com/library/windows/hardware/ff560543(v=VS.85).aspx.

Additional Information

Mobile Broadband Devices MUST support Identity Morphing.

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

CMDA class of Mobile Broadband devices must implement all SMS functionality as defined in the Microsoft Mobile Broadband Driver Model Specification.

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 http://msdn.microsoft.com/en-us/library/ff560543(v=VS.85).aspx

Additional Information

Mobile Broadband Devices based on USB protocol MUST implement loopback functionality for performance and payload conformance testing..

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: http://msdn.microsoft.com/en-us/library/windows/hardware/hh975390.aspx

MB Miniport Driver Performance Requirements: http://msdn.microsoft.com/en-us/library/windows/hardware/ff557193(v=vs.85).aspx .

Additional Information

Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality.

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

Wireless WAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby

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

USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.

Description

USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No alternate USB SS implementation is allowed.

Additional Information

Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities

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

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.

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

Mobile Broadband devices must comply with the following base requirements

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 http://msdn.microsoft.com/en-us/library/ff560543(v=VS.85).aspxNetwork Device Class Power Management Reference Specificationhttp://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/netpmspc.rtf

Additional Information

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.

Description

GSM devices that support EAP-SIM must support EAP-SIM defined in RFC 4186.

Additional Information

USB interface based GSM class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband Interface Model Specification.

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: http://www.usb.org/developers/devclass_docs/MBIM10.zip

Mobile Broadband Driver Model Specification: http://msdn.microsoft.com/library/windows/hardware/ff560543(v=VS.85).aspx.

Additional Information

Mobile Broadband Devices MUST support Identity Morphing.

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

GSM class of Mobile Broadband devices must implement all SMS functionality as defined in the Microsoft Mobile Broadband Driver Model Specification.

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 http://msdn.microsoft.com/en-us/library/ff560543(v=VS.85).aspx

Additional Information

Mobile Broadband Devices based on USB protocol MUST implement loopback functionality for performance and payload conformance testing..

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: http://msdn.microsoft.com/en-us/library/windows/hardware/hh975390.aspx

MB Miniport Driver Performance Requirements: http://msdn.microsoft.com/en-us/library/windows/hardware/ff557193(v=vs.85).aspx .

Additional Information

Mobile Broadband devices that support multi-carrier feature must support the multi-carrier functionality.

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

Multiple PDP context support

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

Wireless WAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby

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

GSM class of Mobile Broadband devices MUST support Fast Dormancy mechanism defined by 3GPP in release 8.

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

USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.

Description

USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No alternate USB SS implementation is allowed.

Additional Information

Mobile Broadband class of devices MUST support the following wake on mobile broadband capabilities.

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

GSM class of Mobile Broadband devices that implement Unstructured Supplementary Service Data (USSD) must support USSD based on Mobile Broadband Driver Model.

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

Routers must meet basic Microsoft product compatibility requirements

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

Wireless router must meet basic wireless performance requirements.

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

Routers must implement a cone or restricted NAT type

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

Routers must respond to the GetTotalBytesSent and GetTotalBytesReceived actions within 1000ms

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 http://go.microsoft.com/fwlink/?LinkId=58381

Additional Information

Routers must support GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

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 http://go.microsoft.com/fwlink/?LinkId=58381

Additional Information

Router must support NAT Loopback.

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

Router must implement UPnP IGD v1.0 and ship with UPnP IGD enabled (turned on) by default.

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

Router must support at least 25 UPnP port mappings.

Description

A router must support at least 25 individual port mappings that can be configured remotely via UPnP.

Additional Information

Router that implements a display must generate a dynamic WCN PIN and display it correctly.

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 http://go.microsoft.com/fwlink/?LinkId=50323.

Additional Information

A wireless router must be WFA (Wi-Fi Alliance) certified.

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

Routers must support WPS-Version 2

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

Wireless routers must support a hardware push-button for WPS Version 2

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

Device.Network.Switch.DAL-TOR.Manageability

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

Boot time and Hibernation requirements for WLAN devices

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

WLAN devices MUST conform to NDIS requirements in the Windows Driver Kit.

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

High Throughput Low Latency Requirements for WLAN devices

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.

Additional Information

WLAN devices that implement D0 Packet Coalescing MUST support D0 Packet Coalescing.

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

IEEE 802.11ac implementation for WLAN devices

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

WLAN devices MUST meet performance requirements.

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.

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.

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

WLAN devices MUST meet scanning and connection requirements.

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

WLAN devices MUST minimize CPU utilization.

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

WLAN devices MUST make only NDIS 6.30 or WDF system calls.

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

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).

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

WLAN devices MUST permit addition of Information Elements to request and response association frames.

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

WLAN devices MUST support filtering for at least 32 multicast addresses on each port.

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

WLAN devices MUST Support IEEE 802.11w standard for protected management frames.

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

WLAN devices MUST support multiple device instances.

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

WLAN devices MUST support promiscuous and multicast packet filtering.

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

WLAN devices MUST support separate beacon and probe Information Elements.

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

WLAN devices MUST support Virtual Wi-Fi.

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

WLAN devices MUST Support Wi-Fi Auto Power Save Mode.

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

WLAN devices MUST be able to transmit packets from buffers aligned on any boundary.

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

BootTimeAndHibernate

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

WLAN devices that go into systems that support connected standby MUST conform to NDIS requirements in the Windows Driver Kit.

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

HighThroughputLowLatency

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.

Additional Information

ImplementIEEE802.11ac

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

WLAN devices that go into systems that support connected standby MUST meet performance requirements.

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.

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.

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

WLAN devices that go into systems that support connected standby MUST meet scanning and connection requirements.

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

WLAN devices that go into systems that support connected standby MUST minimize CPU utilization.

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

WLAN devices that go into systems that support connected standby MUST support D0 Packet Coalescing.

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

WLAN devices that go into systems that support connected standby MUST make only NDIS 6.30 or WDF system calls.

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

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).

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

WLAN devices that go into systems that support connected standby MUST permit addition of Information Elements to request and response association frames.

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

Wireless LAN device on systems that support Connected Standby must deliver reliable connectivity in Connected Standby

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

WLAN devices that go into systems that support connected standby MUST support filtering for at least 32 multicast addresses on each port.

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

WLAN devices that go into systems that support connected standby MUST Support IEEE 802.11w standard for protected management frames.

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

WLAN devices that go into systems that support connected standby MUST support promiscuous and multicast packet filtering.

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

WLAN devices that go into systems that support connected standby MUST support separate beacon and probe Information Elements.

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

WLAN devices that go into systems that support connected standby MUST support Virtual Wi-Fi.

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

WLAN devices that go into systems that support connected standby MUST Support Wi-Fi Auto Power Save Mode.

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

WLAN devices that go into systems that support connected standby MUST be able to transmit packets from buffers aligned on any boundary.

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

WLAN devices that go into systems that support connected standby MUST support Network List Offloads.

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

WLAN devices that go into systems that support connected standby MUST support Soft AP.

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

WLAN Devices that go into systems that support connected standby MUST support at least 2 Wi-Fi Direct role ports concurrently.

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

If WLAN device does not support 802.11ac [Following concurrency matrix is required for 802.11n].

Additional Information

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.

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

WLAN devices that go into systems that support connected standby MUST support all the features related to Wake on Wireless LAN.

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

WLAN devices MUST support Network List Offload.

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

WLAN devices MUST support Soft AP.

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

WLAN Devices MUST support at least 2 Wi-Fi Direct role ports concurrently

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