WCN-NET protocol

The Windows Rally suite of protocols includes the Microsoft implementation of WPS, which is known as Windows Connect Now-NET (WCN-NET). This protocol is used to set up Wi-Fi networks and to add wireless devices to Wi-Fi networks.

This information applies for the following operating systems:

• Windows Server 2008 R2
• Windows 7

Rally Vertical Pairing is achieved by including vendor extensions that identify the device’s UPnP and/or DPWS identity string’s universally unique identifier (UUID) values in the WCN-NET/WPS messages. This enables Windows to determine the device’s intent both to connect to a Wi-Fi network and to pair with Windows. After Windows has configured the device's Wi-Fi settings and has paired with the device, Windows waits for layer-3 PnP-X discovery by using Simple Service Discovery Protocol (SSDP) for a UPnP device or Web Services Dynamic Discovery (WS-Discovery) for a DPWS device. If the device is successfully discovered, Windows installs and loads the appropriate drivers for the device.

WPS vendor extensions

A vendor extension is a custom attribute that a device manufacturer can include in WCN-NET/WPS messages. These vendor extensions are defined as blocks of data that are stored in a WPS message's <other> field. The <other> field is an optional field that exists in all WCN-NET/WPS messages, including messages M1 M8 and in the WPS Information Element (WPS IE) in the Probe Request and Probe Response frames. The following figure shows the location of the vendor extensions in the WPS M1 and M2 messages.

Vendors, such as Microsoft, can define vendor extensions for their own use. Every vendor extension contains a vendor ID and vendor data, as shown in the following figure.

The vendor ID field is three octets long and contains a specific vendor’s ID value that the Internet Assigned Numbers Authority (IANA) provides. The Microsoft vendor ID is 0x137 and is used for every Microsoft vendor extension, including the vendor extension that is used for Rally Vertical Pairing.

Vendor extensions are included with a WPS message by following the WPS message with one or more vendor extensions, as shown in the following figure.

Microsoft vendor extensions

The vendor data block that is in each vendor’s vendor extensions contains an arbitrary block of data that the vendor defines. The vendor data block in Microsoft vendor extensions consists of one or more Type-Length-Value (TLV) structures. The organization of the TLV structure is shown in the following figure.

Microsoft has defined various TLV types. Each TLV type represents specific functionality and has different requirements. For example, the TLVs that are related to Rally Vertical Pairing must be sent in the WPS M1 message. However, they can also be sent in other WPS messages.

In a TLV structure, both the Type and the Length fields are 2 bytes long. The Value field can be anywhere from 0 to 1017 bytes long. The value that is stored in the Type field is feature-dependent, and the value that is stored in the Length field must represent the length of the data, in bytes, that is stored in the Value field. The following table provides a detailed description of each field of the TLV structure.

Microsoft Vendor Extension TLV Structure Fields

The Microsoft vendor extensions allow for one or more TLV structures to be present in the vendor data field, as shown in the following figure.

There is no limit to the number of TLV structures that can be contained in a Microsoft vendor extension. However, if a device specifies multiple Microsoft TLV structures it should use only one vendor extension that contains all the TLV structures instead of using multiple vendor extensions.

Rally Vertical Pairing TLVs

Two specific TLV types are defined for Rally Vertical Pairing. These TLV types are listed in the following table.

Rally Vertical Pairing TLVs

Vertical Pairing Identifier TLV

The Vertical Pairing identifier (VPI) TLV communicates a device’s internal topology, which specifies how Windows can communicate with the device’s services. At least one VPI is required to support Rally Vertical Pairing extensions, even if Vertical Pairing is not implemented in the device. In this situation, the VPI would specify that no transports are used. The VPI TLV must be sent as part of the Microsoft vendor extension in the WPS M1 message.

The data that is included with a VPI TLV is 2 bytes long and consists of two different fields: a Transport field and a Profile Request field, as shown in the following figure. Each field is 1 byte long.

VPI Transport field

The Transport field specifies the transport that Windows can use to communicate with the device. Only one transport can be specified per VPI. If the device supports multiple PnP-X transports, it can communicate this by including multiple VPI TLVs (one for each transport) in the Microsoft vendor extension. The valid values for the VPI Transport field are listed in the following table.

VPI Transport Field Values

Note  Windows 7 provides support for DPWS (0x01) or Secure DPWS (0x03), but not both.

Note  If a device does not implement Rally Vertical Pairing, it must specify only one VPI with a Transport value of 0x00 (None). In this situation, the device should not specify a Transport UUID TLV. This notifies Windows that it should not expect to pair with the device. Therefore, Windows does not try to pre-pair with the device while it configures the device's Wi-Fi settings.

VPI Profile Request field

The VPI lets a device use the WPS protocol to provision the device's services. In this situation, a device service can request that Windows send it information for configuring the service. This information is known as a profile. The VPI’s second field specifies whether the device is requesting that Windows send it a profile. The valid values for the VPI Profile Request field are listed in the following table.

VPI Profile Request Field Values

