Module 01 / Wireless Technologies

How to Read a Wireless Standard & System

Which documents and clauses determine the RF behavior of one product mode? Follow a sensor report from a confident range claim to a trace you can defend—and an evidence request you can act on.

01 / 10

Five range claims, five different questions

Five people say “Bluetooth range.” Are they discussing the same engineering quantity?

The systems engineer needs complete reports on time. The RF designer needs a receiver criterion. Marketing has a demonstration, and procurement has a qualification record. Each document may be accurate within its scope while supporting none of the other conclusions. First extract the claim; only then decide which document could establish it.

PHY means physical layer; MAC means medium access control. Packet error ratio (PER) is the fraction of expected test packets that fail the stated packet criterion. Bit error ratio (BER) counts erroneous bits against the tested bit population. Neither automatically equals the fraction of complete application reports delivered before a deadline.

Prerequisite bridge

Use Path 02’s waveform and decision conventions, Path 05’s requirement grammar, and Path 06’s port, chamber and field evidence. Here we own document authority and applicability. Measurement execution belongs to Path 08; jurisdictional determinations to Path 09.

Five original hypothetical Bluetooth range statements · none is actual product evidence
ClaimWhat was saidStated conditionsWhat is missing?
A · nominal PHY sensitivity“This Bluetooth mode has a −70 dBm reference sensitivity, so our node has long range.”Hypothetical statement about LE 1M receiver requirements; input criterion named, no antenna or deployment specified.Which Core revision, maximum supported test payload, signal conditions, and receive plane? Where is the product trial?
B · conducted vendor result“Our receiver reaches −96 dBm at 1% PER.”Fictional board V1, LE 1M, 25 °C, 50 Ω R1-RX connector, 1000 test packets.Missing packet length/pattern, calibration uncertainty, firmware, blockers, and unit population. This is invented example wording, not measured data.
C · outdoor demonstration“Bluetooth works at 800 m.”Hypothetical line-of-sight demonstration; two raised antennas, LE Coded S=8, one successful message.No delivery probability, deadline, interference distribution, antenna orientation, power or repeatability basis.
D · mounted percentile result“The mounted node delivers 99% of reports within 2 s at 30 m.”Hypothetical 32-byte D0 reports; 100 sites, one orientation per site, ten reports per site, indoor gateway.Potentially relevant service metric, but site selection, orientation strata, firmware and confidence remain unspecified.
E · qualification listing“This Bluetooth-qualified design guarantees our product’s range.”Hypothetical design record Q-EXAMPLE; no actual listing is claimed.Which qualified design/layers and product? Listing scope does not establish this mounting, channel, deadline or jurisdiction.
Think about itWhich statement looks strongest for the node’s required delivery statistic?
Answer

D is closest because it names complete reports and a deadline. It still needs representative mounting/orientation strata and statistical uncertainty. A very precise sensitivity or a much longer demonstration distance is not stronger evidence for a different quantity.

Reading task: underline the quantity, circle the population, and mark the plane in each row. Treat every unfilled condition as unknown. Do not convert a missing report into a measured failure, and do not convert absent evidence into a passing value. The consequence is practical: a team that buys the “best range” number may optimize a receiver mode its gateway never uses.

02 / 10

Define the product mode before opening the standard

What must the node deliver before any technology name is useful?

Freeze a local service variant: one 32-byte application report every 60 s, with at least 99% of complete reports delivered within 2 s in each declared mounting/site stratum. D0 is the application boundary; latency begins when the node releases the report and ends when the gateway delivers it. Duplicates count once; late reports miss the deadline. These are chosen teaching requirements, not standard limits or measured achievements.

P07-M01-LE-EXT-v1 · mode identity before feature comparison
DimensionFrozen choice / unresolved evidence
Topology / infrastructureFixed sensor node to mains-powered gateway; gateway backhaul is outside the stated D0 endpoint.
TelemetryBluetooth LE 1M candidate; non-connectable, non-scannable extended advertising. Gateway must support scanning and decoding that exact mode.
CommissioningSeparate operator-triggered legacy ADV_IND discovery then a connection. A short discovery identity is advertised; the full telemetry report is not forced into that packet. Commissioning service and security remain to be specified.
Environment / mobilityMounted equipment and fixed gateway; moving people/interference are environmental variables. Sampling strata and observation interval still need a test plan.
Band / market2.4 GHz; CH candidate market. Power class, actual antenna and regional applicability remain unresolved.

The portfolio’s 2.450 GHz QPSK waveform remains a generic earlier example. It is not renamed Bluetooth. This module introduces a named LE variant; it carries the earlier antenna evidence IDs without changing their values or turning them into evidence for the new waveform.

Read the host boundary: Core 6.2 GAP §11 defines AD structures with a length byte and type byte. Supplement v14 §1.4 defines manufacturer-specific data with a two-byte company identifier followed by manufacturer-defined content. For a bare 32-byte report, that single AD structure would therefore occupy 36 bytes; no identifier is assigned here. Extra schema/security fields would add bytes. BT-GAP, BT-CSS.

32×8=256bitatD032 \times 8 = 256 \mathrm{bit} \mathrm{at} D_{0}Derived. A byte is eight bits. One manufacturer-data AD structure: 1 + 1 + 2 + 32 = 36 bytes before Link Layer headers.
Common misconceptionThe application payload is the on-air packet.

