Wi-Fi Direct Pairing Implementation

This section provides design guidelines and requirements for a peripheral device to participate in the Tap and Setup and Tap and Reconnect use cases.

Note  The paring implementation described in this topic is currently supported, in Windows 8.1, for paring to printer devices only.

Peripheral Wi-Fi Direct Device Pairing

During the tap, NFP receives pairing information from the connecting device. NFP passes the pairing information to Windows. Wi-Fi Direct devices follow the Wi-Fi Alliance Out-Of-Band (OOB) pairing procedure and the NFC Forum recommendations. Windows relies a propeitary pairing message as defined below.

Windows will prompt the user for consent, and if it is given, Windows will attempt to connect to each of the addresses, in order, until one succeeds. There is no further interaction between an NFP provider in the PC and the connecting device.

Using NFC as an example, unidirectional installation is accomplished by storing the pairing information in a static or passive NFC tag (an active NFC tag in static-emulation mode may also be used). Windows subscribes to this pairing information. An NFC-enabled NFP provider on the PC receives the connection information from the tag and passes this to Windows as a subscriber. Upon receipt of the connection information, Windows performs the actual installation of the device in-band using device class specific techniques.

Interoperability Requirements

To ensure interoperability across NFP providers, the pairing information should be encapsulated in a provider-specific message format.

As described elsewhere in this document, there are no specific requirements for proximity technologies other than for NFC-enabled NFP providers.

Windows requires NFC-enabled NFP providers to support a specific NFC Forum–defined mechanism for conveying the Wi-Fi Direct OOB pairing information for unidirectional pairing. The NDEF message contains a first record with a TNF field value of 0x01 and a TYPE field that is equal to “Hs”, and an alternative carrier record that points to a Wi-Fi Direct Carrier Configuration Record. In this method, only the PAYLOAD of the NDEF record will be used.

Unidirectional Pairing Using NFC for Wi-Fi Direct

This section provides more details on how NFC, Wi-Fi Direct, and Windows work together to support unidirectional wireless pairing for Wi-Fi Direct devices such as printers.

NFP Provider References

Wi-Fi Direct pairing is accomplished using an NFC Forum standardized Connection Handover Select message type. The below graphic provides an overview of how a Connection Handover Select message is applied for Wi-Fi Direct device pairing, specifically NDEF records 3 and 4. The Handover Select message describes one or more “ac” or “Alternate Carrier” records. These records follow the Handover Select record sequentially and each have a well defined type. Finally, the message will contain a Microsoft defined device pairing record which provides Windows with information about how to process the pairing operation.

Connection Handover Select Message

Wi-Fi Direct Device Pairing Message

In the sample use cases that follow, NFC type 2 tags are used as an illustrative example. If it is necessary to use a different NFC tag type, the NDEF message must be properly encapsulated according to that tag definition.

FieldValueDescription
TNF0x02Format of the Type field that follows. Media-type as defined in RFC 2046.
Type'application/vnd.ms-windows.wfd.oob'New type string we define for this scenario.
Size of OOB dataWORDUp to 64 KB of OOB data supported.
Wi-Fi Direct OOB data<blob of size indicated by previous field>Wi-Fi Direct OOB data as defined below.

 

Wi-Fi Direct OOB format

The following table describes the format of the WiFi Direct OOB data. OOB Unidirectional Data may be transmitted by any unidirectional P2P OOB Device.

AttributesAttribute IDRequired/OptionalNote

OOB Header

See OOB Header attribute format table.

N/ARequiredThe OOB Header attribute shall be present in P2P OOB Data blob, and have its OOB Type value set to “OOB Unidirectional Provisioning Data”.

OOB Device Info

See OOB Device info attribute format table.

1RequiredThis attribute must be present. It provides information about this P2P Device.

OOB Provisioning Info

2RequiredThis attribute must be present. It provides provisioning information that this P2P Device is expecting to use.

OOB Configuration Timeout

5RequiredThis attribute must be present. It provides information about how long this P2P Device will wait for a response over Wi-Fi Direct.

 

