Linux wireless network technology: Bluetooth

By Sreekrishnan Venkateswaran

Linux Bluetooth

Bluetooth is a short-range wireless technology used to replace cables. It supports 723 kbps (asymmetric) and 432 kbps (symmetric) speeds to transmit data and voice. The transmission range of a Bluetooth device is about 10 meters (30 feet ).

BlueZ is the official Linux Bluetooth Stack. It consists of the Host Control Interface (HCI) layer, Bluetooth Protocol core, Logical Link Control and Adaptation Protocol (L2CAP) SCO audio layer, other Bluetooth services, user space background processes, and configuration tools.

Bluetooth specifications support UART (Universal Asynchronous Receiver/transmitter) and USB transmission mechanisms for Bluetooth HCI data groups. The BlueZ stack supports both transmission mechanisms (drivers/Bluetooth. BlueZ BNEP (Bluetooth Network Encapsulation Protocol) implements Ethernet simulation on Bluetooth, which enables TCP/IP to run directly on Bluetooth. The BNEP module (net/bluetooth/bnep/) and the user mode pand background process Implement the Bluetooth Personal Area Network (PAN ). BNEP registers itself as an Ethernet device to the Linux network layer using register_netdev, fills sk_buffs with netif_rx described for the WLAN driver above, and sends it to the protocol stack. BlueZ RFCOMM (net/bluetooth/rfcomm/) provides serial simulation on Bluetooth, which enables serial port applications (such as minicom) and Protocols (such as Point-to-Point Protocol (PPP )) run on Bluetooth without modification. The RFCOMM module and the user mode dund background process implement a Bluetooth dial-up network. The following list shows the necessary BlueZ modules, utilities, background processes, and configuration files for configuring various protocol services on Bluetooth.

Next, consider the Bluetooth CF card, Bluetooth USB adapter, devices with built-in CSR Bluetooth chipset, and Sony Bluetooth headset examples to learn how they work in Linux.

Sharp Bluetooth CF card

The sharp Bluetooth CF card uses a UART transmitter to transmit HCI data groups. In addition to serial_cs, It is the card service driver that interacts with Linux PCMCIA core. The interaction between Linux PCMCIA/CF layer and other operating systems of the sharp card is similar to the interaction explained for the intersil wlan cf card. The serial_cs Driver (which will be further explained in the "Linux GPRS and data on GSM" section below) simulates the serial port on the sharp CF card. The bluez hci_uart Link driver interacts with the Bluetooth UART channel and connects the simulated serial port to the bluez stack.

The following list shows the modules that must be loaded when the card is inserted. Other Bluetooth CF cards, such as the pretec compactbt card and socket Bluetooth card, have UART interface, however, they have their own card service drivers (Drivers/Bluetooth/dtl1_cs.c and Drivers/Bluetooth/btuart_cs.c ). Later in this article, you will find more information about the Bluetooth UART transmitter.

Entries for the sharp Bluetooth CF card in/etc/PCMCIA/config:
Card "sharp Bluetooth card"
Version "sharp", "Bluetooth card"
Bind "serial_cs"

Required kernel modules to be loaded:
Insmod serial_cs
Insmod bluez
Insmod L2CAP
Insmod hci_uart
Insmod bnep (for pand)
Insmod rfcomm (for dund)

BlueZ user space background process, utility and configuration file:
Hciattach ttySx any [baud_rate] [flow]
Hciconfig-a: Check the HCI interface.
Hcitool-a hci0 scan 'flush: Other devices are found.
Hcidump: HCI sniffer.
Hcid: HCI background process.
/Etc/bluetooth/hcid. conf: The HCI background process configuration file used by hcid. It specifies the connection mode (master or slave), connection policy, query and scan mode, and so on.
/Etc/bluetooth/pinDB: BlueZ PIN database.
Hcidump: Service Discovery Protocol background process.
Pand: Run TCP/IP on Bluetooth (-- listen is used for the server, and -- connect is used for the client ).
/Etc/bluetooth/pan/dev-up: pand calls this script when activating TCP/IP. This script can contain a command similar to ifconfig bnep0 to configure the IP address for the Bluetooth interface.
Hcidump: run PPP (-- listen for server and -- connect for client) on Bluetooth RFCOMM ).

Belkin Bluetooth USB adapter

The Belkin Bluetooth USB adapter has a Bluetooth CSR chipset and uses a USB transmitter to transmit HCI data groups. Therefore, the Linux USB layer, the BlueZ USB transmitter driver, and the BlueZ protocol stack are the main kernel layers for devices to work. Now, you will learn how to interact between the three layers so that Linux network applications can run on this device.