D1 includes framing/coding, and an advertising event can involve multiple transmissions. Freeze the complete encoding and state sequence before estimating airtime or current. No adopted application sensor profile is claimed: the private schema must be specified by both node and gateway teams.

03 / 10

Identify who owns each document

Does a reputable publisher make every document it publishes normative?

No. An issuer identifies who published the material. The document role identifies the question it can answer. The same organization can publish a specification, an introductory article and a qualification policy. Use the title page, scope, interpretation conventions and references to classify the document before trusting a search-result snippet.

One product mode, separate evidence lanesConceptual dependency map, not RF data. Product mode feeds three lanes: normative base and profile, implementation test and installed product, and qualification and market applicability. Solid connectors mean an evidence request; dashed connector marks unresolved product applicability. The adjacent table lists the same roles.Named product modeBase + profileWhat is specified?Test + implementationWhat was observed?Qualification programWhat was qualified?Bounded RF claimmode / plane / criterionInstalled serviceD0 / R2 / S0 / R3Market applicabilityseparate authority
Original conceptual map. A complete row in one lane does not complete the others. Read the document-role table for the full text alternative; no axis or quantitative RF data is implied. On small screens, scroll the diagram within its border.
Document-role map · who owns the next answer?
RoleReading taskEngineering consequence
Base standardFind PHY/MAC scope, defined terms and normative dependencies.Selects permitted behavior; does not predict a particular chip or installation.
Profile / application definitionFind the feature subset, service semantics and dependency versions.Two peers need compatible application meaning, even with the same PHY.
Regional parametersIdentify the region, device/mode category and underlying authority.A technical regional document does not by itself resolve national authorization.
Test methodMatch measurand, test signal, conditions, reference plane and decision rule.A result acquired using another method may not test the same claim.
Qualification processMatch the submitted design/layers and applicable program rules.Scope is program-specific; do not substitute a range or legal conclusion.
Regulator / authoritative applicabilityIdentify product, market, responsible party and current official requirements.The market lane cannot be closed by a PHY or qualification row.
Vendor evidenceRead exact revision, DUT, firmware, uncertainty, sample population and conditions.May support implementation performance; cannot override a normative requirement.

Checked example: the SIG’s qualification overview describes an interoperability and licensing process. OFCOM’s CH overview routes a product toward applicable legal requirements. They answer different questions even when both are needed for the same product. BT-QUAL, CH-OFCOM.

Decision: give every consequential claim an owner and a source role. If the source is only a catalogue entry, record identity and access limits; do not record that the body of the standard supports your claim.

04 / 10

Read requirements in their actual scope

Can a keyword search for “shall” replace reading the requirement?

A requirement is a conditional statement with a subject and scope. A sentence can be mandatory for one selected feature and irrelevant to another. Read the preceding conditions and following exceptions, then follow normative references. An informative annex can explain intent without adding a requirement; confirm its designation rather than assuming that all annexes have one status.

Bluetooth Core 6.2 Vol 1 Part E §1 uses “shall” for requirements, “should” for recommendations and “may” for permission. Optional implementation choices still carry the specified behavior when implemented. “Must” has a separate factual/consequence usage in this document; do not import another publisher’s vocabulary mechanically. BT-LANGUAGE, Table 1.1 and following paragraph.

Original scope-reading exercise · fictional wording
StatementBounded interpretation
“If the short-timer feature is supported, the node shall expose timer state.”First establish whether that feature is selected; then check its state behavior.
“The gateway should keep recent delivery logs.”A recommendation here; not an invented mandatory interoperability test.
“The node may omit the optional display.”A permitted product choice; it does not permit omitting an unrelated receiver requirement.
Think about itA clause is copied into the trace with a locator and today’s review date. Is support established?
Answer

No. If nobody read the relevant text and dependencies, the evidence is still unreviewed. The complete-looking row is a request to inspect, not proof. The mapper checks this distinction explicitly.

Reading task: rewrite the first fictional sentence as “condition → actor → required behavior.” Attach the feature/conformance-class declaration. The consequence of skipping that step is either overtesting an absent option or overlooking a requirement for a feature you did enable.

Go deeperNormative is a document relationship, not a universal legal label

A referenced requirement can become necessary to satisfy a selected specification without becoming a national legal requirement by itself. Conversely, a regulator’s current route may incorporate a technical standard. Trace each relationship; the publisher’s name and the word “shall” do not determine market applicability.

05 / 10

Build a compatible version chain

Should every document in a valid chain have the same version number?

A base revision can consolidate earlier amendments. An amendment changes selected material; an erratum corrects identified text. A profile selects application behavior; a release groups features on its own schedule. A test package and regional document can evolve independently. Pin complete identities and curate compatibility for the exact endpoints.

Think about itThe teaching sensor profile is 2.0 and its base is 1.2. Reject the chain?
Answer

No. D-PROFILE 2.0 explicitly depends compatibly on D-BASE 1.2 in this fictional fixture. The edge is the evidence. A move to base 1.3 needs another reviewed edge; numeric similarity supplies no answer.

A real different-numbered relationship appears in the Supplement version history: v14 was adopted alongside Core 6.2. For layer mixing, Core 6.2 Vol 0 Part D §3 permits different Host and Controller versions subject to its constraints; all included Controller layers must share one Controller version. A claim that combines PHY 6.2 with Link Layer 6.1 in one Controller violates that rule. Feature dependencies in §4 still need checking. BT-CSS-HISTORY, BT-CONFIG.

