BLE GAP Protocol Analysis

BLE problems often first show up as “cannot connect” or “behaves unreliably.” If you trace one layer back, the root cause is usually still in GAP (Generic Access Profile): was the device actually discovered, did the connection really get established as expected, and did the connection parameters push latency or power in the wrong direction?

This article follows Bluetooth Core Specification 4.2 and covers only Legacy Advertising, the basic scan/connect flow, address types, and security levels. It does not expand into later features such as Extended Advertising, 2M PHY (2M Physical Layer), or Coded PHY.

When you put GAP back into an engineering setting, it is responsible for one continuous chain of decisions:

Device enters advertising or scanning state -> discovers the peer -> starts or accepts a connection -> negotiates connection parameters -> enters a stable connection -> decides how the device is identified and accessed by address and security policy

Overview

What GAP actually handles

From an engineering point of view, GAP is not “all of Bluetooth.” It is closer to the entry and connection-management layer of BLE, and it mainly groups these problems together:

• What identity the device presents: Broadcaster / Observer / Peripheral / Central
• What state the device is in: Advertising / Scanning / Initiating / Connection
• How two devices discover each other over the air
• How a connection is established and how its parameters affect latency, power, and stability
• What kind of address the peer sees, and what security level is required to access data

So the most useful way to read GAP is not to memorize every term, but to treat it as the layer that decides how a device appears, how it enters a connection, and how it is identified:

• Without GAP, there is no device discovery and no connection setup
• Without a correct GAP main path, later GATT data exchange and application logic have nothing to stand on
• For most BLE debugging problems, the first question is still: is the issue in advertising, scanning, connection setup, parameters, or address/security policy?

Where GAP sits in the stack

GAP responsibilities:

• Device discovery: advertising and scanning
• Connection management: creating, maintaining, and tearing down connections
• Security management: defining security modes and levels, with pairing implemented by SMP
• Modes and procedures: defining device roles and operating modes

The key engineering point: every BLE application must pass through GAP discovery and connection setup before it gets to GATT data access.

Device roles and operating modes

Four roles:

Roles are not fixed: a device can support multiple roles. A phone, for example, can be both Central and Peripheral.

Five operating modes:

Three useful judgments:

• Roles describe capability; modes describe what the device is doing right now
• A device can support multiple roles, but at any moment it only occupies a limited set of GAP states
• When reading captures, first decide whether the device is the advertiser, scanner, or initiator; many mysteries disappear immediately

Advertising

Advertising channel PDUs and payload format

The important thing about advertising is not memorizing every field. The important thing is understanding what the advertising stage is trying to solve:

• How the device is discovered
• Whether it can be scanned or connected
• What the scanner sees first
• Whether advertising can later transition into a connection

The engineering flow is simple:

Advertiser sends ADV_* advertising packets
-> Scanner receives them
-> Optional SCAN_REQ
-> Advertiser optionally returns SCAN_RSP
-> Initiator optionally sends CONNECT_REQ
-> Both sides enter connection state

Three layers are easy to mix up:

• ADV_IND / SCAN_RSP / CONNECT_REQ are Link Layer PDU types
• AdvData / ScanRspData are the advertising payload areas inside those PDUs
• Length | AD Type | AD Data is the encoding format inside the payload

If you mix those layers, later analysis of “why the device is visible but not connectable,” “why the name appears only sometimes,” or “why filters do not work” becomes much harder.

Common advertising PDU types:

Most devices start with ADV_IND. Only when the scenario is clear should you move to directed reconnects or non-connectable broadcasting.

If you care about debugging, check these three things first:

• Does the advertising type actually allow connection?
• Is the scanner-dependent information really in the primary advertisement?
• Are the name, UUID, and manufacturer data in AdvData or ScanRspData?

Both AdvData and ScanRspData have a 31 bytes limit. Put the minimum discovery information in the primary advertisement and the display or supplementary information in the scan response. The finer points of advertising data layout, common AD Types, and field design are covered in BLE Advertising Analysis.

Timing

A GAP view only needs one key idea: advertising is not always visible. It depends on whether the advertiser and scanner overlap in time.

The most important quantities are:

• Advertising Interval: how often the advertiser sends an advertising event
• Scan Interval: how often the scanner opens a scan cycle
• Scan Window: how long the scanner actually listens in that cycle

If you see “the device is transmitting, but sometimes it cannot be scanned,” first suspect timing overlap, filtering, or environmental interference, not the advertising content itself.

