Chapter 14. Peripherals

The hand is the cutting edge of the mind.

—Jacob Bronowski

This chapter looks at the design of peripherals, tying together all the parts of this book from the perspective of a peripheral.

14.1. Background

Peripherals are the lifeblood of the Bluetooth low energy ecosystem. While a central device will typically be in a phone, television, or computer, peripherals are custom-designed products that are heavily optimized for ultra-low power consumption.

Peripherals are mostly designed around their battery, their sensors, their inputs and outputs; only then is the wireless technology considered. For peripherals to work, they must interact with central devices. They can do this in three different ways: they can broadcast data; they can be discovered and connected to by a central device; or they can stay disconnected and then establish connections as they need.

14.2. Broadcast Only

Some devices will have a single quantum of data that they want to share with many other devices. The best and lowest power way to do this is by using the broadcasting model. For example, a device that knows the current time and wants to share it with every other device in the area would broadcast that time data so that other devices can receive the current time.

A peripheral that only does broadcasting can be very power efficient. It does not need to be discoverable or connectable. It does not need to accept any connections from central devices or have an extensive attribute database that can be discovered. It just constantly broadcasts useful data.

One consideration is the broadcast interval or frequency at which the device will broadcast. For example, it is possible to broadcast the current time every 100 milliseconds, or 10 times a second. But given that the current time is typically only accurate to the nearest second, it is not worth wasting the energy broadcasting the time repeatedly within a one-second interval. Therefore, the interval at which some data is broadcast may be based on the time that a user is willing to wait before the data is available.

The current time is probably something that can be broadcast at reasonably slow intervals because the observers of this information will only listen infrequently for this information. Say, once a day, or even once a week. Thus, a broadcast interval of once every 10 seconds would then be reasonable.

It is interesting to note that a wall clock that synchronizes its time from a broadcaster once a day only needs to be accurate to the nearest second over the course of that day. A wall clock that would normally be off by half a minute a month would be made more accurate by synchronizing with an accurate time broadcaster once a day.

14.3. Being Discoverable

Apart from peripherals that only broadcast, all other peripherals will start off being discoverable. Discoverable means that the peripheral is advertising to any scanning central device in the area that is looking for peripherals.

There are two types of discoverability: limited and general discoverability. A peripheral is only limited-discoverable for a short time after interacting with the user. At all other times that the peripheral needs to be discoverable it would be generally discoverable.

For example, when the batteries of a peripheral are first installed by the user, it would be limited-discoverable. This makes it possible for a central device, probably held by the same user, to display this new device at the top of a list on the user interface.

Peripherals would also be limited-discoverable immediately after a connect button is pressed on the device. Again, the user would expect to see the peripheral at the top of the list of devices after he has pressed that connect button.

Peripherals don’t need to be discoverable all the time. It is very common for devices that have paired with a central device to never be discoverable again or to only become discoverable again after the connect button is pressed. This has two advantages.

First, peripherals that are not discoverable don’t need to include information in their advertising packets that is related to discoverability such as the device name or the current Transmit Power.

Second, central devices that are looking for devices to discover will only want to display devices that are of interest to the user, and not all peripherals in the area. By peripherals not being discoverable all the time, the list presented to the users of central devices will be much more manageable and useful.

14.4. Being Connectable

Being discoverable and connectable are very similar to one another; they both use advertising packets, yet they serve different purposes. Discoverable devices are typically not paired with any other device, whereas connectable devices are typically bonded with one or more devices and would only accept connections from those devices.

When a device is connectable, it accepts connection requests from initiating central devices that want to connect to it. Essentially, when a peripheral is connectable, it accepts connections from any device that sends it a connection request packet.

This promiscuous behavior is not great from a power consumption point of view. If any central device can connect with the peripheral, it can take lots of time talking with the peripheral, wasting the peripheral’s power, and probably more important, preventing the peripheral’s bonded centrals from connecting to it.