OOB Header attribute format

Field NameSize (octets)ValueDescription
Total Data Length2VariableLength of entire OOB Data Blob (including header).
Length 2VariableLength of the following fields in OOB header.
Version 10x10Value identifying the version of this P2P OOB record.
OOB Type 1VariableValue identifying the type of OOB transaction. The specific value is defined in OOB Transaction Types table.
OUI0 or 3VariableVendor-specific OUI. This is an optional value. Must only be present when OOB Type is Vendor Specific.
OUI Type0 or 1VariableVendor-specific Type. This is an optional value. Must only be present when OOB Type is Vendor Specific.

 

OOB Transaction Types

OOB Type (Hex)Description
0x00OOB Unidirectional Provisioning Data
0x01OOB Provisioning Listener Data
0x02 OOB Provisioning Connector Data
0x03 OOB Reinvoke Data
0x04-0xDC Reserved
0xDDVendor-Specific
0xDE-0xFFReserved

 

OOB Device info attribute format

Field NameSize (octets)ValueDescription
Attribute ID11Identifying the type of P2P OOB attribute. The specific value is defined in the P2P OOB Attributes table.
Length 2VariableLength of the following fields in the attribute.
P2P Device Address 6As defined in P2P Spec.An identifier used to uniquely reference a P2P Device.
Config Methods2As defined in P2P Spec.

The WSC Methods that are supported by this device.

Note  Byte ordering within the Config Methods field shall be big-endian.

Primary Device Type8As defined in P2P Spec.

Primary Device Type of the P2P Device. Contains only the Data part of the WSC Primary Device Type attribute (excludes Attribute ID and Length fields).

Note  Byte ordering within the Primary Device Type field shall be big-endian.

Device Capability Bitmap1As defined in P2P Spec.A set of parameters indicating P2P Device’s capabilities.
Device NameVariableAs defined in P2P Spec.

Friendly name of the P2P Device. Contains the entire WSC Device Name attribute TLV format.

Note  Byte ordering within the Device Name field shall be big-endian.

 

P2P OOB Attributes

OOB Type (Hex)Description
0x00OOB Status
0x01OOB Device Info
0x02 OOB Provisioning Info
0x03 OOB Group ID
0x04 OOB Listen Channel
0x05OOB Configuration Timeout
0x06-0xDCReserved
0xDDVendor specific attribute
0xDE-0xFFReserved

 

OOB Provisioning Info attribute format

Field NameSize (octets)ValueDescription
Attribute ID11Identifying the type of P2P OOB attribute. The specific value is defined in P2P OOB Attributes table.
Length 2VariableLength of the following fields in the attribute.
Provisioning Settings Bitmap 1VariableA set of provisioning settings options, as defined the Provisioning settings table.
Selected Config Method2As defined in P2P Spec.The WSC Method that was selected by this P2P device for provisioning.
Pin Length10 - 8Number of bytes in the following PIN Data field. This field set to 0 indicates no additional PIN data.
Pin DataVariablenThis field is optional. This field is present only if the PIN Length field is not 0, and contains an array of octets which represent a PIN to be used for provisioning.

 

Provisioning settings

Bits(s)InformationNotes
0Create New GroupThe Create New Group bit is set to 1 if this provisioning info is for forming a new group with the target P2P device. Otherwise, this provisioning info is for joining an existing group.
1Enforce Group Type SettingThe Enforce Group Type Setting bit is set to 1 if Desired Group Type bit must be enforced, Otherwise, Desired Group Type bit is simply a preference.
2 Desired Group TypeDesired Group Type bit shall be set to 0 if Desired Group Type is transient, and shall be set to 1 if Desired Group Type is persistent.
3 - 7Reserved

 

OOB Configuration Timeout attribute format

Field NameSize (octets)ValueDescription
Attribute ID15Identifying the type of P2P OOB attribute. The specific value is defined in P2P OOB Attributes table.
Length 21Length of the following fields in the attribute.
Listener Configuration Timeout 10 - 255Amount of time this P2P device will spend waiting for Wi-Fi Direct communication after OOB data transfer, in units of 100 milliseconds. (Maximum of 25.5 seconds).

 