Reading task: draw the arrow and write “requires,” “amends,” “tests,” or “explains.” Do not infer that two independently adopted specifications are compatible merely because one is newer. Preserve the evidence that established the old pair so a later reviewer can see what actually changed.

Class 1 · fictional metadata exercise

Specification Evidence Mapper

Accept a bounded trace, challenge its source, or name the next evidence. Six synthetic documents; three starting claims. Nothing is scraped, measured, saved, or certified.

specification-evidence-mapper/2.0 · p07-m01-trace-rules-v1 · p07-m01-document-chain-v1. Frozen default evaluation: 2026-09-08 UTC.

Guided sequence: predict whether 2.0 and 1.2 conflict → show dependencies → unread source → informative-only support → apply one repair → inspect C-MARKET. Compare each state with the canonical baseline below.

Custom copy · edit bounded teaching metadata

Draft edits do not change the committed results until Apply draft. Blank mode/region mean unknown. Required dates reject blanks. Exact version choices are synthetic; selecting compatibility records a fictional human review.

Document metadata
Blank = unknown; access cannot be after evaluation.
Blank = unknown; access cannot be after evaluation.
Blank = unknown; access cannot be after evaluation.
Required. Current through this date, overdue on the next UTC day.
Claim scope

normative requirement: Hypothetical normative channel/timing requirement in the declared mode. The edge scope remains separately declared; changing the claim does not silently update its evidence.

Support edge and exact compatibility
Only document-to-document edges use a pair. Changing a version invalidates an old endpoint attestation.

Asserted scope: teaching-node-v1 / telemetry / CH / fixture-conditions-v1. Relation: requires; required.

6/12 documents · 3/12 claims · 9/24 edges. Copies keep their declared roles; a copied claim requires its own support edges.

Before / after — canonical baseline stays visible
ClaimCanonical baselineSelected trace
C-PHYtrace completetrace complete
C-DEVICEinspectinspect
C-MARKETinspectinspect
D-BASE · Teaching PHY/MAC base

base · exact version 1.2

Evidence: normative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-BASE · D-BASE teaching row A (synthetic)
Owner: Standards owner
D-PROFILE · Teaching sensor profile

profile · exact version 2.0

Evidence: normative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-PROFILE · D-PROFILE teaching row A (synthetic)
Owner: Standards owner
D-TEST · Teaching test method

test · exact version 4.1

Evidence: informative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-TEST · D-TEST teaching row A (synthetic)
Owner: Standards owner
D-REGION · Teaching regional mode card

region · exact version 3.0

Evidence: informative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-REGION · D-REGION teaching row A (synthetic)
Owner: Standards owner
D-VENDOR · Fictional implementation note

vendor · exact version 0.8

Evidence: informative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-VENDOR · D-VENDOR teaching row A (synthetic)
Owner: Standards owner
D-QUAL · Teaching qualification record

qualification · exact version 1.0

Evidence: informative. Lifecycle: current. Access: read.
Published 2026-06-01; status 2026-06-01; accessed 2026-09-08.
Review due 2026-12-07; within due date.
synthetic:D-QUAL · D-QUAL teaching row A (synthetic)
Owner: Standards owner

Canonical fictional node · evaluated 2026-09-08 UTC. Fictional metadata exercise.

C-DEVICE · inspect

Fictional implementation performance under fixture-conditions-v1.

Mode: telemetry · Region: region-independent definition. packet delivery · ratio · D0 · fraction by 2 s deadline.

Next: A measured receiver report with matching mode, plane, conditions, and statistic. Owner: RF systems owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.

No trace acceptance. Inspect every applicable reason below.

C-MARKET · inspect

Which requirements apply to placing this product in CH?

Mode: telemetry · Region: CH. packet delivery · ratio · D0 · fraction by 2 s deadline.

Next: Authoritative applicability review for the final product and CH market. Owner: Compliance owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.

No trace acceptance. Inspect every applicable reason below.

C-PHY · trace complete

Hypothetical normative channel/timing requirement in the declared mode.

Mode: telemetry · Region: region-independent definition. channel/timing definition · Hz / s · R1 / D1 · defined interval, not delivered service.

Next: Compare the declared trace against the actual document text before real use. Owner: RF systems owner. Review: 2026-12-07 or mode, document, antenna, firmware, or market change.

The declared required metadata chain is complete. This does not establish product conformance, measured performance, certification, or market authorization.

All rule reasons, in deterministic order
  1. inspect · R09 · C-MARKET / C-MARKETMissing required authority evidence. Next owner: Compliance owner.
  2. inspect · R09 · D-VENDOR / C-DEVICEMeasured implementation evidence is absent; an informative note is not a result.
  3. inspect · R10 · C-MARKET / C-MARKETAuthoritative product applicability review remains outside this mapper; no market authorization is computed.
  4. note · R05 · E-DEVICE-PAIR / C-DEVICEExplicit compatibility for 2.0 → 1.2; unequal numbers are not a conflict.
  5. note · R05 · E-PAIR / C-PHYExplicit compatibility for 2.0 → 1.2; unequal numbers are not a conflict.
  6. note · R05 · E-TEST-PROFILE / C-DEVICEExplicit compatibility for 4.1 → 2.0; unequal numbers are not a conflict.
  7. note · R09 · C-MARKET / C-MARKETqualification: optional. Separate industry-program lane. Owner: Standards owner.
  8. note · R09 · C-PHY / C-PHYauthority: not applicable. Region-independent definition; market authorization is a separate claim. Owner: Compliance owner.
  9. note · R09 · C-PHY / C-PHYvendor: optional. An implementation comparison cannot set the rule. Owner: Standards owner.
  10. note · R09 · E-QUAL / C-MARKETOptional or disconnected support does not satisfy the required trace.
  11. note · R09 · E-REGION / C-MARKETOptional or disconnected support does not satisfy the required trace.