To solve the this problem, the controller in a peripheral device can be configured to only accept connections from a limited set of central devices. The set of central devices is stored in a white list, and any connection request from a device that is not in that white list is ignored. This way, the peripheral need only accept connections from the central devices that are bonded and in the white list; thus, the peripheral only uses power to talk with its bonded devices.

This model of only accepting connections from bonded devices in a white list can only be used once the device is bonded. Before this is enabled, the device must be promiscuous and accept connections from any device. Typically, this is only when the device is initially connectable and not bonded with any devices yet.

14.5. Exposing Services

Once in a connection, the peripheral typically exposes one or more services. Each of these services encapsulates the atomic behavior of a component of the peripheral. These services are exposed through attributes by using an Attribute Protocol server. The collection of attributes in a server is normally referred to as an attribute database.

The organization of these attributes is determined by the Generic Attribute Profile (GAP). It has the following structure:

Each service in the attribute database starts with a service declaration that defines the type of the service. The attributes belonging to the service follow this declaration. Next comes the service declaration for the ensuing service.

Within each service, there can be one or more other services that are included by a service. Included services make it possible to incorporate more complicated behavior within a service without extending the core functionality of that service. This encourages the definition of services that only implement some small piece of functionality.

For example, the Battery Service only exposes the battery level. A device like a camera might have two batteries, one for the flash and one for the main camera body. These components can have their own services; for example, the Camera Flash Service and the Camera Service. The Camera Service would therefore include both the Battery Service for the main camera and the flash service. The Camera Flash Service would include a separate Battery Service for the flash.

Also within each service, there can be one or more characteristics. A characteristic is fundamentally a single value that can be accessed. But each characteristic also has a characteristic declaration that defines what the data is, how it can be accessed, and can also include additional information that describes how it is formatted or how it is configured.

Each of these service declarations, service includes, characteristic declarations, characteristic values, and characteristic descriptors are individual attributes within the attribute database. Therefore, the peripheral just exposes the attributes it needs to expose, depending on what behavior it is exposing, and then waits for a client to come along and interact with these attributes.

14.6. Characteristics

Characteristics are the fundamental building blocks of services. A characteristic is just a value with which a client can interact. The format of the value of a characteristic is determined by the characteristic type, and ultimately by an XML file that is the characteristic specification.

The behavior of a characteristic is not defined by this XML file; rather, it is defined in a service specification. Therefore, within a single peripheral, it is possible to have multiple characteristics with the same type, but different behaviors.

For example, the Alert Level characteristic is used in both the Immediate Alert Service and the Link Loss Service, but the behavior is different. In the Immediate Alert Service, the Alert Level characteristic is only writable and causes the peripheral to make an immediate alert based on the value written. This value is not readable because the value of the characteristic is consumed immediately; this is known as a control point characteristic.

In the Link Loss Service, the Alert Level characteristic is both readable and writable and causes an alert only when the central disconnects from the peripheral, based on the value of the characteristic at the point of disconnection. In this service, the characteristic has state and can be read and written. When it is written, the value is stored and can be read at a later point in time.

14.7. Security Matters

A peripheral device can expose data that could be considered confidential or private, or should only be sent to authenticated devices. To ensure this, the attribute server refuses any request for information about an attribute that it considers cannot be completed within the current level of security.

For example, if the client requests to read the number of unread emails from a phone or wants to write the ringer level of a phone, these should only be acceptable from a device that has been authenticated and for which confidentiality can be assured. This requires that the peripheral first authenticates and then bonds with the requesting central device. Typically, it is the central device that initiates the authentication and bonding. Once the devices are authenticated, the connection can be encrypted and the client requests can be re-sent.

This security model is very simple for a peripheral. For each request received by the peripheral’s attribute server, the server first checks the security permissions required to accept the request. If the security permissions are insufficient, the server will send back an error response with a suitable error, giving a hint to the server about how it can go about fixing the problem before resending the request. If the security permissions are acceptable, the server will act upon the request and send back a response. At no point does the peripheral have to initiate any security requests.