Windows Device Pairing Record

The Windows Device Pairing Record follows the NDEF specification. It provides additional information to Windows about how to process the Connection Handover Select message. The TNF and Type fields must be specified according to the NDEF specification. The other fields below will be sequentially listed in the Payload field of the NDEF record.

Field NameValueLength ValueDescription
TNF0x023 bitsFormat of the Type field that follows. Media-type as defined in RFC 2046.
Type 'application/vnd.ms-windows.devicepairing'0x28 bytesNew type string we define for this scenario.
MajorVersion 0x12 bytesMajor version is required to be 0x1.
MinorVersion0x02 bytesMinor version is required to be 0x0.
Flags0x0 or 0x014 bytes

Set to 0x0 to try all transports.

Set to 0x1 to attempt installation sequentially and stop after first success. Preference for transports is indicated by sequence of alternate carrier records.

Note  Values 0x0002 through 0x0064 are reserved.

Length of device friendly nameLength of device friendly name field.1 byteLength of Device friendly name.
Device friendly nameUTF-8 encoded string up to 255 bytes.Length of device friendly nameFriendly name for the device which will be shown in consent UI on the client.

 

Wi-Fi Direct “Just Works” ceremony, Static Connection Handover tag format

As an example, the following is a typical implementation for an NFC passive tag. This corresponds to a static connection handover case with a Wi-Fi Direct carrier record, a network share printer, and the ms-device pairing record.

This first table illustrates the format of the Wi-Fi Direct paring portion of the tag.

OffsetContentLengthExplanation
00x911

NDEF Record Header:

MB=1b, ME=0b, CF=0b, SR=1b, IL=0b, TNF=001b

10x021Record Type Length: 2 octets
20x0A1Record Type Length: 10 octets
30x48 0x732Record Type: “Hs”
50x121Version Number: Major = 1, Minor = 2
60xD11

NDEF Record Header:

MB=1b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=001b

70x021Record Type Length: 2 octets
80x041Payload Length: 4 octets
90x61 0x632Record Type: “ac”
110x011Carrier Flags: CPS=1, "active"
120x011Carrier Data Reference Length: 1 octet
130x301Carrier Data Reference: “0”
140x001Auxiliary Data Reference Count: 0
150x1A1

NDEF Record Header:

MB=0b, ME=0b, CF=0b, SR=1b, IL=1b, TNF=010b

160x221Record Type Name Length: 34 octets
170x3E1Payload Length: 62 octets
180x011Id Length: 1 octet
19

0x61 0x70 0x70 0x6C

0x69 0x63 0x61 0x74

0x69 0x6F 0x6E 0x2F

0x76 0x6E 0x64 0x2E

0x6D 0x73 0x2D 0x77

0x69 0x6E 0x64 0x6F

0x77 0x73 0x2E 0x77

0x66 0x64 0x2E 0x6F

0x6F 0x62

34Record Type Name: 'application/vnd.ms-windows.wfd.oob'
530x301Id: “0”
540x3E 0x002

Wi-Fi Direct OOB data length: 62 octets. The length is read as an unsigned short and is inclusive

of the entire blob. Includes 2 length octets. This value must be stored in little-endian format.

560x02, 0x002Header length: 2 octets
580x101Version: 0x10
590x001OOB type: 0x00 (unidirectional)
600x011 Attribute: 0x01 (Device information attribute)
610x22 0x002Device information length: 34 octets
63

0x01 0x23 0x34 0xab

0xcd 0xef

6Wi-Fi Direct P2P device MAC address: “01:23:34:ab:cd:ef”
690x01 0x002Config type
71

0x00 0x01 0x00 0x50

0xF2 0x00 0x00 0x00

8Primary device type
720x121Capability
730x10 0x112Attribute: Device name
750x00 0x0d2Device name length: 13 octets
77

0x43 0x6f 0x6e 0x74

0x6f 0x73 0x6f 0x20

0x4d 0x6f 0x75 0x73