Claim / source / locator trace
Claim → dependencySource / relationshipReview / exact compatibility
C-PHY: D-BASE → C-PHYrequired; requires. base; D-BASE teaching row A (synthetic)supports; direct claim support; no version pair
C-PHY: D-PROFILE → C-PHYrequired; requires. profile; D-PROFILE teaching row A (synthetic)supports; direct claim support; no version pair
C-PHY: D-PROFILE → D-BASErequired; requires. profile; D-PROFILE teaching row A (synthetic)supports; 2.0 → 1.2: compatible; Teaching fixture author
C-DEVICE: D-TEST → C-DEVICErequired; tests. test; D-TEST teaching row A (synthetic)supports; direct claim support; no version pair
C-DEVICE: D-VENDOR → C-DEVICErequired; explains. vendor; D-VENDOR teaching row A (synthetic)supports; direct claim support; no version pair
C-DEVICE: D-TEST → D-PROFILErequired; tests. test; D-TEST teaching row A (synthetic)supports; 4.1 → 2.0: compatible; Teaching fixture author
C-DEVICE: D-PROFILE → D-BASErequired; requires. profile; D-PROFILE teaching row A (synthetic)supports; 2.0 → 1.2: compatible; Teaching fixture author
C-MARKET: D-REGION → C-MARKEToptional; explains. region; D-REGION teaching row A (synthetic)supports; direct claim support; no version pair
C-MARKET: D-QUAL → C-MARKEToptional; explains. qualification; D-QUAL teaching row A (synthetic)supports; direct claim support; no version pair
Required, optional and not-applicable evidence
Claim / roleRequirement and reasonReview owner
C-PHY / baserequired: Owns the PHY/MAC rule.Standards owner
C-PHY / profilerequired: Selects the teaching mode.Standards owner
C-PHY / vendoroptional: An implementation comparison cannot set the rule.Standards owner
C-PHY / authoritynot applicable: Region-independent definition; market authorization is a separate claim.Compliance owner
C-DEVICE / testrequired: Owns the test conditions.Standards owner
C-DEVICE / vendorrequired: Must supply measured implementation evidence.Standards owner
C-MARKET / authorityrequired: Product-specific authoritative applicability review is outside the mapper.Compliance owner
C-MARKET / qualificationoptional: Separate industry-program lane.Standards owner
Committed one-page evidence summary
Identity / evaluationDecision / next owner
p07-m01-document-chain-v1; Canonical fictional node; 2026-09-08 UTCC-DEVICE: inspect; C-MARKET: inspect; C-PHY: trace complete
BoundaryMetadata review only; no conformance, certification, measured performance, or market authorization.
Next evidenceC-PHY: Compare the declared trace against the actual document text before real use. RF systems owner. C-DEVICE: A measured receiver report with matching mode, plane, conditions, and statistic. RF systems owner. C-MARKET: Authoritative applicability review for the final product and CH market. Compliance owner.

Static broken / repair examples

No-script counterexamples · metadata repairs are not real reading
Broken traceOutcome and next actionAfter the stated repair
C-PHY has no modeInspect · R03; specify the intended operating mode.Restoring telemetry makes the default synthetic C-PHY trace complete.
Base 1.3, explicitly incompatible pairChallenge · R06; restore the chosen base or obtain a reviewed different mode chain.Restoring 1.2 alone leaves the 1.3 pair attestation stale: inspect · R07. Repair that exact edge too.
Catalogue-only D-BASEInspect · R09; read the relevant body and dependencies.The synthetic read attestation repairs this fixture only; real reading must occur.
D-VENDOR alone sets C-PHYChallenge · R08 plus missing-role reasons; restore normative support.Restoring the original base/profile chain makes synthetic C-PHY complete; device measurement remains absent.
D-QUAL closes C-MARKETChallenge · R10; qualification is the wrong authority.Request authoritative applicability review. C-MARKET remains inspect, never an automated legal pass.
Review due 2026-09-07, asOf 2026-09-08Inspect · R12; recheck affected claims.A real recheck can justify a new date. Merely changing a date does not do it.
06 / 10

Trace an RF number with its conditions

Where exactly does an RF number begin and end?

The quantity and its conditions travel together. Channel spacing is not occupied bandwidth; a receiver input criterion is not an OTA distance. Look up the selected mode and test definition before moving a value into the product budget. R1 is a component RF port, R2 the antenna feed, S0 the spatial/OTA reference, and R3 the receiver decision boundary. An antenna connector in a source must be mapped to the actual test fixture; it is never automatically R3.

