Research draft

Bluetooth

vr.tr.bluetooth · PHY.OBJ

Enable an AI agent to recognise a Bluetooth implementation, assess its supported interactions and current state, and decide which discovery, connection, data exchange or configuration actions are appropriate.

Thing Registry Physical world and living systems

Research draft, second pass

A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.

Researched by: Codex + Grok

Purpose and description

Bluetooth is a short-range wireless communications technology and open protocol stack, specified by the Bluetooth Special Interest Group, that enables devices to discover, pair, and exchange data over unlicensed 2.4 GHz ISM-band radio using frequency-hopping spread spectrum.

It can be Discover or observe Bluetooth peers using supported procedures and granted permissions.; Evaluate whether a peer supports the transport, roles and services needed for a requested interaction.; Initiate or accept an authorised connection, pairing or bonding procedure.; Read, write, subscribe to or exchange data through compatible services within their access requirements.; Adjust exposed Bluetooth settings or link preferences within implementation limits and operational constraints.; Diagnose failed interactions and, when authorised, disconnect peers, remove bonds or disable the interface..

Distinguishing features

Require Bluetooth protocol, controller or service evidence; operation in the 2.4 GHz band alone does not distinguish Bluetooth from Wi-Fi or other radios.

Distinguish Bluetooth BR/EDR from Bluetooth Low Energy using supported transport and procedure evidence; a generic Bluetooth label does not establish support for both.

Identify Bluetooth interaction contracts through advertised or discovered profiles and services; a device name or product category does not establish interoperability.

Distinguish a Bluetooth peer relationship from proximity alone by recording the actual advertising, discovery, connection or bonding evidence.

Distinguish a Bluetooth address from enduring device identity by checking its address type and any supported identity-resolution evidence.

Scope

+ Evidence that an implementation uses Bluetooth and which transports, roles and features it supports

+ Bluetooth discovery, advertising, scanning, pairing, bonding and connection states

+ Profiles, services and characteristics through which Bluetooth peers can interact

+ Radio configuration, observed link quality and coexistence conditions

+ Bluetooth-specific permissions, trust relationships and permitted actions

- The complete physical device, its ownership and its non-Bluetooth functions

- Wi-Fi, NFC, Zigbee and other neighbouring communication technologies

- Application meaning and governance of data carried over Bluetooth

- Battery chemistry, charging systems and general device power management

- The full operating system, firmware lifecycle and general vulnerability management

- Bluetooth SIG governance and commercial qualification administration

Characteristics

Modelled Bluetooth subject: technology definition | controller or interface | peer endpoint | deployment | unresolved Prevents capabilities of the technology from being mistaken for capabilities of a particular implementation.
Supported transports: BR/EDR | LE | both | unknown Determines which discovery, connection and service mechanisms may be applicable.
Reported specification and feature support: reported version, explicitly supported features and supporting evidence A version claim alone is insufficient to establish optional feature support.
Bluetooth roles: transport-specific supported and active roles, including LE central, peripheral, broadcaster or observer where applicable Determines which procedures the implementation can initiate or participate in.
Address and identity basis: observed address, address type, observation time and identity-resolution basis where available Supports peer recognition without treating changing addresses as new devices or shared names as unique identifiers.
Procedure and connection state: supported, active or unavailable advertising, scanning, discovery and connection procedures, recorded separately These activities can overlap, and each permits different next actions.
Service compatibility: peer-specific profile, service, characteristic, role and feature compatibility evidence A radio connection does not establish that the intended function is available.
Observed received signal strength: dBm, with peer, observation time and measurement context Helps diagnose reception conditions but does not independently establish distance or reliable service.
Negotiated link parameters: transport-specific values, such as LE connection interval in ms, PHY and negotiated data limits Constrains achievable responsiveness, data exchange and energy use.
Peer security state: separate pairing, bonding, encryption, authentication and application-authorization states, with unknown allowed These states are distinct and must not substitute for one another when permitting access.

Also called

Bluetooth 5

Where this came from

wikidata · CC0 1.0

Source repository Registry entry point

Drafted structure

Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 28 questions.

Bluetooth identity and capability Establishes what Bluetooth subject is being described and which capabilities have evidence.

Bluetooth branding and version labels cannot alone establish the behaviour of an individual implementation.

Subject and protocol evidence

Separates the registered technology concept from its interfaces and endpoints.

