Understanding BLE Connections: A Beginner's Mental Model

A smartphone and wireless earbuds with visible Bluetooth connection signals between them

You just opened your first BLE example project, maybe on an ESP32 or nRF52 dev kit, and your screen is full of callbacks you didn’t ask for. BLE_GAP_EVT_CONNECTED. on_adv_report. security_request. You scroll through the SDK sample, and every function seems to assume you already know what’s happening underneath. You search “BLE connection explained” and land on a tutorial that opens with “The Bluetooth Core Specification defines…” and it’s 3,000 pages long.

Here’s the thing: you don’t need 3,000 pages. You need four states. That’s it. Four states that you can sketch on a napkin, and suddenly every callback, every event, every confusing SDK function snaps into place.

I’m going to give you those four states using one analogy that carries from start to finish: a professional conference. Your BLE device is an attendee trying to have a productive conversation. By the end, you’ll be able to look at any BLE codebase and say, “Oh, we’re in that state.”

Four States on a Napkin

Before we walk through each state, here’s the destination. Pin this in your head:

┌─────────────┐      ┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ ADVERTISING  │─────▶│  SCANNING /  │─────▶│  CONNECTED   │─────▶│   PAIRED /   │
│              │      │  INITIATING  │      │              │      │   BONDED     │
│ Peripheral   │      │  Central     │      │ Two-way      │      │ Trusted &    │
│ shouts       │      │  listens     │      │ data flow    │      │ remembered   │
└─────────────┘      └─────────────┘      └─────────────┘      └─────────────┘
     ▲                                           │
     └───────────── on disconnect ───────────────┘

Two roles to know:

  • Peripheral — the device that advertises. Your sensor, your heart rate monitor, your smart lock.
  • Central — the device that scans and connects. Usually a phone or a gateway.

Technically speaking: Real BLE has additional sub-states and roles (observer, broadcaster). This is the 80/20 model. It covers the vast majority of what you’ll build and debug as a beginner.

State 1: Advertising — Wearing a Name Tag and Shouting Into the Room

Imagine you walk into a conference. You’re wearing a name tag that says your name and your specialty. Every few seconds, you announce it out loud: “Hi, I’m Temperature Sensor, and I measure ambient temperature!”

You’re not talking to anyone. You’re talking at the room. Nobody has to listen. Nobody has to respond.

This is advertising.

Your peripheral sends small packets, just 31 bytes, on three dedicated radio channels at a regular interval. That interval is called the advertising interval (typically 20 ms to several seconds). Shorter intervals mean faster discovery but higher power consumption.

Peripheral:  📢──────📢──────📢──────📢──────📢──────▶ time
             "Hi!    "Hi!    "Hi!    "Hi!    "Hi!
              I'm     I'm     I'm     I'm     I'm
             Sensor"  Sensor" Sensor" Sensor" Sensor"

What’s inside that advertisement? A few things:

  • The device name (“Temperature Sensor”)
  • Service UUIDs — identifiers for what the device offers (temperature data, battery level, etc.)
  • Sometimes a small chunk of sensor data itself

The critical insight: advertising is one-way. No connection exists. The peripheral is just yelling into the void, hoping someone useful is listening. If nobody is, the packets vanish. The peripheral doesn’t know and doesn’t care.

Some devices only advertise and never connect. A beacon broadcasting its location is a good example. It’s wearing a name tag but has no interest in a conversation.

State 2: Scanning and Initiating — Someone Stops to Read Your Name Tag

Another conference attendee, the Central, walks through the room, actively reading name tags. They’re scanning.

The central listens on those same three advertising channels, collecting advertisement reports. It might filter by name, by service UUID, or by signal strength. It’s browsing.

Then it spots your name tag: “Temperature Sensor — that’s exactly what I need.”

The central sends a connection request. In conference terms, they walk up to you and say, “Hey, can we step aside and talk one-on-one?”

This is the initiating step. Two things to lock in:

  1. The central always initiates the connection. The peripheral cannot reach out. It can only advertise and then accept or reject when someone comes knocking.
  2. Scanning and initiating are technically separate activities. Scanning is passive browsing. Initiating is the moment the central commits to one specific peripheral.

Once the peripheral receives and accepts the connection request, both devices transition to the next state.

State 3: Connected — A Private Conversation With a Rhythm

You and the other attendee step to a quiet corner. You’ve agreed to take turns: one speaks, the other listens, then you switch. You do this on a regular beat, say every few seconds.

This is a BLE connection.

When the connection forms, both devices negotiate connection parameters, the rules of the conversation:

  • Connection interval — how often they exchange data (typically 7.5 ms to 4 seconds). This is the beat of your turn-taking.
  • Peripheral latency — how many intervals the peripheral is allowed to skip if it has nothing to say. (Saves power.)
  • Supervision timeout — how long to wait before assuming the other person walked away.
Central:    ──Req──────────Req──────────Req──────▶
               │              │              │
Peripheral: ──Rsp──────────Rsp──────────Rsp──────▶
            ◄──interval──▶

Data flows in both directions using GATT (Generic Attribute Profile), the shared language and structure for the conversation. We won’t deep-dive into GATT here; that deserves its own article. For now, just know that GATT defines what data is available and how it’s organized.

