Getting On-line Anywhere with Bluetooth and GPRS

Bluetooth and General Packet Radio Service (GPRS) are used
widely today to make devices on the move Internet accessible. Bluetooth
is a low-range wireless technology that can be made a part of almost any device
due to its low cost and power consumption, GPRS offers always-on
connectivity to the Internet.

Bluetooth and GPRS can provide standalone network connectivity
to your PDA or laptop. Bluetooth roaming enables continuous
connectivity when you move your device from one floor of your building
to another, and GPRS roaming preserves your Internet connection when
you are on the road and move from one service provider's area to
another. Figure 1 describes some of these scenarios.

Figure 1. On-line Anywhere with Bluetooth and GPRS

Because Linux runs on a variety of embedded devices including
Bluetooth-aware consumer electronics devices, GPRS cell phones and
wireless-enabled PDAs, a discussion on how Linux works with Bluetooth
and GPRS can be helpful in using and designing such devices.

Linux Bluetooth
Bluetooth is a protocol for wireless communication using radio
frequency and was conceived as a replacement for cables. It supports
speeds of 723 kbps(asymmetric) and 432 kbps (symmetric) and it can be
used to transfer both data and voice. Bluetooth devices have a range
of about 10 meters (30 feet).

BlueZ is the official Linux Bluetooth protocol stack. Although there are
other popular Bluetooth implementations on Linux, such as the Affix stack,
the rest of this section is devoted to BlueZ.

BlueZ supports the core Bluetooth protocols, including host control
interface (HCI), logical link control and adaptation protocol (L2CAP),
personal area networking (PAN), service discovery protocol (SDP),
synchronous connection oriented (SCO) audio and serial port emulation
(RFCOMM). It also comes bundled with a bunch of user space dæmons and
configuration tools.

BlueZ supports the different user profiles described by the Bluetooth
specification. BlueZ BNEP (Bluetooth Network Encapsulation Protocol)
implements Ethernet emulation, which lets TCP/IP run directly over
Bluetooth. The BNEP module, together with a user mode dæmon called
pand implements Bluetooth PAN. BlueZ RFCOMM allows serial port
applications, such as terminal emulators, and protocols, such as point-to-point
protocol (PPP), to run unchanged over Bluetooth. The RFCOMM module,
along with a user mode dæmon called dund implements Bluetooth
dial-up networking.

The Bluetooth specification defines the use of UART and USB transport
mechanisms to transfer HCI packets between a Bluetooth device and a
host system. For UART interfaces, the main protocols
available to encapsulate HCI packets are H4/UART and Blue Core Serial
Protocol (BCSP). Whereas H4 serves as the standard method for
transmitting Bluetooth data over a UART interface, BCSP is a
proprietary protocol from CSR that supports error checking and
retransmission. BlueZ supports both H4 and BCSP. If the Bluetooth chip
used on your board has a UART interface to the host processor and is
programmed to encapsulate HCI packets using BCSP, you need to
inform the BlueZ stack of this. Do so using hciattach: hciattach ttySx
bcsp, where x is the UART channel number connected to the
Bluetooth chip. The BlueZ UART link driver hci_uart now talks to the
chip using BCSP and passes the Bluetooth data to and from the BlueZ
stack.

BlueZ also has a link driver hci_usb, which supports USB Bluetooth
devices. The driver uses the services and data structures provided by
the Linux kernel USB core to manage data transfers
asynchronously between the host and the Bluetooth USB device. As per the Bluetooth
specification, the hci_usb driver uses the corresponding USB
pipes—control, interrupt, isochronous or bulk—to transport different types
of Bluetooth data—HCI commands, HCI events, SCO audio or asynchronous
connectionless data). The Belkin Bluetooth USB adapter is an example
Bluetooth USB device that works with BlueZ.

BlueZ also supports the transfer of audio data to devices such as
Bluetooth headsets. An application on the host Bluetooth device uses
BlueZ SCO APIs to send audio data to the headset. The audio data
pumped through the SCO APIs has to be in a format understood by
the headset, for example, A-law pulse code modulation (PCM) format
is used for the Sony Ericsson HBH-30 Bluetooth headset. If the Bluetooth
chipset on your host device has a PCM interface connected to
another audio source, you might have to configure the chipset to
receive the SCO audio over its HCI interface rather than over its PCM
interface.

BlueZ utilities can be used to set up Bluetooth connections. For
example, the hcitool utility can be used to initiate an inquiry
process and discover the names and Bluetooth addresses of units
within range. You then can set up a PAN or a dial-up connection to
a discovered Bluetooth device using pand or dund. The sdptool
program can be used to register or search for a service, say, printing
or networking. The important BlueZ user space dæmons,
utilities and kernel modules, along with a brief description of each, are
listed below:

• hciconfig --a: examine the HCI interface.
• hcitool -f hci0 scan --flush: discover other Bluetooth devices within
  range.
• hciattach ttySx any [baud]: attach an encapsulation method (H4, BCSP),
  baud rate and a flow control mechanism to the serial port connected to
  the Bluetooth device.
