- Introduction
- What Are Bluetooth Profiles?
- Developing Bluetooth Applications
- Understanding the Bluetooth Protocol Stack
- Interoperability
- Qualification
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Understanding the Bluetooth Protocol Stack
Many companies have invested considerable effort in developing Bluetooth protocol stack solutions, which can be purchased off the shelf or tailored for a particular project, where minimum development effort is required; numerous companies have also offered Open Source2 solutions. With a solid foundation in a Software Development Kit (SDK), developers can realise their specific applications with greater speed and economic efficiency. Solutions can be tailored for Microsoft Windows or Linux-based operating systems as well as embedded platforms. In the following sections, we analyse in some more detail the relationship of the Profile and Protocol and further understand the interaction between the host and host controller.
)
Figure 1-5 The MTC-60180 development system from Alcatel Microelectronics. (Courtesy of Alcatel Microelectronics.)
1.4.1 The Profile and the Protocol
In our earlier discussion, we touched upon the purpose and objectives that the Profiles serve. In development terms, the creation of an end-function, is dependent upon the realisation of a Profile specification using the underlying protocol. The Profile addresses the characterisations by stipulating what it expects from the Bluetooth protocol stack. How that application manifests itself to the outside world is also prescribed by the requirement defined in the Profile. With an SDK, a developer may utilise the features of a Bluetooth protocol stack by addressing core functionality through an API. As a company wishing to develop Bluetooth applications, an API may have already been tailored to meet with your specific requirements. In Figure 1-6, we further illustrate the structure of the stack where an API has been imposed upon the key components, in turn exposing core functionality to the application developer.
)
Figure
1-6 The Bluetooth protocol stack exposes APIs throughout, where application
developers utilise these interfaces to realise end-user functionality.
Using Figure 1-6 as our example illustration, APIs such as that illustrated in Table 1-3 and Table 1-4 can be used to control and manipulate core functionality at the heart of the Bluetooth protocol stack.
In Table 1-3 an application may use these APIs in order to quickly establish an RFCOMM connection to its peer device; whereas Table 1-4 illustrates some possible APIs that may be used to learn of the services of devices that are in radio range.
Table 1-3 Some typical APIs that would be used to open and close an RFCOMM connection as well as transmit and receive data over the connection.
| AFI | Description |
| RFCOMM_OpenConnection | An API function that would be used to open or create a communications link with the peer device. |
| RFCOMM_CloseConnection | An API function that would be used to close or disconnect a communications link with the peer device. |
| RFCOMM_TxData | An API function that would be used to transmit data to the peer device. |
| RFCOMM_RxData | An API function that would be used to receive data to the peer device. |
Table 1-4 Some typical APIs that would be used to retrieve service information from a remote device.
| API | Description |
| SDP_ErrorResponse | An API function, which is used to signal an incorrectly formatted requests from the client. |
SDP_ServiceSearchRequest SDP_ServiceSearchResponse |
These APIs are used in combination to instigate a search tequest to identify corresponding records held within a server. |
SDP_ServiceAttributeRequest SDP_ServiceAttributeResponse |
These APIs are used in combination to retrieve specific attribute record information from a server. |
SDP_ServiceSearchAttributeRequest SDP_ServiceSearchAttributeResponse |
Finally, these APIs are used in combination to encompass both the funcionality of the SDP_ServiceSearchRequest and SDP_ServiceAttributeRequest. This funcionality attempts to reduce the SDP trafic when seeking specific services. |
1.4.2 Understanding the Bluetooth Host
The Bluetooth Host is the set of protocol higher-layers provided to manipulate and control the Host Controller; we provide this illustration in Figure 1-7. This interface is controlled through the HCI and most Bluetooth development kits are exposed at this level. Conceptually, the HCI is not a layer, but forms the Hardware Abstract Layer (HAL), where any company's host controller can be plugged into the host and work together transparently; the host can be considered hardware independent.
)
Figure
1-7 An implementation of a host, which forms part of the higher-layers of
the Bluetooth protocol stack.
The HCI has been constructed to facilitate many transport layers to include Universal Serial Bus (USB), Universal Asynchronous Receiver/Transmitter (UART) and RS232. This provides diversity in the availability of development kits where the various applications may differ. In one such example, a USB interface may be provided for the host controller to interact with the host, where a USB dongle is inserted into a notebook device, which houses the host. A connection is established over the USB interface and the host can manipulate and control the host controller that exists on the USB dongle.
1.4.3 Understanding the Bluetooth Host Controller
The Bluetooth Host Controller is the set of protocol lower-layers provided to manipulate and control the radio unit; we provide this illustration in Figure 1-8. The Host Controller is controlled through the HCI, which in turn is responsible for link management and the over the air-interface.
)
Figure
1-8 An implementation of a host controller, which forms part of the
lower-layers of the Bluetooth protocol stack.