Tuesday, December 11, 2007

Using Power Management:

Before going further, its worth spending a little time defining what a power managed
application actually is and exploring some of the reasons why such applications
are necessary. A power-managed application is one that allows the device it
is running on to go into sleep mode for significant portions of its duty cycle.
Sleep mode need not involve powering down the whole device; in fact, this is
highly unlikely, as certain functional blocks will always need to be powered.
However, when a device is in sleep mode it should be consuming significantly
less power than when it is fully “awake,” otherwise power management will be a
waste of time.
A further characteristic of application level power management is that it
should not adversely affect the performance of the application. In fact, the user
should not be aware that your application is using power management and that
the Bluetooth device is not constantly powered on. Powering down a device at
the wrong time can not only result in almost no energy being saved, but it can

also make an application virtually unusable by making it slow to respond. Let’s
consider the example of a wireless headset and a mobile phone. If the headset is
powered down at the wrong time, the phone will not be able to notify it of an
incoming call. Even though the headset may be saving significant amounts of
power, as far as the user is concerned, it is unusable, because it cannot receive calls
in a timely manner.
So, if power management has the potential to make your application unusable
or infuriatingly slow, why bother with it? Used in the correct way, the Bluetooth
power management modes have the potential to extend the battery life of your
device significantly, yet be completely transparent to the user. In general, users do
not like having to lug about heavy batteries or recharge their devices frequently.
A typical mobile phone has a small battery and yet can last several days without
recharging. If adding Bluetooth functionality to such a phone reduces its average
battery life significantly, it is unlikely to be popular with the user. Power management
at both the hardware and software levels of Bluetooth technology is therefore
necessary in order to make these networks viable.A further benefit of
application power management is that the energy savings are independent of the
underlying technology.This means that if through power management you
double the battery life of your device, this will hold true even if the power consumption
of the underlying hardware was significantly improved.
A relatively minor, but nevertheless important, point to consider is who owns
the devices that are being power managed. Often greater power savings can be
achieved by one device at the expense of the energy resources of another.An
obvious example would be where a device is powered down for the majority of
its duty cycle while another device buffers packets destined for it and therefore
must be constantly powered on. Periodically, the first device wakes up to pick up
these packets, acts on them if necessary and then powers down again.Thus, the
first device can achieve very high power savings at the expense of the buffering
device. If the same user owns both devices (and especially if one of those devices
can be mains powered, e.g., a PC) then this is a very good approach to achieving
high power savings. However, if the devices belong to different users then there is
an obvious conflict of interests as both users might be keen to prolong the battery
life of their particular device rather than altruistically providing a service for
others. In this case, a scheme where both devices achieve some, but not maximal,
power savings may be a better compromise rather than having no power saving at
all.The anticipated uses of a power-managed application can therefore be important
in choosing the power management approach taken.


Having discussed how useful power-managed applications can be, it is worth
looking at what types of applications are suitable for these techniques and which
ones will have their performance adversely affected by power management.The
first thing to remember is that in order to save power, the device must be put
into sleep mode. Applications that require large amounts of data to be sent or
received, or that need very fast response times, are not suitable for power management.
On the other hand, applications requiring small amounts of data to be
transmitted or where data transfers are infrequent are very well-suited to being
powered down for the majority of the time they are inactive. Similarly, applications
where a delay in the response time can be tolerated should also consider
power management.
Before choosing a given Bluetooth power management mode to use with
your application you should consider the maximum amount of time the device
can be powered down without adversely affecting the performance of your application.
In general, when using power management, an application designer trades
off an increase in latency and a decrease in data throughput for an increase in the
battery life of the device running the application.The following sections will discuss
the Bluetooth power management modes and the use of each mode in the
context of different types of applications.
Investigating Bluetooth Power Modes
For most applications, if a connection exists between two or more Bluetoothenabled
devices, one of the Bluetooth low power modes can be used to extend
the battery life of either some or all of these devices. In fact, power-managed
devices can be in one of four states, listed in order of decreasing power consumption:
active, hold, sniff, and park mode. Each of these low power modes will be
described, along with a discussion of what type of applications will and will not
be suitable for it.
Active Mode
In active mode, the device actively participates on the radio channel.The master
schedules data transmissions as necessary and the slaves must listen to all active
master-slave slots for packets that may be destined for them.This mode is a
useful benchmark for comparison with the performance of the low power
modes since it not only consumes the most power but also has the highest


achievable data throughput due to the devices being able to use all available
slots.The power consumption of Bluetooth devices is highly dependent on the
manufacturer of the device and the application that it is running. Furthermore,
as the technology matures, the power consumption of Bluetooth-enabled devices
will improve further and hence it is best to compare low power modes relative
to the active mode.
We will briefly discuss the type of applications best suited to active mode,
which are unlikely to benefit or be able to utilize any of the other low power
modes. An application that has very high data rate requirements is unlikely to
power save as it will need to have its radio transceiver powered on for the majority
of its duty cycle. Similarly, applications that require very low latencies are also
unlikely to be able to use the low power modes since they will power down for
such short periods that the overhead in powering down the device will be greater
than the energy saving made (or powering down for longer periods will mean the
application is no longer able to conform to its latency requirements).
Hold Mode
This is the simplest of the Bluetooth low power modes.The master and slave
negotiate the duration that the slave device will be in hold mode for. Once a
connection is in hold mode, it does not support data packets on that connection
and can either power save or participate in another piconet. It is important to
note that the hold period is negotiated each time hold mode is entered. Figure
3.1 shows what the interaction between two devices using hold mode might
look like. A further important aspect of hold mode is that once it has been
entered, it cannot be cancelled and the hold period must expire before communications
can be resumed.

Figure 3.1 Hold Mode Interaction
Power consumption
Active mode
Hold mode
Time

