Anyone in Bluetooth knows you must pass BQB before launch; to be listed you must first be a valid SIG member — holding a module QDID alone with no member account of your own will not get you listed. But ask "which standards do we test against" and few can answer clearly. Most just say "per the core specification" — true, but it leaves planning far off. This article breaks it down by layer.
What TCRL governs
TCRL stands for Test Case Reference List. Think of it as the official exam paper SIG issues: which questions BQB verifies and to what degree each counts as passed are all written on that sheet. When you price with any authorised lab, their first sentence is likely "which TCRL version is this project locked to".
Version cadence
Per the Bluetooth SIG release record, the naming changed from TCRL pkg100 onward. The versions in use now:
(1) TCRL pkg103, with Core 6.3, available 5 May 2026, mandatory from 3 August 2026.
(2) TCRL pkg104, released 23 June 2026, mandatory from 21 September 2026.
(3) Earlier: pkg102 (released 17 February 2026, mandatory 18 May 2026), pkg101 (with Core 6.2, 4 November 2025), pkg100 (8 July 2025), and TCRL 2025-2 (with Core 6.1). Some call pkg102 "TCRL 2026" — do not follow that in technical papers; write the official pkg number.
Version lock point
The TCRL is fixed at the moment you submit the Qualification. While still in lab testing you are free to switch versions; but once the qualification enters the SIG system, switching requires re-assessing the impact and adding difference cases. Switching at final review basically means starting over — do not point at a version casually.
Sub-document management
The TCRL splits into a stack of sub-documents by functional module: base link layer plus security in one, GATT protocol conformance separate, hands-free and audio distribution each with their own test spec. Reading the case numbers halves your report-reading effort. The number contains protocol layer, functional domain, role and verification type, so you locate the failing layer at a glance. Cases also split into A/B/C/D classes; A-class must run in a BQTF, B/C/D can self-test or self-declare — the quote workload difference is here.
2. The Core Specification is the technical baseline
Core Specification is the foundation
The Bluetooth Core Specification defines the parameters, communication protocols and interoperability requirements of each stack layer; all BQB testing uses it as the baseline. The mainstream now moves upward from 5.x; Core 6.3 is already in use.
Version matches TCRL
Choosing Core and choosing TCRL are two sides of one decision. Core 6.3 pairs with pkg103, 6.2 with pkg101, 6.1 with 2025-2. If the two do not match, the lab tests to the wrong version and the report is waste paper on submission.
Withdrawal policy and component reuse
The SIG has a Core Deprecation and Withdrawal Policy. Once old Cores like 4.0 and 4.1 are Withdrawn, you can no longer use them for new Design qualifications. But old module QDID component certificates keep working; an end-product listing can directly reference them — touching a 4.0/4.1 chip does not block a new listing. Long-lifecycle products should note this early.
3. Two RF systems
Official test suites
Split by protocol layer, RF has the RF Test Suite (for BR/EDR) and the RFPHY Test Suite (for BLE); baseband link layer, protocol layer, control adaptation and generic access each have independent suites, plus two 802.11 suites for co-existence.
Why RF and RFPHY are two suites
Classic Bluetooth BR/EDR and low-energy BLE are two independent RF systems; dual-mode products must run both, visibly raising cost and time. But this is not a straight mathematical doubling — some common protocol-layer cases can be reused. First-timers often think "Bluetooth is just one Bluetooth" and only wake up when the quote arrives.
Conducted and OTA are not two tests
Devices with an RF port and external antenna use conducted connection to the instrument; onboard or internal antennas with no port use the OTA chamber. This is only a difference in connection method, not a change in cases — internal antennas do not add a separate supplementary test. A BQTF handles both.
Judgement metrics differ by receiver
BR/EDR receivers are judged by BER (bit error rate); BLE receivers by PER (packet error rate). This is about the receiver side; transmitter-side metrics do not use BER/PER. The two limit logics differ and cannot be mapped onto each other.
4. Do not gloss over ICS and IXIT
ICS is the capability statement
ICS stands for Implementation Conformance Statement. Each protocol layer has a corresponding ICS document listing the functions the product implements, and the lab uses it to scope the testing. The SIG qualification tool can auto-pull this per the current TCRL; hand-filling it is more error-prone.
IXIT is the test parameters
IXIT is Implementation eXtra Information for Testing. It holds the parameters the test run needs: addresses, timeouts, feature combinations. A vague table means the lab keeps coming back with questions, burning all the time on arguments.
Consequences of a false declaration
Claiming support in the ICS but not implementing it fails the test outright; capabilities not declared that you later want to mark require re-running the process. R&D and marketing should review this table together — do not let a non-technical person tick boxes at will.
5. Profiles by claim, components reusable
Base layers follow implementation
Layers like GAP, GATT and SM are only mandatory if the product implements that protocol. A pure BR/EDR classic device does not run GATT/SM, so those layers' cases are skipped — not all Bluetooth products must test everything.
Application layer by claim
Test by the functions actually claimed; common ones fall into three types:
① Audio: A2DP, AVRCP, HFP.
② Data transport: SPP.
③ Human interface: HID.
Each extra claim adds a test group, raising cycle and cost.
New specs counted separately
LE Audio's LC3, Auracast broadcast audio and Mesh networking each have independent test requirements, not following the traditional Profile path. Evaluate these separately.
Component QDID can be reused
End-product certification can inherit the module's already-obtained QDID; PHY and protocol need not fully re-run. Once the module passes, the end product just references it at submission; only a changed RF or antenna triggers re-test. Note: not just RF/antenna — if the module's Bluetooth firmware changed or Profile capabilities were added/removed, the QDID cannot be directly referenced and a new qualification is required. By the way, SIG renamed QDID to Design Number (DN) in July 2024; old documents still say QDID — do not let the name confuse you. Many companies miss this and waste money on unnecessary end-product re-tests.
No certificate expiry
QDID and listing stay valid as long as hardware and claimed functions are unchanged; they do not lapse when the TCRL version updates. Clients often assume an old product's certificate dies with a version change — what actually needs handling is design-change filing, not certificate expiry.
BlueAsia works on wireless certification and helps clients plan BQB, module reuse and regional approvals in one schedule so rework at the test gate is avoided.
Contact: King Email: king.guo@cblueasia.comAddress: Building C, Hongjingda Industrial Park, No. 107 Beihuan Road, Shiyan Street, Bao'an District, Shenzhen, ChinaBlueAsia delivers more than service!
相关新闻