GFSK is Gaussian frequency-shift keying. Its dimensionless shaping product BT uses Gaussian-filter bandwidth B in hertz and symbol interval T in seconds. That filter parameter does not name the occupied RF bandwidth. The timing symbol T_MAFS below denotes minimum auxiliary frame space, an interval at the packet boundary.

Core 6.2 LE 1M · bounded source-reading annotations
RF quantity / locatorWhat the text establishesWhat it does not establish
Channel · Vol 6 A §240 RF channel centers, 2402–2480 MHz at 2 MHz spacing.2 MHz is channel spacing, not a measured occupied bandwidth.
Waveform · Vol 6 A §§1, 3.1LE 1M: uncoded 1 Mbit/s; GFSK, BT=0.5.Application goodput, RF spectral-mask measurement, or the prior QPSK waveform.
Power · Vol 6 A §3Read the source’s antenna-connector/reference-antenna power convention.Installed EIRP/ERP/OTA or permission to use a national power limit.
Sensitivity · Vol 6 A §§4–4.1LE uncoded sensitivity ≤ −70 dBm under the prescribed signal variations; BER depends on maximum supported payload, evaluated via the corresponding PER.A typical chip result, fixed 1% PER for all packets, or mounted product range.
Auxiliary timing · Vol 6 B §4.1.2T_MAFS = 300 µs, minimum end-of-packet to start-of-auxiliary-packet interval.A report deadline, repetition interval, or end-to-end discovery time.

BT-RF: actual normative text read; BT-LL: actual timing definition read. This is a small set of annotations, not a reproduction of the standard’s tables.

Δf=2480240239=2MHz\Delta f = \frac{2480 - 2402}{39} = 2 \mathrm{MHz}Derived check: forty centers create thirty-nine intervals. SI calculation: 78,000,000 Hz ÷ 39 = 2,000,000 Hz.

Checked comparison: the fictional vendor’s −96 dBm result and the −70 dBm requirement cannot be subtracted into a 26 dB “product range margin” until their mode, signal, criterion and planes match. Even then, the difference would be a conducted receiver comparison. Feed, antenna and channel evidence would still be needed to connect it to D0.

The separately curated real trace

Real sources actually read · no fictional support flags transferred
Claim / source IDsExact locatorSupported readingUnresolved dependencies
BT-CHANNEL / BT-RFCore 6.2, Vol 6 A §§1–3.1, 4–4.1LE 1M channel/waveform definitions and conditional receiver requirement.Device performance, actual test payload class, RF fixture and OTA delivery unknown.
BT-MODE / BT-LL + BT-GAPCore 6.2, Vol 6 B §§2.3, 2.3.1.6, 2.3.4, 4.1.2; Vol 3 C §11Selected non-scannable extended advertising format and auxiliary timing.Gateway capability, complete AD encoding, schedule and packet capture required.
BT-AD / BT-GAP + BT-CSSCore 6.2, Vol 3 C §11; Supplement v14, Part A §1.4Manufacturer-specific data structure; no assigned company identifier is invented.Private schema and identifier allocation must be supplied by the product owner.
BT-VERSION / BT-CONFIG + BT-CSS-HISTORYCore 6.2, Vol 0 D §§3–4; Supplement v15 version history, v14 rowLayer mixing rules and the documented v14 / Core 6.2 adoption pairing.No inference that a newer optional feature works on a selected older layer.
BT-TEST / BT-DTM + BT-QPRD + BT-TSCore 6.2, Vol 6 F §1; QPRD v5 §§3.2.2.4–3.2.2.5Test-control alternatives and the ICS/TCRL-to-test-plan dependency.RFPHY TS p22 download returned a landing page; test text, exact applicability and device results unread/unknown.
BT-CHANGE / BT-INDEX + BT-UPDATECore 6.2 catalogue notice for Expedited Specification Update 28108Notice identifies the update as required for a Core 6.2 compliance claim.Update PDF returned a landing page; detailed clause impact remains unresolved. No compliance claim.
NODE-MARKET / CH-OFCOMMarket access overview, published 2025-01-16Routes the CH applicability question to authoritative requirements.Final product/configuration and specialist review still required; no market decision.

Engineering handoff: preserve the original source plane and explicitly name every feed, mismatch, gain or processing transformation. Count each loss once. RF output power and DC energy are different quantities; a conducted limit does not become EIRP by changing its label.

07 / 10

Connect PHY claims to MAC and state behavior

If 256 payload bits take little PHY time, why might the gateway miss a two-second deadline?

The receiver must be listening to the right transmission. Discovery, scan scheduling, host queues, access collisions and retransmission policy all sit between the PHY and delivered service. Aggregation can reduce overhead per report while increasing the time a report waits. Adaptation changes the selected operating point. A fixed nominal rate cannot describe those states.

For this variant, extended advertising carries the report in an auxiliary PDU. The selected non-scannable mode does not request a scan response; repeated broadcasts are not acknowledged application delivery. Commissioning is a separate state. Read the PDU/event conditions in Core 6.2 Vol 6 Part B §§2.3.1.6 and 2.3.4 and the host format in GAP §11 before borrowing timing from a connection. BT-LL, BT-GAP.

tpayload=256106=256μst_{\mathrm{payload}} = \frac{256}{10^{6}} = 256 \mathrm{\mu s}Derived lower bound at LE 1M, excluding every protocol header, primary advertisement, auxiliary spacing, wait, retry and processing interval. This is not a packet airtime or latency estimate.

