Bluetooth Stack Partitioning:
host controller - Bluetooth hardware
Bluetooth host - the PC
HCI - Host Controller Interface
Pairing:
Pairing is the process of establish the right to make a connection. Once the units have been paired and provided the paired unit is "trusted" then connecting becomes automatic. Otherwise you must respond each time an attempt is made to connect that it is ok. Keeping the unit in a connected state makes it easy and convenient to accept calls but you do pay for the higher battery drainage.
Pairing is also and act of exchanging of authentication key.
Inquiry Procedure:
The inquiry procedure enables a device to discover which devices are in range, and determine the addresses and clocks for the devices. The inquiry procedure involve a unit (the source)sending out inquiry packets (inquiry state) and then receiving the inquiry reply .The unit that receives the inquiry packets (the destination), will hopefully be in the inquiry scan state to receive the inquiry packets. The destination will then enter the inquiry response state and send an inquiry reply to the source. After the inquiry procedure has completed, a connection can be established using the paging procedure.
Paging Procedure:
With the paging procedure, an actual connection can be established. The paging procedure typically follows the inquiry procedure. Only the Bluetooth device address is required to set up a connection. Knowledge about the clock (clock estimate) will accelerate the setup procedure. A unit that establishes a connection will carry out a page procedure and will automatically be the master of the connection. The procedure occurs as follows:
1: A device (the source) pages another device (the destination ) : Page state
2: The destination receives the page : Page Scan state
3: The destination sends a reply to the source. : Slave Response state: Step 1
4: The source sends an FHS packet to the destination : Master Response state: Step 1
5: The destination sends it's second reply to the source. : Slave Response state : Step 2
6: The destination & source then switch to the source channel parameters :Master Response state: Step 2 & Slave Response state: Step 3
Bluetooth Protocol:
On Linux, I use Bluez, an open source implementation of Bluetooth protocol. Bluez will run a daemon called bluetoothd, kernel modules called rfcomm, bluetooth, bnep, etc. Bluez is used for receiving and sending the Bluetooth messages.
MCAP - Multi Channel Adaptation Protocol. It is used by HDP. It facilitates the creation of communication link for exchanging commands, and data links to transfer actual Medical Device data. MCAP guarantees reliable transmission of data.
SDP - Service Discovery Protocol. It is used by all Bluetooth profiles to discover available services on remote devices, so that connections over L2CAP can be established.
L2CAP - Logical Link Control and Adaption Protocol. It supports protocol multiplexing, packet segmentation and re-assembly, quality of service, re-transmission, flow control. It is only used for ACL link.
Bluetooth Profile:
It is an interface specification, resides on top of the Bluetooth core specification.
It specifies:
- user interface formats
- specific parts of Bluetooth protocol stack used by the profile
Eg.
Advanced Audio Distribution Profile - A2DP. It defines how high quality audio can be streamed from one device to another over a Bluetooth connection. For example, music can be streamed from a mobile phone to a wireless headset.
Health Device Profile - HDP. It is designed to facilitate transmission and reception of Medical Device data. It also performs SDP behavior, to connect to remote HDP devices.
Serial Port Profile - SPP. It is used to simulate RS-232
Generic Access Profile - GAP. It describes the required features of all Bluetooth profiles, including inquiry, connection, authentication procedures.
Device ID Profile - DIP. It provides device specific information through use of the SDP. If vendor specific info is required, this profile provides specific way to acquire this info. It enables identification of the manufacturer, product id, product version. It is useful in allowing a PC to identify a connecting device and download appropriate drivers.
Bluetooth Power Class:
class 1: long range (100m)
class 3: long range (10m)
class 3: long range (10cm)
Bluetooth CoD:
class 0xSSDDdd (three bytes)
The default CoD (Class of Device) is 0x000100 which simply stands for "Computer".
The Bluetooth device class is a high-level description of the bluetooth device, composed of three bytes: the "Major Service Class" (byte "SS" above), the "Major Device Class" (byte "DD" above) and the "Minor Device Class" (byte "dd" above). These classes describe the high-level capabilities of the device, such as "Networking Device", "Computer", etc. This information is often used by clients who are looking for a certain type of service around them.
Where it becomes tricky is that another type of mechanism for service discovery exists: "SDP", as in "Service Discovery Protocol".
In practice, most Bluetooth clients scan their surroundings in two successive steps: they first look for all bluetooth devices around them and find out their "class". You can do this on Linux with the hcitool scan command. Then, they use SDP in order to check if a device in a given class offers the type of service that they want.
Bluetooth Master/Slave:
It is not possible to detrmine bluetooth master or slave programatically.The master/slave roles which a device assumes is invisible to the user(application).The same device can act as a master of one piconet and a slave in an (adjacent) piconet.What needs to be decided in your application is whether the device will act as a client or a server or both and what will be the services(profiles) that it supports.
Bluetooth FH:
All Bluetooth devices participating in a given piconet are synchronized to the frequency-hopping channel for the piconet. The frequency hopping sequence is determined by the master's device address and the phase of the hopping sequence (the frequency to hop at a specific time) is determined by the master's internal clock. Therefore, all slaves in a piconet must know the master's device address and must synchronize their clocks with the master's clock.
During the connection handshake, the slave receives one packet (FHS, Frequency Hop Synchronization) that contains information about the master's BD_ADDR and the clock, so the slave's internal clock can be synchronized.
Bluetooth State Machine:
Bluetooth device can move from one state to a new state.
Bluetooth VDP
Vena Dongle Protocol (VDP) is an application protocol between Bluecore module and host microprocessor.
The root cause is because the oximeter sends out LMP "not_accepted" in response to the LMP "au_rand" message from Bluetooth module. Here is the message trace in terms of LMP opcode. The "not_accepted" message is the 2nd last message.
au_rand contains a random number that is encrypted by link key. When au_rand is not accepted, meaning the oximeter cannot compute the same number using the link key, meaning the oximeter link key database is corrupted
BT Module Oximeter
-------------- ------------------
host_connection_req
version_req
version_res
features_req
features_res
slot_offset
switch_req
accepted
accepted
feature_req
SET_AFH
setup_complete
feature_res
channel_classification
setup_complete
timing_accuracy_req
max_slot
max_slot_req
channel_classification
timing_accuracy_res
accepted
max_slot_req
feature_req
feature_res
accepted
au_rand
not accepted
detach
K is link key, E is Bluetooth authentication function. The oximeter receives the AU_RAND and sends back SRES as response.
When oximeter sends not_accepted after it receives au-rand, meaning the oximeter link key database is corrupted.
The behavior in this case is up to the Bluetooth module requesting the authentication. It can demand a new pairing by sending LMP in_rand, or it can refuse the connection and sends LMP detach. So for the Bluetooth module, the Bluez stack simply detach the link.
So we need to modify Bluez stack for solving this "Oximeter takes measurement but no data is transmitted" problem.
Payload Format
ACL
Asynchronous Connectionless Link. One of the two types of data links defined for the Bluetooth Systems, it is an asynchronous (packet-switched) connection between two devices created on the LMP level. This type of link is used primarily to transmit ACL packet data. The ACL link is a point-to-multipoint link between the master and all the slaves participating on the piconet. In the slots not reserved for the SCO links, the master can establish an ACL link on a per-slot basis to any slave, including the slave already engaged in an SCO link. Only a single ACL link can exist. For most ACL packets, packet retransmission is applied.
SCO
Synchronous Connection-Oriented. The SCO link is a symmetric point-to-point link between a master and a single slave in the piconet. The master maintains the SCO link by using reserved slots at regular intervals (circuit switched type). The SCO link mainly carries voice information. The master can support up to three simultaneous SCO links while slaves can support two or three SCO links. SCO packets are never retransmitted. SCO packets are used for 64 kB/s speech transmission.
DM
Data - Medium Rate. An ACL link data packet type for medium rate data. DM1 packets carry information data only, contining a 16-bit CRC code and up to 18 info bytes. They are encoded using 2/3 FEC and the packet can cover up to a single time slot. DM3 packets are the same except they can cover up to 3 time slots, and can carry up to 123 info bytes. DM5 packets are the same again except they can cover up to 5 time slots and can hold up to 226 info bytes. See also Bluetooth.
DH
Data-High Rate. An ACL link data packet type for high rate data. DH1 packets are similar to DM1 packets, except the info in the payload is not FEC encoded. This means the DH1 packet can carry up to 28 info bytes and covers a single time slot. The DH3 is the same except it can cover up to 3 time slots and contain up to 185 info bytes. The DH5 packet is the same again except it can cover up to 5 time slots and contains up to 341 info bytes See also Bluetooth packet types.
Bluetooth D-Bus commands:
Bluetooth CoD:
class 0xSSDDdd (three bytes)
The default CoD (Class of Device) is 0x000100 which simply stands for "Computer".
The Bluetooth device class is a high-level description of the bluetooth device, composed of three bytes: the "Major Service Class" (byte "SS" above), the "Major Device Class" (byte "DD" above) and the "Minor Device Class" (byte "dd" above). These classes describe the high-level capabilities of the device, such as "Networking Device", "Computer", etc. This information is often used by clients who are looking for a certain type of service around them.
Where it becomes tricky is that another type of mechanism for service discovery exists: "SDP", as in "Service Discovery Protocol".
In practice, most Bluetooth clients scan their surroundings in two successive steps: they first look for all bluetooth devices around them and find out their "class". You can do this on Linux with the hcitool scan command. Then, they use SDP in order to check if a device in a given class offers the type of service that they want.
Bluetooth Master/Slave:
It is not possible to detrmine bluetooth master or slave programatically.The master/slave roles which a device assumes is invisible to the user(application).The same device can act as a master of one piconet and a slave in an (adjacent) piconet.What needs to be decided in your application is whether the device will act as a client or a server or both and what will be the services(profiles) that it supports.
Bluetooth FH:
All Bluetooth devices participating in a given piconet are synchronized to the frequency-hopping channel for the piconet. The frequency hopping sequence is determined by the master's device address and the phase of the hopping sequence (the frequency to hop at a specific time) is determined by the master's internal clock. Therefore, all slaves in a piconet must know the master's device address and must synchronize their clocks with the master's clock.
During the connection handshake, the slave receives one packet (FHS, Frequency Hop Synchronization) that contains information about the master's BD_ADDR and the clock, so the slave's internal clock can be synchronized.
Bluetooth State Machine:
Bluetooth device can move from one state to a new state.
Bluetooth VDP
Vena Dongle Protocol (VDP) is an application protocol between Bluecore module and host microprocessor.
Host micro without IEEE11073 stack
Host micro with IEEE11073 stack
The messages that are carried across VDP link:
1. HDP messages
2. SPP messages for accessing legacy devices
3, Bluetooth device discovery, device pairing control packets.
Bluetooth Link Management Protocol (LMP)
In the usage of Nonin Oximeter, we have a problem where Oximeter fails to transmit measurement data to Bluetooth module after using for some time.
au_rand contains a random number that is encrypted by link key. When au_rand is not accepted, meaning the oximeter cannot compute the same number using the link key, meaning the oximeter link key database is corrupted
BT Module Oximeter
-------------- ------------------
host_connection_req
version_req
version_res
features_req
features_res
slot_offset
switch_req
accepted
accepted
feature_req
SET_AFH
setup_complete
feature_res
channel_classification
setup_complete
timing_accuracy_req
max_slot
max_slot_req
channel_classification
timing_accuracy_res
accepted
max_slot_req
feature_req
feature_res
accepted
au_rand
not accepted
detach
In normal operation, Bluetooth module challenges oximeter by sending the random 128-bit value AU_RAND and expects from oximeter the response:
SRES = E(K, AU_RAND, BD_ADDR_OXIMETER) K is link key, E is Bluetooth authentication function. The oximeter receives the AU_RAND and sends back SRES as response.
When oximeter sends not_accepted after it receives au-rand, meaning the oximeter link key database is corrupted.
The behavior in this case is up to the Bluetooth module requesting the authentication. It can demand a new pairing by sending LMP in_rand, or it can refuse the connection and sends LMP detach. So for the Bluetooth module, the Bluez stack simply detach the link.
So we need to modify Bluez stack for solving this "Oximeter takes measurement but no data is transmitted" problem.
Bluetooth Packet Format
This is a standard Bluetooth packet:
| ACCESS CODE [72] | HEADER [54] | PAYLOAD [0-2745] |
| ACCESS CODE | Access code is used for synchronization, DC offset compensation and identification. |
| HEADER | Header contains link control (LC) information. |
| PAYLOAD | Payload carries voice and data fields of upper layers. |
Payload Format
| HEADER [8-16] | BODY [Indicated in header] | CRC CODE [16] |
| HEADER | Header is one or 2 bytes longer. Only data fields have a payload header. |
| BODY | Payload body includes the user host information. The length os the body is indicated in the length field of the payload header. |
| CRC CODE | The 16-bit cyclic redundancy check code is generated by the CRC-CCITT polynomial 210041 (octal). |
ACL
Asynchronous Connectionless Link. One of the two types of data links defined for the Bluetooth Systems, it is an asynchronous (packet-switched) connection between two devices created on the LMP level. This type of link is used primarily to transmit ACL packet data. The ACL link is a point-to-multipoint link between the master and all the slaves participating on the piconet. In the slots not reserved for the SCO links, the master can establish an ACL link on a per-slot basis to any slave, including the slave already engaged in an SCO link. Only a single ACL link can exist. For most ACL packets, packet retransmission is applied.
SCO
Synchronous Connection-Oriented. The SCO link is a symmetric point-to-point link between a master and a single slave in the piconet. The master maintains the SCO link by using reserved slots at regular intervals (circuit switched type). The SCO link mainly carries voice information. The master can support up to three simultaneous SCO links while slaves can support two or three SCO links. SCO packets are never retransmitted. SCO packets are used for 64 kB/s speech transmission.
DM
Data - Medium Rate. An ACL link data packet type for medium rate data. DM1 packets carry information data only, contining a 16-bit CRC code and up to 18 info bytes. They are encoded using 2/3 FEC and the packet can cover up to a single time slot. DM3 packets are the same except they can cover up to 3 time slots, and can carry up to 123 info bytes. DM5 packets are the same again except they can cover up to 5 time slots and can hold up to 226 info bytes. See also Bluetooth.
DH
Data-High Rate. An ACL link data packet type for high rate data. DH1 packets are similar to DM1 packets, except the info in the payload is not FEC encoded. This means the DH1 packet can carry up to 28 info bytes and covers a single time slot. The DH3 is the same except it can cover up to 3 time slots and contain up to 185 info bytes. The DH5 packet is the same again except it can cover up to 5 time slots and contains up to 341 info bytes See also Bluetooth packet types.
Bluetooth D-Bus commands:
Bluez:
dbus-send --system --type=method_call --print-reply --dest=org.bluez / org.freedesktop.DBus.Introspectable.Introspect
dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez org.freedesktop.DBus.Introspectable.Introspect
dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/690/hci0 org.bluez.Adapter.RemoveDevice objpath:/org/bluez/690/hci0/dev_00_1C_05_00_4A_AD
dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/1282/hci0 org.bluez.Adapter.ListDevices
dbus-send --system --type=method_call --print-reply --dest=org.bluez / org.bluez.Manager.FindAdapter string:hci0
dbus-send --system --type=method_call --print-reply --dest=org.bluez / org.bluez.Manager.ListAdapters
Antidote Healthd:
dbus-send --system --type=method_call --print-reply --dest=com.signove.health /com/signove/health org.freedesktop.DBus.Introspectable.Introspect
Bluetooth IEEE11073
IEEE11073 is an Bluetooth application layer protocol, used by HDP devices. IEEE11073 specifies the formats and standards that HDP devices use to send messages. The standard itself is long winded and talking about it is time consuming. IEEE11073 is promoted by the Continua Alliance.
On Linux, I use Antidote, an open source implementation of IEEE11073. It is developed by Signove Technologies. It is written in C.
As an example, we can sniff an Bluetooth Nonin 9560BT Oximeter. Oximeter is set as Master. Bluetooth host is slave. If encrypted data that is captured is in error, we need to look at these LMP frames.
LMP_in_rand
LMP_accepted
LMP_comb_key
If these LMP frames are missing, we need to delete the oximeter device from Bluetooth database, then re-pair the device. It is because the link key is generated at local and remote devices during pairing stage. If devices are already paired, then link key generation won't be performed by the devices (link key is saved in devices already), and sniffer won't be able to capture the link key, and can't decrypt the bluetooth packets.
The IEEE11073 message exchange is shown below.
Link Management (LM):
The LM assists in the pairing procedure by communicating parameters and results between the local and remote Bluetooth devices. The calculations are done in the baseband. On the link manager level, the pairing procedure starts with the transmission of the PDU LMP_in_rand (containing the 128-bit random number
IN_RAND) from one of the units to the other. This PDU will trigger the generation of the initialization key for use in the protocol for creating the actual link key. If a unit key is to be used, the LMP unit key
command is sent in one direction only, with the secret unit key XORed with the initialization key as its parameter. The receiver can easily calculate the key from this. If a combination key is to be created, two contributions (one from each side) are needed. This is accomplished through the LMP_comb_key PDU. The argument of this PDU is also a random number, but generating this and deriving the link key from it is slightly more complicated.
After these PDUs have been exchanged, both ends are able to compute the link key. As a final check of success of this procedure and the established link key, a mutual authentication event is performed. A 128-bit challenge is sent through the LMP_au_rand , and the 32-bit response uses the LMP sres PDU. If these authentications do not fail, both the local and the remote Host Controller notify their respective hosts.
Click on the image below to see the link key exchanges.
Bluetooth IEEE11073
IEEE11073 is an Bluetooth application layer protocol, used by HDP devices. IEEE11073 specifies the formats and standards that HDP devices use to send messages. The standard itself is long winded and talking about it is time consuming. IEEE11073 is promoted by the Continua Alliance.
On Linux, I use Antidote, an open source implementation of IEEE11073. It is developed by Signove Technologies. It is written in C.
As an example, we can sniff an Bluetooth Nonin 9560BT Oximeter. Oximeter is set as Master. Bluetooth host is slave. If encrypted data that is captured is in error, we need to look at these LMP frames.
LMP_in_rand
LMP_accepted
LMP_comb_key
If these LMP frames are missing, we need to delete the oximeter device from Bluetooth database, then re-pair the device. It is because the link key is generated at local and remote devices during pairing stage. If devices are already paired, then link key generation won't be performed by the devices (link key is saved in devices already), and sniffer won't be able to capture the link key, and can't decrypt the bluetooth packets.
The IEEE11073 message exchange is shown below.
Link Management (LM):
The LM assists in the pairing procedure by communicating parameters and results between the local and remote Bluetooth devices. The calculations are done in the baseband. On the link manager level, the pairing procedure starts with the transmission of the PDU LMP_in_rand (containing the 128-bit random number
IN_RAND) from one of the units to the other. This PDU will trigger the generation of the initialization key for use in the protocol for creating the actual link key. If a unit key is to be used, the LMP unit key
command is sent in one direction only, with the secret unit key XORed with the initialization key as its parameter. The receiver can easily calculate the key from this. If a combination key is to be created, two contributions (one from each side) are needed. This is accomplished through the LMP_comb_key PDU. The argument of this PDU is also a random number, but generating this and deriving the link key from it is slightly more complicated.
After these PDUs have been exchanged, both ends are able to compute the link key. As a final check of success of this procedure and the established link key, a mutual authentication event is performed. A 128-bit challenge is sent through the LMP_au_rand , and the 32-bit response uses the LMP sres PDU. If these authentications do not fail, both the local and the remote Host Controller notify their respective hosts.
Click on the image below to see the link key exchanges.