Given these constraints, what type of application would benefit from using
hold mode? If your application can determine or control the time of its next data
transmission, then it can most probably use hold mode for power management.
One example of an application that has some degree of control over when its
next data transmission should take place is a wireless e-mail delivery system.
E-mail is not a synchronous communications medium and messages can take
anything from a few seconds to several hours to be delivered to their destination.
More importantly, users do not perceive e-mail delivery to be instantaneous and
hence would tolerate a small additional delay in favor of extending the battery
life of their device.The following sidebar,“Power Management Using Hold
Mode,” discusses in more detail how hold mode can be used by such an application,
along with power saving techniques available.

Power Management Using Hold Mode
Given that e-mail is not an instantaneous communications medium and
the delivery delays involved can be relatively large, any wireless e-mail
delivery system has a lot of flexibility in the way it checks for new messages
and sends off ones that have just been written. In fact, if correctly
implemented, the delivery delay should not be perceptible to the user.
Let’s assume we have a Bluetooth-enabled organizer that periodically
communicates with an access point and retrieves newly arrived emails
as well as sending off ones that have just been written. A simple
way of implementing such a service will be to set up an RFCOMM connection
between the two devices and have the checking device periodically
search for new e-mails. Placing such a link in hold mode is unlikely
to have a significant impact on the delivery time of e-mail and can result
in power savings at both ends of the link. Furthermore, as each hold
interval is negotiated independently of the previous ones, this gives us
the opportunity to write an application that dynamically adapts to its
usage. For example, successive hold intervals can be increased by a certain
factor (up to a particular ceiling, of course) if there are no e-mails
retrieved or sent during the previous “active” period. In the same way,
successive hold intervals can be decreased if the frequency of e-mail
arrivals increases. This approach allows the application to better adapt
to the way it is being used and achieve higher power savings when the
Developing & Deploying…
Continued

A very different candidate for hold mode is one which relies on the use of
a SCO link and does not need to send data packets. Furthermore, if the application
can tolerate a poorer audio quality it can use fewer slots and hence
power down for longer periods of time. For example, a baby monitor needs to
have an active SCO link but does not need the ACL link. Also, given that parents
are mainly interested in detecting whether the baby is crying or not, this
application could probably get away with a slightly poorer quality of audio. By
placing the ACL link in hold mode for relatively long periods of time and
reducing the quality of the SCO link, the application can achieve greater power
savings.
Having discussed application types able to benefit from using hold mode, we
will briefly consider applications that should not use this mode, being it’s likely to
have a negative impact on performance. Hold mode is not suitable for applications
whose traffic pattern is unpredictable and which cannot tolerate unbounded communication
latencies.An obvious example is a device that allows a user to browse
the Web over a wireless link. Even though access to the World Wide Web is notorious
for being slow, if this latency is further increased by using hold mode, the
application becomes too frustrating to use. At this point, it’s worth remembering
that once entered, hold mode cannot be exited until the negotiated hold interval
has expired. Furthermore, the traffic pattern of such an application is impossible to
predict due to the nature of Web browsing.The user may make a number of page
requests in quick succession whilst browsing for a particular page.However, once
the page has been found, they may spend considerably longer looking at the page
and not need the use of the wireless link for some time.

load on the radio is light whilst still being responsive at higher usage
rates. However, designers of such applications should be careful not to
make such transitions too rapid as this may result in a yo-yo effect with
the application swinging from one extreme to the other.
A further power saving technique at the application level, not
directly connected with the use of Bluetooth low power modes, may be
to compress data before transmitting it. If a high enough compression
ratio can be achieved, the time that the transceiver has to be powered on
can be reduced enough to justify the extra work. However, this should
also be used with caution. A small device with relatively little computation
power will use up energy in compressing (or decompressing) a file
and this may offset the savings made in transmitting a smaller file. Such
power-saving techniques are highly dependent, not only on the type of
data being sent, but also on the underlying hardware.
• Power Management
A very different application type whose performance will be negatively
impacted is a network of sensors which need timely delivery of their data—for
instance, intruder detection. Once a sensor has been triggered, fast delivery of this
information to the control center is imperative.A sensor with a long battery life
that spends much of its day powered down may just give an intruder time
enough to avoid being caught.

Reviewing the Protocol Stack

The wide range of possible Bluetooth applications means that there are many
Bluetooth software layers.The lower layers (Radio Baseband, Link Controller, and
Link Manager) are very similar to the over-air transmissions.They can provide
voice connections and a single data pipe between two Bluetooth devices.To ease
integration of Bluetooth into existing applications, the specification provides
middle layers that attempt to hide some of the complexities of wireless communications.
In combination, these layers, when transmitting, can take many familiar
data formats and protocols, package them, multiplex them together, and pass
them on in a manner that matches the lower layers’ capabilities. Matching layers
at the receiving end de-multiplex and un-package the data.
At the bottom of the stack are some layers that are fundamental to Bluetooth
wireless technology: Radio Baseband, Link Manager, Logical Link Control and
Adaptation Protocol (L2CAP), and Service Discovery Protocol (SDP).Above
these layers, different applications require different selections from the higher
layers. Each profile calls up the higher layers it requires. If you implement more
than one profile in your application, you may be able to reuse the common
layers. Not all stack vendors support all layers so, if you are buying in a stack,
www.syngress.com
www.syngress.com
make sure that it supports the layers required for your application’s profiles.
Figure 2.1 shows the layers defined by the Bluetooth specification (shown
unshaded) and some other common layers (shown shaded).
L2CAP
Logical Link Control and Adaptation Protocol multiplexes upper layer data onto
the single Asynchronous ConnectionLess (ACL) connection between two
devices and, in the case of a master device, directs data to the appropriate slave.
It also segments and reassembles the data into chunks that fit into the maximum
HCI payload (the HCI is the Host Controller Interface, which connects higher
layers on a host to lower layers on a Bluetooth device). Locally, each L2CAP
logical channel has a unique Channel Identifier (CID), although this does not
necessarily match the CID used by the remote device to identify the other end
of the same channel. CIDs 0x0000 to 0x003F are reserved with 0x0000 being
Exploring the Foundations of Bluetooth • Chapter 2 71
Figure 2.1 Bluetooth Protocol Stack
Application
Baseband:
Link Manager,
Link Controller
and Radio
L2CAP
SDP
Audio
TCS
RFCOMM
OBEX
Device Manager
Connection
Manager
Security
Manager
Control
Data
Audio
HCI HCI
72 Chapter 2 • Exploring the Foundations of Bluetooth
unused; 0x0001 carrying signaling information; and 0x0002 identifying received
broadcast data.
The stack layers that sit above L2CAP can be identified by a Protocol
Service Multiplexor (PSM) value. Remote devices request a connection to a
particular PSM, and L2CAP allocates a CID.There may be several open channels
carrying the same PSM data. Each Bluetooth defined layer above L2CAP has its
own PSM:
 SDP – 0x0001
 RFCOMM – 0x0003
 Telephony Control Protocol Specification Binary (TCS-BIN) – 0x0005
 TCS-BIN-CORDLESS – 0x0007