At one complete report per 60 s, the offered D0 rate is 256/60 = 4.2667 bit/s, independent of whether the receiver succeeds. Actual goodput is unique delivered D0 bits divided by the declared observation interval. The 99% deadline target is a different statistic again. A short payload does not prove low energy or reliable discovery.

State evidence request · all durations and currents are unknown
State / ownerNeeded evidenceDecision it enables
sleepSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.State duration and DC energy contribution under the traffic plan.
wake/encodeSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.State duration and DC energy contribution under the traffic plan.
primary advertisementSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.State duration and DC energy contribution under the traffic plan.
auxiliary advertisementSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.State duration and DC energy contribution under the traffic plan.
gateway scanSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.Whether the report can be discovered by the deadline.
commissioning connectionSynchronized timestamps (s), supply current (A), supply voltage (V), mode and firmware; unknown, not zero.State duration and DC energy contribution under the traffic plan.
Go deeperThe energy equation can be known while its answer is unknown
EDC=ViIitiE_{\mathrm{DC}} = \sum V_{i} I_{i} t_{i}Vᵢ: volts; Iᵢ: amperes averaged within state i; tᵢ: seconds in that state. Result in joules. Constant-state approximation; include transitions and host/sensor load or integrate V(t)I(t).

No current or duration is supplied for the actual product, so no battery number is calculated. Ask for wake, discovery, receive, retry and sleep traces under the same deadline requirement; sleep current alone cannot answer the question.

08 / 10

Separate qualification from market authorization

What does the qualification record leave for the product team to do?

Keep parallel evidence lanes. A qualification record identifies a program submission; a module note describes an implementation; a host change alters the product configuration; a regulator’s requirements address a market. Match identities within each lane and record the joins. A familiar logo cannot fill missing rows.

QPRD v5’s test-plan process uses the declared Implementation Conformance Statement (ICS) and Test Case Reference List (TCRL) package. The executed plan depends on the design and changes being submitted. Core 6.2 Vol 6 Part F §1 explains RFPHY test-control alternatives; it is not a completed device test report. BT-QPRD §§3.2.2.4–3.2.2.5, BT-DTM.

Parallel evidence lanes for the illustrative CH node
LaneKnown / unknownNext owner
Industry qualificationProgram source read; actual design/layers, product listing and generated test plan unknown.Qualification owner: obtain the exact design and product records.
Vendor / moduleNo actual conducted result, firmware capability record or integration instruction has been supplied.Vendor/RF owner: obtain revisioned evidence and conditions.
Host integrationFinal antenna, enclosure, feed, coexistence states and firmware are unfrozen.Product owner: freeze a configuration matrix and affected tests.
CH applicabilityOFCOM overview read. Exact obligations for the final product remain unresolved.Compliance owner: review current official requirements and applicability.

Reading task: cross out the sentence “qualified therefore legal everywhere” and replace it with two evidence requests. OFCOM’s overview explicitly concerns applicable requirements and distinguishes its telecommunications scope from other legislation. No CH limit or authorization is inferred here. CH-OFCOM, 16 January 2025.

Common misconceptionA complete PHY trace closes every product claim.

C-PHY deliberately does not require national authorization to define a timing quantity. C-MARKET deliberately requires an authoritative applicability review. Requiring every role for every claim would obscure this distinction; omitting the market lane would hide it.

09 / 10

Review changes without rewriting history

A new version appears. Which conclusions actually need reopening?

Publication records when a document was issued; adoption records a publisher’s approval status. Supersession, deprecation and withdrawal describe distinct lifecycle events under the relevant policy. Access records when a reader obtained the source; review records when the claim was assessed and when to revisit it. Do not collapse those dates into “latest.”

On 8 September 2026, the official index listed Core 6.3 as adopted and still listed Core 6.2. The selected 6.2 page identifies Expedited Specification Update 28108 as required when claiming 6.2 compliance. Its download and the RFPHY TS p22 download returned landing pages in this research session; the underlying text was not read. Their detailed applicability stays unresolved, even though the public notice and Core text were read. BT-INDEX, BT-UPDATE, BT-TS.

Frozen review example · ISO Gregorian dates, UTC
ConditionDeterministic resultRequired response
asOf 2026-12-07; review due 2026-12-07Within review through the due date.Retain the reviewed claim and its conditions.
asOf 2026-12-08; review due 2026-12-07Inspect · R12, one UTC calendar day overdue.Recheck affected evidence; do not automatically delete the previous record.
Superseded; explicit legacy applicability and current reviewTrace complete with visible legacy note, if every other required condition holds.Keep the pinned mode and reason; a newer publication does not silently rewrite it.
Unknown, deprecated or withdrawn statusInspect · R11; program/applicability question.Find a pinned relevant rule before claiming an actual prohibition.
Invalid 2026-02-29 or future accessInvalid input; no evaluated result.Repair the date. Never roll it to March or use browser time.

Change task: suppose the firmware owner enables a different advertising mode. Reopen packet-format, gateway capability, timing/current and relevant test claims. An enclosure change instead reopens antenna/OTA evidence and integration applicability. Keep the old reviewed card as history and issue a named variant; do not make every earlier product invalid by declaration.

10 / 10

Complete and audit the evidence card

Can another engineer reconstruct both your conclusion and your next evidence request?