The security that is required by a service or a characteristic within a service is defined by the service specification that is being implemented. Some services might require no security because they are exposing public information such as the current time. Some services might require very strong security, particularly if they are exposing private personal information.

14.8. Optimizing for Low Power

For peripherals to be able to operate with only the power provided by tiny batteries, for extended periods of time, consideration must be given to optimizing the peripheral for low-power operation. This includes determining the best advertising and connection intervals, optimizing access to attributes, and choosing whether to stay connected or to disconnect and reconnect.

To understand how low power can be achieved, consider the typical states that a peripheral device uses (see Figure 14–1). This starts with the peripheral being off. Obviously, when off, it is using no (or very little) power. When the device is first powered on, it moves to the discoverable advertising state. In this state, the peripheral is discoverable and can be found by one or more central devices.

Figure 14–1. The typical states of a peripheral device

At some point, a central device will connect with the peripheral and then bond. Upon bonding, the peripheral moves to the connectable advertising state. If bonding doesn’t happen, the peripheral moves back to discoverable advertising and waits for another central device with which to connect and bond.

Once the devices are bonded, the peripheral will use connectable advertising. Then, only central devices that have paired with this peripheral can make a connection to the peripheral. Once they do reconnect, they move to the connected state and manage their connection intervals, depending on what the central device is doing.

When connected, the peripheral also needs to determine if it should disconnect now, or stay connected. This decision is more relevant if the central device has not made any requests recently, or if the peripheral has not sent any data to the central device or is not expecting to do so for some time.

When it does disconnect, it can move to one of two possible states. One would use the connectable advertising, in which the peripheral is periodically advertising so that the central device can reconnect as it needs. The other option is that the peripheral doesn’t advertise at all until it has some data to send, at which point it would use directed advertising to reconnect to the central.

Finally, don’t forget that the peripheral might have a connect button that when pressed removes the current bond and allows the peripheral to be discoverable again. Any devices that were connected at that point would be disconnected, and the device returns to the discoverable advertising state.

14.8.1. Discoverable Advertising

One of the most fundamental ways to optimize for low power in a peripheral is to choose appropriate intervals for advertising and connection intervals. The choice of good values could mean the difference between a device that has a few weeks’ battery life and one that has a few years’ battery life. But the choice is not simple because there are many compromises that must be made.

A peripheral device will typically start out performing discoverable advertising so that central devices can find it. The time that the peripheral is in this mode of operation should typically be very short in the total lifetime of the device because the user will want to take the device out and connect to it as quickly as possible. Once connected, the device will revert to only connectable advertising.

When in this discoverable mode, the peripheral will want to be found quickly, to provide the best user experience possible. It will also be advertising lots of additional information such as the transmit power so that the central device can sort devices by proximity; the device name to build a good user interface; and the set of services that the device supports to enable the central device to filter devices if necessary.

A discoverable peripheral device should therefore be willing to advertise at a fairly rapid rate to be discovered quickly. An advertising interval of about 250 milliseconds would be a good compromise between the speed of discovery and power savings.

14.8.2. Bonding

Whenever the peripheral engages in a connection, the connection intervals are determined by the central device. The central device should use sensible connection interval values—but this is not guaranteed.

Once the peripheral makes a connection from the discoverable advertising state, the connection interval can be fairly fast. A fast connection interval—for example, between 7.5 milliseconds and 25 milliseconds—can use lots of power, but it also means that the central device can discover the set of services and characteristics that this peripheral offers, and therefore can provide prompt feedback to the user about how it can interact with the peripheral.

If the connection interval is very slow (between 1 second and 4 seconds), it can take an extremely long time before the central device determines how to utilize the peripheral and the user might think that the device is not working.

Once the device is bonded and the central device has finished analyzing the device, it should be able to reduce the connection interval significantly to save power. The correct interval to choose is discussed a little later on. The central device can also start using the exposed services on this peripheral. At some point the device will disconnect.

Once the bonded peripheral is disconnected, it could move to the connectable advertising state, or to the directed advertising state. Each of these options is detailed in the following sections.