The Linux USB subsystem is similar to the PCMCIA subsystem. They all have host controller device drivers that interact with mobile devices and contain a core layer that provides services to host controllers and device drivers of a single device. The USB Host Controller follows one of two standards: UHCI (Universal Host Controller Interface) or OHCI (Open Host Controller Interface ). With PCMCIA, Linux Device Drivers for a single USB device do not depend on host controllers. Data transmitted by a USB device can be divided into four types (or pipelines ):
Control
Interrupt
Bulk
Isochronous

The first two are usually used for small messages and the last two are used for larger messages.

When a USB device is inserted, the host controller uses a control pipe to enumerate it and assign it a device address (1 to 127 ). The device descriptor read by the Host Controller Device Driver contains information about the device, such as class, subclass, and protocol. The Linux USB core kernel module supports USB Host controllers and USB devices. It also contains functions and data structures that can be used by the USB driver. The USB driver uses usbcore and its own class/subclass/protocol information (see struct usb_driver in include/linux/usb. h) to register two entry points: probe and disconnect. When a USB device is attached, usbcore uses the class information read from the device configuration descriptor during enumeration to match the registered class information and binds the device to the corresponding driver. This core uses a data structure called USB Request Block or URB (defined in include/linux/usb. h) to asynchronously manage data transmission between hosts and devices. The device driver uses these routines to request various types of data transmission (control, interrupt, bulk, or isochronous ). After the request is sent, the core uses the previously registered callback function to notify the driver.

For Bluetooth USB devices, the HCI command is transmitted using the Control pipeline, HCI events use the Interrupt pipeline, Asynchronous (ACL) data uses the Bulk pipeline, and Synchronous (SCO) Audio Data uses the Isochronous pipeline. The Bluetooth specification defines the class/subclass/protocol code 0xE/0x01/0x01 for a Bluetooth USB device. BlueZ USB transmission Driver (drivers/bluetooth/hci_usb.c) registers the class/subclass/protocol information to the Linux USB core. When the Belkin USB adapter is inserted, the host controller device driver will enumerate it. Because the device descriptor read from the adapter during enumeration matches the information registered to the USB core by the hci_usb driver, this driver can be attached to the Belkin USB device. HCI, ACL, and SCO data read by the hci_usb driver from each of the preceding endpoints are transparently transmitted to the BlueZ protocol stack. Once this is done, the Linux TCP/IP application can run on BlueZ BNEP by using the BlueZ services and tools described above, while the serial application can run on BlueZ RFCOMM.

Motherboard with built-in CSR Bluetooth chipset

Now, let's take a look at the Bluetooth Network Data Flow on a device with a built-in Bluetooth chipset. Consider connecting a handheld device with a built-in CSR Bluetooth chipset to a system using UART interfaces. For UART interfaces, available protocols for transmitting HCI data groups between Bluetooth devices and systems include BlueCore Serial Protocol (BCSP), H4/UART, and H3/RS232. H4 serves as a standard method for transmitting Bluetooth data through UART. UART is a proprietary BCSP protocol defined in the specification from CSR. It supports error checksum and retransmission. BCSP is used on non-USB devices based on the CSR BlueCore chip, including PCMCIA and CF cards. BlueZ supports BCSP and H4.

The UART channel of this motherboard uses a traditional serial driver that can send and receive data from the BlueZ UART transmission driver. If you use the BSCP protocol to design the CSR chip as an encapsulation HCI Data Group, you must use hciattach (hciattach ttySx bcsp) to notify the BlueZ Link driver, here x is the UART channel number connected to the CSR chipset. Now hci_uart interacts with the CSR chip and transmits Bluetooth data to and from the BlueZ stack.

Sony HBH-30 Bluetooth headsets

The preceding Bluetooth device example shows network data streams. Now, you can view Sony Ericsson Bluetooth headphones to consider the transmission of Bluetooth audio (SCO) data. Before the headset can communicate with a Linux device, it must be detected by the Bluetooth link layer on the Linux device. Therefore, you must place the headset in discovery mode (by pressing a button on the headset ). In addition, you need to configure the headset PIN through BlueZ on the Linux device. Applications using BlueZ SCO APIs on Linux Bluetooth devices can now send audio data to headphones. Audio Data should be in A headset-understandable format (for example, A-law PCM [Pulse Code Modulation] format for Sony headphones ). Some common primary domain utilities can convert audio (or even text files) to various PCM formats.

In addition to the HCI transmission interface, the Bluetooth chipset also has the PCM Interface PIN. For example, if the device supports both GSM and Bluetooth, the PCM line of the GSM chipset can be directly connected to the PCM audio line of the Bluetooth chip. Then, you may have to configure a Bluetooth chipset on a Linux device to send and receive SCO audio data groups through the HCI transmission interface instead of the PCM Interface.

About the author

Sreekrishnan Venkateswaran holds a master's degree in computer science from the Indian Science and Technology Institute in Kanpur, India. He has been working for IBM India since February 1996. His interests include designing device drivers and network protocols. You can contact Sreekrishnan through a s_krishna@in.ibm.com.

Full text from: IBM developerWorks Chinese website