Identify the Bluetooth subject

Record the subject boundary and the evidence that identifies its communication interface as Bluetooth.

Does this record describe Bluetooth as a technology, a particular controller or interface, a peer endpoint or a deployment? boundary
Which inspected controller information, protocol observation or implementation documentation establishes Bluetooth support? provenance

Transport and feature support

Records supported transports, roles and optional features without inferring them from a version number.

Establish usable capabilities

Distinguish advertised, documented and directly verified capability support.

Which BR/EDR or LE transports and roles are supported, and which are exposed to the agent? definition
What evidence supports each required feature beyond the reported Bluetooth version? provenance

Radio and link behaviour Describes Bluetooth radio availability and the observed conditions of particular links.

Peer visibility, responsiveness and connection stability depend on radio conditions and negotiated parameters.

Radio availability and observation

Distinguishes an unavailable controller from an enabled radio that has not observed a peer.

Assess radio conditions

Record controller availability and contextualised observations without translating signal strength directly into distance.

Is the Bluetooth controller enabled and available to the agent, or blocked by hardware, platform policy or permissions? measurement
What timestamped reception, loss or coexistence observations explain the peer's current visibility, and what remains unobserved? measurement

Negotiated link performance

Relates active transport parameters to the requirements of the intended service.

Assess link fitness

Evaluate actual link behaviour rather than treating nominal radio capability as delivered performance.

Which transport, PHY and link parameters are active, and what latency, throughput or failure behaviour has been measured? measurement
Which exposed parameter changes could meet the service requirement, and what responsiveness or energy tradeoffs must be accepted? action

Peer discovery and session lifecycle Tracks how Bluetooth peers become observable, identifiable and connected.

Advertising, discovery, connection and remembered peer identity represent different conditions with different next actions.

Discovery and peer recognition

Records visibility procedures and the strength of evidence linking observations to a peer.

Recognise an observed peer

Preserve address type, observation context and identity uncertainty when recognising Bluetooth endpoints.

Was the peer observed through LE advertising or scanning, BR/EDR discovery or another supported Bluetooth procedure? provenance
What evidence links this observation to the intended peer despite address changes, duplicate names or stale discovery results? provenance

Connection transitions

Separates supported connection procedures from current peer-specific session state.

Choose a session transition

Record active connections, role constraints and failure reasons before choosing the next lifecycle action.

For the intended peer, is connection establishment pending, active, failed or ended, and what event or reason supports that state? measurement
Can the agent initiate, accept, retry or terminate this connection given the active roles, peer availability and concurrent-connection limits? action

Profiles, services and data access Establishes what useful Bluetooth interactions compatible peers can perform.

Bluetooth connectivity is useful only when the required service contract and access operations are supported.

Interaction contract

Identifies profiles and services required for an intended function.

Verify service compatibility

Record the profile or service, complementary roles and required features behind the requested interaction.

Which Bluetooth profile or service implements the requested function, and which roles must each peer provide? definition
Which advertised, discovered or tested evidence confirms the required service and features on both peers? provenance

Permitted data operations

Describes the operations exposed by a discovered service and their prerequisites.

Select a service operation

Connect service-specific operations to supported properties, access requirements and freshness of discovery evidence.

For the chosen service, which operations are available, including GATT reads, writes, notifications or indications where applicable? definition
What security, authorization, subscription or service-rediscovery prerequisites must be satisfied before the requested operation? action

Pairing, trust and authority Records Bluetooth security relationships and the authority to create, use or revoke them.

A visible, connected or bonded peer is not automatically authenticated sufficiently or authorised for every operation.

Pairing and link protection

Separates pairing method, stored bonding material and protection of the current connection.

Assess peer security

Record independently evidenced security properties and any required human participation.

What pairing method and resulting authentication properties are evidenced, and is a bond stored for this peer? measurement
Is the current link encrypted with protection sufficient for the requested service, and does pairing require user confirmation or an out-of-band step? action

Permission and trust revocation

Connects Bluetooth operations to platform permissions, user intent and peer-specific authorization.

Bound agent authority

Record who permits discovery, access and trust changes, including the operational consequences of revocation.

Which user instruction, platform permission and service authorization permit the agent's proposed Bluetooth action? provenance
When may the agent disconnect, remove a bond or disable Bluetooth, and which dependent interactions would that interrupt? action

Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.