Some things in this description have been simplified to the point of being imprecise, but others may be outright wrong; please report errors not already in the "to be precise..." page to email@example.com.
Contrary to how it looks to a user, a low-level bluetooth connection is not point-to-point, but rather one-to-many, with one master and up to seven slaves. This is a piconet.
A device can be a master of only one piconet, but at the same time may be the slave of many other piconets. This happens, for example, when a computer equipped with a USB dongle wants to connect to a mobile that is already connected to an headset.
In this initial configuration, the mobile is the master of the piconet that contains only it and the headset (the arrow is from the master to the slave). The connection between the mobile and the computer can be started by either of the two.
|The computer enters the piconet where the mobile is master, and becomes its second slave.|
|A new piconet is established, where the computer is the master and the mobile is the slave. The mobile remains the master of the piconet comprising it and the headset.|
Every dongle, mobile, headset, etc. has an identifier called BDADDR (bluetooth device address), of the form 21:4E:27:00:91:EA.
It generally also has a friendly name, like "john's phone" or "nokia6125".
Once in a piconet, a device also has a piconet address LTADDR, a number from 1 to 7.
This is the process of discovering which devices are in the range of radio communication. Of each, the inquiry process returns only:
For example, if the mobile wants to find out which devices are in range, it starts by sending an inquiry request. This is a message that is not directed to a specific device, and in particular not only to the devices that are already in a piconet with the mobile.
If another mobile in range is "visible" or "temporarily visible", it answers to the inquiry. For the computer, hciconfig hci0 iscan makes it answer to inquiries (this is the command to make a computer answer inquiries under Linux with the bluez libraries and tools). In this case, the computer answers with its BDADDR, CoD and other parameters that the mobile later uses for forming a piconet with the computer.
The inquiry process ends here. The mobile has acquired the BDADDR of the computer but not its friendly name. This is done in another step.
"To page" means "to call".
The page scan process is a procedure that makes the called device enter the piconet of the caller. In the example, the mobile knows the BDADDR of the computer and the other parameters needed for connecting from the resut of the inquiry, so it can start paging (calling) the computer.
If the computer is configured to accept page requests (e.g., hciconfig hci0 pscan), it answers the call. The paging procedure continue with an exchange of messages.
At the end of paging, the computer is a slave in the piconet of the mobile.
In summary, a device pages another to make it enter its piconet. If successful, at the end of the procedure the device that started paging is the master and the called device a slave of the piconet.
When the user of the mobile starts a discovery of the devices in range, for example for sending a picture to the computer via Bluetooth, several things happen:
As a result of the paging procedure, the paged device acquires an access code (a number) shared with all other devices in the piconet and is assigned a unique number from 1 to 7. This way, all devices in the piconet share the access code, and each slave is assigned a different number from 1 to 7 called LTADDR.
Continuing the example, after the mobile has successfully paged the computer, that may be assigned LTADDR=2, while the previously connected headset has LTADDR=1. All three devices share the piconet access code, for example AC=51F3 (in reality, the access code is a longer number, here a four-digit one is used for the sake of simplicity).
Communication is always initiated by the master, in this example the mobile. Since data is trasmitted over the air, it is received by all slaves. Also devices that are not in this piconet may receive a packet [technical note], but they discard it because of the access code, which is included in all packets and is unique to the piconet. The packet also contains the LTADDR of the slave it is directed to.
For example, the mobile queries the friendly name of the computer by sending a query_name packet that includes LTADDR=2.
Both the computer and the headset receive the packet, and both recognize the access code AC of the piconet, but the headset ignores the packet because it contains LTADDR=2 while its LTADDR is 1. Devices of other piconets that happen to receive the packet discard it because it does not match their AC. The computer knows the packet is directed to it because both its AC and LTADDR match. It answers with another packet containing its name and still LTADDR=2.
Again, the headset receives the packet but discards it because of the LTADDR. The mobile instead finds the packet to come from its piconet because it contains AC=51F3, and is directed to it because slaves interact only with the master. Since LTADDR=2, it was sent by the computer. The included name is therefore the friendly name of the computer.
When a device is a slave in a piconet, the master may send commands to it and receive answers. The packets for querying and answering the friendly name are examples. Other packets are used for establishing a point-to-point connection, which is necessary to perform high-level operations such as exchanging files, requesting phonebook entries, exchange master/slave roles, etc.
Authentication and pairing matter only at this point, when an attempt to establish this connection.
Just because the devices are in the same piconet does not mean that they can exchange files, pictures, phonebook entries, audio, etc. All of this requires additional steps. It only means that the master can send packets to a slave, and the slave can answer.
The packets that are exchanged are of type ACL-C (connection management), ACL-U (data) or SCO (audio). Every packet contains some fields that identify the type (technically, this is not as simple as it looks).
The Link Management Protocol (LMP) creates a point-to-point connection between the master and a slave of the piconet. It uses ACL-C packets. Examples of such packets are:
Only when an attempt to create a connection is done authentication and pairing are checked or established.
After the connection is accepted and possibly authentication or pairing is established, a single data link exists between the master and the slave. Up to three audio channels can be then created, but the data link remains only one. Data is all carried by ACL-U packets.
From the user point of view, Bluetooth can be used for connecting to an headset or a car kit, for sending pictures and phonebook entries, for making the mobile act as a modem, etc. These requires different services. Apart from audio, all data is carried by ACL-U packets exchanged over the single data link between the master and the slave. The L2CAP protocol multiplexes them to the appropriate services.
The ACL-U packets have three fields [technical note: this is for connection-oriented links, basic mode], apart the access code, etc.:
At the beginning, only packets with channelID=1 are accepted. These packets are used to create other channels between the two devices, so that for example packets for sending files have channelID=12, packets for telling the mobile to call the number for an Internet connection is channelID=32, etc. The packets with channelID=1 are:
The name "channelID" is misleading, in that it is more like a TCP port than the identifier of a channel. Indeed, the packets of a channel may have a channelID in a direction and a different channelID in the other. For example, the packet for requesting a file may have channelID=4 and the packet containing the file channelID=9.
This channel uses the pair of channelIDs 4,9. Another channel may for example use 13,2. Yet another may use 8,7. Each channel has two ChannelIDs, one for the packets sent from the master and one for the packets sent from the slave.
Having multiple channels allow for different services being offered by the same device, for example:
For example, the PAN service may use ChannelID=6 in one direction and ChannelID=2 in the other, while SIM access uses 4 and 2. A further complication is that many services are based on RFCOMM, which uses a single pair of channelIDs and does its own multiplexing.
One of the uses of a channel is to serve as a serial link, where either device sends and receives data. This is done by RFCOMM. Most services are based on it, two exceptions being SDP and PAN. All other services listed above use RFCOMM: OBEX push and ftp, DUN, SyncML, SIM access, Phonebook access.
RFCOMM uses a single L2CAP channel, so two ChannelIDs (one for packets from the master and one for packets from the slave). For example, sending pictures (OBEX push), requesting phonebook entries (Phonebook access), using the mobile as a modem (dial-up networking) and synchronizing (SyncML) all use the same L2CAP channel. RFCOMM multiplexes this single L2CAP channel to all these services.
For example, if the mobile starts a synchronization session with the computer, an L2CAP channel is created; this means two ChannelIDs, for example 4 and 9. All packets used for synchronization contain ChannelID 4 or 9 depending on the direction. If the mobile sends a picture (OBEX push) before synchronization is over, this takes place using the same L2CAP channel, still with ChannelID 4 and 9.
To distinguish the packets of different services, they contain another number, the RFCOMM channel. For example, synchronization may use RFCOMM channel 21 while OBEX push may use RFCOMM channel 14. These RFCOMM channels have nothing to do with the L2CAP channel: the packets that contain for example a synchronization alert and the name of a file that is being sent (pushed) both contain ChannelID=4, but also contain a different RFCOMM channel number.
All packets of all services based on RFCOMM use the same pair of ChannelIDs, but they differ on their RFCOMM channel. Contrary to ChannelIDs, the RFCOMM channel is the same in both directions. In the example, while packets for synchronization have ChannelID=4 when sent by the mobile and ChannelID=9 when sent by the computer, they all have RFCOMMCHan=21.
OBEX (OBject EXchange) is a protocol for exchanging objects. It uses RFCOMM. The same mobile may provide many services that use OBEX at the same time, on different RFCOMM channels. For example:
OBEX is based on RFCOMM, so every OBEX service runs on an RFCOMM channel. Some services use RFCOMM but not OBEX; for example: dial-up networking, SIM access. Some other services use neither, like the personal area network service.
The RFCOMM channels are not fixed. Contrary to HTTP, which uses TCP port 80 by default, the RFCOMM channels depend on the specific device. For example, a mobile may receive files (OBEX push service) on RFCOMM channel 9, while another does it on channel 8 and a computer on channel 11. A headset usually does not provide such a service at all.
The services a device provides can be queried with the Service Discovery Protocol. For example, the mobile may ask the computer whether it supports OBEX push, and its RFCOMM channel if it does. A mobile with can be queried for its services from a computer with a bluezlib tool; for example, if the BDADDR of the mobile is 21:4E:27:00:91:EA:
sdptool browse 21:4E:27:00:91:EA