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 Reconnect use 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 “app/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 “app/vnd.bluetooth.ep.oob”). In this method, only the PAYLOAD of the “app/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

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

76543210
MBMECFSRILTNF(2)TNF(1)TNF(0)

 

FlagDescriptionValue (in binary)Notes
MBMessage Begin1 – start of an NDEF recordDefined by NDEF; must be 1 for Windows
MEMessage End1 – end of an NDEF recordDefined by NDEF; must be 1 for Windows
CFChunk Flag0 – the only and the termination chunk of an NDEF recordDefined by NDEF; must be 0 for Windows
SRShort Record1 – PLAYLOAD_LENGTH field is a single octet for setting length of a record that is less or equal to 256 bytesDefined by NDEF; a short record (1) is recommended for this field.
ILID_LENGTH field is present 0 – ID_LENGTH field is not presentDefined by NDEF; a short record (1) recommended for this field.
TNFType Name Format001 (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 Header1 byte (see previous table)
Record Type Name Length1 byte
Payload Length

1 byte (for short record)

4 bytes (for long record)

Payload ID LengthThis field is not present if the IL flag is 0
Record Type NameNumber of bytes specified in “Payload Type Name Length”
IDID 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

NameSection typeSize (octets)Required or OptionalDescription
OOB Data Lengthn/a2RequiredDefined by NDEF; must be 1 for Windows 8
Bluetooth Device Addressn/a6RequiredDefined by NDEF; must be 1 for Windows 8

 

OOB Data fields for BR/EDR devices:

NameSection typeSize (octets)Required or OptionalDescription
Class of Service (CoD)0x0d3RequiredDefined by NDEF; must be 0 for Windows
Local Name0x09VariableRequired

Windows uses the value in user consent UI. Windows Bluetooth provider reads the COD value in the format of:

(COD_PERIPHERAL_MINOR_POINTER_MASK 
<< COD_MINOR_BIT_OFFSET) |
(COD_MAJOR_PERIPHERAL <<
COD_MAJOR_BIT_OFFSET) |
(COD_LIMITED_SERVER <<
COD_SERVICE_BIT_OFFSET).

Refer to bthdef.h in Windows SDK.

Simple Pairing Hash C0x0e1OptionalWindows uses the value in pairing UI.
Simple Pairing Randomizer R0x0f1OptionalThe 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].

OffsetContentLengthExplanation
00x021

NDEF Record Header:

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

10x201Record Type Name Length: 32 octets
20x4a1Payload 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

32Record Type Name: 'app/vnd.bluetooth.ep.oob'
350x4a 0x002

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

430x181EIR Data Length: 24 octets
440x091EIR 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".

680x041EIR Data Length: 4 octets
690x0e1EIR Data Type: 0x0E
700x80 0x05 0x003

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

730x111EIR Data Length: 17 octets
740x0e1EIR Data Type: 0x0e
75

0x30 0x31 0x32 0x33

0x34 0x35 0x36 0x37

0x38 0x39 0x3a 0x3b

0x3c 0x3d 0x3e 0x3f

16SSP Hash value
910x111EIR Data Length: 17 octets
920x0e1EIR Data Type:0x0e
93

0x40 0x41 0x42 0x43

0x44 0x45 0x46 0x47

0x48 0x49 0x4a 0x4b

0x4c 0x4d 0x4e 0x4f

16SSP 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].

OffsetContentLengthExplanation
00x021

NDEF Record Header:

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

10x201Record Type Name Length: 32 octets
20x261Payload 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

32Record Type Name: 'app/vnd.bluetooth.ep.oob'
350x26 0x002

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

430x181EIR Data Length: 24 octets
440x091EIR 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".

680x041EIR Data Length: 4 octets
690x0e1EIR Data Type: 0x0e
700x80 0x05 0x003

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

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”
110x031Carrier Flags: CPS=3, "unknown"
120x011Carrier Data Reference: "0"
130x301Carrier Data Reference Count: 0
140x001Auxiliary Data Reference Count: 0
150x5a1

NDEF Record Header:

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

160x201Record Type Name Length: 32 octets
170x261Payload 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

32Record Type Name: 'app/vnd.bluetooth.ep.oob'
500x26 0x002

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.

526

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

580x181EIR Data Length: 24 octets
590x091EIR 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".

830x041EIR Data Length: 4 octets
840x0e1EIR Data Type: 0x0e
850x80 0x05 0x003

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.

 

 

Send comments about this topic to Microsoft

表示:
© 2014 Microsoft