Bluetooth Low Energy- speak up about the architecture - (second part)

after the short introduction that we had in our first blog let us dive deeply now in the architecture of BLE

physical layer :

The physical layer is the part that actually contains the analog communications circuitry, capable of modulating and demodulating analog signals and transforming them into digital symbols. The radio uses the 2.4 GHz ISM (Industrial, Scientific, and Medical) band to communicate and divides this band into 40 channels from 2.4000 GHz to 2.4835 GHz.

The Link Layer:

The Link Layer is the part that directly interfaces with the physical layer and it is usually implemented as a combination of custom hardware and software and it defines the main role of ble device see previous blog.

Host Controller Interface (HCI):

he Bluetooth specification defines HCI as a set of commands and events for the host and the controller to interact with each other, along with a data packet format and a set of rules for flow control and other procedures.

L2CAP :

the most important layer in the bluetooth stack is Logical Link Control and Adaptation Protocol without is we couldn’t use ble as one of most important wireless technologies in IoT you can take look at the other wireless protocols in this blog, this layer provides two pieces of functionality First, it serves as a protocol multiplexer that takes multiple protocols from the upper layers and encapsulates them into the standard BLE packet format .

It also performs fragmentation and recombination, a process by which it takes large packets from the upper layers and breaks them up into chunks o draw a simple comparison, L2CAP is similar to TCP, in that it allows a wide range of protocols to seamlessly coexist through a single physical link, each with a different packet size and requirements.

For Bluetooth Low Energy, the L2CAP layer is in charge or routing two main protocols:the Attribute Protocol (ATT) and the Security Manager Protocol (SMP)

Attribute Protocol (ATT):

The Attribute Protocol (ATT) is a simple client/server stateless protocol based on attributes presented by a device. In BLE, each device is a client, a server, or both, irrespective of whether it’s a master or slave. A client requests data from a server, and a server sends data to clients. . Each server contains data organized in the form of attributes, each of which is assigned
a universally unique identifier (UUID), a set of permissions, and finally, of course, a value.

When a client wants to read or write attribute values from or to a server, it issues a read or write request to the server . The server will respond with the attribute value or an acknowledgement. In the case of a read operation, it is up to the client to parse the value and understand the data type based on the UUID of the attribute. On the other hand, during a write operation, the client is expected to provide data that is consistent with the attribute type and the server is free to reject the operation if that is not the case.

Security Manager (SM):

The Security Manager (SM) is both a protocol and a series of security algorithms designed to provide the Bluetooth protocol stack with the ability to generate and exchange security keys, which then allow the peers to communicate securely over an encrypted link, to trust the identity of the remote device, and finally, to hide the public Bluetooth Address if required to avoid malicious peers tracking a particular device.

Generic Access Profile (GAP):

The Generic Access Profile (GAP) dictates how devices interact with each other at a lower level, outside of the actual protocol stack. GAP can be considered to define the BLE topmost control layer, given that it specifies how devices perform control procedures such as device discovery, connection, security establishment, and others to ensure interoperability and to allow data exchange to take place between devices from different vendors.
GAP establishes different sets of rules and concepts to regulate and standardize the low level operation of devices:
• Roles and interaction between them
• Operational modes and transitions across those
• Security aspects, including security modes and procedures

GATT:

The Generic Attribute Profile (GATT) establishes in detail how to exchange all profile and user data over a BLE connection. In contrast with GAP , which defines the low-level interactions with devices, GATT deals only with actual data transfer procedures and formats.

GATT uses the Attribute Protocol as its transport protocol to exchange data between devices. This data is organized hierarchically in sections called services, which group conceptually related pieces of user data called characteristics. This determines many fundamental aspects of GATT discussed in this chapter.

the GATT protocol starts by defining roles :

Client:

The GATT client corresponds to the ATT client, It sends requests to a server and receives responses (and server initiated updates) from it. The GATT client does not know anything in advance about the server’s attributes, so it must first inquire about the presence and nature of those attributes by performing service discovery. After completing service discovery, it can then start reading and writing attributes found in the server, as well as receiving server-initiated updates.

Server:

The GATT server corresponds to the ATT server . It receives requests from a client and sends responses back. It also sends server-initiated updates when configured to do so, and it is the role responsible for storing and making the user data available to the client, organized in attributes. Every BLE device sold must include at least a basic GATT server that can respond to client requests, even if only to return an error response.

UUIDs:

A universally unique identifier (UUID) is a 128-bit (16 bytes) number that is guaranteed to be globally unique. UUIDs are used in many protocols and applications other than Bluetooth, and their format, usage, and generation is specified in ITU-T Rec. X.667, alternatively known as ISO/IEC 9834–8:2005.

Attributes:
Attributes are the smallest data entity defined by GATT (and ATT). They are address‐able pieces of information that can contain relevant user data about the structure and grouping of the different attributes contained within the server. Both GATT and ATT can work only with attributes, so for clients and servers to interact, all information must be organized in this form.

Permissions:

Permissions are metadata that specify which ATT operations can be executed on each particular attribute and with which specific security
requirements. ATT and GATT define the following permissions:
Access Permissions
Similar to file permissions, access permissions determine whether the client can read or write (or both) an attribute value each attribute can have one of the following access permissions:
None
The attribute can neither be read nor written by a client.
Readable
The attribute can be read by a client.
Writable
The attribute can be written by a client.
Readable and writable
The attribute can be both read and written by the client

Value:

The attribute value holds the actual data content of the attribute

Services:

GATT services group conceptually related attributes in one common section of the attribute information set in the GATT server.

Characteristics:

You can understand characteristics as containers for user data. They always include at least two attributes: the characteristic declaration and the characteristic value

the figure below presents the hierarchy of GATT server