ULCP: Minimum Requirements

This chapter is the conformance statement for ULCP. A device that meets the requirements below is a ULCP device; everything past them is optional and is discovered through PROP_CAPS.

There are no protocol levels, tiers, or profiles. A host that wants a plain frame pipe and a host that wants a fully provisioned companion radio speak the same protocol to the same devices and differ only in which capabilities they look for. A device implements the subsystems its hardware and purpose call for and advertises exactly those.

Framing

A device MUST implement the frame format in full: the header with its FLG, RESERVED, and TID fields, the packed unsigned integer encoding for command, property, and stream identifiers, and the transport’s framing (HDLC-Lite on serial links, the GATT frame transport over BLE).

The TID discipline is normative in both directions: a device MUST NOT send a frame with a non-zero TID that is not a response to a frame it recently received with that TID, and all unsolicited commands MUST use TID zero.

Commands

CMD_PROP_INSERT, CMD_PROP_REMOVE, and their notifications belong to the base grammar rather than to any capability. A device that defines no mutable multi-value property has nothing to apply them to and rejects them under the ordinary property rules. CMD_QUEUE_DRAIN, CMD_SAVE, and CMD_RESTORE belong to their subsystems’ capabilities and MUST fail with STATUS_UNIMPLEMENTED when the capability is not advertised; CMD_CLEAR and CMD_FACTORY_RESET are available regardless of capabilities (see Saved State).

Properties

Every other property is gated by a capability. A device that does not advertise the capability does not implement the property, and rejects it with STATUS_PROP_NOT_FOUND or STATUS_UNIMPLEMENTED.

Status and Reset Reporting

A device MUST implement PROP_LAST_STATUS as the failure channel for every command, using the most specific applicable status code, and MUST emit a reset code asynchronously after every reset. A device that cannot determine the cause reports STATUS_RESET_UNKNOWN rather than omitting the notification.

Optional Subsystems

Everything else in this specification is a capability. Each grants the commands and properties defined in its chapter, and a device MUST NOT advertise a capability without also advertising the capabilities it requires.

A device advertising none of them is a transparent radio: it configures its PHY, transmits what it is given, and delivers everything it hears.

Requirements on Hosts

A conforming host:

• MUST tolerate unsolicited CMD_PROP_IS, CMD_PROP_INSERTED, and CMD_PROP_REMOVED notifications at any time while attached, and update its view of the affected property accordingly. Device state changes for reasons the host did not initiate, and publication of the new authoritative value is how the protocol reports it.
• MUST take the value in a CMD_PROP_IS as the property’s value, and MUST NOT treat one that differs from what it wrote as an error. A write is refused by a PROP_LAST_STATUS carrying the failure and by nothing else; anything a device reports as a property value is what that property is, whether or not it is what was asked for — see PROP_PHY_TX_POWER, which a device clamps to what its radio can reach. A host that shows the value to a user shows the reported one.
• MUST NOT treat a failed capability-gated property read as a failed attach. A device advertising a capability implements its properties, so a refusal is a device fault — but what is unknown is the setting, not the device. A host finishes the rest of the read, presents the affected setting as unavailable rather than as a default, and omits it from what it writes.
• MUST NOT assume that a reset implies documented factory defaults. On a device holding a saved snapshot the post-reset value of every saved property is its saved value; a host fetches or explicitly sets what it depends on.
• MUST establish its complete host domain on every tethered attach, if it uses host services at all, rather than reasoning about what the device already holds.
• MUST NOT write host-domain properties when it is merely administering a device rather than being that device’s host — see Two Kinds of Attach.
• SHOULD follow the post-attach procedure in Attach, Detach, and Synchronization.

Deployment Shapes

The capability sets that correspond to the familiar deployments, as a reader’s aid rather than a normative classification:

The same firmware ordinarily advertises all of them: which deployment a device is doing is a matter of what its operator provisioned, not of what it can do.