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.