A typical advertising event only needs the three advertising channels 37 / 38 / 39.

Practical checks

At the engineering level, advertising debugging boils down to three things:

• Separate “visible,” “scannable,” and “connectable”
• Decide the advertising type before designing the payload
• Look at advertising interval, scan window, discovery latency, and power together

If you need to go deeper into payload design, scan responses, address semantics, or field debugging, use BLE Advertising Analysis.

Scanning

What scanning solves

A scanner does not know which channel the target network is on after power-up. Scanning solves “what is currently in the air,” not “should I connect.”

The two common methods are:

• Passive scanning: listen for advertising packets
• Active scanning: send SCAN_REQ and wait for SCAN_RSP

What matters later is not just “did I see a device name,” but:

• What name or filtering information is available
• What channel or path it came from
• What the RSSI looks like
• Which advertising fields were actually scanned

What to check in the field

• Seeing a name does not mean the connection will succeed
• Seeing the same name does not mean it is the same device
• Check band support, channel list, hidden-name behavior, and RSSI before blaming the stack

Scanning design and analysis points

What really matters in scanning is three things:

• Passive scanning is simpler and cheaper in power, but it cannot obtain SCAN_RSP
• Active scanning gets more information, but it increases air-interface interaction and power consumption
• Scan Window / Scan Interval is fundamentally a trade between discovery speed and average current

Connection establishment and management

Connection setup flow

CONNECT_REQ parameters:

CONNECT_REQ timing and channel rules:

• Timing: send the request immediately within T_IFS (Inter Frame Space, 150 μs ±2 μs) after receiving ADV_IND
• Channel: must be sent on the same advertising channel (37/38/39) where the ADV_IND was received
• Single transmission: CONNECT_REQ is sent only once and is not repeated on other advertising channels
• Analysis focus: first verify timing, channel, and field consistency, then check whether the data channels really came up

Example timing:
Advertiser                   Initiator
   |                              |
   |---ADV_IND (Ch 38)----------->| received on Ch 38
   |                              | T_IFS = 150μs
   |<--CONNECT_REQ (Ch 38)--------| sent on Ch 38
   |                              |
   [stop advertising]             [enter connection state]

If the first try fails:

• The initiator keeps listening and waits for the next advertising event (at the Advertising Interval)
• The next CONNECT_REQ may be sent on any of the next advertising channels (37/38/39)

How connection success is confirmed:

• CONNECT_REQ itself has no dedicated ACK PDU
• Connection success is confirmed by the first data-channel exchange
• The Central sends the first data-channel packet within the Transmit Window
• The Peripheral must start listening in that window and respond according to the connection-event timing after receiving the packet

How connection failure is judged:

• No first data-channel communication is established within the Transmit Window
• The received packet fails CRC or uses the wrong Access Address
• The Initiator returns to Scanning and can try connecting again

Transmit Window key points:

1. Clock error compensation:

   • The two sides have different oscillator accuracy (SCA: 20-500 ppm)
   • The window provides tolerance for the timing mismatch

2. Processing delay:

   • The Peripheral needs time to switch to the data channels
   • It must start receiving and preparing responses within the window

3. Flexibility optimization:

   • The Central can choose when to send the first packet inside the window
   • The Peripheral only needs to start listening inside the window, not at one exact absolute instant

Common engineering values:

Connection parameters in detail

Connection Interval:

Range: 7.5 ms - 4 s (unit: 1.25 ms)
Value: 0x0006 (7.5 ms) - 0x0C80 (4 s)
Meaning: the interval between two connection events

Slave Latency:

Range: 0 - 499
Meaning: how many connection events the Peripheral may skip
Purpose: reduce power consumption (do not respond when there is no data)

Supervision Timeout:

Range: 100 ms - 32 s (unit: 10 ms)
Value: 0x000A (100 ms) - 0x0C80 (32 s)
Meaning: connection-loss detection time

Parameter constraint:

Timeout > (1 + Latency) × Interval × 2

Example:
Interval = 50 ms, Latency = 4
Minimum Timeout = (1 + 4) × 50 ms × 2 = 500 ms
Recommended Timeout ≥ 1 s (leave some safety margin)

Connection-event timing:

┌────────────────────────────────────────────┐
│      Connection Interval (50 ms)           │
├─────────┬──────────────────────────────────┤
│ CE #0   │         Sleep                    │
│ ████    │                                  │
└─────────┴──────────────────────────────────┘
          ↓