L2CAP only deals with data traffic, not voice, and all channels, apart from
broadcasts (transmissions from a master to more than one slave simultaneously),
are considered reliable.
RFCOMM
RFCOMM (a name coming from an Radio Frequency [RF]-oriented emulation
of the serial COM ports on a PC) emulates full 9-pin RS232 serial communication
over an L2CAP channel. It is based on the TS 07.10 standard for a software
emulation of the RS232 hardware interface.TS 07.10 includes the ability to multiplex
several emulated serial ports onto a single data connection using a different
Data Link Connection Identifier (DLCI) for each port. However, each TS 07.10
session can only connect over a single L2CAP channel and thus only communicate
with one device.A master device must have separate RFCOMM sessions
running for each slave requiring a serial port connection.
Version 1.1 of the Bluetooth specification has added to the capabilities of the
standard TS07.10 specification by providing flow control capabilities.This caters
for mobile devices with limited data processing and storage capabilities allowing
them to limit the incoming flow of data.
OBEX
The Object Exchange standard (OBEX) was developed by the Infrared Data
Association (IrDA) to facilitate operations common to IR-enabled devices like
personal digital assistants (PDAs) and laptops. Rather than develop a new standard,
the Bluetooth SIG took OBEX largely as is, detailed a few specifics
regarding Bluetooth implementation (e.g., making some optional features mandatory),
and used it in the File Transfer, Synchronisation, and Object Push profiles.
OBEX allows users to put and get data objects, create and delete folders and
objects, and specify the working directory at the remote end of the link. IrDA has
also provided formats for data objects, while the Bluetooth specification has
adopted the vCard format for business card exchange and the vCal format for
exchanging calendars.
PPP
The Point-to-Point Protocol (PPP) is the existing method used when transferring
Transmission Control Protocol/Internet Protocol (TCP/IP) data over
modem connections.The Bluetooth specification reuses this protocol in the
local area network (LAN) Access Profile to route network data over an
RFCOMM port.Work is already underway on a TCP/IP layer that will sit
directly above L2CAP, bypassing and removing the overhead of PPP and
RFCOMM.This work is hinted at in some areas of the specification, but in v1.1
PPP, is all that’s available.
TCS Binary
Telephony Control Protocol Specification Binary (TCS Binary, also called TCSBIN),
is based on the International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q.931 standard for telephony call control. It
includes a range of signaling commands from group management to incoming
www.syngress.com
74 Chapter 2 • Exploring the Foundations of Bluetooth
call notification, as well as audio connection establishment and termination. It is
used in both the Cordless Telephony and Intercom profiles.
SDP
The Service Discovery Protocol differs from all other layers above L2CAP in that
it is Bluetooth-centered. It is not designed to interface to an existing higher layer
protocol, but instead addresses a specific requirement of Bluetooth operation:
finding out what services are available on a connected device.The SDP layer acts
like a service database.The local application is responsible for registering available
services on the database and keeping records up to date. Remote devices may
then query the database to find out what services are available and how to connect
to them.The details of service discovery can be complex and are discussed
further in Chapter 5, but each profile describes exactly what information should
be registered with SDP based on the application implementation.
Management Entities
Device, Security, and Connection Managers are not protocol layers so much as
function blocks.The Device Manager handles the lower level operation of the
Bluetooth device.The Connection Manager is responsible for coordinating the
requirements of different applications using Bluetooth channels and sometimes
automating common procedures.The Security Manager checks that users of the
Bluetooth services have sufficient security privileges.
HCI
The Host Controller Interface is not a software layer, but a transport and communications
protocol that aids interoperability between different manufacturers’
solutions. It is not mandatory to use the HCI interfaces defined in the specification
(Universal Serial Bus [USB]; RS232; or a simple Universal Asynchronous
Receive Transmit [UART]), or indeed any HCI transport at all, if there are better
solutions for your application.
Lower Layers
The lower layers (Radio Baseband, Link Controller, and Link Manager) format
the over-air transmissions, handle error detection and re-transmission, and manage
the links between devices.
Table 2.1 illustrates which profiles use which layers.

Allowing for Interference

Allowing for Interference
Wireless means a radio link—and radio links are subject to interference.
Interference can impact both the quality of an audio (Synchronous Connection
Oriented [SCO]) connection or the throughput of a data (Asynchronous
Connectionless [ACL]) connection. High levels of interference can interrupt
communications for long enough to cause the protocol stack to timeout and
abandon the link altogether. Although this is addressed in the Bluetooth

