Bluetooth Low Energy Introduction

If you want to take the leap and learn a little bit about Bluetooth Low Energy then this is the place to start.

Bluetooth Low Energy is powerful technology and now it’s available for everyone because it is inexpensive and less complex than it’s older brother, Bluetooth classic.


Bluetooth Low Energy is incredibly flexible; anyone can create a custom profile for specific applications and still adhere to the Bluetooth SIG.


Let’s first talk basic terminology and then go into details:

  • Master (or “central“) devices scan for other devices. Usually, the master is a smartphone/tablet/PC (Bluetooth Smart Device).
  • Slave (or “peripheral“) devices advertise and wait for connections. Usually, the slave is a small device like a fitness tracker or a smartwatch.
  • Client devices access remote resources over a BLE link using the GATT protocol. Usually, the master is also the client but that is not required.
  • Server devices have a local database and access control methods, and provide resources to the remote client. Usually, the slave is also the server (again, that is not required)
  • A device can switch between a Master and Slave but it cannot be both at the same time.
  • A device can be a Server and Client at the same time.
  • You can use readwritenotify, or indicate operations to move data between the client and the server.
  • Read and write operations are requested by the client and the server responds (or acknowledges).
  • Notify and indicate operations are enabled by the client but initiated by the server, providing a way to push data to the client.
  • Notifications are unacknowledged, while indications are acknowledged. Notifications are therefore faster, but less reliable.



So what is the difference between a master and a slave? First let me remind you that a master and a slave is not interchangeable with client/server.

A master (or Central) is the BLE device that initiates an outgoing connection request to an advertising peripheral device.

A slave (or Peripheral) is the BLE device which accepts an incoming connection request after advertising.

A slave can only be connected to one master, but a master can be connected to multiple slaves. In the smartwatch example, your iPhone can theoretically connect to multiple smartwatches at the same time. However, your smartwatch can only ever connect to one smartphone at a time.

There is no limit in the Bluetooth SIG on the number of slaves a master can connect to. Generally this will be limited by the BLE technology or Bluetooth stack you use.



Let’s move on to the differences between a GATT server and a GATT client

A GATT client is a device which accesses data on the remote GATT server via read, write, notify, or indicate operations.

A GATT server is a device which stores data locally and provides data access methods to a remote GATT client.

You can easily see that it is possible for a device to be a GATT server and a GATT client at the same time. While it is most common for the slave (peripheral) device to be the GATT server and the master (central) device to be the GATT client, this is not required. The GATT functionality of a device is logically separate from the master/slave role. The master/slave roles control how the BLE radio connection is managed, and the client/server roles are dictated by the storage and flow of data.


What is GATT and how do we move information from one device to another?

A GATT database implements one or more profiles, and each profile is made up of one or more services, and each service is made up of one or more characteristics. For example:


You can implement as many profiles, services, and characteristics as you need. When using a non-standard profile, a 128bit UUID is required and must be generated randomly by you. You can also adhere to any Bluetooth SIG profiles (services, and characteristics) currently supported, in which case your profile UUID is 16bit long.

For example, you decided to create a smartwatch that also measures your heart rate. You can either implement the standard “Heart Rate” profile from the Bluetooth SIG or you can implement your own which could look like this:


Every BLE device acting as a GATT server must implement the official Generic Access service. This includes two mandatory characteristics: Device Name and Appearance.


Remember that a service is made up of one or more characteristics. However, one characteristic may be comprised of many different attributes.

Each attribute is given a unique numerical handle which the GATT client may use to reference, access, and modify it. Every characteristic has one main attribute which allows access to the actual value stored in the database for that characteristic. When you “write a value to a characteristics” or “read the value of the characteristic” you are doing read and write operations o the main data attribute (of said characteristic).

Some other related attributes are read-only (such as a Characteristic User Description attribute), some control the behavior of the characteristic (such as the Client Characteristic Configuration attribute which is used to enable notify or indicate operations).

Every attribute has a UUID. These may be either 16 bits (e.g. “180A“) or 128 bits (e.g. ” 6BCF0ED3-68E3-4804-96D5-5AB8765FB9BC “). All 16-bit UUIDs are defined by the Bluetooth SIG and are known as adopted UUIDs. All 128-bit UUIDs are custom and may be used for any purpose without approval from the Bluetooth SIG. Two very common 16-bit UUIDs that you will see are 2901, the Characteristic User Description attribute and 2902, the Client Characteristic Configuration attribute (to enable either “notify” or “indicate” on a characteristic).

One important note is that some attribute UUIDs do not technically need to be unique. Their handles are always unique, but the UUIDs occasionally overlap. For example, every Client Characteristic Configuration attribute has a UUID of 0x2902, even though there may be a dozen of them in a single GATT database. You should always give your own custom characteristics fully unique UUIDs.


The four operations for moving data in BLE are: Read, Write, Notify, Indicate. The BLE protocol specification requires that the maximum data payload size for these operations is 20 bytes, or in the case of read operations, 22 bytes. BLE is built for low power consumption, for infrequent short-burst data transmissions. Sending lots of data is possible, but usually ends up being less efficient than classic Bluetooth when trying to achieve maximum throughput.

This is the reason that many Bluetooth headsets and wireless speakers still use Bluetooth Classic whereas Temperature sensors and Heart Rate monitors will use Bluetooth Low Energy.

Here are a few general guidelines about what kind of data transfer you will need to use:

  • If the client needs to send data to the server, use write.
  • If the client needs to get data from the server on-demand (i.e. polling), use read.
  • If the server needs to send data to the client without the client requesting it first, use notify or indicate. (The client must subscribe to these updates before any data will be transferred.)
  • The server cannot pull data from the client directly. If this is necessary, the server must use notify or indicate to send pre-arranged request data to the client, and then the client may follow up with a write operation to send back whatever data that the server needs.
  • Read – this operation is requested by the GATT client on a specific attribute exposed by the GATT server, and the server then responds with the requested value.
  • Write – this operation is requested by the GATT client on a specific attribute exposed by the GATT server, and a new value to write is provided at the same time. The server then stores the new value and (optionally) acknowledges the write operation back to the client.
  • Notify – this operation is initiated by the server when a new value is written to a notify-enabled characteristic. If the client has subscribed to notifications on that characteristic, then the new value is pushed to the client when it is written. Notifications are not acknowledged, but you may send more than one notification in a single connection interval, which can be helpful for maximizing throughput. Notifications cannot be enabled by the server; they must be enabled by the client in order for the actual data transmission to occur.
  • Indicate – an indicate operation is identical to a notify operation except that indications are acknowledged, while notifications are not. This increases reliability at the expense of speed.

Typically, the GATT server functionality is provided by one side and the client functionality is entirely on the other side, but it could be that both sides provide both kinds of functionality. This does not usually pose any advantages for a well-designed and efficient BLE project—it usually complicates the implementation needlessly—so we will not go into it here.

This concludes BLE 101. The best thing you can do now is pick up a module or development board and try it out. The best feature about BLE is that it is almost free.

*images courtesy of Apple.