You’re a few hours into a BLE project, the vendor sample is running, data is flowing, and then a doc throws a word at you like “CCCD” or “supervision timeout” and assumes you already know it. BLE carries a lot of vocabulary, and a good chunk of it shows up under two different names depending on which spec version or SDK you happen to be reading. The Core Specification is exact about all of it and close to unreadable when you just want to know what a word means.
So this is the plain version. Every term below is defined the way we’d explain it to someone sitting next to us, grouped by where it shows up in an actual BLE exchange instead of alphabetically, so the words connect rather than sitting in a list. Where a term has an older name you’ll still run into, we’ve flagged it.
The Building Blocks: What BLE Is and Who’s Talking
Before anything talks to anything else, BLE has to sort out which device plays which role, and a surprising amount of later confusion traces straight back to mixing these up.
BLE
Bluetooth Low Energy, the low-power branch of the Bluetooth standard, designed so a device can spend most of its life asleep and wake up to move a small amount of data. That’s why a coin-cell sensor can run for months or years on it. BLE arrived as the low-power alternative to Bluetooth Classic, and that framing has aged. Most new Bluetooth work happens on BLE now, audio is migrating over with LE Audio, and Classic mostly survives for backward compatibility with the devices already in the field. If you’re starting something new, BLE is almost certainly the part of Bluetooth you want.
Central / Client
The device that scans for others and starts the connection, which in most projects is the phone or computer. It’s the Central in the connection sense and the Client in the data sense, so yes, that’s two names for roughly the same side of the conversation. The Central usually does the heavier lifting and burns more power doing it.
Peripheral / Server
The device that advertises and waits to be connected to, usually the small low-power thing like a sensor, a wearable, or a tracker. Peripheral is its connection-side name and Server is its data-side name, since it’s the one holding the data the Central comes to read. In older docs and specs you’ll see the Link Layer version of this role called the Slave. It’s the Peripheral now.
The client-server model
Once connected, the Peripheral is the server that holds the data and the Central is the client that reads and writes it. Same idea as an app talking to an API, where the device hosts the information and the app asks for it. Worth knowing that these data roles sit separate from the connection roles, so a Peripheral can act as the server most of the time and still read from the Central when data needs to flow the other way.
GAP roles
GAP defines four roles across two situations. When a connection is the goal, you’ve got the Central, which scans and connects, and the Peripheral, which advertises and accepts. When no connection is involved and a device just wants to broadcast into the room, the roles are the Broadcaster, which sends advertisements with no intention of connecting, and the Observer, which listens for them. A phone picking up a beacon is an Observer listening to a Broadcaster.
Bluetooth SIG and the Core Specification
The Bluetooth Special Interest Group, the SIG, is the body that owns the Bluetooth standard and publishes the Core Specification, the document that defines how every layer of Bluetooth, BLE included, is supposed to behave. When someone cites “the spec” or a version like 4.2 or 5.0, this is what they mean. You rarely read it front to back. You go to it when a vendor’s stack does something surprising and you need the authoritative answer for who’s right.
Finding Each Other: Advertising and Discovery
Nothing connects until two devices find each other, and discovery is a one-sided arrangement. The Peripheral talks, the Central listens.
Advertising and Advertising Data
Advertising is the Peripheral announcing itself by sending small packets on a set schedule. The contents of those packets are the Advertising Data, usually just enough to identify the device, a name, a UUID, or sometimes an address. There isn’t much room in there. Legacy advertising, the form you’ll hit first and the one most devices still use, caps out at 31 bytes, which is plenty for “here I am” and nowhere near enough for real data transfer. Extended advertising raises that ceiling, and it gets its own entry below.
Advertising Interval
How often the Peripheral sends that set of advertisements. A shorter interval means the Central finds it faster and the radio works harder. A longer interval means less power burned and a longer wait to be discovered. It’s one of the first real power-versus-responsiveness trade-offs you’ll set.
Scanning
The Central side of discovery. It listens on the advertising channels for those packets. Because it can only listen on one channel at a time and shares the crowded 2.4 GHz band with Wi-Fi and everything else, it listens in windows rather than continuously, so discovery isn’t instant and isn’t guaranteed on the first advertisement.
Scan Request and Scan Response
While scanning, the Central can ask a Peripheral for a bit more information with a Scan Request. The Peripheral answers with a Scan Response, which is basically a second advertising packet, and in legacy advertising it’s how a device roughly doubles the Advertising Data it can hand over before any connection exists. That doubling trick is specific to legacy. With extended advertising, the extra room comes from chained packets instead.
Legacy vs Extended Advertising
Legacy advertising is the original form, capped at 31 bytes of advertising data. Extended advertising, added in Bluetooth 5, gets around that cap by sending a small pointer packet on the primary advertising channels and putting the real payload on a secondary channel. A single extended packet carries up to 254 bytes, and a chain of them carries up to 1,650 bytes of advertising data in total. If you need to advertise more than a name and a UUID, extended advertising is why you can.
Beacon
A beacon is a Peripheral that only ever advertises and never connects, so it’s really the Broadcaster role with a product name attached. It fires the same advertisement over and over for any Observer in range to pick up. Most “proximity” and “presence” features are beacons underneath. Because there’s no connection and no acknowledgment, a beacon has no idea who heard it or whether anyone did.
RSSI (Received Signal Strength Indicator)
Received Signal Strength Indicator, a number the receiving device reports for how strong an incoming signal is, measured in dBm and always negative, where closer to zero is stronger. You’ll see it on every scan result. Read it as louder-or-quieter, and don’t try to turn it into a distance in meters, because walls, bodies, and orientation all move the number around.
Bluetooth device address and address types (MAC Address)
Every BLE device identifies itself with a 48-bit address, the BLE counterpart to a MAC address. It comes in a few flavors. A public address is fixed and permanently tied to the device. A random static address is fixed for a power cycle but not permanently assigned. And a resolvable private address rotates on a timer so the device can’t be tracked, where only devices holding the right key, traded during bonding, can tie it back to the real device. If your Peripheral’s address seems to change on its own, that last one is usually why.
Staying Connected: The Connection and Its Parameters
A connection isn’t an open pipe you pour data into. It’s a shared schedule the two devices agree to keep, and the settings on that schedule are where power, speed, and responsiveness get decided.
Connection and Connection Event
A connection starts when the Central sends a connection request in response to an advertisement. From then on the two devices talk on a fixed rhythm. Each scheduled exchange is a Connection Event, where the Central sends first and the Peripheral answers. If neither side has anything to say, they trade empty packets anyway, which is how each side keeps knowing the other is still there.
Connection Interval
The time between Connection Events. A short interval gives more frequent chances to exchange data, lower latency, and more power draw. A long interval flips all three. Almost every connection tuning decision comes back to this one number.
Connection Parameters
The set of values that define the connection’s rhythm, mainly the Connection Interval, the Peripheral Latency, and the Supervision Timeout taken together. Here’s the catch that bites people. The Peripheral proposes these in firmware, but the phone OS gets the final say and often quietly clamps them to its own allowed range, and iOS is especially strict about it. The parameters you asked for and the ones you got aren’t always the same, so it’s worth checking what actually landed.
Peripheral Latency (formerly Slave Latency)
How many Connection Events the Peripheral is allowed to skip when it has nothing to send. Set it to zero and the Peripheral answers every event. Set it to five and it can ignore five in a row, then check in, which saves power without slowing things down when data does show up, because the Peripheral can always answer early the moment it has something to say. This used to be called Slave Latency, and plenty of tools still label it that way.
Supervision Timeout
How long either side will wait, hearing nothing from the other, before it declares the connection dead. Cross that line and both sides treat the connection as gone. Most devices drop back to advertising and scanning to try again, though going idle is a legitimate choice and plenty of firmware does exactly that.
Exchanging Data: GATT and The Data Model
This is where you’ll spend most of your time, and it carries the most vocabulary, so the shape is worth getting right. Once you’re connected, the real data moves through GATT.
GAP and GATT
Two profiles that split the work. GAP, the Generic Access Profile, runs everything up to and including the connection, so advertising, scanning, roles, and connecting. GATT, the Generic Attribute Profile, takes over once you’re connected and governs how data is structured and exchanged. Rough rule, getting connected is GAP and moving data is GATT. It’s a rough rule because GAP doesn’t clock out once the connection exists. It still handles connection parameter updates, security procedures like pairing, and configuration down at the link layer. For the fuller story on how the two divide the work, we’ve got a dedicated write-up.
ATT (Attribute Protocol)
The Attribute Protocol, the layer just under GATT that actually moves the data. ATT handles the raw reads, writes, and responses on the small pieces of data called attributes. GATT is the structure and the rules, and ATT is the delivery. If GATT is the filing system, ATT is the act of pulling a file and handing it over.
Attribute, Characteristic, and Service
These nest inside each other. An Attribute is the smallest unit, a single piece of addressable data. A Characteristic wraps an attribute with meaning and rules, like what you’re allowed to do with it and its current value. A Service groups related Characteristics into one feature. The classic example is a Battery Service that holds a Battery Level Characteristic whose Attribute holds the actual percentage. Stack up the Services and you have the device’s data model, which lives in its GATT Table.
Descriptor and the CCCD (Client Characteristic Configuration Descriptor)
A Descriptor is extra information attached to a Characteristic, metadata about the data itself. The one you’ll meet constantly is the Client Characteristic Configuration Descriptor, the CCCD. It’s the switch a Central flips to subscribe to a Characteristic’s updates. When you “turn on notifications” in your app, you’re writing to the CCCD. Forget to, and you’ll sit there wondering why the updates you set up never arrive.
GATT Table
The full set of Services, Characteristics, and Descriptors a device actually exposes, assembled into one structure and sometimes called the GATT database. It’s the menu the Peripheral publishes and the Central reads, and it’s a real database living on the device, taking up memory, addressing each entry by a number called a handle, and changing as values update. Those handles are what a Central uses to read or write anything. When people talk about a device’s GATT, this structure is usually what they mean.
Profile
A Profile is the specification for how a GATT Table ought to be built for a particular use case, written either by the Bluetooth SIG or by you. The Heart Rate Profile says which Services and Characteristics a heart rate monitor exposes and how it should behave, so any client that knows the Profile can talk to any device that implements it. The GATT Table is the database on one specific device. The Profile is the schema that database follows, and it usually dictates expected GAP behavior along with the structure.
UUID (Universally Unique Identifier)
Universally Unique Identifier, the 128-bit ID that names a Service, Characteristic, or Descriptor. The standard SIG-adopted ones, like Battery Service, get a short 16-bit shorthand. Anything custom you invent uses the full 128-bit form. It’s how both sides agree on what a given piece of data actually is.
Reads, Writes, Notifications, and Indications
The four ways data moves once you’re connected. A Read is the Central pulling a Characteristic’s current value. A Write is the Central sending a value to the Peripheral. Notifications and Indications are the Peripheral pushing updates to the Central when a value changes, and they’re the main way a Peripheral talks back. The difference between the two, a Notification is fire-and-forget, while an Indication waits for the Central to acknowledge each one, which makes it safer and slower.
Most streaming data rides on Notifications for exactly that reason. The same split exists in the other direction. A Write Request, also called a write with response, waits for the Peripheral to confirm, which makes it the Indication equivalent. A Write Command, or write without response, doesn’t wait, which makes it the Notification equivalent.
Service discovery
The step right after connecting where the Central asks the Peripheral for its GATT Table and learns what Services and Characteristics exist and how to address them. Nothing else works until this finishes, because the Central needs the handles it discovers here to read or write anything. It’s also where caching bites. A Central can hang on to an old copy of the table and miss changes, which is a classic source of “it worked yesterday” bugs.
Under The Hood: The Stack and Throughput
Most of the time you live up at the GATT layer and never think about what’s beneath it. When throughput or range questions come up, it helps to know what the lower floors are doing.
The BLE stack
BLE is built in layers, grouped into three blocks. The Application is your code. The Host covers the upper layers you mostly deal with, including GAP, GATT, and ATT. The Controller covers the lowest layers that run the radio. In between sit pieces you’ll see named in logs and specs, including L2CAP for packet routing and reassembly, the Security Manager for pairing and keys, the Host Controller Interface or HCI for the boundary between Host and Controller, and the Link Layer for the abstraction right above the radio. You can build a lot without touching these directly. When you do need to go deeper, our Connectivity Architecture guide walks the whole stack.
PHY (Physical Layer) and the 2.4 GHz Band
The PHY, or physical layer, is the bottom of the stack, the part actually sending and receiving over the air on the 2.4 GHz ISM band, the same crowded stretch of spectrum Wi-Fi uses. That crowding is part of why BLE hops across channels and why range and reliability are never a given. Worth knowing that 2.4 GHz isn’t permanent. The SIG has an active project to define BLE operation in the 5 and 6 GHz bands.
Throughput
How much application data you actually move per second once all the overhead is counted. It’s always lower than the raw radio rate, because headers, acknowledgments, and connection timing each take a cut. When someone’s disappointed that their “1 Mbps” BLE link delivers a fraction of that in practice, this gap is why.
MTU / ATT MTU (Maximum Transmission Unit)
Maximum Transmission Unit, the largest ATT packet the two sides agree to use. Other layers in the stack have their own MTUs, and when someone says MTU in a BLE conversation they almost always mean this one. The default is a small 23 bytes, three of which are header, so you’re moving 20 bytes of real data per packet until you raise it. Negotiate it up, commonly toward 247, and your per-packet overhead drops sharply. The ceiling that actually matters is the payload, since a single attribute value tops out at 512 bytes however high the MTU goes. Android allows an MTU of 517 and iOS 527, both sized to carry that 512-byte payload plus headers. Raising it is one of the biggest and easiest throughput wins available.
DLE (Data Length Extension)
Data Length Extension, added in Bluetooth 4.2. Without it, the Link Layer payload maxes out at 27 bytes. With it, that jumps to as much as 251 bytes, so fewer packets carry the same data. MTU and DLE work together, since a large MTU riding on a small data length still gets chopped into small pieces on the air, so you generally want both raised.
1M, 2M, and Coded PHY
The three flavors of the physical layer. 1M is the original and the safe default. 2M, from Bluetooth 5, doubles the raw rate for higher throughput at some cost to range. Coded PHY trades speed for much longer range. Most projects start on 1M and only reach for the others with a specific reason.
A fourth is on the way. High Data Throughput, or HDT, is a new PHY the SIG is standardizing that uses higher-order modulation to reach raw rates as high as 7.5 Mbps, with the radio able to shift rate packet by packet as conditions change. It doesn’t change what you build today, and it’s the reason the throughput ceiling you plan around now won’t be the ceiling for long.
Keeping It Secure: Pairing, Bonding, and Privacy
Security in BLE isn’t automatic, and it isn’t a single switch. The terms below are the ones you’ll hit first, and the full method-by-method breakdown has its own guide, so treat this as the map rather than the manual.
Pairing and Bonding
Two related steps people constantly conflate. Pairing is two devices establishing a secure, encrypted connection right now, exchanging keys for this session. Bonding is when they store those keys so they can reconnect securely later without redoing the whole exchange. Pairing is the handshake. Bonding is remembering each other. Bonding is also why a device shows up in your phone’s list of saved Bluetooth devices. You can pair without bonding, and if you want a device to trust yours across reconnects, you bond. The pairing and bonding guide goes into when each one is the right call.
Encryption
Scrambling the data on the connection so anyone listening in gets nothing useful. Pairing is what sets up the keys that make encryption possible. With encryption, how the keys get exchanged in the first place matters more than how long the key is, which is why the pairing method you pick carries more weight than the key size.
MITM (Man-in-the-Middle)
Man-in-the-middle, an attack where someone slips between the two devices during setup, relays their messages, and quietly reads or alters what passes through. The pairing methods that protect against it all work by making each side confirm it’s really talking to the other and not to an impostor sitting in the middle.
LE Privacy
The feature that rotates a device’s address on a timer, often every fifteen minutes, so someone can’t track your Peripheral, and maybe you, by a fixed address. Only devices that bonded with it, and hold the key, can tell it’s still the same device. What it protects is identity, so the device is harder to follow around. It doesn’t hide what’s inside the advertisement, since advertising data goes out in the clear unless you’re using encrypted advertising, and it has nothing to do with encrypting connection data, which pairing handles separately. LE Privacy is also usually off by default.
Pairing methods and security modes
When you go deeper you’ll meet the specific methods, Just Works, Passkey Entry, Numeric Comparison, and Out-of-Band, along with the two generations of pairing, LE Legacy and the stronger LE Secure Connections from Bluetooth 4.2. Which one you use decides how much protection you actually get, especially against man-in-the-middle attacks. That choice deserves more room than a glossary line, so we’ve written it up in the pairing and bonding guide.
Where To Go Next
If you read this far, you’ve probably got the vocabulary and now want to put it somewhere. Where you go next depends on what you’re about to do.
If you want to see how these pieces fit together rather than what they mean one at a time, how GAP and GATT work is the layer directly above this one, and it’s where the terms start behaving like a system. If you’re about to write code, go to the guide for your platform, Core Bluetooth for iOS or the Android BLE guide, since the vocabulary maps onto the actual APIs there.