Figure 1.4 A Wireless HAN for AV Control and Distribution
8 Chapter 1 • Introducing Bluetooth Applications
Specification with a frequency-hopping scheme which does provide robustness, it
is still a serious consideration for some applications.
Bluetooth technology should not be used for safety-critical applications
where data absolutely must get through, because there is always a possibility of a
burst of interference stopping the link. Interference can come from a variety of
sources: microwave ovens, thunderstorms, other communications systems (such as
IEEE 802.11b), even other Bluetooth devices in the area (although these will not
have a great effect as they are designed to cope with interference from one
another in normal use).
It is possible to overcome the problem of link failure. For example, if you are
relying on a Bluetooth link to monitor your baby and you know the environment
is such that the link will only fail approximately once a week, then you
might be happy to have the receiver alert you when the link fails. Once a week
you may be out of touch, but an alert will let you know that the link has failed,
so you have the option of returning within earshot of the infant. Since the
Bluetooth links only operate up to around 100 meters, it shouldn’t take you too
long to get there!
There are other safety-critical applications where an unreliable link may be
acceptable. An example is a system developed for Nokian tires, which allows tire
pressure to be automatically monitored and sent to the car dashboard display.A
wireless link will be subject to frequent failures in the harsh automotive environment,
but the link can be re-established. Even if it only works a tenth of the time,
it is still checking tire pressures far more often than will the average motorist!
Here again, the system could be set to alert the driver if the tire pressures have not
been reported recently.This way the driver knows that a manual check is needed.
So far, we have looked at effects of the Bluetooth link receiving interference,
but, of course, it can also interfere with other devices. Bluetooth devices are obviously
completely unsuitable for use in an environment where the Bluetooth link
would interfere with sensitive control equipment—an aircraft being the primary
example. Interference issues are explained in more depth later in this chapter.
Considering Connection Times
With a radio link, although the connections can be unconscious, connection
times can be lengthy as transmitters and receivers all need to synchronize before
communication can commence.These limitations could have serious consequences
if the wireless link was of a critical nature—for example, a “panic
button,” a life-dependant medical monitor, or an engine management system.
There are two delays in setting up a Bluetooth link. First, it takes time to discover
devices in the neighborhood. In device discovery, a device sends out
inquiry packets, and receives responses from devices in the area, then reports these
to the user. It can take ten seconds to find all the devices in an area, and even
then you will only find those devices which are willing to report their presence.
Some devices may not be set to scan for inquiries, in which case you will never
find them!
A second delay occurs when you set up the connection itself.Again, this can
take up to ten seconds.This lengthy connection time means that Bluetooth
devices are unsuitable for systems where a fast response is needed, such as automatic
toll collection on busy roads.
Coping with Limited Bandwidth
Wireless can also mean “slower.” An Internet connection via a Bluetooth LAN is
limited to the maximum data rate (723.2 Kbps) over the air interface. After
allowing for management traffic and the capacity taken up by headers for the various
protocol layers, even less is available to applications at the top of the stack.
This will not compete with a high-speed wired link.Thus, for sending or downloading
vast amounts of data, a Bluetooth wireless connection would not be the
optimum method.
This also impacts on audio quality: Bluetooth technology simply does not
have the bandwidth for raw CD quality sound (1411.2 Kbps). However, if a suitable
compression technique is employed (using MP3 to compress an audio stream
down to 128 Kbps, for example), it is feasible to use an ACL link for high-quality
audio.The quality of a Bluetooth SCO link is certainly not high quality—it is
approximately equivalent to a GSM telephone audio link (64 Kbps).
Compression can be useful for data devices. If large amounts of data are to be
sent, using a compressed format will obviously speed up transfer time.
Considering Power and Range
Power is a critical consideration for wireless devices. If a product is to be made
wireless, unleashed from its wired connection, where will its power come from?
Often the communication cable also acts as a power cable.With the cable gone,
the subject of batteries is brought into focus, and the inevitable questions arise
concerning battery life, standby time, and physical dimensions.
Some devices, such as headsets, have no need for power when they are connected
with wires. Audio signals come down a wire and drive speakers directly; a

10 Chapter 1 • Introducing Bluetooth Applications
very simple system with no need of extra power connections.When the wires are
replaced with a Bluetooth link, suddenly we need power to drive the link, power
to drive the microprocessor that runs the Bluetooth protocol stack, and power to
amplify the audio signal to a level the user can hear.With small mobile devices
you obviously do not want to install huge batteries, so keeping the power consumption
low is an important consideration.
Deciding on Acceptable Range
The Bluetooth specification defines three power classes for radio transmitters
with an output power of 1 mW, 2.5 mW and 100 mW.The output power defines
the range that the device is able to cover and thus the functionality of your
product must be considered when deciding which power class to use.The user
would not want to have to get up from his desk to connect to the LAN and
therefore requires a higher power radio. Conversely, a cellular phone headset is
likely to be kept close to the phone, making a lower range acceptable, which
allows smaller batteries and a more compact design.Table 1.1 details the respective
maximum output power versus range.
Table 1.1 Bluetooth Radio Power Classes
Power Class Max Output Power Range
Class 1 100 mW 100 meters+
Class 2 2.5 mW 10 meters
Class 3 1 mW 1 meter
It is important to realize that the range figures are for typical use. In the
middle of the Cambridgeshire fens, where the land is flat and there is not much
interference, a Class 1 device has been successfully tested at over a mile. But in a
crowded office with many metal desks and a lot of people, the Bluetooth signal
will be blocked and absorbed, so propagation conditions are far worse and ranges
will be reduced.
Recognizing Candidate Bluetooth Products
Taking into account the preceding sections, we can see that for a product to be a
candidate for Bluetooth technology, it needs to adhere to the six loosely defined
There are two delays in setting up a Bluetooth link. First, it takes time to discover
devices in the neighborhood. In device discovery, a device sends out
inquiry packets, and receives responses from devices in the area, then reports these
to the user. It can take ten seconds to find all the devices in an area, and even
then you will only find those devices which are willing to report their presence.
Some devices may not be set to scan for inquiries, in which case you will never
find them!
A second delay occurs when you set up the connection itself.Again, this can
take up to ten seconds.This lengthy connection time means that Bluetooth
devices are unsuitable for systems where a fast response is needed, such as automatic
toll collection on busy roads.
Coping with Limited Bandwidth
Wireless can also mean “slower.” An Internet connection via a Bluetooth LAN is
limited to the maximum data rate (723.2 Kbps) over the air interface. After
allowing for management traffic and the capacity taken up by headers for the various
protocol layers, even less is available to applications at the top of the stack.
This will not compete with a high-speed wired link.Thus, for sending or downloading
vast amounts of data, a Bluetooth wireless connection would not be the
optimum method.
This also impacts on audio quality: Bluetooth technology simply does not
have the bandwidth for raw CD quality sound (1411.2 Kbps). However, if a suitable
compression technique is employed (using MP3 to compress an audio stream
down to 128 Kbps, for example), it is feasible to use an ACL link for high-quality
audio.The quality of a Bluetooth SCO link is certainly not high quality—it is
approximately equivalent to a GSM telephone audio link (64 Kbps).
Compression can be useful for data devices. If large amounts of data are to be
sent, using a compressed format will obviously speed up transfer time.
Considering Power and Range
Power is a critical consideration for wireless devices. If a product is to be made
wireless, unleashed from its wired connection, where will its power come from?
Often the communication cable also acts as a power cable.With the cable gone,
the subject of batteries is brought into focus, and the inevitable questions arise
concerning battery life, standby time, and physical dimensions.
Some devices, such as headsets, have no need for power when they are connected
with wires. Audio signals come down a wire and drive speakers directly; a