A useful audit makes three things visible: what is supported, the conditions under which it is supported, and the next unresolved decision. Start with the eight flawed statements below. Rewrite each before opening the answers; preserve any supported part rather than rejecting the entire source.

One-page summary audit · ungraded

Repair the technology summary

Eight original flawed claims
Flawed claimCorrected interpretation · reveal below
1 · “−70 dBm means long range.”Identify quantity, scope, source role and missing evidence.
2 · “−96 dBm at the connector is our OTA sensitivity.”Identify quantity, scope, source role and missing evidence.
3 · “One packet at 800 m proves reliable coverage.”Identify quantity, scope, source role and missing evidence.
4 · “99% at 30 m covers all installations.”Identify quantity, scope, source role and missing evidence.
5 · “The qualification listing proves range.”Identify quantity, scope, source role and missing evidence.
6 · “Profile 2.0 must use base 2.0.”Identify quantity, scope, source role and missing evidence.
7 · “Qualification authorizes the CH market.”Identify quantity, scope, source role and missing evidence.
8 · “A clause number proves we checked it.”Identify quantity, scope, source role and missing evidence.
Reveal all eight corrected interpretations

1 · “−70 dBm means long range.” A receiver requirement is conditional input evidence; require the installed link and D0 service model.

2 · “−96 dBm at the connector is our OTA sensitivity.” Retain the conducted result at R1-RX; account for R2/feed, S0 pattern and actual RX configuration.

3 · “One packet at 800 m proves reliable coverage.” A demonstration establishes that event only; demand a predeclared population, deadline and uncertainty.

4 · “99% at 30 m covers all installations.” Keep the tested sites/orientations and sampling basis; extrapolation to other installations is unresolved.

5 · “The qualification listing proves range.” Read the program/design scope; it does not replace a mounted-product delivery trial.

6 · “Profile 2.0 must use base 2.0.” Compare the exact declared dependency, not numbers from different series. The synthetic 2.0 → 1.2 pair is compatible.

7 · “Qualification authorizes the CH market.” Keep the qualification lane; separately request current product/market applicability from the compliance owner.

8 · “A clause number proves we checked it.” Read the text, dependencies and conditions; record the support review and access date. An unread locator remains inspect.

One completed authoritative definition trace: BT-CHANNEL → Core 6.2 identity → Vol 6 Part A §2 → forty channel centers with the stated spacing → arithmetic check in Section 6. This supports a channel-definition annotation for the selected LE mode. NODE-DELIVERY still needs a representative mounted trial; NODE-MARKET still needs an authoritative applicability review. The trace is complete for that definition, not for product conformance.

Rule evaluation order and outcome meaning
Order / outcomeInterpretation
1–2 · identity then graphR01 validates schema, dates and duplicate identity; R02 validates required endpoints and cycles. Invalid input produces no evaluated claims.
3–4 · scope then compatibilityR03/R04 match mode, conditions and region. R05/R06/R07 use exact curated endpoint records; they do not guess version semantics.
5 · authority and readingR08/R09/R10 check role, required evidence, human review and limits of qualification. Every applicable reason is preserved.
6–7 · lifecycle, freshness, explanationR11/R12 evaluate applicability and review due dates. Display reasons by severity, rule ID, entity ID, then claim ID.
Challenge / inspect / trace completeChallenge: explicit contradiction, incompatible required pair or wrong authority. Inspect: unknown/incomplete/overdue evidence. Trace complete: required declared metadata is consistent, read, scoped, supported and in review only.
p07-technology-evidence-card-v1 · P07-M01-LE-EXT-v1

One-page mode handoff

Illustrative engineering case. Owner: RF systems owner. Evaluation 2026-09-08 UTC; review due 2026-12-07.

