bluetooth tutorial - bluetooth address class of device in bluetooth

Bluetooth Device Address, Class of Device & Communication Basics

BD_ADDR · Class of Device · Bluetooth Clock · PDU · Data Rates · Topologies

Topics Covered

48-bit

BD_ADDR Size

24 Mbps

Max Data Rate

Bit 47                                               Bit 0
┌──────────────────────────────┬──────────────────────────────────┐
│ OUI — Company ID (24 bits)   │ Company Assigned Address         │
│ Assigned by IEEE             │ (24 bits) — Assigned by vendor   │
│ Most Significant Bits        │ Least Significant Bits           │
└──────────────────────────────┴──────────────────────────────────┘

Field	Bits	Assigned By	Also Called
OUI (Company ID)	Bits 47–24 (MSB)	IEEE	Organizationally Unique Identifier
Device Address	Bits 23–0 (LSB)	Bluetooth chip manufacturer	Company-assigned portion

Simple way to remember: The top 24 bits (OUI) tell you who made the Bluetooth chip, and the bottom 24 bits tell you the unique number that manufacturer assigned to that specific device. Together they form a globally unique 48-bit address — just like a MAC address.

Bluetooth Device Name

In addition to the BD_ADDR, every Bluetooth device also has a Bluetooth device name. Unlike the BD_ADDR, the device name is a friendly, human-readable name (for example: “John’s Phone” or “My Headset”).

Key points about the device name:

It can be changed by the user at any time, unlike the fixed BD_ADDR.
It helps users identify their device when multiple Bluetooth devices are visible nearby.
It is sent during the Bluetooth discovery process so other devices can show it in a readable format.

2. Class of Device (CoD)

The Class of Device (CoD) is a 24-bit value that a Bluetooth device broadcasts to tell nearby devices about its type and capabilities. Think of it as a small label the device wears that answers: “What kind of device am I, and what can I do?”

When you scan for Bluetooth devices, the CoD is returned as one of the parameters in the scan results — that is how your phone knows to show a headset icon instead of a phone icon when a headset is detected nearby.

CoD Bit Layout (24 Bits)

Class of Device — 24-Bit Structure

Bit 23                                              Bit 0
┌────────────────────┬───────────────┬─────────────────┬─────────┐
│ Service Class      │ Major Device  │ Minor Device    │ Reserved│
│ (11 bits)          │ Class (5 bits)│ Class (6 bits)  │ (2 bits)│
│ Bits 23–13         │ Bits 12–8     │ Bits 7–2        │ Bits 1–0│
└────────────────────┴───────────────┴─────────────────┴─────────┘

Field	Bits	Size	Purpose
Service Class	23 – 13	11 bits	What services the device supports (Audio, Telephony, File Transfer, etc.)
Major Device Class	12 – 8	5 bits	Big category — Phone, Computer, Audio/Video, Peripheral, etc.
Minor Device Class	7 – 2	6 bits	Specific type within major class — Laptop, Desktop, Headset, Speaker, etc.
Reserved	1 – 0	2 bits	Always set to 00 — reserved for future use

The Three Sections Explained

1. Major Device Class — The Big Category

This tells you the main type of device. For example:

Phone Computer Audio / Video Peripheral (Keyboard, Mouse) Imaging (Printer, Scanner) Networking Wearable Toy

2. Minor Device Class — The Exact Type

This provides more detail within the major class:

Computer → Laptop or Desktop Audio → Headset or Speaker Phone → Smartphone or Cordless

3. Service Class — What It Can Do

This tells you which services the device supports:

Audio Output Telephony File Transfer Networking Information

Real-World Example: Bluetooth Headset

How CoD Describes a Bluetooth Headset

