Bluetooth Low Energy (BLE) is a widely adopted wireless standard for low-power, short-range communication. Its advertising mechanism is simple and flexible, which is why many beacon formats such as iBeacon or Eddystone are built on top of it.
However, when building real systems — industrial tracking, coordinated device networks, or long-lived deployments — we found that existing beacon formats were too limited. They are narrowly defined, focused on simple identification, and provide little structure for evolution. This lack of protocol clarity makes consistent implementation difficult as systems grow in complexity.
To address this, we developed and open-sourced AltessaBeacon: a BLE advertising protocol with a clear specification, explicit versioning, structured payloads, and defined extension policies.
👉 https://github.com/altessa-s/altessabeacon-protocol
Why standard beacon formats didn't work for us
In practice, common beacon formats are rigid. Their payloads are fixed, versioning options are limited, and extending them without breaking compatibility is hard. Security is often missing entirely, which makes spoofing and replay trivial. There is also no formal concept of device state, priority, or controlled behavior changes — everything is just a repeating broadcast.
Industrial environments make these limitations more visible. Interference, dense deployments, metal structures, and strict battery constraints mean that packet loss is normal rather than exceptional. Once beacons start carrying structured data instead of simple IDs, these issues turn into operational risks.
Design approach
AltessaBeacon treats BLE advertising as a constrained but serious communication channel. The protocol assumes loss, duplication, and partial reception, and is designed to remain parseable and meaningful under those conditions.
At its core, AltessaBeacon uses a TLV-based framing model. This allows payloads to evolve over time without breaking existing receivers. Explicit versioning supports mixed deployments and gradual upgrades, which is critical for long-lived industrial systems.
Security is considered part of the protocol design rather than an optional add-on. The framing model allows authenticated and encrypted payloads, as well as replay protection, to be implemented consistently.
A protocol, not just a payload
AltessaBeacon is not a vendor-specific format or a loosely defined frame layout. It is a documented protocol that specifies how advertising data is structured, how fields are identified, and how receivers are expected to interpret them.
The specification emphasizes predictability. Frames are explicitly versioned, fields are formally defined, and extension rules are documented. This allows independent implementations to interoperate without relying on undocumented assumptions or implicit conventions.
For example, a wearable safety device can switch from periodic status broadcasts to high-priority emergency alerts when it detects a fall — and receivers know how to interpret this state change without custom logic.
Key protocol mechanisms
The specification introduces several named mechanisms that govern frame structure and interpretation.
EET (Extended Event Transmission) defines how protocol data relates to advertising events, allowing receivers to treat related transmissions as part of a single logical context rather than isolated packets.
BAIS (Beacon Adaptive Information Set) defines how the set of advertised information can change depending on device state or operational context, while preserving a consistent structure.
SCF (Structured Control Fields) define standardized control and signaling fields inside the payload, providing explicit protocol-level semantics instead of application-specific interpretation.
Together, these mechanisms allow AltessaBeacon to describe not only the advertised data, but also how that data should be interpreted.
Versioning and extensibility
AltessaBeacon explicitly separates protocol versioning from payload content. This makes it possible to evolve the protocol over time while remaining backward-compatible at the framing level.
Extensions are governed by a public registry and policy that define how new fields are introduced and documented. Receivers can safely ignore unknown fields while continuing to process known ones, which is essential for long-lived deployments.
Open specification by design
AltessaBeacon is fully open and vendor-neutral. The repository includes: a protocol overview, a formal specification, a registry and extension policy, and a reference C header.
The specification is intended to be implemented independently, not tied to a single stack or product. This openness is deliberate: it enables interoperability, review, and long-term maintenance.
Closing thoughts
BLE advertising is often treated as a minimal broadcast mechanism. AltessaBeacon takes a different approach, treating advertising as a structured communication channel with defined semantics and evolution rules.
The protocol is open, documented, and intentionally conservative in scope. If you need a clear and extensible baseline for structured BLE advertising data, AltessaBeacon aims to provide exactly that.
🔗 Repository: https://github.com/altessa-s/altessabeacon-protocol
Top comments (0)