Bluetooth Structure

Bluetooth is a short-range cable-replacement technology that carries both data and voice. It supports speeds of up to 723Kbps (asymmetric) and 432Kbps (symmetric). Class 3 Bluetooth devices have a range of 10 meters, and Class 1 transmitters can communicate up to 100 meters.

 

Bluetooth is designed to do away with wires that constrict and clutter your environment. It can, for example, turn your wristwatch into a front-end for a bulky Global Positioning System (GPS) hidden inside your backpack. Or it can, for instance, let you navigate a presentation via your handheld. Again, Bluetooth can be the answer if you want your laptop to be a hub that can Internet-enable your Bluetooth-aware MP3 player. If your wristwatch, handheld, laptop, or MP3 player is running Linux, knowledge of the innards of the Linux Bluetooth stack will help you extract maximum mileage out of your device.

 

As per the Bluetooth specification, the protocol stack consists of the layers shown in Figure 16.1 . The radio, link controller, and link manager roughly correspond to the physical, data link, and network layers in the Open Systems Interconnect (OSI) standard reference model. The Host Control Interface (HCI) is the protocol that

carries data to/from the hardware and, hence, maps to the transport layer. The Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) falls in the session layer. Serial port emulation using Radio Frequency Communication (RFCOMM), Ethernet emulation using Bluetooth Network Encapsulation Protocol (BNEP), and the

Service Discovery Protocol (SDP) are part of the feature-rich presentation layer. At the top of the stack reside various application environments called profiles. The radio, link controller, and link manager are usually part of Bluetooth hardware, so operating system support starts at the HCI layer.

Figure 16.1. The Bluetooth stack.

A common method of interfacing Bluetooth hardware with a microcontroller is by connecting the chipset's data lines to the controller's UART pins. Figure 13.4 of Chapter 13 , "Audio Drivers," shows a Bluetooth chip on an MP3 player communicating with the processor via a UART. USB is another oft-used vehicle for communicating with Bluetooth chipsets. Figure 11.2 of Chapter 11 , "Universal Serial Bus," shows a Bluetooth chip on an embedded device interfacing with the processor over USB. Irrespective of whether you use UART or USB (we will look at both kinds of devices later), the packet format used to transport Bluetooth data is HCI.

BlueZ

The BlueZ Bluetooth implementation is part of the mainline kernel and is the official Linux Bluetooth stack. Figure 16.2 shows how BlueZ maps Bluetooth protocol layers to kernel modules, kernel threads, user space daemons, configuration tools, utilities, and libraries. The main BlueZ components are explained here: bluetooth.ko contains the core BlueZ infrastructure. All other BlueZ modules utilize its services. It's also

responsible for exporting the Bluetooth family of sockets (AF_BLUETOOTH ) to user space and for populating related sysfs entries.

1.

For transporting Bluetooth HCI packets over UART, the corresponding BlueZ HCI implementation is

hci_uart.ko. For USB transport, it's hci_usb.ko .

2.

l2cap.ko implements the L2CAP adaptation layer that is responsible for segmentation and reassembly. It

also multiplexes between different higher-layer protocols.

3.

To run TCP/IP applications over Bluetooth, you have to emulate Ethernet ports over L2CAP using BNEP.

This is accomplished by bnep.ko. To service BNEP connections, BlueZ spawns a kernel thread called

kbnepd .

4.

To run serial port applications such as terminal emulators over Bluetooth, you need to emulate serial ports

over L2CAP. This is accomplished by rfcomm.ko. RFCOMM also functions as the pillar that supports

networking over PPP. To service incoming RFCOMM connections, rfcomm.ko spawns a kernel thread called

krfcommd. To set up and maintain connections to individual RFCOMM channels on target devices, use the

rfcomm utility.

5.

The Human Interface Devices (HID) layer is implemented via hidp.ko . The user mode daemon, hidd , lets

BlueZ handle input devices such as Bluetooth mice.

6.

7. Audio is handled via the Synchronous Connection Oriented (SCO) layer implemented by sco.ko .

Figure 16.2. Bluetooth protocol layers mapped to BlueZ kernel modules.

BlueZ is the official Linux Bluetooth stack, which is composed by the Host Control Interface（HCI） layer, Bluetooth protocol core, Logical Link Control and Adaptation Protocol（L2CAP), SCO audio layer, and other Bluetooth services, user-space background process and the configuration tool.

Bluetooth specification support for the Bluetooth HCI packets of the UART (Universal Asynchronous Receiver / Transmitter), and USB mass
Transmission mechanism. BlueZ stack of these two transport mechanisms (drivers / Bluetooth /) support. BlueZ BNEP (Bluetooth Network    Encapsulation Protocol) implements Bluetooth on the Ethernet emulation, which makes TCP / IP can run on Bluetooth on. BNEP Module (net / bluetooth / bnep /) and user-mode pand daemon implements Bluetooth Personal Area Network (PAN). BNEP  Use register_netdev itself as a Linux Ethernet device registered to the network layer, and use netif_rx to fill the sk_buffs and send it to the protocol stack. BlueZ RFCOMM (net / bluetooth / rfcomm /) Bluetooth provides a serial simulation, which makes the serial port applications (such as minicom) and protocols (such as Point to Point Protocol (PPP)) run on the Bluetooth without any change. RFCOMM module and user-mode dund background process to achieve a Bluetooth Dial-Up Network
Network.

Bluetooth USB Adapter
Bluetooth USB Adapter has a Bluetooth CSR chipset and use the USB transmitter to transmit HCI data Group. Therefore, Linux USB layer, BlueZ USB transmitter drivers, and BlueZ protocol stack is to make devices work in the main kernel Layer. Now, you will learn how the interaction between the three-tier web application to allow Linux run on this device.

 

Linux USB subsystem is similar to the PCMCIA subsystem, they all have to interact with the mobile devices host controller device driver,
And both contain a single device to the host controller and device drivers to provide services to the core layer. USB host controller follow one of the two Standards: UHCI (Universal Host Controller Interface) or OHCI (Open Host Controller Interface). With PCMCIA, single USB device Linux device driver does not rely on the host controller. The data transmitted via the USB devices are divided into four types
(Or pipe):
Control
Interrupt
Bulk
Isochronous

As Bluetooth USB devices, HCI command uses the Control Tunnel, HCI event uses the Interrupt pipe
Asynchronous (ACL) data uses the Bulk pipe, while the Synchronous (SCO) audio data using the Isochronous pipe.
Bluetooth USB Device Bluetooth specification defines a class / subclass / protocol code 0xE/0x01/0x01. BlueZ USB
Transport driver (drivers / bluetooth / hci_usb.c) registered the class/subclass/protocol information to the Linux USB core.

When Belkin USB adapter is inserted, the host controller device driver will enumerate it. The driver can be attached to the Belkin USB adapter, because the descriptors read from the adapter match the information registered in the USB core from hci_usb driver program during enumeration. Hci_usb driver transparently transferred description of the various endpoints read HCI, ACL and SCO data to the BlueZprotocol stack. Once done this, through the use of the above described BlueZ services and tools, Linux TCP / IP application program Can run on BlueZ BNEP, while the serial application can be run on the BlueZ RFCOMM.

 

reference: