Device.Connectivity Requirements
Device.Connectivity.BluetoothDevices
Devices that connect to the PC via Bluetooth.
| Related Requirements |
Device.Connectivity.BluetoothDevices.BluetoothDeviceIdProfileVer12 Device.Connectivity.BluetoothDevices.BluetoothDeviceIdProfileVer13 Device.Connectivity.BluetoothDevices.BluetoothHidLimitedDiscoverableMode Device.Connectivity.BluetoothDevices.BluetoothUSBPlugandPlay Device.Connectivity.BluetoothDevices.ComplementarySubsystemList Device.Connectivity.BluetoothDevices.FunctionAfterSystemSuspendCycle Device.Connectivity.BluetoothDevices.HidInitiatedReconnect Device.Connectivity.BluetoothDevices.KeyboardsSupportPasskeyAuthentication Device.Connectivity.BluetoothDevices.RespondToServiceDiscoveryRequests Device.Connectivity.BluetoothDevices.SupportBluetooth21 |
Device.Connectivity.BluetoothDevices.BluetoothDeviceIdProfileVer12
Devices that support Bluetooth must implement the DeviceID profile, version 1.2.
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 |
Description
The Bluetooth system defines a Service Discovery Protocol (SDP). Bluetooth PC peripherals must support SDP as described in Specification of the Bluetooth System, Version2.1+EDR, PartB. The Plug and Play information is a single record that gives the device s VID/PID.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.BluetoothDevices.BluetoothDeviceIdProfileVer13
Devices which support Bluetooth must implement the Device ID (DI) profile version 1.3 or Device Information Service (DIS), as applicable
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Bluetooth PC peripherals must include the Device ID record as specified in the Device ID profile, version 1.3, for BR/EDR Bluetooth or the Device Information Service (DIS), version 1.1, Bluetooth LE.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.BluetoothDevices.BluetoothHidLimitedDiscoverableMode
Bluetooth HID devices must be discoverable only in Limited Discoverable Mode.
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Bluetooth HID devices must be discoverable only in Limited Discoverable Mode.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.BluetoothDevices.BluetoothUSBPlugandPlay
Bluetooth wireless technology device supports Plug and Play on the applicable bus
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Vista Client x86, x64 |
Description
USB must comply with Specification of the Bluetooth System, Version 1.1 or later, "Part H:2, USB Transport Layer."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.BluetoothDevices.ComplementarySubsystemList
Bluetooth wireless technology subsystem end product lists Windows operating system in its complementary subsystem list
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The Bluetooth subsystem end product must list the Windows operating system in the complementary subsystem list as described in Bluetooth Qualification Program Reference Document, Version2.1, Section6.1, "Bluetooth Subsystems."
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.BluetoothDevices.FunctionAfterSystemSuspendCycle
Bluetooth device appears and continues to function properly after a system suspend resume cycle
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Bluetooth devices which are present before any system sleep state are present upon wake from that sleep state.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.BluetoothDevices.HidInitiatedReconnect
HID Devices which support Bluetooth support HID-initiated re-connect
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
The HIDReconnectInitiate attribute (defined in Bluetooth HID Profile, 1.0, Section7.11.5, "HIDReconnectInitiate") must be enabled. To automatically reconnect to the host if the connection is dropped, the device must enter page mode.
Additional Information
| Enforcement Date |
Sep. 05, 2008 |
Device.Connectivity.BluetoothDevices.KeyboardsSupportPasskeyAuthentication
Bluetooth Keyboards which implement Secure Simplified Pairing must support the Passkey authentication method
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Keyboards which implement Secure Simplified Pairing must support the Passkey authentication method.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Connectivity.BluetoothDevices.RespondToServiceDiscoveryRequests
Bluetooth Devices respond to Service Discovery requests before requiring authentication and while in inquiry scan state.
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Service discovery must be completed before requiring authentication. Bluetooth PC peripherals must support Security Specification as described in Specification of the Bluetooth System, Version2.1+EDR, Part H.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.BluetoothDevices.SupportBluetooth21
Devices which support Bluetooth must implement the Bluetooth 2.1 requirements
| Target Feature |
Device.Connectivity.BluetoothDevices |
| Applies to |
Windows 7 Client x86, x64 |
Description
The Bluetooth devices must comply with the Bluetooth 2.1 + EDR requirements outlined in Bluetooth Version 2.1 + EDR specifications.
Additional Information
| Enforcement Date |
Jun. 01, 2012 |
Device.Connectivity.NearFieldProximity
Near Field Proximity is a set of short range wireless technologies to enable communication between a personal computer and a device.
| Related Requirements |
Device.Connectivity.NearFieldProximity.DeviceNFCCertification Device.Connectivity.NearFieldProximity.DeviceRangeOfActuation Device.Connectivity.NearFieldProximity.DeviceTapToSetup Device.Connectivity.NearFieldProximity.NfcForumTag Device.Connectivity.NearFieldProximity.TouchMark |
Device.Connectivity.NearFieldProximity.DeviceNFCCertification
NFC Implementations must receive NFC certification
| Target Feature |
Device.Connectivity.NearFieldProximity |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
A device that implements air interface specifications incorporated by the NFC Forum by reference as approved specifications must receive NFC Certification from the NFC Forum, inclusive of:
Wave 1 compliance
SNEP compliance
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.NearFieldProximity.DeviceRangeOfActuation
Proximity technology meets range of actuation
| Target Feature |
Device.Connectivity.NearFieldProximity |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
A device that implements NFP technology must support an effective operating volume to enable users to successfully use NFP technology with Windows in 95 times out of 100 attempts for all tap and do scenarios. Refer to the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document for detailed placement guidance, as well as acceptable, minimum, and maximum values for the required effective operating volume. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.NearFieldProximity.DeviceTapToSetup
Proximity device supports tap and setup
| Target Feature |
Device.Connectivity.NearFieldProximity |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
A device that supports pairing with Windows using NFP technology must implement the tap and setup scenario defined in more detail in the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.NearFieldProximity.NfcForumTag
Tap and setup with passive devices
| Target Feature |
Device.Connectivity.NearFieldProximity |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
A device that uses only an NFC Forum tag as the NFP technology must adhere to the NFC Forum NDEF specification.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.NearFieldProximity.TouchMark
To help users locate and use the proximity technology, the use of a visual mark is required by, and is only permitted for, NFC NFP providers (those NFP providers that implement air interface specifications incorporated by the NFC Forum by reference as approved specifications).
Implementation can include but not limited to etching, inking and removable stickers. The mark that is used is at the discretion of the system builder.
| Target Feature |
Device.Connectivity.NearFieldProximity |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
To help users locate and use the proximity technology, the use of a visual mark is required for NFC enabled devices (those devices that implement air interface specifications incorporated by the NFC Forum by reference as approved specifications). Refer to the most current version of the 'Windows 8 Near Field Proximity Implementation Specification' document for placement guidance and mark usage requirements. The spec can be found at:https://go.microsoft.com/fwlink/?LinkId=237135
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.Network.VerticalPairing
Root for former Rally technologies
| Related Requirements |
Device.Connectivity.Network.VerticalPairing.WCN |
Device.Connectivity.Network.VerticalPairing.WCN
An 802.11 network-enabled device that operates as a station (STA) must implement WCN-NET and meet basic 802.11 requirements
| Target Feature |
Device.Connectivity.Network.VerticalPairing |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
A 802.11 network-enabled device that operates as a station (STA) must meet the following requirements:
The device must implement WCN-NET and comply with the specification.
The device must implement WCN-NET vertical-pairing extensions and indicate whether it supports a PnP-X transport protocol. If the device supports a PnP-X transport protocol, it must ensure correct universally unique identifier (UUID) alignment.
If WCN-UFD is implemented, it must comply with the specification.
If the device has a display that capable of showing a four-digit or eight-digit number, it must support displaying a dynamic Windows Connect Now (WCN) PIN without user intervention. The PIN must be displayed for a minimum of two minutes after the device receives a Wireless Provisioning Services (WPS) M2D message with the value of "Windows" in the WPS Model Name attribute.
If the device does not have a display that is capable of showing a four-digit or eight-digit number, it must provide a physical label affixed to the device that includes the eight-digit PIN and clearly labels the PIN value as a PIN (for example, PIN: 12345670).
The device must be certified by the Wi-Fi Alliance, including Wi-Fi certification, Wi-Fi Protected Access 2 (WPA2) certification, and Wi-Fi Protected Setup certification.
Design Notes:For implementation details, see the WCN-NET specification at https://go.microsoft.com/fwlink/?LinkId=109371 and the WCN-UFD specification at https://go.microsoft.com/fwlink/?LinkId=109372.
For more information, see the "Installing Wi-Fi Devices Using Rally Vertical Pairing" white paper at https://www.microsoft.com/whdc/connect/rally/WiFiVerticalPair.mspx.
Additional information can be found at https://go.microsoft.com/fwlink/?LinkId=109373 and https://go.microsoft.com/fwlink/?LinkId=109368.
WCN-NET is required. WCN-UFD is optional and is supported in Windows for backward compatibility with devices that are designed to support WCN functionality for Windows XP with Service Pack 2.
A device uses WCN-NET vertical-pairing extensions to indicate that its supports PnP-X. The device must provide a single UUID that is provided in both the WCN-NET exchange and the UPnP /Web Services for Devices (WSD) device file or provide the UPnP/WSD device UUID in the TransportUUID attribute of the WCN-NET vertical-pairing extension. The UUID that is provided in UPnP or WSD must be in lowercase (decimal digits can also be used).
For WSD implementations, the WSD UUID is provided as the endpoint reference address and must be of the form urn:uuid:. For UPnP implementations, the UPnP UUID is provided as the root device UUID.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.PciConnected
| Related Requirements |
Device.Connectivity.PciConnected.64BitPrefetchableBar Device.Connectivity.PciConnected.ConfigurationSpaceCorrectlyPopulated Device.Connectivity.PciConnected.ExpressCardImplementsSerialNumber Device.Connectivity.PciConnected.InterruptDisableBit Device.Connectivity.PciConnected.MsiOrMsixSupport Device.Connectivity.PciConnected.PciAndPcixDevicesArePciCompliant Device.Connectivity.PciConnected.PCIExpress Device.Connectivity.PciConnected.SubsystemIdsRequired |
Device.Connectivity.PciConnected.64BitPrefetchableBar
PCI-X and PCI Express devices that use prefetchable memory BARs, implement 64-bit prefetchable memory base address registers (BARs)
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
Devices that sit on the PCI-X or PCI Express bus and use prefetchable memory BARs must implement 64-bit prefetchable memory BARs on x64-based systems.Design Notes:See "Firmware Allocation of PCI Device Resources in Windows"https://www.microsoft.com/whdc/system/bus/pci/PCI-rsc.mspxIf the device supports 64-bit prefetchable memory BARs, Windows attempts to assign a region above 4 GB. In a PCI bridge, Windows ignores boot configuration for an entire device path emanating from the bridge in whose scope this method is defined. For the bridge and devices below it to be assigned a region above 4 GB, all devices in the path must support 64-bit prefetchable BARs. If this is not true, the rebalance code runs and moves all resource assignments below 4 GB, because the goal is to start as many devices as possible
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Connectivity.PciConnected.ConfigurationSpaceCorrectlyPopulated
Configuration space for PCI device is correctly populated
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
PCI2.3 describes the configuration space that thesystem uses to identify and configure each device that is attached to the bus. The configuration space is made up of a header region and a device-dependent region. Each configuration space must have a 64-byte header at offset0. All the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit within the space between byte64 and byte255.All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must finish normally and return zero. Writes to reserved registers must finish normally, and the data must be discarded.All registers that the device requires at interrupt time must be in I/O or memory space.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.PciConnected.ExpressCardImplementsSerialNumber
A single ExpressCard module that supports both USB and PCI Express interfaces implements a common serial number
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
An ExpressCard module that supports both USB and PCI Express interfaces on a single module must implement the common serial number as described in the PCI ExpressCard Electromechanical Specification.This is the only method that Windows will use to determine the relationship of USB and PCI Express on one module.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.PciConnected.InterruptDisableBit
PCI and PCI-X devices, that are PCI 2.3 compliant, support the interrupt-disable bit
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
All PCI and PCI-X devices that claim support for PCI Local Bus Specification Revision 2.3 or later, must support the interrupt-disable bit.Design Notes: See PCI Local Bus Specification, Revision2.3, Section6.2.2.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.PciConnected.MsiOrMsixSupport
PCI device that reports PCI-X capability in the PCI configuration space and that generates interrupts may support MSI or MSI-X but is not required to do so
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
As part of the PCI Conventional Specification 2.2 or later, PCI-X Addendum, Section 3.2, all PCI-X devices that generate interrupts must support message-signaled interrupts. For MSI implementation, MSI capabilities must be implemented in the configuration space. For MSI-X implementation, MSI-X capabilities must be implemented in the configuration space.However, because PCI-X is being replaced by PCI Express and many existing implementations do not support MSI or MSI-X, this requirement is being relaxed. Any device that claims to support MSI or MSI-X must do so or will fail the relevant WDK tests. Design Notes:Message Signaled Interrupt for PCI-X device is required by industry standard specification. However, see above.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.PciConnected.PciAndPcixDevicesArePciCompliant
PCI and PCI-X devices, at a minimum, are PCI 2.1 compliant
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2008 x86, x64 Windows Vista Client x86, x64 |
Description
All PCI and PCI-X devices must comply with the PCI Local Bus Specification, Revision 2.1 or later. This requirement applies to devices on X86, IA64 and x64 systems.Design Notes:See PCI Local Bus Specification, Revision 2.1 or later.
Additional Information
| Enforcement Date |
Jun. 01, 2007 |
Device.Connectivity.PciConnected.PCIExpress
PCI Express requirement
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
- Device driver for PCI Express device does not modify VC Enable settings:The device driver must not modify the "VC Enable" bit (PCI Express Base Specification, Version1.0a, Section7.11.7, VC Resource Control Register: bit 31) for any of the device's extended (non-VC0) virtual channel or channels. 2. PCI Express link active state L1 exit latency does not exceed 64 S:A PCI Express link, between root complex and device or bridge, cannot have an active state L1 exit latency of more than 64 microseconds on systems unless the link is associated with a PCI Express cable; that is, a value of 111b cannot be reported in the link capabilities register field 17:15. See PCIe Express Base Specification, Revision 1.0a, Section 7.8.6.3. PCI Express hot-plug port that supports firmware-controlled hot plug uses the _OSC control method for enable and disable:All PCI Express hot-plug ports that support firmware-controlled hot-plugs must support the_OSC control method for enabling and disabling firmware-controlled hot-plug as described in the PCI Firmware Specification Version 3.0. See PCI Express Base Specification, Revision 1.1, Section 6.7.4.4. PCI Express component implements a single device number on its primary interface:Every PCI Express component (that is, physical device) is restricted to implementing a single device number on its primary interface (upstream port), but it may implement up to eight independent functions within that device number. See PCI Express Base Specification, Revision1.1 (or later), Section 7.3.1.5. PCI Express device implements support for MSI or MSI-X:MSI support, which is optional for PCI 2.1, PCI 2.2, and PCI 2.3 devices, is required for PCI Express devices. This capability can be either implemented as MSI or MSI-X. See PCI Express Base Specification, Revision1.0a, Section 6.1.6. PCI Express root complex supports the enhanced (memory-mapped) configuration space access mechanism:The root complex must support the enhanced configuration space access mechanism as defined in PCI Express Base Specification, Revision 1.1 (or later), Section 7.9.7. PCI Express device that can interrupt supports the interrupt disable bit:If an interrupt is implemented, PCI Express devices must support the interrupt disable functionality described in PCI Local Bus Specification, Revision2.3. This bit disables the device or function from asserting INTx. A value of 0 enables the assertion of its INTx signal. A value of 1 disables the assertion of its INTx signal. This bit's state upon reset is 0
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.PciConnected.SubsystemIdsRequired
Device IDs include PCI subsystem IDs
| Target Feature |
Device.Connectivity.PciConnected |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
The SID and SVID fields must comply with the SID requirement in PCI Local Bus Specification 2.3 and the implementation details in "PCI Device Subsystem IDs and Windows." AMR devices and MR devices on the system board are not exempt from the requirement for SID and SVID.SVID is not required for PCIe to PCI/PCI-X bridges.Design Notes:See "PCI Device Subsystem IDs and Windows" at https://go.microsoft.com/fwlink/?LinkId=36804.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices
Applies to all devices connected via USB including USB Hubs. Does not apply to USB Controllers
| Related Requirements |
Device.Connectivity.UsbDevices.Addressing Device.Connectivity.UsbDevices.AlternateDriver Device.Connectivity.UsbDevices.CompliesWithChap9 Device.Connectivity.UsbDevices.DebugCompliesWithDebugSpec Device.Connectivity.UsbDevices.DebugCompliesWithDebugSpecUSB3 Device.Connectivity.UsbDevices.DeviceAttachLessThan100ms Device.Connectivity.UsbDevices.EsdRecovery Device.Connectivity.UsbDevices.FunctionSuspendSelectiveSuspend Device.Connectivity.UsbDevices.InstallViaUniquePnpIdentifier Device.Connectivity.UsbDevices.InternalDevicesMustSupportSuspend Device.Connectivity.UsbDevices.IsochronousDeviceAndDriver Device.Connectivity.UsbDevices.MsOsContainerId Device.Connectivity.UsbDevices.MustBeFunctionalAfterResume Device.Connectivity.UsbDevices.MustEnumerateOnEhciAndXhci Device.Connectivity.UsbDevices.MustNotDisconnectDuringSuspend Device.Connectivity.UsbDevices.MustResumeWithoutForcedReset Device.Connectivity.UsbDevices.MustSignalAttachWithin500ms Device.Connectivity.UsbDevices.MustSupportSuspend Device.Connectivity.UsbDevices.MustSupportSuspendOnRT Device.Connectivity.UsbDevices.PeripheralOperatesInFunctionMode Device.Connectivity.UsbDevices.PortMove500ms Device.Connectivity.UsbDevices.RespondAllStringRequests Device.Connectivity.UsbDevices.ResponsesLimitedByWlengthField Device.Connectivity.UsbDevices.SerialNumbers Device.Connectivity.UsbDevices.SerialNumbersUseValidCharacters Device.Connectivity.UsbDevices.SuperSpeedOnConnectViaUsb3Port Device.Connectivity.UsbDevices.TestedUsingMicrosoftUsbStack Device.Connectivity.UsbDevices.Usb3CompatibleWithDownLevel Device.Connectivity.UsbDevices.UsbifCertification Device.Connectivity.UsbDevices.UseUsbClassOnlyForControllerOrHub Device.Connectivity.UsbDevices.WirelessUsbObtainsWusbLogoFromUsbif Device.Connectivity.UsbDevices.WirelessUsbWiMediaAlliace |
Device.Connectivity.UsbDevices.Addressing
USB device can be configured to any USB address
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
To ensure that the devices function at all device address ranges, USB devices must be able to be configured to any USB address that the host provides. The device must enumerate and function correctly at any address ranging from 1 to 127. See USB Specification, Revision 2.0 or later, Sections9.1.1.4 and 9.4.6.Justification: Reduces resume time and maintains device state on resume from S3.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.AlternateDriver
USB devices should allow the Operating System to load an alternate driver on device
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Devices must retain basic USB functionality after a driver re-enumeration occurs. For example, a driver that redirects I/O to alternate paths requires re-enumeration. A common way to perform USB redirection is to issue an IOCTL_USB_CYCLE_PORT report on the target driver to trigger re-enumeration of the physical device. Justification: When a virtual PC needs to connect to a physical USB device, the virtual PC loads a driver that is called an "Alternate Driver". This event triggers re-enumeration. After re-enumeration occurs many times, the physical device can no longer function. This requirement attempts to address this problem.
Additional Information
| Exceptions |
This Requirement does NOT apply to Systems that Support Connected Standby |
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.UsbDevices.CompliesWithChap9
USB device complies with implementation details from the USB specification
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Any devices that are connected externally or internally to a USB port must be tested as USB devices that is, the devices provide the capabilities of one or more functions, a hub to the host, or both, as described in USB Specification, Revision 2.0 or later, Chapters 9 and 11. Therefore, these requirements apply to any device that is connected to a USB port: the USB specification and any related USB device class specification, and the Windows Hardware Certification Kit (Windows HCK) program requirements for USB and the related device class.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.DebugCompliesWithDebugSpec
USB debug device complies with USB2 Debug Device Specification
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB devices designed for debug purposes over USB 2.0 must comply with USB2 Debug Device Functional Specification, which includes details on the device framework, commands, and additional operational requirements.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.DebugCompliesWithDebugSpecUSB3
USB 3.0 debug cables comply with USB 3.0 specification
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB cables designed for USB 3.0 host debugging must comply with the Universal Serial Bus 3.0 Specification, section 5.5.2.
Additional Information
| Enforcement Date |
Jun. 30, 2012 |
Device.Connectivity.UsbDevices.DeviceAttachLessThan100ms
USB device that signals device-attach responds after at least 100 ms
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
When the USB device has signaled device-attach, the operating system provides a debounce interval of 100ms. The device must respond at the end of that interval. This is described in USB Specification, Revision2.0, Section 7.1.7.3. This requirement ensures that the electrical and mechanical connections are stable before the attached device is reset. Justification: Some devices after a few iterations of going into s3 fail to show up on the device tree
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.EsdRecovery
USB device does not trigger ESD recovery on USB hubs
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Devices must not trigger ESD recovery when connected to a USB hub. Triggering ESD causes fail-safe code to be executed in the hub driver and negatively affects the functionality of other devices attached to the hub. This is described in USB Specification, Revision 2.0 or later, Sections 7.2.3.Justification: Triggering ESD causes fail safe code to be executed in the hub driver and will impact the functionality of other devices attached to the hub.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.FunctionSuspendSelectiveSuspend
USB 3.0 devices correctly implement Function Suspend and Selective Suspend
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Any function that is in a suspend state before a device is selectively suspended remains in the function suspend state when the device is resumed from the selective suspend state. Devices must not place all device functions in the function suspend state. Devices must report the selective suspend state.SuperSpeed devices ignore the DEVICE_REMOTE_WAKEUP feature selector.When all functions of a SuperSpeed device are in the function suspend state and the PORT_U2_TIMEOUT field is programmed to 0xFF, the device initiates U2 after 10 milliseconds (ms) of link inactivity. For more information, see section 9.2 of the USB 3.0 Specification.Devices that are resumed from the selective suspend state retain a minimum set of device state information as specified in section 9.2.5.2 of the USB 3.0 Specification.
Additional Information
| Enforcement Date |
Dec. 01, 2010 |
Device.Connectivity.UsbDevices.InstallViaUniquePnpIdentifier
Third-party drivers for USB devices install through a unique PnP identifier match or a compatible ID match when allowed
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All Universal Serial Bus (USB) devices must have VID and PID sections in the PnP Device ID string. Third-party USB function drivers must not install through a compatible ID match, unless specifically permitted for a particular technology. The list of devices drivers that can be installed using a compatible ID match (Class, SubClass, Prot) is the following:WirelessUSB Cable Association Driver (CLASS_EF&SUBCLASS_03&PROT_01)
Additional Information
| Enforcement Date |
Jun. 01, 2008 |
Device.Connectivity.UsbDevices.InternalDevicesMustSupportSuspend
All internally connected USB devices must go to Selective Suspend after periods of inactivity
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All internally connected USB devices must be capable of entering the suspend state after device drivers for those devices initiate the USB Selective Suspend process. Third-party drivers for internal devices on applicable systems must implement USB Selective Suspend.
Devices belonging to these device classes can opt out of supporting USB Selective Suspend:
Printers
Scanners
Fax
Additional Information
| Exceptions |
Printers, scanners and fax device class |
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.IsochronousDeviceAndDriver
Isochronous USB device and driver requirement
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
- ISO USB device and driver provide multiple alternate settings to support maximum flexibility of hardware interface options:If any alternate setting consumes isochronous bandwidth, devices and drivers must provide multiple alternate settings for each interface.2. USB device and driver do not use isochronous bandwidth for alternate setting 0:Devices and drivers must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use.3.USB isochronous full-speed or high-speed device that uses more than 50 percent of USB bus bandwidth provides alternate settings:If a USB isochronous full-speed or high-speed device uses more than 50 percent of USB bus bandwidth, it must provide alternative settings that allow the device to switch to a setting that uses less than 50 percent of the bus bandwidth and operate as a device of that particular class (ex. if it is a camera then it must continue to stream video), even though it may be in a lower quality mode.Devices with attached host controllers are exempt from this requirement.4. USB device with interfaces containing isochronous endpoints has at least one alternative interface for low bandwidth scenarios:USB device must provide at least one alternative interface for low bandwidth as described inUSB Specification, Revision 2.0 or later, Section 9.6.5.Design Notes:See section 9.6.5 in the Universal Serial Bus Specification, Revision 2.0.If two or more devices are connected that use more than 50 percent of the bus bandwidth and do not provide alternate settings, only one of the devices works at a time.See USB Specification, Revision 2.0or later, Sections 5.6 and 5.7.Justification: Alternate settings are at the interface descriptor level, specifying different amounts of bandwidth a device requests the host controller to reserve for it. Imagine a conference camera with settings like 50% ,30%, 20%. It starts by asking the host if 50% is available and whether the host can reserve it. If not, then the host chooses the next alternate setting till they have a mutual agreement.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.MsOsContainerId
USB devices which implement the MS OS Container ID descriptor implement it correctly
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If a multifunction USB device implements the Microsoft operating system ContainerID descriptor, the device does this in the Microsoft operating system feature descriptor. The Microsoft operating system ContainerID descriptor allows Windows to correctly detect multifunction devices. The descriptor provides a way for all the device nodes to appear as one physical object in the Devices and Printers user interface (UI).
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Connectivity.UsbDevices.MustBeFunctionalAfterResume
Attached USB devices must be functional after resuming from system power states.
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Devices not entering a timely ready state will be marked code 10 or other by the system. Certain classes of devices do not properly respond to system events, such as resume, and require upper driver or expect precise boot timings in order to function properly. Device also must be able to function without a port reset upon resume but also remain functional if a reset does occur.A device must be in the attached state (USB Specification 2.0, section 9.1) to be configured and device must be in the configured state before its functions maybe used (aka, the device is useable). This is per the USB spec 2.0 as in section 9.1 and 9.2.6.2 "After a port is reset or resumed, the USB System Software is expected to provide a "recovery" interval of 10 ms before the device attached to the port is expected to respond to data transfers. The device may ignore any data transfers during the recovery interval."Clarification:Devices must be functional after resuming from system power states whether a port reset is issued or not. Justification: Devices not entering a timely ready state will be marked code 10 or other by system. Certain classes of devices do not have sufficient resources to handle system events, such as resume, and require upper driver or expect precise boot timings in order to function properly.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Connectivity.UsbDevices.MustEnumerateOnEhciAndXhci
All USB devices must enumerate and operate on EHCI and xHCI controllers as well as downstream of full speed, high speed, and SuperSpeed USB hubs
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All USB devices must enumerate and operate as a user would expect on Enhanced Host Controller Interface (EHCI) controllers and Extensible Host Controller Interface (xHCI) controllers. All USB devices must also operate as a user would expect downstream of a full-speed, high-speed or SuperSpeed hub.
The following scenarios will be covered in this requirement:
EHCI + device under test (DUT)
EHCI + high-speed hub + full-speed hub + DUT
EHCI + high-speed hub + DUT
xHCI + DUT
xHCI + SuperSpeed hub + DUT
xHCI + High speed hub + DUT
When selecting a system with xHCI controllers for testing this requirement, note that some of these hubs may already be integrated into the controller chipset or embedded into the system that is under testing. External physical ports must be checked for their exact routing to the xHCI controller to test the correct scenario.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.MustNotDisconnectDuringSuspend
USB devices must not disconnect from the upstream port while going to or resuming from selective suspend.
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB devices must not disconnect from the upstream port during the selective suspend process. To test this requirement, we will cause the device to go into the selective suspend state and then resume the device. During this process, we will observe the port status bits of the upstream port and verify that the device does not disconnect during this time. We will repeat this process several times.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.MustResumeWithoutForcedReset
All USB devices work properly upon resume from sleep, hibernation or restart without a forced reset of the USB host controller
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All USB devices work properly upon resume from sleep, hibernation or restart without a forced reset of the USB host controllerDesign Notes: Registry key ForceHCResetOnResume documented at the KB below is not needed for devices to function properly upon resume in Windows 7.https://support.microsoft.com/kb/928631Note that a known set of currently existing devices do require a forced reset upon resume, these devices should be covered in a list kept by the OS which will reset these devices upon resume. The goal of this requirement is to ensure that this list of devices which need a reset to appear after resume does not grow and that devices can properly handle sleep state transitions without being reset. A reset of the entire USB Host Controller results in significantly increased time that it takes for all USB devices to become available after system resume since there could be only one device at address 0 at a time, this enumeration has to be serialized for all USB devices on the bus. We have also seen that resetting the host controller can lead to an illegal SE1 signal state on some host controllers, which in turn can cause some USB devices to hang or drop off the bus. Moreover, devices cannot maintain any private state across sleep resume as that state will be lost on reset.
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Connectivity.UsbDevices.MustSignalAttachWithin500ms
Devices must signal attach within 500 ms after the system resumes.
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
After the system resumes from sleep, the hub driver will fetch the status of the port to which the device is connected. If the device does not show as connected, the hub driver will wait 500 milliseconds (ms) before the hub driver queries the port status again. If the device appears as connected within that time, the hub will not need to re-enumerate the device for Plug and Play, which will result in a better user experience. This requirement already exists for bus-powered devices in the USB specification. The requirement will now also apply to self-powered devices. Justification: Some devices take a long time to be discoverable by the operating system. This requirement does not try to enforce the device being back from sleep from a functional point of view. A certain amount of time is necessary to know if the device remains on the bus.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.MustSupportSuspend
All Bus powered USB devices support USB Suspend after periods of inactivity
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The device driver for a bus-powered device initiates the USB Selective Suspend process. The device can enter the suspend state from any powered state. The device must begin the transition to the suspend state after it sees a constant idle state on its upstream facing bus lines for more than 3.0 ms. In suspend state, the device must only draw suspend current from the bus after no more than 10 ms of bus inactivity on all its ports, as described in the USB Specification, Revision 2.0, Sections 7.1.7.6, 6 9.1.1.6 and 9.2.6.2.
Clarification about USB Selective Suspend in embedded USB devices can be found in the following requirement: Device.Connectivity.UsbDevices.InternalDevicesMustSupportSuspend
Clarification about USB Selective Suspend in Windows RT systems can be found in the following requirements: Device.Connectivity.UsbDevices.MustSupportSuspendOnRT
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.MustSupportSuspendOnRT
All Windows RT USB devices must go into Selective Suspend after periods of inactivity
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client ARM (Windows RT) Windows 8.1 Client ARM (Windows RT 8.1) |
Description
All USB devices must be capable of entering the suspend state after device drivers for those devices initiate the USB Selective Suspend process.
Devices belonging to these device classes can opt out of supporting USB Selective Suspend:
Printers
Scanners
Fax
Additional Information
| Exceptions |
Printers, scanners and fax device class |
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.PeripheralOperatesInFunctionMode
USB peripheral operates in function mode when connected to a computer host controller
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
When connected to a system's host controller, a USB peripheral must operate as a USB function only. A function is a USB device that provides additional capabilities to the host controller. This is described in USB Specification, Revision 2.0 or later, Section 4
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.PortMove500ms
If the software enables the SuperSpeed and then resets the 2.0 port, device should correctly move over
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In a USB 3.0 hub, two downstream ports, a USB 2.0 port and a SuperSpeed port, share the same connector. The USB 3.0 Specification says that if a device is currently connected on the USB 2.0 port, the device should try to reconnect at the SuperSpeed port when software resets the port. This situation has two relevant time intervals: The time that is necessary for the device to disconnect from the USB 2.0 port, and the total time that is necessary for the device to reconnect on the SuperSpeed port.The time between the time that the reset starts and the time that the device starts RxDetect on USB 3.0 can be up to 1 millisecond (ms). RxDetect can take up to 16 ms in the worst case. The time between the time that RxDetect succeeds and the time that RxDetect signals a disconnect on USB 2.0 can be up to 1 ms. Therefore, the total time from the start of the reset to disconnect signaling can be up to 18 ms. Accounting for the polling interval of the hub, the total comes to 50 ms.Next, the time between the time that RxDetect succeeds and the time that the device enters U0 can be up to 300 ms. With an extra margin for hub control transfers and other delays, the total comes to 500 ms.To test this requirement, we will first disable the SuperSpeed termination, then re-enable SuperSpeed termination after some time, and then reset the USB 2.0 port. After these actions occur, the software will wait for a port status change notification on the USB 2.0 port and the SuperSpeed port. We will verify that the USB 2.0 port shows a status change that indicates that the device disconnected from the USB 2.0 port and that the SuperSpeed port then shows a status change that indicates that the device connected on the SuperSpeed port. For more information, see Figure 9-1 in section 9.1.1 of the USB 3.0 Specification.
Additional Information
| Exceptions |
This Requirement does NOT apply to Systems that Support Connected Standby |
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.RespondAllStringRequests
USB device responds to all string requests that the host sends to indexes
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB devices must respond accordingly to string requests that the host sends. Devices must stall if no string is stored at the index being queried or if a request error exists. Devices must not reset themselves or stop functioning. This is described in USB Specification, Revision 2.0 or later, Section 9.6.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.ResponsesLimitedByWlengthField
USB device responses to host requests are limited in size by the wLength field
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All USB device requests contain a wLength field. Responses by the USB device to host requests must be of size <= wLength field of the device request as defined in the USB Specification, Revision1.1 or later, Section 9.3.5.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.SerialNumbers
USB serial numbers are implemented for specific device classes and are unique across specific device models
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB serial numbers must be implemented for the following device classes: Bluetooth (Class Code 0xE0, SubClass 0x01, Protocol 0x01) Communication device class (Class Code 0x02) Mass storage (Class Code 0x08) Scanning/imaging (Class Code 0x06) Printing (Class Code 0x07) Host Wire Adapters and Device Wire Adapters (Class Code 0xE0, subclass 02)USB serial numbers are optional for all other device classes. Additionally, if serial numbers are implemented on the device's model, all devices of the same model must have unique serial numbers.Design Notes:For more information on USB device class details, see "Defined 1.0 Class Codes" at https://go.microsoft.com/fwlink/?LinkId=40497. For more information on implementation of serial numbers, see USB Specification, Revision 2.0 or later, Section 9.6.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.SerialNumbersUseValidCharacters
USB device that implements manufacturer-defined serial numbers contains valid characters
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
A USB serial number must be a string that contains a manufacturer-determined ID composed of valid characters. Valid characters are defined in the Windows Driver Kit, "USB_DEVICE_DESCRIPTOR." Justification: Devices with invalid serial numbers force drivers to remove these invalid characters when reporting the info to PNP. Doing so may cause two devices with different serial numbers (the numbers different via an invalid char) to be reported to PNP as having the same serial number.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.SuperSpeedOnConnectViaUsb3Port
If upstream SuperSpeed termination is on, devices must always connect on the USB 3.0 port and never connect on the USB 2.0 port
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In a USB 3.0 hub, two downstream ports, a USB 2.0 port and a Superspeed port, share the same connector. When a SuperSpeed (that is, non-hub) device is plugged into such a connector, the device must always connect on the SuperSpeed port. The device must never connect on the USB 2.0 port. To test this requirement, the software will verify that the USB 3.0 port status bits show a connected device and that the USB 2.0 port status bits do not show a connected device. For a definition of "connect", see section 2 of the USB 3.0 Specification under "connected".
Additional Information
| Exceptions |
This requirement does NOT apply to Systems that Support Connected Standby |
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.TestedUsingMicrosoftUsbStack
USB Devices must be tested with Microsoft's xHCI Stack installed
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All USB Devices (Low, Full, High and Super Speed devices) must be tested with Microsoft's Extensible Host Controller Interface (xHCI) Stack installed and enabled on a Windows system. Note: During USB-IF self testing a specific USB Test Stack is installed for testing purposes, this is expected and acceptable.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Connectivity.UsbDevices.Usb3CompatibleWithDownLevel
USB 3.0 devices are backwards compatible with down level controllers and hubs
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
USB 3.0 devices both enumerate and function on USB 2.0 controllers. USB 3.0 devices also need to enumerate and function when USB 3.0 devices are connected to a full-speed hub or to a high-speed hub, according to section 5.3.1.1 of the USB 2.0 specification. "Function" means to operate as a user would expect a device of that class to operate. Design Notes:USB 3.0 devices must be able to do the following:
Reset successfully at high and full speeds.
Respond successfully to standard requests at high and full speeds for device and configuration descriptors. Standard requests are set_address, set_configuration, and get_descriptor.
Return appropriate information.
USB 3.0 devices must also be able to function at a minimum level, although USB 3.0 devices will not operate at super speed. For example, a USB 3.0 mass storage device must be able to transfer files at full speed mode as well as at super speed mode. Although data transfer is much slower at the lower speed, data transfer is still possible.
Additional Information
| Enforcement Date |
Jun. 01, 2010 |
Device.Connectivity.UsbDevices.UsbifCertification
USB IF Tests are passing or device is USB IF certified
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Effective June 1, 2011, USB devices must pass USB Implementers Forum (IF) tests or be USB-IF certified.
See white paper on Windows HCK USB-IF Testing
at https://www.microsoft.com/whdc/connect/usb/wlk-usb-if-testing.mspxJustification:This is an existing requirement that is based on industry specifications.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbDevices.UseUsbClassOnlyForControllerOrHub
Third-party INF files include the class "USB" only if the device is a USB host controller, a root, or an external hub
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Class USB is often used incorrectly for devices that do not have a predefined class. For example, a USB mouse uses class HID, whereas a USB smartcard uses class smartcard reader. Class USB is reserved for host controllers and root or external USB hubs. If the vendor has a device that has no Windows-defined class but uses USB as the bus, it must define its own class or class GUID. The setup class associated with the type of USB device, not with the bus type, must be used. The setup class "USB" (ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}) is reserved for USB host controllers and root or external USB hubs. It must not be used for other device categories. Design Notes:Microsoft provides system-defined setup classes for most device types. System-defined setup class GUIDs are defined in the Windows Driver Kit, "Devguid.h."If you choose the wrong class, the device appears in an incorrect location in Device Manager and in the Windows Vista UI. Using this class incorrectly may cause the device driver to fail hardware compatibility testing.For a list of Windows class GUIDs, see the Windows Driver Kit, "System-Supplied Device Setup Classes" at https://msdn.microsoft.com/library/ff553419(VS.85).aspx.
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbDevices.WirelessUsbObtainsWusbLogoFromUsbif
Wireless USB device or host obtains Certified Wireless USB logo from the USB-IF
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All Wireless USB devices must get a Certified Wireless USB Logo from the USB-IF.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Connectivity.UsbDevices.WirelessUsbWiMediaAlliace
Certified Wireless USB device or host passes all required WiMedia Alliance compliance tests.
| Target Feature |
Device.Connectivity.UsbDevices |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Wireless USB device must pass WiMedia Alliance radio compliance tests.
Additional Information
| Enforcement Date |
Jun. 01, 2009 |
Device.Connectivity.UsbHub
Requirements that apply only to USB Hubs
| Related Requirements |
Device.Connectivity.UsbHub.CompliesWithChap11 Device.Connectivity.UsbHub.IdentifyNumOfUserAccessiblePorts Device.Connectivity.UsbHub.ImplementSuperSpeedDescriptors Device.Connectivity.UsbHub.MapPortsPerUsb3Specification Device.Connectivity.UsbHub.ProvideStandardInterfacesToHostPeripherals Device.Connectivity.UsbHub.SuperSpeedRemainsOnAfterPortReset Device.Connectivity.UsbHub.SupportSuspend Device.Connectivity.UsbHub.Usb3HubCompliesWithUsb3Spec Device.Connectivity.UsbHub.Usb3ReportPortStatusBitsCorrectly |
Device.Connectivity.UsbHub.CompliesWithChap11
USB hub that implements USB functionality complies with the related specification
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB hubs that fit into one of the USB device class definitions must comply with the appropriate USB specification as follows: USB 1.1, Revision1.1 USB 2.0, Revision2.0
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbHub.IdentifyNumOfUserAccessiblePorts
USB hub correctly identifies and reports the number of ports that the user can access
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The USB hub must include details in its hub descriptor that provide the operating system with an accurate count of the number of downstream-facing ports that the hub supports and that are exposed to the user. See USB Specification, Revision 2.0, Section11.23, and USB 3.0 Specification, Section 10.14. Root hubs are exempt from this requirement.
Additional Information
| Exceptions |
Does not apply to Root Hubs |
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbHub.ImplementSuperSpeedDescriptors
USB 3.0 hubs must properly implement the SuperSpeed hub descriptor, the standard SuperSpeed descriptors, the USB 2.0 ports, and USB 3.0 hubs report version 2.1.
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
As described in section 10.0 of the USB 3.0 Specification, a USB 3.0 hub incorporates a USB 2.0 hub and a SuperSpeed hub. All exposed downstream ports on a USB 3.0 hub must support both SuperSpeed and USB 2.0 connections.For more information on USB 3.0 devices that operate at speeds other than SuperSpeed, see section 9.2.6.6 of the USB 3.0 Specification.When a USB 3.0 hub is operating in SuperSpeed mode, the hub must correctly implement the descriptors that are described in Section 10.13 of the USB 3.0 Specification in addition to the standard USB descriptors. As described in section 10.13.1 of the USB 3.0 Specification, the hub must support the following SuperSpeed descriptors in SuperSpeed mode:
Device descriptor
Binary Device Object Store (BOS) descriptor
USB 2.0 Extension
SuperSpeed USB Device Capability descriptor
Container ID
Configuration descriptor (SuperSpeed information)
Interface descriptor
Endpoint descriptor (for status change endpoint)
Endpoint Companion descriptor (for status change endpoint)
The class-specific descriptors for SuperSpeed hubs that must be supported, as defined in section 10.13.2.1 in the USB 3.0 Specification, are as follows: SuperSpeed Hub descriptorImplementation DetailsStandard USB SuperSpeed descriptors will be tested via the USB Command Verifier chapter 9 test for USB 3.0 devices. In the Driver Test Manager (DTM), this test is the USB Device Framework Test.Table 1. SuperSpeed Hub Descriptor Asserts
| Assert |
Description |
| 1 |
The bDescLength field of the SuperSpeed Hub descriptor has a value of 0xCh. |
| 2 |
The bDescriptorType field of the SuperSpeed Hub descriptor has a value of 0x2Ah. |
| 3a |
Bits D1..D0 of the wHubCharacteristics field of the SuperSpeed Hub descriptor must be 00 if the hub supports ganged power switching. |
| 3b |
Bits D1..D0 of the wHubCharacteristics field of the SuperSpeed Hub descriptor must be 01 if the hub supports individual port power switching. |
| 4a |
Bit D2 of the wHubCharacteristics field of the SuperSpeed Hub descriptor must be 0 for a hub that is not part of a compound device. |
| 4b |
Bit D2 of the wHubCharacteristics field of the SuperSpeed Hub descriptor must be 1 for a hub that is part of a compound device. |
| 5 |
Bits D4:D3 of the wHubCharacteristics field of the SuperSpeed Hub descriptor must not be 11 or 10 for a self-powered hub. |
| 6 |
Bits D15D5 of the wHubCharacteristics field of the SuperSpeed Hub descriptor are reserved and must be 0. |
| 7 |
The bPwrOn2PwrGood field of the SuperSpeed Hub descriptor must be 0 if the hub does not support power switching. |
| 8 |
The bHubHdrDecLat field of the SuperSpeed Hub descriptor must be in the range of 0x00h to 0x04h. |
| 9 |
The DeviceRemovable field of the SuperSpeed Hub descriptor reports the correct non-removable ports as non-removable. |
| 10 |
The bNbrPorts field of the SuperSpeed Hub descriptor reports the correct number of ports on the hub. |
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbHub.MapPortsPerUsb3Specification
USB 3.0 hubs must map their ports as defined in section 10.1 of the USB 3.0 Specification
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
External USB 3.0 hubs must follow the USB3 specification's connector mapping, except when the USB 3.0 hub may have an unequal number of USB 2.0 and USB 3.0 protocol ports. For example, the SuperSpeed part of the 3.0 Hub has 'n' ports and 2.0 part of the 3.0 Hub has 'm' ports and minimum(m,n) = 'p'. The first p ports of the SuperSpeed part and the 2.0 part should be mapped in order, so that port 1 of SuperSpeed hub maps to port 1 of the 2.0 hub, port 2 of the SuperSpeed hub maps to port 2 of the 2.0 hub and so on until port number p. Each of these 'p' port mappings must either have an external connector for it OR both of the ports in the mapping should be marked as "non-removable" in their respective parent hub descriptors. Note, that if the ports in a mapping are marked as non-removable, only one of the ports in that mapping can have a device attached to it. The other port in that mapping should neither have any device attached to it nor a device can be attached to it i.e. the port should remain unused.If there are excess ports on the 2.0 part (i.e. m-p is not 0), each of those m-p ports may either be exposed to the user OR can be marked as non-removable. If there are excess ports on the SuperSpeed part (i.e. n-p is not 0), none of those n-p ports should be exposed to the user, all of them should be marked as non-removable.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbHub.ProvideStandardInterfacesToHostPeripherals
USB hub provides standard connection interfaces to the host and USB peripherals
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All USB hubs must have one upstream-facing port and at least one downstream-facing port. The upstream-facing port must be a single Std-A receptacle for downstream traffic. The downstream-facing port or ports must be one of the following: Std-B receptacleMini-B receptacleCaptive Std-A cable, for upstream traffic Micro - B receptacleThis is described in USB Specification, Revision1.1 or later, Sections 6.2 and 11.1.2. and Micro-USB cables and connectors Revision 1.01
Additional Information
| Enforcement Date |
Jun. 01, 2006 |
Device.Connectivity.UsbHub.SuperSpeedRemainsOnAfterPortReset
USB 3.0 hubs must not turn off SuperSpeed termination on downstream ports upon over-current and port reset
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
DSPORT.Powered-off must be entered only when Rx termination is not detected or downstream Vbus is off. ClearPortFeature(PORT_POWER), Overcurrent, Upstream port reset, and SetConfig(0) must not cause SuperSpeed termination to be removed unless Vbus is also removed. If Vbus is removed, SuperSpeed termination must be re-enabled when Vbus is back on. If Upstream Vbus is removed, but the hub still provides Downstream Vbus (self-powered hub), then it must turn downstream SuperSpeed terminations back on.For more information, see figure 10-9 in the USB 3.0 Specification.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbHub.SupportSuspend
USB hubs must support suspend, and downstream devices must not drop off the bus when the hub resumes from selective suspend
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
USB hubs must support the selective suspend state, as stated in both the USB Specification and other certification requirements. After a hub is resumed from the selective suspend state, all devices that were attached downstream of the hub, and that were not removed while the hub was suspended, must be present.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbHub.Usb3HubCompliesWithUsb3Spec
USB 3.0 Hubs are compliant with USB 3.0 specification.
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
USB 3.0 Hubs must be compliant with Universal Serial Bus (USB) 3.0 Specification USB 3.0 Hubs must :
Pass the USB-IF interoperability tests
Pass the USB 3.0 Hub compliance test suite
Pass the USB 3.0 CV test
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.UsbHub.Usb3ReportPortStatusBitsCorrectly
USB 3.0 hubs must always report the port status bits correctly as per the USB 3.0 Specification
| Target Feature |
Device.Connectivity.UsbHub |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In the current stack, a number of invalid port status bit combinations that the hub reports are ignored. Any invalid combination of port status bits will be treated as an error. In particular, checks will follow these actions:
Resetting a port
Suspending and resuming a port
System resume
A hub should not report spurious change interrupts. A hub should complete the port status interrupt transfer without reporting changes.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Connectivity.WSD
| Related Requirements |
Device.Connectivity.WSD.DPWS Device.Connectivity.WSD.DPWSExtensibility Device.Connectivity.WSD.MetadataExchange Device.Connectivity.WSD.MetadataValid Device.Connectivity.WSD.Schema Device.Connectivity.WSD.WSDiscovery |
Device.Connectivity.WSD.DPWS
Devices which use or interact with the Web Services on Devices API (WSDAPI) comply with Device Profiles for Web Services (DPWS) specification
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
Devices which plan to use or interact with Microsoft Windows' implementation of DPWS, the Web Services on Devices API (WSDAPI), must implement the DPWS specification themselves. (WSDAPI)
Design Notes:
DPWS Specification available at
https://go.microsoft.com/fwlink/?LinkId=109231
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.WSD.DPWSExtensibility
Devices Profile for Web Services Devices must accept messages that contain extensibility sections, and process the messages as appropriate.
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
Devices Profile for Web Services (DPWS) devices must accept messages where the XML has been extended. If the device understands the content in the extensible section, it may process it.
Design Notes:
DPWS Specification available at
https://go.microsoft.com/fwlink/?LinkId=109231
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.WSD.MetadataExchange
Devices Profile for Web Services (DPWS) Devices support metadata exchange
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
DPWS Devices which interact with the Web Services on Devices API (WSDAPI) must support metadata exchange as defined in the metadata exchange specification.
Design Notes:
Metadata Exchange specification can be obtained at https://go.microsoft.com/fwlink/?LinkId=109248
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.WSD.MetadataValid
Devices which interact with the Web Services on Devices (WSDAPI) produce metadata that conforms to the Devices Profile for Web Services
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
Devices which interact with WSDAPI must populate the Metadata as defined in the Device Profile for Web Services Specification of February 2006.
Design Notes:
The Device Profile for Web Services Specification of February 2006 is available at https://go.microsoft.com/fwlink/?LinkId=109231
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.WSD.Schema
A network-enabled device that implements Devices Profile for Web Services (DPWS) must adhere to the protocol and schema.
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
A network-enabled device that implements Devices Profile for Web Services (DPWS) must adhere to the Devices Profile for Web Services as described by the schema.
The device must also reference the namespace URI as described in The Devices Profile for Web Service specification.
A device the implements DPWS must adhere to the Web Services Description Language (WSDL) associated with the logo device class. The WSDL defines services as collections of network endpoints, or ports. WSDL specification provides an XML format for documents for this purpose. Devices must implement the WSDL version 1.1.
Design Notes:
See the Web Services Description Language (WSDL) Version 1.1 at https://www.w3.org/TR/2001/NOTE-wsdl-20010315
See the Devices Profile for Web Services schema at https://schemas.xmlsoap.org/ws/2006/02/devprof/devicesprofile.xsd.
See the Devices Profile for Web Service specification at http://specs.xmlsoap.org/ws/2006/02/devprof/devicesprofile.pdf.
Additional information can be found in the Windows Rally Development Kit at https://go.microsoft.com/fwlink/?LinkId=109368.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Connectivity.WSD.WSDiscovery
Devices Profile for Web Services (DPWS) Devices interacting with the Web Services on Devices API (WSDAPI) implement WS-Discovery
| Target Feature |
Device.Connectivity.WSD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 x86, x64, Windows Server 2008 Release 2 x64 Windows Server 2012 x64 Windows Vista Client x86, x64 |
Description
DPWS Devices must implement WS-Discovery to work with WSDAPI.
Design Notes:
WS-Discovery specification can be obtained at https://go.microsoft.com/fwlink/?LinkId=109247
Additional Information
| Enforcement Date |
Jun. 26, 2013 |