14.8.3. Connectable Advertising

When the peripheral is disconnected, it can periodically advertise to allow the central device to reconnect. The advertising interval used in this state is a compromise between how fast a central device can reconnect to this peripheral and the power consumption that the peripheral will use when disconnected.

For some peripherals, the time when not in a connection will be significant. For example, a heart-rate belt might only be connected while the user is running for an hour, three times a week. Each week, the heart-rate belt is therefore connected for three hours, but for the other 165 hours, it is in a connectable advertising state. Therefore, the peripheral should seriously consider the benefits of using a longer connectable advertising interval.

A connectable advertising interval of 1 second would allow a central device to be able to connect within a few seconds. This is probably a perfectly acceptable time for the average user. However, if the device needs to allow the central to make a connection quicker, then it would have to decrease the connectable advertising interval to 0.5 second or less.

It should also be noted that some devices would not need to advertise continuously. Again, let’s look at the example of the heart-rate belt. When this peripheral is not being worn, the device does not need to use connectable advertising. It can therefore disable advertising when it’s not being worn and save a significant amount of power when it is disconnected.

If the heart-rate belt is worn, it can then use more power when it is advertising, perhaps using a 100 millisecond advertising interval. This gives the user the impression that once she puts the belt on, it connects instantly—an excellent user experience. Obviously, if the central is not ready to initiate a connection with the heart-rate belt at this time, it would be prudent for the heart rate belt to move to a slower advertising rate, using a longer advertising interval, to save power in those cases when the belt is being worn but the central device is not within range.

14.8.4. Directed Advertising

Some peripherals will want to connect directly with a central device when something happens. For peripherals, where the time between something happening and when it sends a notification about the event to the central device must be as short as possible, it is best to use directed advertising.

Directed advertising burns a lot of power on the peripheral because the peripheral transmits lots of advertising packets very quickly to a single central device. If that central device is ready to initiate a connection to this peripheral, it will immediately connect, allowing the peripheral to send whatever data it needs, quickly.

Directed advertising is also the quickest way for a peripheral to make a connection to a central device. Connection times of fewer than 3 milliseconds are possible, including the transmission of application data.

There is no way to configure the intervals used when using directed advertising because the advertising packets must be sent every 3.75 milliseconds on each of the 3 advertising channels. This means that there will be one directed advertising packet transmitted by the peripheral every 1.25 milliseconds, or 800 packets per second.

For a peripheral that must send data very quickly, and that also rarely needs to be connectable, directed advertising is probably the best model.

14.8.5. Connected

When in a connection, the central device has complete control over the connection intervals and latency used by the peripheral. The peripheral does have the option to make a request to the central’s host, by using a Logical Link Control and Adaptation Protocol (L2CAP) signaling channel command to suggest to the central device that the values currently being used are not useful.

For example, if the central device is monitoring the proximity of the peripheral device it would only need a connection interval rate of perhaps three times a second. If the actual connection interval used is shorter than this, the peripheral would be forced to use too much power synchronizing with the central with no user benefit. If the connection interval used is longer than this, the peripheral would possibly be synchronizing so slowly that the pair of devices would not be able to detect the movement of the devices early enough to warn the user.

There are two configurable values for the connection parameters that relate to power consumption: the connection interval and the slave latency. The connection interval is a time that determines how often the central will transmit and synchronize with the peripheral device. This is any multiple of 1.25 milliseconds.

The connection interval is not the most significant factor. The slave latency is much more important from a peripheral power consumption point of view. The slave latency determines the number of master connection intervals that the slave can ignore. This is a value from 0 to 500.

For example, suppose that the connection interval is 12.5 milliseconds and the slave latency is 0, then the slave would have to listen every 12.5 milliseconds for the master. This would burn a lot of power. With the same 12.5 milliseconds connection interval but a slave latency of 1, the slave can ignore one connection interval but must listen to the next one. This halves the power consumption of the slave, yet allows the slave to have the same ability to send data within 12.5 milliseconds if necessary.

