Bluetooth BQB Certification Standards System: How Core Specs Connect to QPRD Qualification

2026-06-16

People working with Bluetooth products often confuse two things: Bluetooth has technical standards, and it has certification rules. What's the relationship between these two layers?

Simply put: the Bluetooth SIG publishes technical specifications (Bluetooth Core Specification, various Profile specifications) that define how Bluetooth should work. The SIG's qualification program (QPRD — Qualification Program Reference Document) defines how you prove your Bluetooth actually works as specified. The former is the textbook; the latter is the exam rules. The two evolve independently, but during certification they must align.

QPRDv2: The Currently Effective Qualification Rulebook

How BQB certification is executed, how products are classified, how testing is selected, how documents are submitted — all of this is defined by the QPRD (Qualification Program Reference Document). To understand BQB certification, start by locking down the QPRD version number.

The currently effective global specification is QPRDv2. QPRDv3 is in the draft public comment stage and has not been officially released. Some articles in the market treat it as the current rule — that's misinformation. If your BQB certification project is in progress or about to launch, all filing, material review, and ICS declarations must follow QPRDv2. Don't plan based on draft content.

Under QPRDv2, the product configuration system has three categories:

·BR/EDR Core Configuration — corresponding to traditional Classic Bluetooth

·LE Core Configuration — corresponding to Bluetooth Low Energy (BLE)

·BR/EDR and LE Combined Core Configuration — dual-mode solutions

Which configuration path your product takes is determined by which Bluetooth capabilities your hardware implements. Classic Bluetooth only? BR/EDR configuration. Low Energy only? LE configuration. Both? Combined configuration.

A common practical pitfall: these three configuration categories are strictly for Qualification Workspace online filing classification — they don't have a forced binding to your Bluetooth Core specification version or hardware chip model.

·If you use a dual-mode chip but disable one Bluetooth capability in software — say, only enabling BLE with Classic Bluetooth turned off — you can file under single-mode LE configuration. You're not forced into the combined configuration.

·Conversely, if your chip is labeled BLE single-mode but you add a separate Classic Bluetooth transceiver on the board, you need to file under combined configuration. The filing configuration reflects the product's actually enabled Bluetooth capabilities, not the chip spec sheet's printed parameters.

Filing under the QPRDv2 configuration system has no direct relationship to whether you're doing CE or FCC certification or which module you're using. Bluetooth certification is an independent system — QPRD only governs Bluetooth compliance.

Core Specification: Bluetooth's Technical Foundation

The Bluetooth Core Specification published by SIG is the fundamental technical standard all Bluetooth products must follow. It's not called the "BQB standard" — BQB is the abbreviation for the certification execution body, not the standard itself. The accurate statement is: products follow SIG Core specifications, pass the QPRD qualification program, and thereby obtain BQB certification.

The Core Specification is a substantial document divided into multiple volumes. The sections most relevant to certification testing:

Radio Layer

Defines the physical characteristics of Bluetooth wireless signals: operating frequency band (2.4 GHz ISM), modulation schemes (GFSK and PSK families), transmit power classes, receiver sensitivity requirements. The Radio Layer is the foundation of certification testing — regardless of which Bluetooth version your product runs, RF testing is unavoidable.

Baseband and Link Manager Layers

Define how Bluetooth devices establish connections, switch master/slave roles, and perform frequency-hopping to avoid interference. Baseband parameters directly affect interoperability and connection stability.

L2CAP and HCI

L2CAP manages data segmentation/reassembly and service multiplexing. HCI defines the standard communication interface between host and controller. Implementation consistency at these layers is the core inspection target of protocol stack consistency testing.

GAP and GATT

Generic Access Profile (GAP) defines basic device roles, discovery, and connection procedures. Generic Attribute Profile (GATT) is the foundational framework for BLE application-layer data exchange. GATT directly determines whether your product and phone app can communicate properly — it's the protocol layer with the highest error rate in BLE certification testing.

Profile Specifications: Application-Layer Scene Standards

The Core specification governs the underlying protocol stack; Profile specifications govern how it's used. Each Bluetooth Profile is essentially a standard interface definition for a specific application scenario.

·A2DP (Advanced Audio Distribution Profile): Stereo audio transmission. In-car Bluetooth music and Bluetooth headphone audio streaming run on this protocol.

·HFP (Hands-Free Profile): Hands-free calling. The underlying protocol for in-car Bluetooth phone calls.

·AVRCP (Audio/Video Remote Control Profile): Remote control. When you skip tracks or adjust volume on your car head unit, AVRCP is transmitting those control commands.

·SPP (Serial Port Profile): Serial port emulation. Data transmission between car head units and OBD diagnostic devices relies on this.

·HID (Human Interface Device Profile): Bluetooth keyboards, mice, and game controllers all use HID.

Your product implements which Profiles, those are the ones you must declare during BQB certification — declared Profiles require corresponding consistency testing. No omissions, no extras.

A boundary in ICS filing that many people get confused about: QPRDv2 rules require truthfully declaring hardware-native supported protocols and Profile features. Declare what the hardware actually does — don't deliberately conceal to dodge test items, and don't over-declare to expand the test scope beyond what the rules actually require.

Bluetooth Version Numbers and Certification Standards

This is one of the most frequently asked questions: what's the actual difference between Bluetooth 5.4 and 5.0 in terms of certification?

The answer: SIG certification testing doesn't cut by Core version number — it cuts by feature capability. If your product does Classic Bluetooth A2DP and HFP, it doesn't matter whether the underlying chip is labeled 5.0, 5.1, or 5.4. As long as the hardware doesn't implement LE Audio, the test items are the traditional set. A higher chip version number doesn't automatically mean more testing.

Same logic for Channel Sounding. Core 6.0's headline feature is channel sounding — phase-based measurement for centimeter-level high-precision positioning. Only products with Channel Sounding functionality enabled need dedicated testing. Ordinary Bluetooth devices — even those using a 6.0 chip without ranging enabled — don't need to test this. BQTF labs are opening commercial Channel Sounding certification testing throughout 2026.

How Test Standards Are Derived from Specifications

When a certification lab tests your product, the engineer isn't making judgment calls based on experience. There are standardized test cases derived item by item from the Core and Profile specifications.

RF Test Standards

Reference the RF Test Specification published by SIG, corresponding to Core specification Radio Layer requirements. Test parameters include transmit power, frequency offset, modulation accuracy, receiver sensitivity, spurious emissions, etc.

Protocol Stack Consistency Testing

Uses SIG's official PTS (Protocol Test Suite) automated testing suite, covering every state machine transition and error handling path across core protocol layers including L2CAP, HCI, GATT, and ATT.

Critical external reference point: PTS is SIG's unified mandatory standardized tool. All BQTF-authorized labs must use PTS to produce compliant reports. Custom test scripts, internal packet capture logs — these are not accepted by SIG review. Don't try to substitute debugging records for PTS reports — the review team can spot it immediately.


Need guidance on BQB certification standards? Contact BlueAsia Testing & Certification — Consultant: 13534225140 (Benson)