Imagine you could expand the Advertise-Scan design patterns that Bluetooth uses for device discovery to your non-Bluetooth devices, such as the printer in the office or other audio/video devices running Wi-Fi at home. Now you can with the newly introduced Bluetooth Transport Discovery Service (TDS). This service, using Bluetooth, acts as a uniform device discovery mechanism for other wireless transport technologies, including Wi-Fi.

Why do we need another Bluetooth service?

Every one of the existing wireless communication transports has a design focused on certain user scenarios. Bluetooth has a well-designed Generic Access Profile and Generic Attribute Profile at the application layer which provides a powerful yet straightforward service discovery procedure and protocol. While device discovery is a key component of the Bluetooth protocol, other wireless protocols aren’t necessarily designed with these features in mind. With Bluetooth TDS, we combine the rich device discovery features of Bluetooth to provide an enhanced user experience, leveraging Bluetooth’s device discovery features while utilizing the strengths of other protocols for their purpose-specific communication mechanisms. For example, Bluetooth TDS could help on service discovery and connection initialization between two Wi-Fi devices.  After the devices have used TDS to discover each other, communications will be handed over to Wi-Fi to send the actual communication data. When there’s no data exchange, the device can simply turn off Wi-Fi to save energy and let Bluetooth handle the service advertising and discovery.

Looking at the Technical Details of the Transport Discovery Service

The service contains 2 parts: a new TDS AD type and a characteristic for the TDS control point.

• TDS AD type

The device with a TDS service will be using a new AD type: TDS AD type. A service seeker will be using this information in the Bluetooth advertisement packet to discover the transport services.  This AD type will be in the advertisement packets’ Protocol Data Unit (PDU). It will have the following fields:

• TDS AD Type code.
• Organization ID
• TDS flags
• Transport Data Length
• Transport Data
• TDS control-point characteristic

This characteristic is used to request activation of a transport. When a second transport (for example, Wi-Fi) is turned off, we can use this Bluetooth characteristic to turn it on. The client can send a TDS Op Code over Bluetooth to the server and the server will set the desired transport to a connection-ready state and send the indication to the client with either “Success” or “Failure” result. Then the client and server can start a transport-specific connection procedure.

Figure 1: Example flow of TDS Control Point

Using Bluetooth Developer Studio to Design the TDS Service

Now developers can use the Bluetooth Developer Studio to design and implement this TDS service.

Here’s a screenshot of the finished TDS service with TDS control point characteristic.

With this new service, developers can have consistent device discovery mechanism across all protocols and transports that use an established standards-based discovery procedure already utilized by billions of devices. Applications can provide a unified user experience on device discovery and connection. WithTDS, our customers are a step closer to the ubiquitous, all-connected, IoT world. We are looking forward to seeing more adoptions of this service soon.

(Credit: Vincent Gao)