Note  The VPI Profile Request field value of 0x00 is considered reserved because it is not currently supported by Windows 7. The VPI Profile Request field should only be set to a value of 0x01 (Wi-Fi profile requested), even if a value of 0x00 (none) is specified for the transport.

Transport UUID TLV

The Transport UUID TLV specifies that a specific transport (DPWS or UPnP) has a different base UUID value than the WPS UUID. The Transport UUID TLV is optional. If the Transport UUID TLV is not included, the WPS UUID is used to form an identity for the specified transport.

If a Transport UUID TLV is included, it must immediately follow the VPI TLV that identifies the transport. If more than one VPI TLV is included, a Transport UUID TLV can be included after each VPI TLV.

Note  The Transport UUID TLV data value must be in network byte order.

Note  If the device specifies a VPI Transport value of 0x00 (none), do not include a Transport UUID TLV.

WPS example

For this example, assume that a printer device uses DPWS and implements the WS Print interface. The device uses the UUID values that are listed in the following table.

WPS Example—Service UUID Values

Note  UUID values are specified in all lowercase, and the DPWS identity string uses the format **urn:uuid:**uuid_value.

Note  The UUID values in this example are fictitious and must not be used in a real device.

When the device sends out its WPS M1 messages, it includes the Microsoft vendor extension that is shown in the following figure.

In this example, the vendor extension contains a Vendor ID value of 0x137, which identifies it as a Microsoft vendor extension. Inside the vendor extension’s vendor data field are two TLV structures.

The first TLV has a Type value of 0x1001, which identifies the TLV as a VPI. The length of the data in the first TLV is 2 bytes, which contain a value of 0x0101. This specifies that the device supports the DPWS transport (0x01) and that it is requesting a profile (0x01).

The second TLV has a Type value of 0x1002, which identifies the TLV as a Transport UUID. The length of the data in the second TLV is 16 bytes, which contain the binary version of the UUID value 00010203-0405-0607-0809-0a0b0c0e0e0f.

When a customer vertically pairs the printer, Windows first configures the device’s Wi-Fi radio with appropriate settings. It then pairs the device’s DPWS device by using the specified transport UUID value.

After the device connects to the Wi-Fi network and announces its DPWS services, Windows creates the appropriate PnP device nodes and installs and loads the appropriate drivers.

Protocol transport requirements

In Windows 7, Rally Vertical Pairing supports only the UPnP and DPWS protocols. A device can use either or both protocols. It is the responsibility of the device to communicate its intent to use a protocol to Windows. This means that the device must explicitly state which protocol Windows is to use to pair with the device. If a device exposes no protocols, it must explicitly specify that the device uses no protocols.

UUID values

The WPS, UPnP, and DPWS protocols all use a UUID value. For Rally Vertical Pairing support, you must observe the following guidelines when you use UUIDs:

• Identity strings must use all lowercase characters. A device’s UPnP root node must implement its identity string by using only numeric digits and lowercase characters. This is important because UPnP matches case-sensitive identity strings. When the device communicates its UUID over WPS by using a vendor extension, it is sent in its binary format. When Windows converts the binary UUID to a text UUID, it uses all lowercase characters. Therefore, if the device uses any uppercase characters in its identity string, UPnP discovery of the device fails.

• The DPWS identity must use the ”urn:uuid:<uuid_value>” format. All DPWS devices must implement a uniform resource identifier (URI) by using the format that is recommended in the DPWS specification urn:uuid:uuid_value, for example, urn:uuid:f8d8fe06-6f4a-4ea2-93aa-38061a6c8550. Windows assumes that the URI consists of only numeric digits and lowercase characters.

• Identity string UUID values can be shared. Devices can share the same UUID value across different transports to conserve space in the Rally Vertical Pairing vendor extension. If a transport uses the same UUID as the WPS UUID, there is no requirement for the vendor extension to include a Transport UUID TLV for that particular transport. However if the UUID value is shared only between UPnP and DPWS but differs from the WPS UUID, both transports must include their own Transport UUID TLV.

  For example, if a device uses the UUIDs that are listed in the following table, providing a Transport UUID TLV for UPnP is optional but is required for DPWS.

  Example UUIDs

  Protocol	Identity
  WPS	f8d8fe06-6f4a-4ea2-93aa-38061a6c8550
  UPnP	uuid:f8d8fe06-6f4a-4ea2-93aa-38061a6c8550
  DPWS	urn:uuid:55363c1c-8547-4195-a325-fc3ecba5b312

   

  As another example, if the device uses the UUIDs in the following table (UPnP and DPWS UUIDs are shared but differ from the WPS UUID), both transports require their own Transport UUID TLV.

  Protocol	Identity
  WPS	f8d8fe06-6f4a-4ea2-93aa-38061a6c8550
  UPnP	uuid:55363c1c-8547-4195-a325-fc3ecba5b312
  DPWS	urn:uuid:55363c1c-8547-4195-a325-fc3ecba5b312

   

For more information about WCN-NET, see Configuration Technologies: Windows Connect Now.

Related topics

Using Windows Rally Vertical Pairing to automatically install Wi Fi devices

Send comments about this topic to Microsoft