How GAP and GATT Work — Bluetooth Low Energy Basics

---

Originally Published in 2013 and Updated April 1, 2024:
Bluetooth Low Energy (BLE) continues to evolve, and understanding the roles of the Generic Access Profile (GAP) and the Generic Attribute Profile (GATT) is crucial in leveraging this technology effectively. This updated article provides expanded information on GAP vs GATT and additional resources to support you on your BLE development journey.

Introduction

Bluetooth Low Energy (BLE) is a pivotal innovation in wireless technology, offering power efficiency and streamlined connectivity. Central to BLE’s functionality are the Generic Access Profile (GAP) and the Generic Attribute Profile (GATT), essential for anyone involved in BLE technology. The team at Punch Through can certainly attest to that, having built and tested “x” number of consumer and medical IoT solutions over the past 15+ years.

Originating from the Bluetooth Special Interest Group (SIG), BLE is an advanced protocol that evolved from the rich heritage of Bluetooth Classic. It stands out by consuming significantly less power, simplifying device pairing, and maintaining lower connection speeds — all while providing reliable communication.

In this article, we’ll delve into the difference between GAP vs GATT. You’ll gain a clear understanding of their roles and functionalities within the BLE framework, making it easier to develop and build interoperable IoT devices.

---

How do GAP and GATT differ?

It is important to differentiate between GAP vs GATT. While independent, they work together to facilitate seamless BLE communication. 

The Bluetooth Protocol Stack is divided into the controller and the host. Each category has sub-categories, which perform specific roles: Generic Access Profile (GAP) and Generic Attribute Profile (GATT).

• GAP defines the device discovery and connections of the BLE network stack.
• GATT manages how attributes (data) are transferred once devices have a dedicated connection.

GATT specifically focuses on how data is formatted, packaged, and sent according to its described rules. In the BLE network stack, the Attribute Protocol (ATT) is closely aligned with GATT, where GATT sits directly on top of ATT. GATT uses ATT to describe how data is exchanged between two connected devices.

Generic Access Profile (GAP): Navigation Connections & Communications

There are two mechanisms a BLE device can use to communicate to the outside world: broadcasting or connecting. These mechanisms are subjected to the Generic Access Profile (GAP) guidelines. GAP defines how BLE-enabled devices can make themselves available and how two devices can communicate directly with each other.

Getting Connected: Navigation Connections and Communications

GAP dictates how BLE devices discover each other and establish connections, playing a crucial role in defining BLE network availability and direct communication. Since our last update, GAP has seen enhancements in handling extended-range connections and improved data broadcasting methods, which are crucial for IoT devices and smart applications.

A device can join a BLE network by adopting these roles specified in GAP:

Broadcasting Roles

What distinguishes broadcasting roles is that they don’t have to connect to one another to transfer data explicitly.

• Broadcaster: A device that sends public advertising data packets without the need for a direct connection. For example, advertisement data may indicate how long a button has been pressed.
• Observer: A device that listens to the data in the broadcasting packets without establishing a connection.

Connecting Roles

Connecting roles are different from broadcasting roles in that they must explicitly connect and handshake to transfer data. These roles are more commonly used than the broadcasting roles.

• Peripheral: A device that advertises its presence so central devices can establish a connection.
  • After connecting, peripherals no longer broadcast data to other central devices and stay connected to the device that accepted the connection request.
  • Peripherals are low-power because they only have to advertise periodically. 
  • Central devices are responsible for starting communication with peripherals.
  • Airpods are an example of a BLE peripheral.
• Central: A device that initiates a connection with a peripheral device by first listening to the advertising packets.
  • A central device can connect to many other peripheral devices.
  • When the central device wants to connect, it sends a connection request data packet to the peripheral device. If the peripheral device accepts the request from the central device, a connection is established.
  • Your smartphone is an example of a BLE Central device when it connects to Airpods.

Once You’re Connected: Post-Connection Dynamics in GAP

• Central Devices: The central device typically establishes the connection parameters between the peripheral device and itself. The central device can only modify the connection parameters. However, the peripheral device can ask the central device to change the connection parameters.

• Peripheral Devices: Can request changes in connection parameters.

Both central and peripheral devices may terminate a connection intentionally at any time. Connections may also be terminated inadvertently for a variety of reasons, including loss of power or network interference.

Generic Attribute Profile (GATT): Managing & Organizing Data

GATT focuses on how data is formatted, packaged, and exchanged between devices. The GATT layer defines hierarchical relationships between attributes, characteristics, services, and profiles. Attributes are grouped into characteristics and are often consolidated into a service. Profiles consist of one or more services. The Bluetooth SIG has developed a variety of standard profiles and services for common use cases, though customization is also common.

Roles in GATT

Similar to GAP, there are certain roles that interacting devices can adopt:

• Client: Request data from the server and are capable of reading and writing attributes.
• Server: Stores and makes attributes available upon client requests.

An Example of Client-Server Relationships

One example of a client-server relationship is as follows: 

I completed a workout wearing my smart fitness tracker, and I want the computer to read and display my fitness data. In this scenario, the smart fitness tracker acts as a server, providing information about my workout. The computer, running a fitness application, acts as a client, reading that workout information.

GAP vs GATT roles are essentially independent of one another. Peripheral or central devices can be servers or clients, depending on the direction of data flow. For instance, if I wanted to configure settings or update firmware from the computer to the smart fitness tracker, the computer would act as a server, sending the necessary data or commands, while the fitness tracker would act as a client, receiving and implementing these instructions.

GAP and GATT Considerations in BLE Development

While GAP and GATT form the backbone of BLE technology, their practical application comes with some development considerations. Here are some considerations and resources that can help you address them:

• Complex Implementation: GAP and GATT’s intricate roles and procedures require a deep understanding of effective implementation. You can find a more comprehensive overview of its implementation and other key aspects in The Ultimate Guide to BLE Connectivity Architecture.
  
• Security: Implementing secure data transfer via GATT without compromising efficiency requires careful consideration. There is where BLE Security: Where to Begin When Creating a Connected System, guide will come in handy.
  
• Connection Management: Effectively managing connection parameters for optimal power, speed, and reliability balance is crucial. If you want a comprehensive guide to addressing connection management, explore Ultimate Guide to Managing Your BLE Connection.
  
• Data Throughput and Latency: Maximizing throughput while minimizing latency in GATT transactions is essential, especially in real-time applications. Given the size of this topic we’ve dedicated three separate posts on how you can best address BLE throughput:
  
  • Maximizing BLE Throughput on iOS and Android – Part 1
  • Maximizing BLE Throughput: Use Large ATT MTU – Part 2
  • Maximizing BLE Throughput: Data Length Extension – Part 3
  • Maximizing BLE Throughput: Everything You Need To Know – Part 4
    
• Debugging: Identifying and resolving issues in wireless communication can be complex and time-consuming. Our BLE development and debugging tool, LightBlue, is our go-to resource to help. It’s free and available on both iOS and Android. We also recommend this guide on BLE Sniffers: Debugging when you may need to upgrade for a deeper dive into leverage sniffers for testing and optimization.

We hope you found this Bluetooth Low Energy Basics useful. While we listed a number of helpful articles here, for a more comprehensive resource on your BLE development journey, check out the Punch Through Resource Hub.