The peripheral typically stops advertising once connected. It’s busy in conversation. It’s stepped away from the crowd.

Either device can disconnect at any time. Someone “walks away.” When that happens, the peripheral usually goes right back to advertising, and the cycle can start again.

Here’s the part that surprises most beginners:

Connected does not mean secure. Right now, data is flowing in plaintext. Anything you send can theoretically be eavesdropped on by another BLE radio nearby. For a temperature sensor, maybe you don’t care. For a smart lock, you absolutely care.

That’s what the next state fixes.

State 4: Pairing and Bonding — Exchanging Business Cards and a Secret Handshake

You’ve been chatting with this conference attendee and you decide to trust each other. Two things happen:

  1. Pairing — You agree on a secret handshake right now. This establishes encryption for your current conversation. Nobody else can eavesdrop anymore.
  2. Bonding — You exchange business cards. Both of you store each other’s contact info (encryption keys) so that next time you meet, you don’t have to repeat the whole introduction.

Technically speaking: Pairing and bonding are distinct steps in the Bluetooth spec. Pairing generates the keys. Bonding stores them. As a beginner, think of them as one combined “trust establishment” flow. You’ll separate them later when you need to.

What’s actually happening at a high level:

  • The devices exchange encryption keys using one of several methods (Just Works, Passkey Entry, Numeric Comparison, etc.)
  • They agree on a security level
  • If bonding is enabled, both devices store the keys in flash memory

The key insight: bonding means the devices remember each other. Next time the peripheral advertises and the central scans, they can reconnect and restore encryption almost instantly, with no full pairing ceremony needed.

First time:   Advertise → Scan → Connect → Pair → Bond → Encrypted
Next time:    Advertise → Scan → Connect → ✅ Already bonded → Encrypted
                                           (keys loaded from flash)

Not every BLE application needs pairing or bonding. That temperature beacon? It might never pair. A heart rate monitor sending data to your phone? Probably bonded. A smart door lock? Definitely bonded, with a strong pairing method.

The Full Conference Story in 30 Seconds

Your device walks into a conference wearing a name tag, shouting its name and specialty every few hundred milliseconds (Advertising). A phone across the room is browsing name tags, looking for something useful (Scanning). It spots your device and says, “Let’s talk” (Initiating → Connected). They step aside and have a structured, turn-taking conversation, exchanging data over GATT. If trust is needed, they agree on a secret handshake and swap business cards (Pairing & Bonding). Next time they meet, they skip the introductions and go straight to an encrypted conversation.

Every BLE SDK callback you’ll encounter maps to a transition in this flow.

Mapping the Mental Model to Real SDK Events

You don’t need to write code yet. But here’s why this mental model matters in practice: every mysterious callback in your SDK corresponds to a state or transition.

State              │ Typical SDK Event / Callback
───────────────────┼─────────────────────────────────
Advertising starts │ on_adv_started()
Device discovered  │ on_device_found(adv_report)
Connection formed  │ on_connected(conn_handle)
Trust established  │ on_security_complete()
Connection lost    │ on_disconnected(reason)

Next time you open an SDK example and see BLE_GAP_EVT_CONNECTED, you’ll think: “We just stepped into the quiet corner. Two-way data flow begins. Not yet encrypted.”

That’s the power of having the mental model first.

Quick-Reference Cheat Sheet

Save this. Screenshot it. Tape it next to your monitor.

┌─────────────────────────────────────────────────────────────┐
│              BLE CONNECTION MENTAL MODEL                     │
├──────────────┬──────────────────────────────────────────────┤
│ ADVERTISING  │ Peripheral broadcasts packets. One-way.      │
│              │ No connection. "Shouting into the room."      │
├──────────────┼──────────────────────────────────────────────┤
│ SCANNING /   │ Central listens, finds peripherals.          │
│ INITIATING   │ Central sends connection request.             │
├──────────────┼──────────────────────────────────────────────┤
│ CONNECTED    │ Two-way data exchange via GATT.               │
│              │ Has rhythm (connection interval).              │
│              │ NOT encrypted by default.                      │
├──────────────┼──────────────────────────────────────────────┤
│ PAIRED /     │ Encryption keys exchanged (pairing).          │
│ BONDED       │ Keys stored for next time (bonding).          │
├──────────────┼──────────────────────────────────────────────┤
│ ROLES        │ Peripheral = advertises. Central = connects.  │
└──────────────┴──────────────────────────────────────────────┘

Where to Go From Here

You now have the mental scaffolding. Every BLE concept you encounter from here, whether it’s GATT tables, characteristic notifications, MTU negotiation, or PHY updates, hangs on this four-state frame.

Your next steps:

  1. Open your SDK’s BLE example again. Find each callback and label it with the state it belongs to. It will feel different this time.
  2. Read up on GATT. It’s the structure inside State 3 that defines how data is organized and exchanged. (That’s the next article in this series.)
  3. Build something simple. Advertise a device name. Connect to it with your phone using a free app like nRF Connect. Watch the states happen in real time.

The Bluetooth spec is 3,000+ pages. You just handled the first 80% of what matters in a napkin sketch. The rest is details, and now you have somewhere to put them.

Hubble Network extends BLE connectivity from satellite to sensor—no gateways, no line-of-sight constraints. See how it works →