Architecture of Bluetooth Low Energy

The architecture of Bluetooth Low Energy is divided into three important layers:

• Application
• Host
• Controller

Refer to the following figure:

Figure 9: Bluetooth Low Energy architecture

We shall touch on every segment/layer briefly before delving deeper into each of the layers.

Application

We will develop multiple applications for several IoT and Bluetooth Low Energy use cases throughout the course of this book and these applications will be hosted in the application layer of a Bluetooth Low Energy compatible device. This is the layer which will contain the user interface, application logic, and the overall application architecture.

A working knowledge of this layer is necessary to start building Bluetooth Low Energy oriented applications. However, it is always good to know what goes under the hood and how our application talks to the underlying Bluetooth Low Energy hardware/chipset; hence, we will also explore the host and the controller layers.

Host

Lying just the following Application layer is the Host layer, which has the following layers:

• Generic Access Profile (GAP): This defines how Bluetooth Low Energy devices access and communicate with each other. Bluetooth Low Energy devices can connect to each other in one of the following roles:
  • Broadcaster: Also referred to generically as peripheral, this is a role where a Bluetooth Low Energy device broadcasts/advertises information packets.
  • Observer: Also referred to generically as central, this is a role where a Bluetooth Low Energy device listens for the packets and then decides to initiate a connection, or not, depending on the use case.
• Generic Attribute Profile (GATT): This defines how data or attributes are formatted, packaged, and sent across connected devices according to its described rules. Similar to GAP, there are certain roles that interacting devices can adopt:
  
  • Client: This typically sends a request to the GATT server. The client can read and/or write attributes/data found on the server.
  • Server: One of the main roles of the server is to store attributes/data. Once the client makes a request, the server must make the attributes/data available.
• Attribute Protocol: This defines rules for accessing attributes/data on a device. A GATT profile is built on top of the attribute protocol. Although GATT implements the client server roles, these are defined by the Attribute Protocol. This protocol also defines the fact that data on a server will be arranged in the form of attributes each of which will have:
  • A 16-bit attribute handle
  • A UUID
  • A set of permissions
  • A value

Next, the protocol also defines various read and write operations for attributes also known as ATT operations:

• Read Operations
• Write Operations: These are of type Write Requests with Response (write to an attribute and expect a response), Write (write without expecting acknowledgement), Signed Write (similar to write but uses a signature to authenticate the data)
• Indications: These are asynchronous notification operations initiated by the server for the client. This is initiated if the client has subscribed to the updates of attribute values. It requires an acknowledgement from the client.
• Notifications: are similar to an indication. The only difference is that they do not require an acknowledgement from the client.

All in all, Attribute Protocol is just a set of rules related to accessing data. Don't worry if you don't understand the significance of it at this stage. We will be covering the significance of these characteristics/attributes and related operations in the upcoming sections:

• Security Manager Protocol: This defines rules regarding authentication processes such as pairing
• Logical Link Controller and Adaptation Protocol (L2CAP): This defines the following rules:
  • Fragmentation and defragmentation of application data
  • Multiplexing and demultiplexing of multiple channels over a shared logical link

The Host layer defines three very important specifications, that is, characteristics, services, and profiles, which help Bluetooth Low Energy devices to discover, identify, and talk to each other.

It really can't be stressed enough that a thorough understanding of these three specifications is absolutely imperative to design robust Bluetooth Low Energy oriented applications. We will go over each of these in detail, right after we have briefly touched on the controller layer.

Controller

Simply speaking, the controller is the actual Bluetooth chip or hardware, which facilitates transmission and receipt of Bluetooth signals:

Figure 10: TI CC2540 Bluetooth Low Energy SoC

It consists of the Link Layer and the Physical Layer. As the name already suggests, the Physical layer consists of all the complex analog circuits, which transmit and receive the digital data over the air. The Link Layer, on the other hand, is responsible for scanning, advertising, creating, and maintaining links (connections) between devices. The link layer can have five states: Standby, Advertising, Scanning, Initiating, and Connection (master- slave):

Figure 11: Link Layer States, source: www.bluetooth.com

Delving deeper into the three main pillars of the Bluetooth Low Energy technology should have already given you an idea of what lies under the hood. Now, as promised, let's discuss the important specifications defined by the Host layer, starting with profiles.