┌─────────────────────────────────────────────────────────────────┐
│         Class of Device — Bluetooth Headset                     │
├──────────────────┬──────────────────┬───────────────────────────┤
│ Major Class      │ Minor Class      │ Service Class             │
│ Audio / Video    │ Headset          │ Audio + Telephony         │
├──────────────────┴──────────────────┴───────────────────────────┤
│ Result: Your phone recognizes the device as a Headset           │
│ and shows the headset icon when it is connected.                │
└─────────────────────────────────────────────────────────────────┘

Why does this matter in development? When you write code to scan for Bluetooth devices using HCI or BlueZ, the CoD value is returned in the inquiry results. You can filter or display device types based on this value — for example, show only audio devices in your app.

Bluetooth in my laptop give below output

raviteja@raviteja-Inspiron-15-3511:~/Downloads/linux-6.19-rc5$ bluetoothctl show
Controller 10:6F:D9:0D:0B:DA (public)
	Name: raviteja-Inspiron-15-3511
	Alias: raviteja-Inspiron-15-3511
	Class: 0x006c010c
	Powered: yes
	Discoverable: no
	DiscoverableTimeout: 0x000000b4
	Pairable: no
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0555
	Discovering: no
	Roles: central
	Roles: peripheral
Advertising Features:
	ActiveInstances: 0x00 (0)
	SupportedInstances: 0x05 (5)
	SupportedIncludes: tx-power
	SupportedIncludes: appearance
	SupportedIncludes: local-name
	SupportedCapabilities Key: MaxAdvLen
	SupportedCapabilities Value: 0x1f (31)
	SupportedCapabilities Key: MaxScnRspLen
	SupportedCapabilities Value: 0x1f (31)
| Service Class (11 bits) | Major Class (5 bits) | Minor Class (6 bits) | Format (2 bits) | 
MAJOR DEVICE CLASS
From 0x010c
👉 Major class = 0x01
✔ 0x01 = Computer
MINOR DEVICE CLASS
From 0x010c
👉 Minor = 0x0C
✔ 0x0C = Laptop
SERVICE CLASS
From 0x006c0000
👉 0x6c = binary → 0110 1100
This means multiple services enabled:
✔ Networking
✔ Rendering
✔ Capturing
✔ Object Transfer

3. Bluetooth Clock

The Bluetooth clock is the native clock of a Bluetooth device. It is derived from the normal system clock running on the device. Every Bluetooth controller has its own independent clock that starts running as soon as the device is powered on.

Why Is the Bluetooth Clock Important?

Since Bluetooth devices need to communicate with each other in a time-synchronized way (for frequency hopping, slot timing, etc.), they need a common time reference. The problem is — each device starts its own clock independently, so the clock values will be different on each device.

Bluetooth Clock Synchronization

Device A                     Device B

┌───────────────┐           ┌───────────────┐
│ Native Clock  │           │ Native Clock  │
│ value: X      │           │ value: Y      │
└───────┬───────┘           └───────┬───────┘
        │                           │
        │   Exchange Clock Offset   │
        │◄──────── Offset = (X - Y) ────────►│
        │                           │
        ▼                           ▼

┌─────────────────────────────────────────────────────┐
│ Synchronized Clock = Native Clock + Clock Offset    │
│ Both devices now operate on the same time reference │
└─────────────────────────────────────────────────────┘

Instead of trying to match the absolute clock values (which is impossible since they start at different times), Bluetooth uses clock offset values for synchronization. When the offset is added to the native clock, both devices arrive at a mutually synchronized clock.

Clock Accuracy: In the worst case, a drift of 20 ticks per million ticks is considered the maximum allowed drift. Keeping the clock accurate is essential for reliable frequency-hopping synchronization between devices.

4. Protocol Data Unit (PDU)

The term Protocol Data Unit (PDU) is commonly heard in Bluetooth development. A PDU is a small, formatted packet of data that Bluetooth uses to send and receive information between two devices.

Bluetooth is divided into layers (like a stack), and each layer adds its own header and defines how data should look before passing it to the next layer. The formatted unit of data at each layer is called a PDU.

PDU Across Bluetooth Layers

Device A                         Device B