The slave latency is not just a way for the slave device to save power; it also determines the latency that any data from the master can be sent to the slave. For example, if you have a keyboard with a Caps-Lock light, then this light might need to be turned on and off within 0.5 second. If the connection latency was 12.5 milliseconds, slave latency would have to be 39. The slave could then skip 39 out of every 40 packets from the master, and therefore would listen once every 500 milliseconds. This would also allow the slave to save a significant amount of power compared with a slave latency of 0 or 1. Of course, this is an approximation because it assumes a perfect channel without the need for retransmissions. In practice, retransmissions will be required, so sometimes latency will be greater.

It should be noted that this is not a never-ending benefit. For example, if the data flow were only from the peripheral to the central device, it could be possible to use a very high slave latency. However, using a very high slave latency yields diminishing returns.

For example, consider a mouse that only sends data to a computer. If the connection interval is 15 milliseconds, and the slave latency is set to 500, then the mouse would only need to listen once every 7.5 seconds. But consider the fact that both the central and the peripheral are timed based on clocks that have a certain level of inaccuracy. In the worst case, these inaccuracies can amount to 500 parts per million on each device. In other words, every second, the timing of either the central or the peripheral might be off by up to half a millisecond.

This means that after the 7.5 seconds of time that the mouse has not been in synchronization, its concept of time could be off by 3.75 milliseconds, as would that of the master, possibly in different directions. Therefore, the total uncertainty would be 7.5 milliseconds. The peripheral has to listen for an additional 7.5 milliseconds before the time when it has calculated the master should be transmitting, and up to 7.5 milliseconds after. This is called window widening. This burns power. So every 7.5 seconds, the radio has to be on for 7.5 milliseconds (best case).

If the slave latency was only 50, the mouse would have to listen once every 750 milliseconds, but the window widening would mean that the slave has to listen 0.75 milliseconds early. Unsurprisingly, this requires the same proportion of time for window widening as the previous example.

The peripheral also must receive and transmit some empty packets, an 80 microsecond packet from the master and an 80 microsecond packet in reply. As the slave latency increases, the time taken to transmit and receive the packets becomes insignificant; therefore, the additional power savings from not having the slave synchronize frequently is lost to window widening.

As a result, it makes no sense to set a slave latency of greater than about 1 second or fewer than 300 milliseconds. Below this range, the power used to repeatedly synchronize is higher than it would be to wait a little bit longer. Above it, the power used by window widening doesn’t save any significant amount of power, and so it is better to use the lower latency to enhance the user experience.

14.8.6. Stay Connected or Disconnect

When the peripheral is connected, the use case might require that data is transferred at a random interval. A peripheral that is performing in such a use case could stay connected or disconnect and then reconnect when it has some more data.

There are two main decisions to make. First, can the central device reconnect back to the peripheral in a reasonable latency if the peripheral starts advertising so that the users don’t know that it was disconnected? Second, if it does stay connected, what connection latency is being used or is possible to ask for, such that the battery life is still acceptable?

To enable the peripheral to make more informed decisions, the Scan Parameters Service can be exposed on a peripheral so that a central device can inform the peripheral what scan parameters it is using. When the central device connects to the peripheral, it discovers this service on the peripheral, and the central device can then write the latency that it will honor to the peripheral when reestablishing a connection. Using this information, a peripheral can determine if and when it should disconnect, given the excepted user experience.

For example, if the connection latency written by the central device into the peripheral’s scan parameters service is 100 milliseconds, and the peripheral is happy with a latency of 250 milliseconds, then it could theoretically disconnect at any time if it has no data to send. The device knows that it can reconnect within 100 milliseconds and be able to send data. However, although disconnecting saves power, the reconnection procedure uses lots of power. With a 100-millisecond reconnection latency, the peripheral will spend on average 50 milliseconds to make a connection. During these 50 milliseconds, the peripheral will be sending a 176-microsecond packet every 1.25 milliseconds, therefore powering the radio for 8.64 milliseconds.

