In this entry we look into the architecture of Bluetooth a little more.
Stack to Basics
The Bluetooth protocol stack consists of separate layers from the physical radio up to the high level services which enable various uses from headsets to printers and beyond. The lower levels happen below the Host Controller Interface which is the boundary between device drivers and the OS provided APIs.
In a very simplified form the stack looks like this:-
- Services
- RFComm
- L2CAP
- HCI
- Baseband
- Radio
At the bottom the radio level defines the physical radio properties and the actual transmission and receipt of signals. Closely linked to this is the Baseband layer which defines addressing, packet formats and power control.
HCI (Host Controller Interface) is the layer that provides a standard communication with the host operating system. The OS (whether desktop like Windows or macOS or mobile like Android) provides its own API over this. One of the challenges of 32feet.net is to provide a consistent API across these different operating systems.
L2CAP (Logical Link Control and Adaptation Protocol) manages multiplexing of multiple services to the underlying HCI, segmentation and reassembly of packets and quality of service(QoS). Not all OSs expose an API for L2CAP services for app developers.
RFComm (Radio Frequency Communication) provides a simple protocol over L2CAP which emulates the functionality of serial port communication. Operating systems generally expose RFComm functionality via Sockets (similar to IP networking). Essentially once you’ve opened a connection you have the ability to read and write and the socket handles buffering for you.
Profile or Service?
You may see features described as either a profile (Serial Port Profile) or a service. Each profile represents a related group of functionalities, and it can consist of one or more service. Commonly this might be because of separate client and server elements to the service. In most cases the profile is assigned the same UUID as the main service it exposes, but in a few cases, there is a separate UUID for the profile from the related services e.g. Basic Imaging Profile (0x111A) which defines separate services including ImagingResponder (0x111B). Therefore, you would never connect to 0x111A itself.
The services above RFComm start with the most generic – Serial Port Profile which is designed to emulate an RS-232 style serial port connection wirelessly. The other common services fit into a number of broad categories – those based around telephony and audio generally use AT style text commands for control, many of which are based on earlier modem and GSM specifications. For services with audio the RFComm service provides only the control, the audio is carried by a separate SCO (Synchronous Connection-Oriented) link beneath the HCI layer.
Other services used for exchanging data such as contacts, files and photos use the Object Exchange (Obex) protocol over a serial connection. Obex is a very lightweight protocol originally used over IrDA (Infrared) connections to exchange business cards and more. Switching to Bluetooth meant that you could exchange data faster, over longer distances and without having to have the devices pointing exactly at each other! Fun fact: 32feet.net still supports IrDA and OBEX even on Windows 11 if you have an IrDA adaptor!
Bluetooth and .NET
32feet is a .NET library for working with Bluetooth and related personal area networking technologies. When I created it in 2003 it originally contained Bluetooth serial support for Windows CE and desktop Windows along with IrDA and OBEX (Object Exchange). More recently the library has been modernised and Bluetooth LE added, along with support for more platforms. If you would like to get involved there are plenty of opportunities to contribute to the code or documentation as the project expands to new device platforms and functionality. You can also sponsor the project to help move things along.
Next Time
In future posts we will expose some of the common services that you might come across.
In The Hand Ltd 