┌──────────────────────────┐     ┌──────────────────────────┐
│ Application Layer        │     │ Application Layer        │
├──────────────────────────┤     ├──────────────────────────┤
│ L2CAP Layer              │◄── L2CAP PDU ───►│ L2CAP Layer              │
│ (Breaks data into chunks │     │ (Reassembles chunks,     │
│  routes to channels)     │     │  routes to channels)     │
├──────────────────────────┤     ├──────────────────────────┤
│ Link Layer               │◄── LL PDU ─────►│ Link Layer               │
│ ADV_IND / SCAN_REQ /     │     │ ADV_IND / SCAN_REQ /     │
│ CONNECT_IND ...          │     │ CONNECT_IND ...          │
└──────────────────────────┘     └──────────────────────────┘

Common PDU Types

ADV_IND SCAN_REQ SCAN_RSP CONNECT_IND L2CAP PDU ATT PDU HCI Event PDU HCI Command PDU

Simple way to remember: Think of PDUs as letters in an envelope. As data moves down through the Bluetooth layers, each layer puts the data in its own envelope (adds a header). On the receiving side, each layer opens its envelope and passes the contents up. We will look at each PDU type in detail in its respective section.

5. Bluetooth Data Rates

Understanding data rates is very important when working on Bluetooth development. Bluetooth data rates have evolved significantly over the years.

Bluetooth Data Rate Evolution

─────────────────────────────────────────────────────────────────────►

   Bluetooth 1.x          Bluetooth 2.0 + EDR         Bluetooth 3.0 + HS
   (Before v2.0)          (From v2.0 onwards)         (From v3.0 onwards)

┌──────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Basic Rate  │ ───►│ Enhanced Data    │ ───►│ High Speed (HS)  │
│  BR          │     │ Rate (EDR)       │     │ via Alt. MAC     │
│  ≤ 721 kbps  │     │ up to 2.1 Mbps   │     │ up to 24 Mbps    │
└──────────────┘     └──────────────────┘     └──────────────────┘

Bluetooth Version	Mode	Max Data Rate	Notes
Before v2.0	Basic Rate (BR)	Up to 721.2 kbps	Original Bluetooth data rate
v2.0 + EDR	Enhanced Data Rate (EDR)	Up to 2.1 Mbps	Uses π/4-DQPSK and 8DPSK modulation
v3.0 + HS	High Speed (via Alternate MAC/PHY)	Up to 24 Mbps	Uses Wi-Fi radio for high-speed bursts
v4.0 onwards	Bluetooth Low Energy (BLE)	Up to ~2 Mbps (LE 2M PHY)	Separate from BR/EDR — discussed in BLE section

BR/EDR vs BLE: You will often see the term BR/EDR in Bluetooth development. BR/EDR refers to the classic Bluetooth radio — it is completely separate from Bluetooth Low Energy (BLE). We will cover BLE in detail in a dedicated section.

6. Bluetooth Connection Process

Now that you know about BD_ADDR, Class of Device, and data rates, let us see how two Bluetooth devices actually find each other and connect.

Step-by-Step Connection Flow

Device B: Enters Discoverable Mode

Device B is now visible to other Bluetooth devices

▼

Device A: Performs Inquiry

Device A searches for nearby devices — finds Device B’s BD_ADDR

▼

Device B: Enters Connectable Mode

Device B allows incoming connections

▼

Device A: Pages Device B

Device A initiates the connection request — this is called Paging

▼

Connection Established

Device A = Master, Device B = Slave. Both can now send and receive packets.

▼

Either Side Initiates Disconnection

Connection released — can be reconnected when needed

Inquiry and Paging — Side-by-Side View

Device A (Initiator)                 Device B (Target)
─────────────────────               ─────────────────────

1. INQUIRY
──────────────────────────────────►  (Listening for inquiry)
◄──────── INQUIRY RESPONSE

2. PAGE
──────────────────────────────────►  (Uses BD_ADDR found during inquiry)
◄──────── PAGE RESPONSE