• hcidump: HCI sniffer.
• hcid: HCI dæmon.
• /etc/bluetooth/hcid.conf: HCI dæmon configuration file used by hcid that
  specifies link mode (master or slave), link policy, inquiry and scan
  mode and so on.
• /etc/bluetooth/pinDB: BlueZ PIN database.
• sdpd: service discovery protocol dæmon.
• pand: runs TCP/IP over Bluetooth (--listen for the server,
  --connect<bluetooth_address> for the client).
• /etc/bluetooth/pan/dev-up: pand invokes this script when bringing up
  TCP/IP. This script can contain a command like ifconfig
  bnep0<ip_address>up to configure the Bluetooth interface with an IP
  address.
• dund: runs PPP over Bluetooth RFCOMM (--listen for the server,
  --connect<bluetooth_address> for the client).

BlueZ kernel modules:

• bluez: the BlueZ core layer.
• l2cap: L2CAP implementation.
• hci_uart: UART transport driver (supports H4/BCSP).
• hci_usb: USB transport driver.
• bnep: Ethernet emulation (used along with pand).
• rfcomm: serial port emulation.
• SCO: support for voice transport over Bluetooth.

Example Bluetooth Devices
The Sharp Bluetooth CF card uses a UART transport to transfer HCI
packets. serial_cs, the generic card service driver used for
accessing PCMCIA serial devices, emulates a serial port over the Sharp
CF card. The first unused serial device (/dev/ttySx) is allotted to
the card. When the Sharp Bluetooth CF card is inserted, the kernel
PCMCIA card services module parses the card information structure
(CIS) tuples resident in the card's attribute memory and passes them
up to the user mode cardmgr dæmon.

Because the manufacturer ID
tuple in the card's CIS matches an entry in the PCMCIA configuration
file, /etc/pcmcia/config as shown in Listing 1, cardmgr binds the card
to the serial_cs device. Card services then invokes the serial_cs
module's PCMCIA event handler and signals a card insertion event,
which configures the socket and makes the card available to the
system. Also, because the device is of class Bluetooth, cardmgr
executes the script /etc/pcmcia/bluetooth while starting and stopping the
device; the exact location of all
configuration files depend on the Linux distribution used.
This script can, among other things,
load the BlueZ kernel modules listed above and attach the BlueZ
stack to the virtual serial port allotted to the card.

Listing 1. An Entry in /etc/pcmcia/config for the Sharp Bluetooth CF
Card

card "SHARP Bluetooth Card"
     manfid 0x00b0, 0x0001
     bind "serial_cs"
 
device "serial_cs"
    class "Bluetooth" module "serial_cs"

The legacy UART device driver for the board, along with the Bluetooth
N_HCI line discipline, is used to drive the serial port emulated over
the card. A line discipline is a kernel layer residing above the
serial driver, which controls the way that the serial driver
behaves. The same serial driver can be used for different
purposes—terminal emulation, PPP, SLIP, Bluetooth—by
respectively gluing a different line discipline above the serial
driver—N_TTY, N_PPP, N_SLIP, N_HCI. When data is received by the
Sharp card, the legacy UART driver's receive interrupt service routine
invokes the receive entry point registered by the N_HCI line
discipline, which in turn calls the receive function of the
corresponding HCI transport protocol. That is h4_receive in this case,
because
the H4 protocol is being used for encapsulation. This routine
allocates and populates an skbuff, the key data structure used by
the Linux networking stack, and passes it on to BlueZ. If the data
belongs to an IP datagram, BlueZ BNEP code subsequently passes it on
to the TCP/IP layer by invoking netif_rx.

Some PCMCIA/CF Bluetooth cards, such as the Socket Bluetooth CF card, have
specific BlueZ card service device drivers that directly control the
UART in the card and transport the data to the HCI layer. For example,
the Socket Bluetooth card, built around a Nokia Bluetooth chipset, uses
the dtl1_cs card service driver. In this case, the data flow does
not pass through the legacy serial driver or through the N_HCI line
discipline. Instead, the PCMCIA interrupt handler that is part of
dtl1_cs allocates skbuffs and populates them with the received
Bluetooth data. The rest of the code flow through the BlueZ stack is
similar to that described for the Sharp card. Another example of a
device that has a specific BlueZ card service driver is the Pretec
CompactBT Bluetooth card, which has a driver called bt950_cs.

Bluetooth Roaming
When Bluetooth is used in tandem with GPRS to network-enable a dumb
device, a Bluetooth-aware GPRS cell phone usually acts as the gateway
to the network. However, when Bluetooth is being used as a means for
standalone Internet connectivity, network traffic is routed by way of a
Bluetooth access point.

An access point is a Bluetooth gateway and usually supports additional
network interfaces, such as Ethernet or DSL. Typically, an access point
also can act as a DHCP server and dole out IP addresses on the
Bluetooth side.

When you walk around a building with your Bluetooth device, you could
move out of range of one access point and enter the range of
another. Depending on the link quality, which can be queried using a
HCI command, your mobile device can maintain constant connectivity to
a computer on a fixed network by switching to a new access point. To
maintain seamless roaming for different higher layer networking
protocols, you might need to implement extra software layers on your
device. However, continuous Web browsing capability can be maintained
by sending out a fresh DHCP request when your device switches to a new
access point.