10 Chapter 1 • Introducing Bluetooth Applications
very simple system with no need of extra power connections.When the wires are
replaced with a Bluetooth link, suddenly we need power to drive the link, power
to drive the microprocessor that runs the Bluetooth protocol stack, and power to
amplify the audio signal to a level the user can hear.With small mobile devices
you obviously do not want to install huge batteries, so keeping the power consumption
low is an important consideration.
Deciding on Acceptable Range
The Bluetooth specification defines three power classes for radio transmitters
with an output power of 1 mW, 2.5 mW and 100 mW.The output power defines
the range that the device is able to cover and thus the functionality of your
product must be considered when deciding which power class to use.The user
would not want to have to get up from his desk to connect to the LAN and
therefore requires a higher power radio. Conversely, a cellular phone headset is
likely to be kept close to the phone, making a lower range acceptable, which
allows smaller batteries and a more compact design.Table 1.1 details the respective
maximum output power versus range.
Table 1.1 Bluetooth Radio Power Classes
Power Class Max Output Power Range
Class 1 100 mW 100 meters+
Class 2 2.5 mW 10 meters
Class 3 1 mW 1 meter
It is important to realize that the range figures are for typical use. In the
middle of the Cambridgeshire fens, where the land is flat and there is not much
interference, a Class 1 device has been successfully tested at over a mile. But in a
crowded office with many metal desks and a lot of people, the Bluetooth signal
will be blocked and absorbed, so propagation conditions are far worse and ranges
will be reduced.
Recognizing Candidate Bluetooth Products
Taking into account the preceding sections, we can see that for a product to be a
candidate for Bluetooth technology, it needs to adhere to the six loosely defined
Let’s examine the traditional headset and mobile phone and decide if
Bluetooth technology makes this more convenient for the user.With current
hands-free technology, you have to decide in advance if you require the handsfree
option.This involves fitting your car with a hands-free kit—a microphone or
headset plugged in, with the wire trailing from it to your phone which is either
in your pocket, clipped to your jacket/belt, in a cradle on your dashboard, or like
most of us, fallen down between the seat and the handbrake!
When you receive a call, you answer by pressing a button on the cable;
volume control is available via a button on the cable.The limitation is that you
always have to have your telephone with you; it can only be as far away as the
cable is long.Thus, it is always a conscious decision to use the headset, and to
decide to plug it in! With a Bluetooth headset and phone, the phone can be
inside your briefcase, in the boot of the car, in your jacket on the hook in the
office, in fact, absolutely anywhere—as long as it’s within the range of the
headset. In much the same way as the conventional technology, you press a
button on the headset to receive a call or to adjust the volume.The connection
between the two devices is extremely different, however, and although virtually
invisible to the user, it will incur a connection time overhead. First, the headset
must “pair” with the Audio Gateway (AG), the Bluetooth part of the phone.This
allows Bluetooth addresses to be swapped, and link keys to be established.The
headset will then be able to make a connection to the AG or the AG will be able
to connect to the headset—the exact operation is a software application issue. If
the headset connects to the phone, then the phone needs to know why, either to
set up voice dialing, action voice dialing, or some other function. If the phone
connects to the headset, it patches a SCO link across and the headset can be used
to take the incoming call.
The connection time could be a problem if you must connect every time a
call comes in. After ten seconds of trying to make a connection, the caller has
probably decided you are not going to answer and given up! A low power park
mode allows headset and phone to stay constantly connected without draining
their batteries; this overcomes the slow connection problem. So you must
beware—if connection time is an issue for your product, make absolutely sure
your system supports park mode—although it’s becoming increasingly common,
it’s still possible to buy devices that do not support it.
My conclusion would be that Bluetooth technology would make answering
my phone far more convenient, although extremely expensive at the moment! I
do not have to worry where my phone is, per-equip my car, or have to endure a