0x65

13

Device friendly name in UTF-8. Note that there is no NULL terminating character and that UTF-8

may be one or two bytes per character. This example reads “Contoso Mouse”

900x021Attribute: provisioning info
910x0c 0x002Provisioning info length: 12 octets
930x071Setting bitmap: new group, enforce persistent
940x01 0x002Config method: pin entry
960x081Pin length: 8 octets
97

0x01 0x02 0x03 0x04

0x05 0x06 0x07 0x08

8Pin: “12345678”
1050x051Attribute: Configuration timeout information
1060x01 0x002Configuration timeout length
1080x64110 seconds, in 100 millisecond units

 

This second table illustrates the format of the network printer paring portion of the tag.

OffsetContentLengthExplaination
1090x121

NDEF record header:

MB=0b,ME=0b, CF=0b, SR=1b, IL=0b,TNF=010b

1100x291Type length field
1110x191Payload length field
112

0x61 0x70 0x70 0x6c

0x69 0x63 0x61 0x74

0x69 0x6f 0x6e 0x2f

0x76 0x6e 0x64 0x2e

0x6d 0x73 0x2d 0x77

0x69 0x6e 0x64 0x6f

0x77 0x73 0x2e 0x6e

0x77 0x70 0x72 0x69

0x6e 0x74 0x69 0x6e

0x67 0x2e 0x6f 0x6f

0x62

41Record type name: “application/vnd.ms-windows.nwprinting.oob”
154

0x5c 0x5c 0x70 0x72

0x69 0x6e 0x74 0x53

0x65 0x72 0x76 0x65

0x72 0x5c 0x70 0x72

0x69 0x6e 0x74 0x65

0x72 0x4e 0x61 0x6d

0x65

25Printer name: “\\printServer\printerName"

 

This third table illustrates the format of the MS-Device paring portion of the tag.

OffsetContentLengthExplaination
1790x521

NDEF record header:

MB=0b, ME=1b, CF=0b, SR=1b, IL=0b,TNF=010b

1800x281Type length field
1810x151Payload length field
182

0x61 0x70 0x70 0x6c

0x69 0x63 0x61 0x74

0x69 0x6f 0x6e 0x2f

0x76 0x6e 0x64 0x2e

0x6d 0x73 0x2d 0x77

0x69 0x6e 0x64 0x6f

0x77 0x73 0x2e 0x64

0x65 0x76 0x69 0x63

0x65 0x70 0x61 0x69

0x72 0x69 0x6E 0x67

40Record type name: “application/vnd.ms-windows.devicepairing”
2220x00 0x01 0x00 0x004Version: Major = 1, Minor = 0
2260x001Flags: Set to 0, try all transports
2270x0F1Length of device friendly name
228

0x43 0x6f 0x6e 0x74

0x6f 0x73 0x6f 0x20

0x50 0x72 0x69 0x6e

0x74 0x65 0x72

15The device friendly name displayed to the user: “Contoso Printer”

 

Wi-Fi Direct Connectivity Requirements

Devices and clients must have the Wi-Fi radio turned on. If not, pairing will fail.

Handling Edge Cases

If a user has previously paired a device, but then manually removes the device from the device list, tapping again will result in an attempt to install or pair.

If a user enters into the range of actuation but then suddenly leaves before the out-of-band (OOB) information is transferred, the device may become connectable but the PC will not look for the device. In this case, there will be no consent UI from the PC and the user will need to tap again. If the device is already discoverable when it is tapped again, it should remain discoverable and should reset the timeout period.

For Wi-Fi Direct devices, if the Wi-Fi radio turns off then the installation will not be successful.

If a user taps two devices at approximately the same time, only the pairing for the first received OOB information will be attempted.

Any attempt to tap the device on a system running an operating system that doesn’t support Tap to Setup or Tap to Reconnect may result in the device going into connectable mode but pairing will not take place. Users will need to use a pairing UI provided for Bluetooth and use the pairing button to initiate pairing.

 

 

Send comments about this topic to Microsoft

Show:
© 2014 Microsoft