Bluetooth Pairing Implementation
This section provides design guidelines and requirements for a peripheral Bluetooth device to participate in the Tap and Setup and Tap and Reconnectuse cases.
Peripheral Bluetooth Device Pairing Methods
During the tap, NFP receives pairing information from the connecting device. NFP passes the pairing information to Windows. Bluetooth devices follow the Bluetooth Out-Of-Band (OOB) pairing procedure and the NFC Forum recommendations.
There is no further interaction between an NFP provider in the computer 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 computer 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 pairing device in-band to Bluetooth using Bluetooth-specific procedures.
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.
However, Windows requires NFC-enabled NFP providers to support two specific NFC Forum–defined mechanisms for conveying the Bluetooth OOB pairing information for unidirectional pairing. These mechanisms are functionally equivalent. They are both supported because vendors have adopted both approaches in the market.
The following list summarizes these supported methods:
- The first supported method is for an NDEF message to contain one record with a TNF field value of 0x02 and a TYPE field that is equal to “application/vnd.bluetooth.ep.oob”.
- The second supported method is for an NDEF message to contain 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 Bluetooth Carrier Configuration Record (mime-type “application/vnd.bluetooth.ep.oob”). In this method, only the PAYLOAD of the “application/vnd.bluetooth.ep.oob” NDEF record will be used.
Unidirectional Pairing Using NFC for Bluetooth
This section provides more details on how NFC, Bluetooth, and Windows work together to support unidirectional wireless pairing for Bluetooth devices such as mice, keyboards, and headphones.
Provider References
| Provider | Specification |
|---|---|
| Near Field Communication | NFC Data Exchange Format (NDEF) Technical Specification, NFC Forum, NDEF 1.0 2006-07-24 Bluetooth Secure Simple Pairing using NFC, NFC Forum, 2011 |
| Bluetooth BR/EDR | NFC Data Exchange Format (NDEF) Technical Specification, NFC Forum, NDEF 1.0 2006-07-24 NFC Bluetooth Secure Simple Pairing using NFC, App Document, NFC Forum, NFCForum-AD-BTSSP_1.0_draft_10, 2011-06-09 |
NDEF Message Header
NDEF message header values are defined by the NFC Forum. The Windows implementation has no impact on and does not alter the standard with the exception that the TNF (Type Name Format) needs to always be set to 0x02 for MIME Type. The following is an example for the device pairing implementation.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| MB | ME | CF | SR | IL | TNF(2) | TNF(1) | TNF(0) |
| Flag | Description | Value (in binary) | Notes |
|---|---|---|---|
| MB | Message Begin | 1 – start of an NDEF record | Defined by NDEF; must be 1 for Windows |
| ME | Message End | 1 – end of an NDEF record | Defined by NDEF; must be 1 for Windows |
| CF | Chunk Flag | 0 – the only and the termination chunk of an NDEF record | Defined by NDEF; must be 0 for Windows |
| SR | Short Record | 1 – PLAYLOAD_LENGTH field is a single octet for setting length of a record that is less or equal to 256 bytes | Defined by NDEF; a short record (1) is recommended for this field. |
| IL | ID_LENGTH field is present | 0 – ID_LENGTH field is not present | Defined by NDEF; a short record (1) recommended for this field. |
| TNF | Type Name Format | 001 (in binary) – message type is NFC Forum well-known type [NFC RTD] | Windows requires 001 for NFC Forum well-known type [NFC RTD] |
NDEF Message Content
The remaining values in the NDEF message are presented here for completeness. For full definitions see the NDEF specification.
| NDEF message field | Content |
|---|---|
| NDEF Message Header | 1 byte (see previous table) |
| Record Type Name Length | 1 byte |
| Payload Length | 1 byte (for short record) 4 bytes (for long record) |
| Payload ID Length | This field is not present if the IL flag is 0 |
| Record Type Name | Number of bytes specified in “Payload Type Name Length” |
| ID | ID field if ID Length is not 0; it is not present if IL flag is 0 or ID Length field is 0 |
Bluetooth OOB Data Requirement
| Name | Section type | Size (octets) | Required or Optional | Description |
|---|---|---|---|---|
| OOB Data Length | n/a | 2 | Required | Defined by NDEF; must be 1 for Windows 8 |
| Bluetooth Device Address | n/a | 6 | Required | Defined by NDEF; must be 1 for Windows 8 |
OOB Data fields for BR/EDR devices:
| Name | Section type | Size (octets) | Required or Optional | Description |
|---|---|---|---|---|
| Class of Service (CoD) | 0x0d | 3 | Required | Defined by NDEF; must be 0 for Windows |
| Local Name | 0x09 | Variable | Required | Windows uses the value in user consent UI. Windows Bluetooth provider reads the COD value in the format of: Refer to bthdef.h in Windows SDK. |
| Simple Pairing Hash C | 0x0e | 1 | Optional | Windows uses the value in pairing UI. |
| Simple Pairing Randomizer R | 0x0f | 1 | Optional | The Bluetooth Simple Pairing Hash C and Randomizer R values are not required for OOB pairing. When these values are used, they should be uniquely created for each pairing transaction. |
Bluetooth OOB Data Examples
The following example use cases are formatted as NFC type 2 tags. The NDEF message is encapsulated within a TLV with type “03”. The length of this TLV is determined by the length of the entire NDEF message body. If it is necessary to use a different NFC tag type, the NDEF message must be properly encapsulated according to that tag definition.
Bluetooth with SSP Hash value C and Randomizer value R, simplified tag format
This is a typical implementation for an NFC active tag. This corresponds to the simplified tag format for a single Bluetooth carrier in section 4.2.1 of [NFC BTSSP].
| Offset | Content | Length | Explanation |
|---|---|---|---|
| 0 | 0x02 | 1 | NDEF Record Header: MB=1b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=010b |
| 1 | 0x20 | 1 | Record Type Name Length: 32 octets |
| 2 | 0x4a | 1 | Payload Length: 74 octets |
| 3 | 0x61 0x70 0x70 0x6C 0x69 0x63 0x61 0x74 0x69 0x6F 0x6E 0x2F 0x76 0x6E 0x64 0x2E 0x62 0x6C 0x75 0x65 0x74 0x6F 0x6F 0x74 0x68 0x2E 0x65 0x70 0x2E 0x6F 0x6F 0x62 |
32 | Record Type Name: 'application/vnd.bluetooth.ep.oob' |
| 35 | 0x4a 0x00 | 2 | Bluetooth OOB data length: 74 octets. The length is read as an unsigned short and is inclusive of the entire blob. Includes two length octets. This value must be stored in little-endian format. |
| 37 | 0x4c 0x66 0x00 0x00 0x73 0x20 |
6 | Bluetooth device MAC address: 20:73:00:00:66:4c These bytes must be stored in little-endian order in the pairing data blob. For this example it its “4c 66 00 00 73 20” . |
| 43 | 0x18 | 1 | EIR Data Length: 24 octets |
| 44 | 0x09 | 1 | EIR Data Type: 0x09 |
| 45 | 0x43 0x6f 0x6e 0x74 0x6f 0x73 0x6f 0x20 0x42 0x6c 0x75 0x65 0x74 0x6f 0x6f 0x74 0x68 0x20 0x4d 0x6f 0x75 0x73 0x65 |
23 | Device friendly name in UTF-8.
Note There is no NULL terminating character and UTF-8 may use one or two bytes per character.
This example reads “Contoso Bluetooth Mouse". |
| 68 | 0x04 | 1 | EIR Data Length: 4 octets |
| 69 | 0x0e | 1 | EIR Data Type: 0x0E |
| 70 | 0x80 0x05 0x00 | 3 | Class of device: 0x000580 These bytes must be stored in little-endian order in the pairing data blob. For this example it is “0x000580”, which is the CoD type for a “HID-mouse”. |
| 73 | 0x11 | 1 | EIR Data Length: 17 octets |
| 74 | 0x0e | 1 | EIR Data Type: 0x0e |
| 75 | 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f |
16 | SSP Hash value |
| 91 | 0x11 | 1 | EIR Data Length: 17 octets |
| 92 | 0x0e | 1 | EIR Data Type:0x0e |
| 93 | 0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f |
16 | SSP Randomizer. |
Bluetooth “Just Works” ceremony, simplified tag format
This is a typical implementation for an NFC passive tag. This corresponds to the simplified tag format for a single Bluetooth carrier in section 4.2.1 of [NFC BTSSP].
| Offset | Content | Length | Explanation |
|---|---|---|---|
| 0 | 0x02 | 1 | NDEF Record Header: MB=1b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=010b |
| 1 | 0x20 | 1 | Record Type Name Length: 32 octets |
| 2 | 0x26 | 1 | Payload Length: 38 octets |
| 3 | 0x61 0x70 0x70 0x6C 0x69 0x63 0x61 0x74 0x69 0x6F 0x6E 0x2F 0x76 0x6E 0x64 0x2E 0x62 0x6C 0x75 0x65 0x74 0x6F 0x6F 0x74 0x68 0x2E 0x65 0x70 0x2E 0x6F 0x6F 0x62 |
32 | Record Type Name: 'application/vnd.bluetooth.ep.oob' |
| 35 | 0x26 0x00 | 2 | Bluetooth OOB data length: 38 octets. The length is read as an unsigned short and is inclusive of the entire blob. Includes two length octets. This value must be stored in little-endian format. |
| 37 | 0x4c 0x66 0x00 0x00 0x73 0x20 |
6 | Bluetooth device MAC address: 20:73:00:00:66:4c These bytes must be stored in little-endian order in the pairing data blob. For this example it its “4c 66 00 00 73 20” . |
| 43 | 0x18 | 1 | EIR Data Length: 24 octets |
| 44 | 0x09 | 1 | EIR Data Type: 0x09 |
| 45 | 0x43 0x6f 0x6e 0x74 0x6f 0x73 0x6f 0x20 0x42 0x6c 0x75 0x65 0x74 0x6f 0x6f 0x74 0x68 0x20 0x4d 0x6f 0x75 0x73 0x65 |
23 | Device friendly name in UTF-8.
Note There is no NULL terminating character and UTF-8 may use one or two bytes per character.
This example reads “Contoso Bluetooth Mouse". |
| 68 | 0x04 | 1 | EIR Data Length: 4 octets |
| 69 | 0x0e | 1 | EIR Data Type: 0x0e |
| 70 | 0x80 0x05 0x00 | 3 | Class of device: 0x000580 These bytes must be stored in little-endian order in the pairing data blob. For this example it is “0x000580”, which is the CoD type for a “HID-mouse”. |
Bluetooth “Just Works” ceremony, Static Connection Handover tag format
This is a typical implementation for an NFC passive tag. This corresponds to the static connection handover case with a single Bluetooth carrier record in section 4.2 of [NFC BTSSP].
| Offset | Content | Length | Explanation |
|---|---|---|---|
| 0 | 0x91 | 1 | NDEF Record Header: MB=1b, ME=0b, CF=0b, SR=1b, IL=0b, TNF=001b |
| 1 | 0x02 | 1 | Record Type Length: 2 octets |
| 2 | 0x0a | 1 | Record Type Length: 10 octets |
| 3 | 0x48 0x73 | 2 | Record Type: “Hs” |
| 5 | 0x12 | 1 | Version Number: Major = 1, Minor = 2 |
| 6 | 0xd1 | 1 | NDEF Record Header: MB=1b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=001b |
| 7 | 0x02 | 1 | Record Type Length: 2 octets |
| 8 | 0x04 | 1 | Payload Length: 4 octets |
| 9 | 0x61 0x63 | 2 | Record Type: “ac” |
| 11 | 0x03 | 1 | Carrier Flags: CPS=3, "unknown" |
| 12 | 0x01 | 1 | Carrier Data Reference: "0" |
| 13 | 0x30 | 1 | Carrier Data Reference Count: 0 |
| 14 | 0x00 | 1 | Auxiliary Data Reference Count: 0 |
| 15 | 0x5a | 1 | NDEF Record Header: MB=0b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=010b |
| 16 | 0x20 | 1 | Record Type Name Length: 32 octets |
| 17 | 0x26 | 1 | Payload Length: 38 octets |
| 18 | 0x61 0x70 0x70 0x6C 0x69 0x63 0x61 0x74 0x69 0x6F 0x6E 0x2F 0x76 0x6E 0x64 0x2E 0x62 0x6C 0x75 0x65 0x74 0x6F 0x6F 0x74 0x68 0x2E 0x65 0x70 0x2E 0x6F 0x6F 0x62 |
32 | Record Type Name: 'application/vnd.bluetooth.ep.oob' |
| 50 | 0x26 0x00 | 2 | Bluetooth OOB data length: 38 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. |
| 52 | 6 | Bluetooth device MAC address: 20:73:00:00:66:4c These bytes must be stored in little-endian order in the pairing data blob. For this example it its “4c 66 00 00 73 20” . |
|
| 58 | 0x18 | 1 | EIR Data Length: 24 octets |
| 59 | 0x09 | 1 | EIR Data Type: 0x09 |
0x43 0x6f 0x6e 0x74 0x6f 0x73 0x6f 0x20 0x42 0x6c 0x75 0x65 0x74 0x6f 0x6f 0x74 0x68 0x20 0x4d 0x6f 0x75 0x73 0x65 |
23 | Device friendly name in UTF-8.
Note There is no NULL terminating character and UTF-8 may use one or two bytes per character.
This example reads “Contoso Bluetooth Mouse". |
|
| 83 | 0x04 | 1 | EIR Data Length: 4 octets |
| 84 | 0x0e | 1 | EIR Data Type: 0x0e |
| 85 | 0x80 0x05 0x00 | 3 | Class of device: 0x000580 These bytes must be stored in little-endian order in the pairing data blob. For this example it is “0x000580”, which is the CoD type for a “HID-mouse”. |
Bluetooth Connectivity Requirements
In wiring up the NFC tag with the Bluetooth stack in a HID device, it is required that the Bluetooth radio be put into the connectable mode instead of in the discovery mode when a read of the NFC tag is detected. Windows uses the page procedure to perform SSP OOB pairing in-band.
Handling Special 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 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 computer will not look for the device. In this case, there will be no consent UI from the computer 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.
If a pairing button is pressed (or similar mechanism use) in the middle of pairing via NFP, the device may become discoverable again and the system pairing will not be successful. Tapping again will pair the device.
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.