• Introducing Bluetooth Applications
cable running from my ear. If the complex connection issues are invisible to me
and I look as cool as Lara Croft (she wore the original Ericsson Bluetooth
headset in the Tomb Raider movie), who really cares! However if it turns into a
software setup nightmare and I have to read through vast user guides, I would not
be so sure.
The medical sector offers many opportunities for Bluetooth technology to
add convenience. In hospitals, patient medical data could be stored on PDA
type devices that would update a central database when brought within range
of an access point (small scale trials for this application in the neurology department
at the University Hospital in Mainz, Germany, have already begun).
Wireless foot controls for medical equipment, respiratory monitors that transmit
data to a PDA rather than a body-worn data collection system, ambulatory
monitoring equipment for easier patient access in emergency situations… the
list goes on.The questions of interference and security will need to be
addressed in some of these applications, but if they are not “life-dependant”
these issues could be overcome.
Regarding the LAN access points, we need to consider the issue of range. If
the consumer has to get up and walk to be within range, there is no added convenience—
in fact, it would become very inconvenient. A Class 1 Bluetooth
device has a range of approximately 100 meters. In reality, this could be much
further, which would be viable in an office, home, or a hotel/airport lounge scenario,
thus making possible the unconscious convenience of the airport check-in
and car rental confirmation detailed at the beginning of this chapter.
With our own personal “toys” the added convenience is unequivocal. Our
laptops will be able to play multiuser Quake with our colleagues in the airport or
the office! Our PDAs and phones will synchronise with our laptops—gone are
the days of database management. Our presentations can be shown at meetings
directly on the laptops of the attendees without the need for a projector or any
worries about forgetting your laptop’s I/O expander.
Against this optimistic picture there are a few inconveniences envisaged that
will affect the consumer. I wouldn’t be happy if my new wireless product spends
longer attached to a battery charger than it can be used without one, if the poor
placement of an antenna within a handheld product means I had be a contortionist
to be able to hold it and have it function, or if calls get dropped while
waiting for my headset to connect to my phone. But the BIG one is inevitably the
man-machine interface (MMI)—it must be simple to use, it must be simple to set
up, it simply must be simple:“connect to Adam’s PDA, Petra’s phone, or the

Introduction

As human beings, we accept without question that we have the ability to communicate,
that if we speak or write according to a pre-defined set of linguistic
rules that we will succeed in conveying information to one another.The tools of
human communication, producing sounds that are perceived as speech or creating
words on a page, once learnt are used without thought.The limitation on these
physical processes that we take for granted is the actual translation of thoughts
into effective and meaningful statements.When it comes to electronic communication,
however, there is very little that can be assumed or taken for granted.
Communication between electronic devices can only be achieved when they also
abide by a set of predetermined rules and standards—the Open Systems
Interconnect (OSI) model for communications systems protocol stacks being the
primary example, and the basis from which many others have evolved.
These standards need to be applied to every aspect of the communication
process, from the manipulation of data at the highest level to the utilization of
physical transmission media at the lowest. Electronic communication has evolved
significantly over the last decade from the earliest packet switched data networks
(PSDNs) and the Xerox, Ethernet, and IBM Token Ring local area network
(LAN) technologies, to the now common-place mobile telephony and dedicated
high-speed data communication. (How would we survive without e-mail and
the WWW?)
New technologies are now emerging that allow wireless communication.The
IEEE 802.11b or Wi-Fi standard is becoming accepted as the choice for the networking
community as it supports features that enable it to perform handovers
between access points, and it can effectively become a transparent wireless network,
expanding the static wired network. IEEE 802.11b has a data throughput
of up to 11 Mbps, which gives it viability against wired networks.This is evolving
further with the advent of IEEE 802.11a and its competitor HyperLAN2 with
even greater data rates.This technology is expensive and therefore not compatible
with price-conscious consumer products, but we have now been provided with
the means to create wireless, low-power, cost-effective, unconscious and ad-hoc
connectivity between our devices. Its name: Bluetooth. If we believe all of the
hype surrounding Bluetooth technology, we can expect our fridge to use our
mobile phone to order groceries over the Internet, and, of course, end up
ordering an extremely expensive new car instead of a steak! Yes, we have all seen
the jokes, but in reality we can utilize this technology now to develop products
that will allow us to throw away all the wires—and communicate without cables.
Excellent, we all think, and our imagination races into the realms of Science
Fiction, removing the wires from everything! Musing on using our mobile phone
to communicate and control everything the same way we use the TV remote to
operate our entertainment systems.
This is a book for engineers in the real world, so let’s take a long hard look
at what Bluetooth technology really does offer. For some applications, Bluetooth
technology delivers the dream of convenient wireless connectivity. For other
applications, however, it just isn’t the right answer.You do not want to spend a
lot of time and effort learning about Bluetooth technology only to realize it isn’t
for you, so we are going to start out by analyzing what the features of a really
good Bluetooth product are. If your application does not fit into the Bluetooth
scheme of things, you can put the book down after this chapter and go and look
elsewhere.
If you make it past this chapter, you can be confident Bluetooth technology is
right for you.There will still be quite a few make or break pitfalls before you
have a killer application, but they are minor issues compared to choosing the
wrong technology.
What you need to know before reading this chapter:
 There are no pre-requisites for this chapter, though a broad familiarity
