In What do Bluetooth profiles do?, we looked at the specifications that let different wireless devices communicate, giving them the right functions for the job they are designed to do. However, before the profiles can kick in, there needs to be a more basic level of communication between devices, so that they can talk to each other over the air, at the right frequencies, using the right channels, and finding the right destination stations.
So if you have a more basic problem in getting your Bluetooth equipment to work, maybe you need to delve a bit deeper into the protocols involved.
As per the Bluetooth specification (http://www.bluetooth.org/spec/), everything in Bluetooth runs over the Radio Layer, which defines the operation of the radio transceivers. These work in the 2.4GHz band, and three different device types are defined, based on their power classes, for long (100m), normal (10m) or short (10cm)-range operation. This layer specifies output power, receive sensitivity and frequency-hopping.
Next up the stack is the Baseband Layer, which is analogous to the physical layer of the OSI seven-layer model. It controls device addressing (there are four different types of Bluetooth addresses that a host can have: three that depend on the state of the host in addition to the 48-bit unique device address), channel control (how devices find each other, through inquiry and paging procedures) and power-save operation, and also flow control and synchronisation. Some very basic security measures are also detailed here.
The Link Manager Protocol (LMP) running in a Bluetooth device looks after the link setup and configuration. This is all done by two devices exchanging Protocol Data Units (PDUs). One master and one or more slaves in a Bluetooth grouping make up what’s rather cutely called a piconet — a device can be a slave in multiple overlapping piconets, though only a master in one. It is possible for companies to write their own LMP.
Just up from LMP in the protocol stack is what’s defined as the Host Controller Interface (HCI), which is there to allow command line access to the Baseband Layer and LMP for control and to get at status information. It’s made up of two parts: the HCI firmware, which is part of the actual Bluetooth hardware, and the HCI driver, which is resident within software on the Bluetooth host.
Above the HCI level, but plugging into the Baseband Layer, rather than riding directly over LMP, the Logical Link Control and Adaptation Protocol (L2CAP) provides data services to the higher-level host protocols. It’s at this stage that we finally start to talk about connection-oriented and connectionless services.
L2CAP is where protocol types are first identified, and protocol multiplexing can take place. It masks the lower layers and provides sensible sized packets to higher protocols. The MTU (maximum transmission unit) of the Baseband layer, negotiated by the LMP, is very limited compared with typical wired and other wireless networks: typically a few hundred bytes. This means that L2CAP spends a lot of its time handling segmentation and reassembly tasks. L2CAP also deals with QoS services.
Running over L2CAP, the RFCOMM protocol is what actually makes upper layer protocols think they’re communicating over a wired serial RS-232 interface, so there’s no need for applications to know anything about Bluetooth. Over the top of this you’ll have the likes of your normal PPP and IP traffic, or an AT command structure, or an OBEX implementation for swapping business cards.
Also relying on L2CAP is the Service Discovery Protocol (SDP), to let the applications on your Bluetooth hosts find out which services are available. With Bluetooth being so mobile, and also pretty limited in terms of geographical coverage, this can change quite dynamically. SDP is used by the Service Discovery Profile, which also defines how the discovery process works.
Putting it all together
As with most network troubleshooting, if you can’t get things to communicate the way they should, you’re going to have to start working your way through the layers to determine where the problem lies. With each layer dependant on the one below, you’ll need to understand what to expect at each — there’s no point looking for LMP PDUs with your wireless sniffer if the transmitter output power’s too low to get the signal anywhere.
It’s likely that LMP, HCI and L2CAP are where you might need to focus, since that’s where you start running into options about network services, including things like QoS, but make sure the actual radio part is working first before you get too bogged down in analyser traces.