Versioned mode card · complete local snapshot
FieldEvidence and decision
Scenario / requirementIllustrative condition-monitoring node; fixed mounted units and a mains-powered gateway; separate operator commissioning state. At least 99% of complete 32-byte reports received by D0 at the gateway within 2 s of release, in each predeclared mounted-orientation/site stratum; 60 s report period. This is a new illustrative requirement, not a result.
Family / exact identityBluetooth LE candidate; the earlier 2.450 GHz QPSK example is preserved as a generic baseline. Core 6.2 LE 1M and Supplement v14 data format (BT-CSS); telemetry: non-connectable, non-scannable extended advertising (ADV_EXT_IND → AUX_ADV_IND). Commissioning: separate legacy ADV_IND discovery, then a connection; commissioning service/security remains to be specified. GAP is in Core; no adopted application sensor profile is claimed.
Band / region / device classCH candidate market; 2.4 GHz band; final antenna, power class, device category, and applicability unresolved.
D0 payload / service256 bit (32 bytes), period 60 s, deadline 2 s. Release of a complete D0 report at the node to delivery of that same complete report at gateway D0; duplicate reports count once, omissions and late arrivals fail the deadline statistic.
PHY/MAC / infrastructureLE 1M candidate; proprietary advertising data encoding and total protocol overhead require a frozen schema. The complete report is not placed in a single legacy advertisement. Gateway must scan/support the selected extended advertising mode and decode the private data schema. Gateway backhaul is outside the stated D0 endpoint.
States / DC assumptionssleep: duration unknown, current unknown; wake/encode: duration unknown, current unknown; primary advertisement: duration unknown, current unknown; auxiliary advertisement: duration unknown, current unknown; gateway scan: duration unknown, current unknown; commissioning connection: duration unknown, current unknown. No battery result.
Antenna / RF interfacesR1 transceiver port → feed/match → R2 antenna feed → radiation at S0 → R2-RX → receive chain → R3 decisions → D0 report. R1-TX/RX and R2-TX/RX are directional aliases. Each feed loss is counted once; no loss numbers or EIRP are asserted.
Evidence / uncertaintyBT-CHANNEL [BT-RF]: Normative text read, bounded definition; BT-MODE [BT-LL, BT-GAP]: Selected mode documented; implementation unknown; BT-TEST [BT-DTM, BT-QPRD, BT-TS]: Test applicability incomplete; BT-CHANGE [BT-INDEX, BT-UPDATE]: Required update notice read; detailed impact unresolved; NODE-DELIVERY [no source]: Unknown; representative measurement required; NODE-MARKET [CH-OFCOM]: Unknown; authoritative applicability review required. No device sensitivity, installed antenna, scan duty, deployment distribution, timing/current trace, or confidence interval has been measured.
Qualification / regulationRead QPRD v5; selected design/layers, ICS, TCRL, test plan, and product record still unknown. CH applicability assigned to compliance owner; OFCOM orientation is not a product determination.
Decision / next evidenceRetain the LE extended-advertising variant for investigation; accept only the bounded document definitions. Product service feasibility remains unknown. Firmware owner: freeze advertising schema/capabilities and commissioning mode. Lab owner: synchronized D0/packet/current logs in mounted strata. Standards owner: read TS/update and generate applicable test plan. Compliance owner: review final CH configuration.
Continuity / review triggerInherited IDs (unaltered prior evidence): p06-evidence-map-v1, M01-A, M01-B-LOSS, M01-INSTALL-UNKNOWN. Earlier of review due, new Core/update/test program, or change in mode, host, firmware, antenna, gateway, installation, or market.

Handoff to 07.2: compare short-range candidates using this same D0 service definition. Carry the unresolved scan schedule, schema, gateway capability, current trace and market questions with their owners. Changing a number or checking a box cannot manufacture the missing evidence.

Ungraded review

Check your understanding

Answer each question in your own words, then reveal the model answer.

  1. 01Which document can establish a normative PHY rule?
    Model answer

    The applicable normative base/profile text and its dependencies. A vendor measurement can establish implementation behavior under its conditions, but cannot rewrite that rule. The product still needs its own evidence.

  2. 02Does “may implement” permit a feature to behave however the designer chooses?
    Model answer

    No. Selection may be optional while behavior, once selected, is constrained. Read the feature condition, drafting conventions, and conformance declaration. The family name alone does not tell you whether the feature is implemented.

  3. 03Is profile 2.0 with base 1.2 necessarily incompatible?
    Model answer

    No. The fictional pair is explicitly compatible; these are different document series. The conclusion applies only to those exact endpoints. An unreviewed base 1.3 pair remains unknown.

  4. 04Does a conducted sensitivity result establish a mounted node’s range?
    Model answer

    It supports only the tested receiver configuration and decision criterion at the declared input plane. Antenna/feed behavior, interference, orientation, environment, and D0 delivery statistics still need evidence.

  5. 05How do an unread clause and an overdue review differ?
    Model answer

    Unread means the supporting text has not been inspected; a locator does not repair it. Overdue means the previous review needs rechecking as of the frozen date. Neither is a measured failure; extending a date alone does not do the review.

  6. 06What closes the next market-applicability question?
    Model answer

    A qualified owner must match current authoritative requirements to the final product, modes, antenna, responsible party, and region. Qualification and a complete PHY trace are separate evidence lanes. This mapper cannot produce that determination.

References and further study

What was actually consulted

Access date: 8 September 2026, matching the frozen example evaluation date. Real-source review due: 7 December 2026, or earlier on a source/product change. Source roles and limits are recorded separately from fictional fixture values.

  1. Bluetooth Core Specification 6.2, version date 3 November 2025. Actual HTML text: Vol 1 E §1; Vol 0 D §§3–4; Vol 6 A §§1–4.1; Vol 6 B §§2.3, 2.3.1.6, 2.3.4, 4.1.1–4.1.2; Vol 3 C §11; Vol 6 F §1. Read only the stated material; no claim of whole-Core review.
  2. Core Specification Supplement v14, Part A §1.4, 3 November 2025; v15 title/version history, 5 May 2026, used to check the adoption pairing and newer revision. The v14 manufacturer-data definition is pinned for the example; newer changes require review.
  3. Qualification Program Reference Document v5, approved 21 April 2026, §§3.2.2.4–3.2.2.5 and version history; qualification overview. Public program text, not an actual qualified-product record.
  4. Specification index and Core 6.2 update notice, status snapshots. The linked update and RFPHY TS p22 bodies were not obtained; exact test/update applicability remains open.
  5. Swiss OFCOM, Market access of radiocommunications equipment, published 16 January 2025. Official orientation only; verify final product applicability with the current authoritative route.

Evidence labels: Definition names a convention; Derived means calculated from shown inputs; Illustrative means fictional teaching choices; Normative means the stated source requirement; Informative explains a source. No Simulated RF measurements, actual Measured results, certification or market approvals are produced by this lesson.