with communications products will be useful.
Why Throw Away Wires?
Wired or wireless? Let’s examine just why we’d want to connect without wires,
and what it might offer us in tangible terms; we can use the paradigm of our
own personal area network (PAN).We have a PC with its ubiquitous mouse and
keyboard, a laptop, a personal digital assistant (PDA), a mobile phone with a
“hands free” kit and a printer. How do we currently communicate between these
devices? The answer is: with a rather unwieldy network of cables, hubs, and connectors—
plugging, unplugging, and synchronizing often with the compulsory
intervention of the overworked and often less-than-friendly IT department!
In the wired solution scenario that we are all accustomed to, all of the mobile
devices are used in the singular—the interaction between them is always userinitiated.
We generally keep our contacts’ addresses in our PCs or laptops, while
their phone numbers also need to be entered into our mobile phone’s directory.
We are effectively forced to become database managers simply in order to maintain
an up-to-date record of our contact’s details.We connect to our company
LAN via user-initiated password entry and connect to a printer only if we have
already installed the driver or have administrator rights on our PC’s—nothing is
unconscious.
Figure 1.1 illustrates the alternative scenario—to Bluetooth-enable all of these
devices.The simple act of utilizing Bluetooth technology as cable replacement
removes the problem of the actual physical connections and the unconscious and
ad-hoc connection capability of the technology can allow communication
between the devices with no user intervention at all (OK, after some software
configuration and initial device setup!).
This fully wireless scenario can be achieved because of the master/slave nature
of the Bluetooth technology. All devices are peers, identified by their own unique
48-bit address, and can be assigned as a master either by function or user intervention.
A master can connect to up to seven slaves at the same time, forming a
piconet—this “point-to-multipoint” feature is what sets Bluetooth apart from other
wireless technologies. Figure 1.2 illustrates several connection scenarios.
Figure 1.1 A Bluetooth PAN (Doesn’t Include Power Cables to PC
and Printer)
Headset
Cellular
Phone
PDA
Laptop
Mouse
Printer
In the ultimate scenario, a member of one piconet can also belong to another
piconet. Figure 1.3 illustrates the scatternet, wherein a slave in one piconet is also
the master of a second piconet—thus extending the networking between devices.
A device in my PAN can communicate with one in yours!
Let us put this into context by interpreting exactly what “unconscious and
ad-hoc connections” can mean to us in real life, and how the fundamental components
of the Bluetooth PAN in Figure 1.1 can be integrated into a wireless
infrastructure to enhance our lives and even reduce the need to queue!
Adding Usability to Products
Mr. I.M.Wireless is embarking on a business trip. At the airport, as he gets
within range of the airline’s counter, his reservation is confirmed and a message
is sent to his mobile phone detailing flight confirmation, personal boarding reference,
seat information and departure gate number, which he listens to via a
headset being that his phone is actually in his briefcase.While in the departure
lounge, he connects to the Internet and accesses his e-mail via his mobile
phone or the wireless LAN Access Point fitted in the lounge. He boards his
flight and during the journey composes e-mails which will be sent as he enters
the range of a LAN in the arrivals lounge or again via his mobile phone. He
walks to the rental car company’s counter to pick up his keys—as with the airline,
all booking, payment, and car location details would have been transmitted
between his PDA/mobile telephone and the rental company’s computer. He
starts to drive the rental car and his PDA downloads his hotel information into
the car’s on-board systems, which allows the navigation system to smoothly
direct him to its location. On arrival, his room booking reservation is already
confirmed. At his meeting, the normal 15-minute exchange of business cards is
removed as all of the personal information is exchanged automatically via his
PDA. He then uses his PDA to run his presentation from his laptop, which all
attendees at the meeting are viewing simultaneously on their own laptops. Back
in his hotel room after the meeting, his PDA synchronizes with both his laptop
and mobile phone—now the telephone details of all the new contacts he met
are stored in his mobile phone directory and the address and e-mail information
in his laptop. Later, while relaxing, he listens to MP3 files stored on his
laptop with the same headset that he answers his phone with. He also uses his
digital camera to send “an instant postcard” via his mobile phone and the
Internet to his wife’s PC at home (obviously, it won’t be a picture from the
Karaoke evening arranged by his clients!)
If we extract some conclusions from this slightly excessive example, we find
that wireless connectivity offers us immense freedom and convenience. It allows
us to perform tedious tasks with a minimum of intervention, allows some of our
devices to have dual functionality, and makes the vast array of cables we inevitably
always leave in the office redundant. Bluetooth technology “will” change the
assumptions we all have about our electronic devices.With the cables gone, the
idea of having a particular gadget for a specific job will no longer be relevant.
With many of the devices already available to consumers, this scenario grows
closer to reality every day.
As human beings, we accept without question that we have the ability to communicate,
that if we speak or write according to a pre-defined set of linguistic
rules that we will succeed in conveying information to one another.The tools of
human communication, producing sounds that are perceived as speech or creating
words on a page, once learnt are used without thought.The limitation on these
physical processes that we take for granted is the actual translation of thoughts
into effective and meaningful statements.When it comes to electronic communication,
however, there is very little that can be assumed or taken for granted.
Communication between electronic devices can only be achieved when they also
abide by a set of predetermined rules and standards—the Open Systems
Interconnect (OSI) model for communications systems protocol stacks being the
primary example, and the basis from which many others have evolved.
These standards need to be applied to every aspect of the communication
process, from the manipulation of data at the highest level to the utilization of
physical transmission media at the lowest. Electronic communication has evolved
significantly over the last decade from the earliest packet switched data networks
(PSDNs) and the Xerox, Ethernet, and IBM Token Ring local area network
(LAN) technologies, to the now common-place mobile telephony and dedicated
high-speed data communication. (How would we survive without e-mail and
the WWW?)
New technologies are now emerging that allow wireless communication.The
IEEE 802.11b or Wi-Fi standard is becoming accepted as the choice for the networking
community as it supports features that enable it to perform handovers
between access points, and it can effectively become a transparent wireless network,
expanding the static wired network. IEEE 802.11b has a data throughput
of up to 11 Mbps, which gives it viability against wired networks.This is evolving
further with the advent of IEEE 802.11a and its competitor HyperLAN2 with
even greater data rates.This technology is expensive and therefore not compatible
with price-conscious consumer products, but we have now been provided with
the means to create wireless, low-power, cost-effective, unconscious and ad-hoc
connectivity between our devices. Its name: Bluetooth. If we believe all of the
hype surrounding Bluetooth technology, we can expect our fridge to use our
mobile phone to order groceries over the Internet, and, of course, end up
ordering an extremely expensive new car instead of a steak! Yes, we have all seen
the jokes, but in reality we can utilize this technology now to develop products
that will allow us to throw away all the wires—and communicate without cables.
Excellent, we all think, and our imagination races into the realms of Science
Fiction, removing the wires from everything! Musing on using our mobile phone
to communicate and control everything the same way we use the TV remote to
operate our entertainment systems.
This is a book for engineers in the real world, so let’s take a long hard look
at what Bluetooth technology really does offer. For some applications, Bluetooth
technology delivers the dream of convenient wireless connectivity. For other
applications, however, it just isn’t the right answer.You do not want to spend a
lot of time and effort learning about Bluetooth technology only to realize it isn’t
for you, so we are going to start out by analyzing what the features of a really
good Bluetooth product are. If your application does not fit into the Bluetooth
scheme of things, you can put the book down after this chapter and go and look
elsewhere.
If you make it past this chapter, you can be confident Bluetooth technology is
right for you.There will still be quite a few make or break pitfalls before you
have a killer application, but they are minor issues compared to choosing the
wrong technology.
What you need to know before reading this chapter:
 There are no pre-requisites for this chapter, though a broad familiarity
