Getting started with Bluetooth Low Energy


One of the main features of the Bluetooth 4 specification is Bluetooth Low Energy (BLE). Also called Bluetooth smart, this technology allows peripherals to communicate by consuming much less energy than regular Bluetooth. Another major advantage is that the user does not need to manually pair with the device using the system settings. This article serves as a quick introduction to BLE and shows how to make an iOS that connects to a BLE peripheral.


Bluetooth Low Energy is also abbreviated to BLE. For clarification, the Bluetooth 4 specification defines a set of technologies which include Classic Bluetooth, Bluetooth high speed and Bluetooth low energy protocols. So be careful to check the compatibility of the peripheral with BLE.
We can recognize a BLE peripheral if it contains in its specifications the terms “Bluetooth smart” “Bluetooth Low Energy” or “BLE”.
Now that we have some BLE peripherals, we will see in the next section how they communicate.

BLE communication; the central and the peripheral:

In the BLE world there are two type of devices: peripheral and central.
A peripheral is a device that exposes services and data for reading or writing.
The central is a device that connects to peripherals in order to read or write data exposed by the peripherals. The central is the device that initiates the connection to the peripheral.
In a client / server model the central can be seen as the client and the peripheral can be seen as the server.
Some devices can act a as central peripheral at the same time. iOS and Mac devices are such an example.
Peripheral / central example:

  • Smart-bands such the MI-Band is a peripheral.
  • The iPhone that connects to a smart band acts as a central.




In the next section, we will introduce the possible communication modes in BLE.

BLE communication modes

The are two communication modes in BLE:

  • Advertising mode: the peripheral sends information to be available to all the centrals around. This mode allows a peripheral to be known by centrals, thus the term “advertising”. In this mode, simple information can be exchanged using GAP broadcasting. In the perspective of a peripheral, this is a one-to-many mode.
  • Connected mode: allows a central to exchange complex data with a peripheral. The GATT protocol describes how the conversation is made in this mode. In the perspective of a peripheral, the connected mode is a one-to-one mode.

Here are some additional rules:

  • A central cannot connect to another central and a peripheral cannot connect to another peripheral.
  • A peripheral can be connected to only one central device at a time

In the following section, we delve into more details about the communication in connected mode.

BLE communication in connected mode; services and characteristics:

The GATT protocol defines how a central can communicate with a connected peripheral. First of all the data structure is defined like this:

  • The peripheral exposes fields that the central car read, write or be notified of. Each of these fields is called a characteristic. A characteristic is also accompanied by a descriptor which explains it.
  • Characteristics are grouped into a service.
  • We can also group services into a profile.

Let’s take an example: a heart rate monitor is BLE peripheral that has a rate profile which in turn has 2 services: a Heart rate service and a Device information service. The heart services define a read characteristic that provides the measured heart rate. It also defines a write characteristic for the body sensor location. The device information services contains characteristics about the model, the firmware version, etc. of the device.

Each characteristic and service is defined by a unique identifier called UUID. There are predefined UUIDs for many services and characteristics. You can find a list here:

Of course, you can define your own UUID for your services and characteristics. You are also not obliged to recuse predefined UUIDs. Official BLE UUIDs are on 16 bits and custom one take 128bits. They are generally represented in hexadecimal form. For example the UUID of the heart rate service is 0x180D.