This doesn’t sound like a very long time. But if the peripheral were connected with a connection interval of 250 milliseconds, and it was not sending any data, it would only have the radio on for 640 microseconds every second. Therefore, the peripheral would have to be connected to the central device for 13.5 seconds before it would use more power staying connected than disconnecting and then reconnecting.

However, unfortunately, it’s not that simple. If the peripheral also wants to be connectable, then it would also need to advertise slowly when disconnected. Suppose that the peripheral has a 1-second advertising interval. It would have to send up to 3 advertising packets that take 504 microseconds. So, the peripheral could stay connected and use 640 microseconds of time every second to stay connected, or it could disconnect, advertise periodically, and then rapidly advertise when it needs to make a reconnection.

Therefore, the peripheral is only saving 136 microseconds per second by disconnecting. This means that the peripheral would actually need to stay connected for over a minute before it makes sense to disconnect. It gets worse: If the peripheral wants to allow a central device to connect quicker, it would need to advertise quicker. An advertising interval of 500 milliseconds would actually use more power than just being in a connection. Therefore, for some devices, it actually makes sense to stay connected all the time.

This implies that for some peripherals, there is no need to implement this service. Once the peripheral is connected, it would remain connected. This really depends on the use case and how the peripheral is used.

Of course, if a peripheral has exposed the scan parameters service but the central device doesn’t write any useful values into the service characteristics, then the peripheral must use guesswork to determine when it should stay connected or it should disconnect. This guesswork is typically a simple matter of staying connected for a given period of time after the last application data was sent. Once this timeout has expired, the peripheral would disconnect. Typical values for this might be measured in the order of minutes or even hours.

14.9. Optimizing Attributes

At the end of the day, the typical use of a peripheral is to provide access to the data it generates. For example, a heart monitor exposes the heartbeat rate of the person who is wearing it. The final optimization that a peripheral can use is how this data is transferred.

Typically, a peripheral exposes one or more services. The central device discovers these services and their characteristics and descriptors. The central device then reads, writes, and configures these characteristics to utilize the services offered by the peripheral. But the peripheral can help itself to save power by implementing notifications and indications about its characteristics.

Characteristics and services are described by using attributes, and these are accessed by using the attribute protocol. This protocol enables a client (in a central device) to access these attributes in a peripheral. The protocol not only makes it possible for attributes to be read and written but also notified and indicated.

Take a characteristic of a device—for example, a measured heart rate—that is being transmitted once per second from the heart-rate monitor to a central device such as a watch or phone. This data transmission could be implemented by reading the characteristic’s value once every second. But this would require a read request to be sent by the central and a read response sent in reply by the peripheral. The peripheral’s radio would be active for 272 microseconds every second just to send the request and receive the response.

If the characteristic is configured for notifications, this would reduce the active time to just 232 microseconds. This is significantly more energy efficient than the polling case. This advantage is more evident when the data is only available at random times and not periodic. In this case, the client might be polling for data more often than is necessary.

Consider a device that monitors a sensor once per second, but the value only changes infrequently, perhaps once every 30 seconds. In this case, polling by using a read request and read response would need to be performed 60 times per minute, but the value might only change once during this time. This requires 60 requests to be sent, and 60 responses to be received in return. This takes 16.32 milliseconds every minute. But, if the peripheral supports notifications, and the central device configures notifications, the radio would only need to be active for 9.744 milliseconds. This is almost half the power consumption of the polling case.

Indications are similar to notifications, except that they also have a response message to acknowledge at the protocol layer that the information has been received. This uses slightly more energy than the preceding notification case, approximately 10 milliseconds, but this has the advantage that no data is lost. Because notifications are not acknowledged at the protocol layer, they can be ignored if the receive buffers are full. But indications can only be sent one at a time and cannot be sent again until a confirmation message has been received.

Notifications and indications are therefore highly efficient when compared with a polling model. A peripheral can help itself be more energy efficient by ensuring that as many characteristics as possible are exposed for notification or indication. This makes it possible for a central device to configure characteristics to be notified or indicated.