with communications products will be useful.
Why Throw Away Wires?
Wired or wireless? Let’s examine just why we’d want to connect without wires,
and what it might offer us in tangible terms; we can use the paradigm of our
own personal area network (PAN).We have a PC with its ubiquitous mouse and
keyboard, a laptop, a personal digital assistant (PDA), a mobile phone with a
“hands free” kit and a printer. How do we currently communicate between these
devices? The answer is: with a rather unwieldy network of cables, hubs, and connectors—
plugging, unplugging, and synchronizing often with the compulsory
intervention of the overworked and often less-than-friendly IT department!
In the wired solution scenario that we are all accustomed to, all of the mobile
devices are used in the singular—the interaction between them is always userinitiated.
We generally keep our contacts’ addresses in our PCs or laptops, while
their phone numbers also need to be entered into our mobile phone’s directory.
We are effectively forced to become database managers simply in order to maintain
an up-to-date record of our contact’s details.We connect to our company
LAN via user-initiated password entry and connect to a printer only if we have
already installed the driver or have administrator rights on our PC’s—nothing is
unconscious.
Figure 1.1 illustrates the alternative scenario—to Bluetooth-enable all of these
devices.The simple act of utilizing Bluetooth technology as cable replacement
removes the problem of the actual physical connections and the unconscious and
ad-hoc connection capability of the technology can allow communication
between the devices with no user intervention at all (OK, after some software
configuration and initial device setup!).
This fully wireless scenario can be achieved because of the master/slave nature
of the Bluetooth technology. All devices are peers, identified by their own unique
48-bit address, and can be assigned as a master either by function or user intervention.
A master can connect to up to seven slaves at the same time, forming a
piconet—this “point-to-multipoint” feature is what sets Bluetooth apart from other
wireless technologies. Figure 1.2 illustrates several connection scenarios.
Figure 1.1 A Bluetooth PAN (Doesn’t Include Power Cables to PC
and Printer)
Headset
Cellular
Phone
PDA
Laptop
Mouse
Printer
In the ultimate scenario, a member of one piconet can also belong to another
piconet. Figure 1.3 illustrates the scatternet, wherein a slave in one piconet is also
the master of a second piconet—thus extending the networking between devices.
A device in my PAN can communicate with one in yours!
Let us put this into context by interpreting exactly what “unconscious and
ad-hoc connections” can mean to us in real life, and how the fundamental components
of the Bluetooth PAN in Figure 1.1 can be integrated into a wireless
infrastructure to enhance our lives and even reduce the need to queue!
Adding Usability to Products
Mr. I.M.Wireless is embarking on a business trip. At the airport, as he gets
within range of the airline’s counter, his reservation is confirmed and a message
is sent to his mobile phone detailing flight confirmation, personal boarding reference,
seat information and departure gate number, which he listens to via a
headset being that his phone is actually in his briefcase.While in the departure
lounge, he connects to the Internet and accesses his e-mail via his mobile
phone or the wireless LAN Access Point fitted in the lounge. He boards his
flight and during the journey composes e-mails which will be sent as he enters
the range of a LAN in the arrivals lounge or again via his mobile phone. He
walks to the rental car company’s counter to pick up his keys—as with the airline,
all booking, payment, and car location details would have been transmitted
between his PDA/mobile telephone and the rental company’s computer. He
starts to drive the rental car and his PDA downloads his hotel information into
the car’s on-board systems, which allows the navigation system to smoothly
direct him to its location. On arrival, his room booking reservation is already
confirmed. At his meeting, the normal 15-minute exchange of business cards is
removed as all of the personal information is exchanged automatically via his
PDA. He then uses his PDA to run his presentation from his laptop, which all
attendees at the meeting are viewing simultaneously on their own laptops. Back
in his hotel room after the meeting, his PDA synchronizes with both his laptop
and mobile phone—now the telephone details of all the new contacts he met
are stored in his mobile phone directory and the address and e-mail information
in his laptop. Later, while relaxing, he listens to MP3 files stored on his
laptop with the same headset that he answers his phone with. He also uses his
digital camera to send “an instant postcard” via his mobile phone and the
Internet to his wife’s PC at home (obviously, it won’t be a picture from the
Karaoke evening arranged by his clients!)
If we extract some conclusions from this slightly excessive example, we find
that wireless connectivity offers us immense freedom and convenience. It allows
us to perform tedious tasks with a minimum of intervention, allows some of our
devices to have dual functionality, and makes the vast array of cables we inevitably
always leave in the office redundant. Bluetooth technology “will” change the
assumptions we all have about our electronic devices.With the cables gone, the
idea of having a particular gadget for a specific job will no longer be relevant.
With many of the devices already available to consumers, this scenario grows
closer to reality every day.