3. CONNECTION ESTABLISHED
◄──────────────────────────────────────────────────────────
A = Master                     B = Slave

4. DATA PACKETS
◄──────────────────────────────────────────────────────────►
(Both can send and receive)

5. DISCONNECT
◄──────────────────────────────────────────────────────────
(Either master or slave can disconnect)

Important: The Master/Slave roles only exist after a connection is established. The device that initiates the connection (does the paging) becomes the Master, and the device that responds becomes the Slave.

Ad Hoc Network: Bluetooth connections are established when needed and released when no longer required. This on-demand connection model is called an Ad Hoc network.

7. Bluetooth Communication Topologies

Bluetooth defines two main communication topologies: Piconet and Scatternet.

Piconet

[M] ← Master / | \ [S][S][S] ← Slaves …up to 7

A Piconet is the smallest unit of a Bluetooth network. It contains exactly one master and up to seven active slaves. All slaves communicate only with the master — not directly with each other.

Scatternet

Piconet 1 Piconet 2 [M1] [M2] / \ / \ [S1] [S2/M*]──►[S3] [S4] ↑ Bridge device (Slave in both)

A Scatternet is formed when two or more piconets are connected together through a shared/bridge device. The bridge device is a slave in both piconets simultaneously.

Scatternet — How It Works

┌─────────────────────────────────────────────────────────────────┐
│                           SCATTERNET                           │
│                                                                 │
│        PICONET 1                         PICONET 2              │
│   ┌────────────────────┐        ┌─────────────────────────┐     │
│   │     Master (M1)    │        │      Master (M2)        │     │
│   │      /   |   \     │        │        |   \            │     │
│   │    S1   S2  [S3]   │◄──────►│      [S3]  S4           │     │
│   │   (Bridge Device)  │        │   (Bridge Device)       │     │
│   └────────────────────┘        └─────────────────────────┘     │
│                                                                 │
│ Bridge device (S3) is:                                          │
│ → Slave in Piconet 1 (communicates with M1)                     │
│ → Slave in Piconet 2 (communicates with M2)                     │
└─────────────────────────────────────────────────────────────────┘

Quick Comparison

Feature	Piconet	Scatternet
Number of masters	1	More than 1 (one per piconet)
Number of slaves	Up to 7 active slaves	Many (across all piconets)
How formed	Single master initiates connections	Two or more piconets share a bridge device
Bridge device role	Not applicable	A device that is a slave in multiple piconets
Used for	Local device clusters (e.g., phone + headset + keyboard)	Extended range networks, IoT mesh-like setups

We will explore Piconets and Scatternets in more detail through hands-on lab exercises, where you will be able to observe these topologies in real Bluetooth traffic using HCI logs and BlueZ tools.

Summary — What You Learned

In this bluetooth development tutorial you covered all the foundational Bluetooth concepts needed before diving into the protocol stack:

BD_ADDR — 48-bit unique address (OUI + company-assigned) Bluetooth Device Name — friendly, user-changeable name Class of Device — 24-bit value describing device type and services Bluetooth Clock — per-device clock, offset used for sync PDU — formatted data packets used by each protocol layer Data Rates — BR (721 kbps) → EDR (2.1 Mbps) → HS (24 Mbps) Connection Process — Inquiry → Page → Connect → Disconnect Piconet — 1 master + up to 7 slaves Scatternet — two or more piconets joined by a bridge device

In the next lecture, we will go deeper into the Bluetooth lower layers — starting with the physical layer and the link controller. so please follow our bluetooth development tutorials.

Keep Learning — It’s Free!

EmbeddedPathashala offers free Bluetooth development, BLE development, and Linux Embedded Systems tutorials for all engineers.

Visit EmbeddedPathashala Bluetooth Series

embeddedpathashala.com

bluetooth tutorial – bluetooth address class of device in bluetooth

In This Article

BD_ADDR Structure