Linux GPRS
GPRS is a packet service for carrying data over GSM, the prominent
digital cellular standard. Data over GPRS is an always-connected,
packet-switched data stream where users pay according to usage. GPRS
can run at speeds of 56 kbps to 170 kbps. The GPRS network connects to
the Internet through a GGSN (gateway GPRS support node), as shown in
Figure 1.

GPRS devices usually have a UART interface to the host system. For
example, some cell phones have a Siemens MC-45 chipset connected to an
on-board UART channel. The legacy serial device driver then can be
used to talk to the GPRS device. For a GPRS card with a PCMCIA/CF form
factor (an Options GPRS card, for example), the generic serial card
service driver discussed earlier can be used to let the kernel see the
card as a serial device. For USB GPRS modems, a USB-to-serial
converter typically converts the USB port into a virtual serial port,
so the rest of the system sees it as a serial device.

A GPRS device resembles a modem with an extended AT
command set. The GPRS device has to define a context using an AT
command before it enters data mode. An example context string is as
follows:

AT+CGDCONT=1,"IP","internet2.voicestream.com","0.0.0.0",0,0

where 1 stands for the context number, IP is the packet type,
internet2.voicestream.com is an access point name (APN) string
specific to the GPRS service provider and 0.0.0.0 implies that
the service provider assigns your IP address. The remaining parameters
pertain to header and data compression. A user name and password
usually are not needed. The APN string depends on the kind of service
is desired. You would need to use one APN for Internet-over-GPRS,
but a different one to browse dedicated wireless application protocol
(WAP) content.

PPP enables networking protocols such as TCP/IP to run over a serial
link. A common syntax for invoking the Linux PPP dæmon, pppd, is:

pppd ttySx call connection-script

where ttySx is the physical or virtual serial device over which PPP
runs and connection-script is a file in the /etc/ppp/peers/
directory that contains the AT command sequences exchanged between
pppd and the service provider in order to establish a link. After
establishing the link connection and completing authentication, PPP
starts a network control protocol (NCP). Internet protocol control
protocol (IPCP) is the NCP used for running IP. Once IPCP successfully
negotiates IP addresses, PPP starts talking with the TCP/IP stack.
Your device now is ready to run TCP/IP applications over the GPRS
link.
Listing 2 is an example PPP connection script for connecting your
device to a GPRS service provider.

Listing 2. A sample Linux pppd Connection Script for GPRS
(/etc/ppp/peer/gprs-script)

115200
connect '/usr/sbin/chat -s -v "" AT+CGDCONT=1,"IP",
"internet2.voicestream.com","0.0.0.0",0,0 OK AT+CGDATA="PPP",1'
crtscts
noipdefault
modem
usepeerdns
defaultroute
connect-delay 5000

The Linux kernel modules that
need to be loaded for running PPP are as follows:

• ppp_generic: generic PPP layer.
• ppp_async: PPP async serial channel line discipline(N_PPP).
• slhc: compression/decompression of TCP packets.
• ppp_deflate: deflate PPP compression.

To get a list of service providers in your current location, you can
issue the AT+COPS=? command to the GPRS module. To
maintain continuous connectivity, a Linux application can monitor the
available service providers in the current area and restart the PPP
session using the connection-script for the new service provider, if a
switch is deemed necessary.

Bridging Bluetooth and GPRS
A cell phone or a PDA with integrated Bluetooth and GPRS capabilities
can provide Internet access to Bluetooth devices in different ways:

• The cell phone talks with Bluetooth devices over a Bluetooth dial-up
  (RFCOMM) connection and pipes data between the RFCOMM connection and
  its GPRS interface. The Bluetooth devices directly establish a PPP
  connection to the GPRS service provider by sending GPRS commands over
  the RFCOMM link.
• The cell phone makes an Internet connection through the GPRS service
  provider using PPP. It talks with Bluetooth devices over a PAN
  connection and routes TCP/IP packets between the Bluetooth and GPRS
  interfaces.
• The cell phone supports some of the Bluetooth generic object
  exchange profiles that the Bluetooth devices can use to transfer
  objects, such as files or images.

Because Bluetooth supports device inquiry and service discovery, the
Bluetooth devices automatically can use a nearby cell phone for
Internet connectivity, without cumbersome configuration of such details
as physical addresses.

Conclusion
Bluetooth technology integrated into GPRS cell phones extends the
Internet to Bluetooth-aware consumer electronics devices. Also, due to
the wide availability of GPRS and Bluetooth devices in CF and USB form
factors, handheld computers and laptops can make use of these
technologies for standalone network connectivity on the move. With
Linux providing stable support for both these technologies, and with
many embedded devices running Linux, a wide world of possibilities
opens up.

Sreekrishnan Venkateswaran has been working for IBM India since
1996. He holds a Master's degree in Computer Science from the Indian
Institute of Technology, Kanpur, India. His interests include
designing device drivers and network protocols.