┌────────────────────────────────────────────┐
│      Connection Interval (50 ms)           │
├─────────┬──────────────────────────────────┤
│ CE #1   │         Sleep (Latency=0)        │
│ ████    │                                  │
└─────────┴──────────────────────────────────┘

With Slave Latency = 3:
┌────────────────────────────────────────────┐
│ CE #0   │ Skip #1 │ Skip #2 │ Skip #3 │CE #4│
│ ████    │         │         │         │████ │
└─────────┴─────────┴─────────┴─────────┴─────┘
         ↑                              ↑
      respond to connection       respond after 4 intervals

Connection-parameter tuning strategy

Latency vs power tradeoff:

Selection principles:

1. Low-latency applications: minimize Interval, set Latency = 0
2. Low-power applications: increase Interval and Latency when data updates are infrequent
3. Balanced applications: adjust dynamically based on the real data-transfer rate

Slave Latency constraints:

• Only applies when the Peripheral has no data to send
• If there is data to send, it must respond to the connection event immediately
• Timeout must be large enough to cover the latency period

Connection-parameter update

Method 1: L2CAP Connection Parameter Update Request (initiated by Peripheral)

Method 2: LL_CONNECTION_UPDATE_IND (initiated by Central)

When updates happen:

• At application startup: switch from generic parameters to application-optimized parameters
• When battery is low: increase Interval and Latency to reduce power
• During high traffic: decrease Interval to improve throughput

Update constraints:

• Do not update too often (recommended interval ≥ 1 second)
• Instant must be later than the next 6 connection events
• Failed updates need a retry mechanism

Connection design and debugging points

This chapter is critical for embedded development. Connection establishment and connection parameters often determine 80% of the user experience.

When you get to bring-up, focus on these four points:

• After receiving ADV_IND, CONNECT_REQ must be sent immediately on the same advertising channel and within T_IFS
• CONNECT_REQ is not the same as “connected”; real success is confirmed by the first data-channel exchange afterward
• Connection Interval / Slave Latency / Supervision Timeout must be considered together, not tuned one by one by intuition
• Many problems such as “connected but feels bad,” “occasional disconnects,” and “power is wrong” come from the combination of these three parameters and the update strategy

When you debug connection issues, check these first:

• CONNECT_REQ fields and transmission rules
• The role of Transmit Window
• The constraint Timeout > (1 + Latency) × Interval × 2
• Recommended parameter tables for different application scenarios

Address types and Privacy

BLE device address types

Four address types:

IRK means Identity Resolving Key, which is used to resolve the identity of paired devices that use privacy addresses.

Address formats:

Public Address (48-bit):
┌────────────────────┬────────────────────┐
│  Company ID (OUI)  │  Device ID (NIC)   │
│     24 bits        │     24 bits        │
└────────────────────┴────────────────────┘
Example: 12:34:56:78:9A:BC

Random Static Address (48-bit):
┌──┬──────────────────────────────────────┐
│11│     Random (46 bits)                 │
└──┴──────────────────────────────────────┘
Example: C3:45:67:89:AB:CD

Resolvable Private Address (48-bit):
┌──────────────────┬────────────────────┐
│  hash (24 bits)  │ prand (24 bits)    │
└──────────────────┴────────────────────┘
                     prand upper 2 bits = 01
hash = AES-128(IRK, padding || prand)[0:23]
Example: 4F:12:34:56:78:9A

Address design points

Address type is not just theory. It directly affects product identity, privacy, debugging difficulty, and mass-production strategy.

• For fixed devices where traceability and compatibility matter, Public Address is often easier to accept
• Many embedded devices default to Random Static Address, because it is simple, stable, and easy to debug
• If the product really needs privacy, consider RPA, but accept that packet-capture identification, background bonding, and allow-list management all get harder

When designing an address strategy, ask one question first: does this device need a stable identity, or does it need to reduce the risk of long-term tracking?

Security modes and levels

Security modes

This GAP chapter only answers three things: what security level the connection is currently at, what happens when a protected attribute is accessed, and how address and privacy policy affect discovery and reconnect.

Mode 1: LE Security Mode 1 (encryption-based):

Mode 2: LE Security Mode 2 (data-signing-based) is rarely used in practice. It is enough to know that it exists:

• Typical entry point: ATT Signed Write (0xD2)
• It provides integrity only, not link encryption
• Most consumer and industrial products still use Mode 1 Level 2/3/4

Relationship between security level and GATT permission

GATT characteristic permissions:

// Typical permission definitions
enum {
    READ_OPEN          = 0x01,  // no security required
    READ_ENCRYPTED     = 0x02,  // requires Level 2+
    READ_AUTHENTICATED = 0x04,  // requires Level 3+
    WRITE_OPEN         = 0x10,
    WRITE_ENCRYPTED    = 0x20,
    WRITE_AUTHENTICATED= 0x40,
};

How permissions trigger pairing:

ATT Error 0x05 is one common way to trigger pairing or raise the security level; SMP Security Request is another standard entry point.

Level selection recommendations

• Public data (for example device name, battery level): Level 1, no encryption
• General data (for example sensor readings): Level 2, Just Works encryption
• Control commands (for example on/off, settings): Level 3, authenticated encryption
• Sensitive data (for example payment, medical data): Level 4, LESC

Security design points

The most important thing in the security chapter is not memorizing every mode and level. It is understanding that permission requirements drive pairing and encryption in the opposite direction.

• If a characteristic requires encryption or authentication, application access will push the connection security level upward
• For ordinary consumer products, Level 2 is often enough for most sensor read/write scenarios
• Once you are dealing with control commands, configuration writes, lock products, or sensitive data, you should not stay at the “it connects, so it is fine” stage

Security design should start with three questions:

• The relationship between GATT Permission and Security Level
• Why ATT Error 0x05 triggers re-pairing
• Which business functions should at least be designed for Level 3

Authentication methods, key derivation, MITM protection, and Privacy details are covered in BLE SMP Secure Pairing.

When performance and power issues should first go back to GAP

Many BLE projects do not fail to connect or read/write. They just feel slow, power-hungry, or unstable after the connection is up. Do not only change MTU or blame the RF environment first. Check whether the GAP parameters have already locked in the upper bound.

These symptoms usually mean you should go back to GAP first:

• First discovery and reconnect feel slow
• The device is connected, but response is sluggish
• Over-the-air captures do not show obvious retransmissions, but throughput is still low
• Standby power is high, but business data is not frequent
• It times out or disconnects easily in edge environments

Check this set of parameters first:

If the issue has already narrowed down to MTU, DLE, packets per connection event, retransmission, and PHY, then BLE Link Layer / PHY is the next place to look.

Default design conclusions

If you do not have strong business constraints, a BLE 4.2 device can usually start with this default thinking:

• Use ADV_IND for connectable devices, and keep the advertising data to the minimum needed for identity and discovery
• Start the advertising interval at 100 ms for discovery experience, then lengthen it to 500 ms or 1 s based on power goals
• Start the scanner with a medium duty cycle, and tune Scan Window / Scan Interval if discovery is too slow
• Never look at only one connection parameter; always treat Interval / Latency / Timeout as a group
• Use Random Static Address first if you do not have a privacy requirement, and introduce RPA only when you really need privacy
• For ordinary sensor reads and writes, design for at least Level 2; for control commands and sensitive data, design directly for Level 3+

If bring-up gives you symptoms like “cannot scan,” “cannot connect,” “power is wrong,” or “occasional disconnects,” go back and check the four layers of advertising, scanning, connection parameters, and security level first. Do not start by suspecting GATT business logic.

Quick reference appendix

The following sections keep only the parameters and commands that are most often checked during implementation and bring-up.

GAP key parameter reference

Common HCI commands

Chip-level power experience values

The following numbers are empirical values for nRF52832 @ 3V, not BLE specification values. They are mainly meant to provide a sense of scale.

References

Standards

• Bluetooth Core Spec

  • Volume 3, Part C: Generic Access Profile (GAP)
    • Section 9: Modes and Procedures
    • Section 10: Security Aspects
    • Section 11: Privacy Feature
    • Section 12: Advertising and Scan Response Data Format
  • Volume 6, Part B: Link Layer Specification
    • Section 4: Air Interface Protocol
    • Section 4.4: Advertising Physical Channel PDUs
    • Section 4.5: Data Physical Channel PDUs
  • Volume 4, Part E: Host Controller Interface
    • Section 7.8: LE Controller Commands

• Bluetooth SIG specification downloads

Further reading

• BLE Architecture Overview: return to the full stack, role boundaries, and a unified debugging entry point
• BLE Advertising Analysis: separate advertising types, advertising data, scan responses, and address semantics
• BLE Link Layer / PHY: continue with over-the-air packets, connection events, ACK/retransmission, and hopping
• BLE SMP Secure Pairing: continue with how security levels map to pairing, bonding, encryption, and privacy