Article summary
Imagine having a lamp in your house that you can control from your phone. You don’t need to pass Gigabytes of data back and forth, you only need a hand full of bytes to tell the lamp to turn on, or off, or report its current status. You also shouldn’t need to be in constant, on-going communication with the lamp. You should be able to connect long enough to send a command and then stop communicating. Every bit of data that is transmitted or received uses more energy, so reducing the data throughput reduces the energy usage.
This is exactly the type of interface provided by Bluetooth LE (marketed as Bluetooth Smart). New devices are entering the market today that, because of Bluetooth LE, are capable of doing things that have never been possible before.
Less Energy = More Possibilities
People are becoming more and more connected, and with that they want to control every device in their homes (from the thermostat to the front porch light) with their smartphones. At the same time, there’s a never-ending push for devices to decrease in size and use less energy.
Most communication protocols are increasing their data rates with every spec that is released, but the Bluetooth Special Interest Group realized that no wireless protocol was trying to bring connectivity to many devices, while keeping cost and size at a minimum. Their latest version, v4.0, significantly reduced the data rate and added Bluetooth LE (“low energy”). It’s finally starting to gain some traction.
With version 4.0 of the specification, the Bluetooth SIG focused on two main areas of change in order to reduce power usage, cost, and size of electronics.
- They sought to reduce the complexity of the protocol. Generally speaking, the more complicated a protocol is, the more memory and processing power you need to implement it. By simplifying the protocol, you can simplify the device that implements it.
-
They changed the data model. All previous versions of the Bluetooth spec brought faster transfer rates which supported (and encouraged) moving larger amounts of data in less time. But with v4.0, the stack has been revamped to focus on moving small pieces of data.
How Does it Work?
Client-Server Model
As part of the attempt to simplify the protocol, the Bluetooth LE has shifted to using a client-server model for data access. In our earlier example of a smart lamp, the lamp would essentially be a very simple server. A client can come along and make a request to the server for the lamp status to determine if it’s on or off. It might also make a request to set the state of the lamp to a new value.
From a programming standpoint, this new client-server is quite convenient to work with. When spec-ing out a Bluetooth LE service, you do not need to include details about both sides of the connection; you only need to frame the behavior and characteristics of one side at a time. This allows code to be easily tested because the interface is pure and predictable.
Attributes
The client-server model described above is made possible by the “Attributes Protocol” that is fundamental to Bluetooth LE. In the model, a server is serving specific pieces of data which are referred to as attributes. Common attributes might be the device name, the current temperature, a battery level indication, a volume, etc.
When an attribute is defined, it has an associated access rule. This can be readable, writeable, or readable and writable. For a smart thermostat, you might want to allow the set point to be written to and read but the current temperature (measured from a sensor) should never be written by a client.
The Attribute Protocol also supports defining authentication and authorization restrictions on attributes. Any client device can discover what attributes a client has available but if that client is not authenticated it might not be allowed to read or write the value of the attribute.
Requests and Data Transfers
Generally, a Bluetooth LE client will issue a request to read or write an attributes value and the server will respond with either the requested value or an acknowledgment. However, the protocol supports a few other options. Using a “Write Command” a client can set the value of an attribute without invoking a response from the server.
Another feature supported by the protocol is data transfers that are initiated by the server. These are called Notifications and Indication. An Indication is always acknowledged by the client with a response where a Notification invokes no response.
References
Most of the information in this post came from Bluetooth Low Energy: The Developer’s Handbook, a great book by Robin Heydon. I would highly recommend reading it cover to cover if you’re planning on developing your own Bluetooth LE device or application.