Lightweight discrete protocol for resource-constrained IoT devices
Fink is a lightweight discrete protocol designed for resource-constrained IoT devices with limited bandwidth.
The Fink frames are called fink-o-gramm and have their own structure.
| Field | Size | Description |
|---|---|---|
Magic |
1 byte | Protocol identifier calculated by the Together method (see below). |
Flags |
1 byte | Frame flags (see below). |
Length |
1 byte | Length of the payload. |
Payload |
0~255 bytes | User data up to 255 bytes. |
Checksum |
1 byte | CRC-8/ROHC checksum of the frame. |
The Magic field is a one-byte identifier that uniquely represents both the protocol and its version. It is calculated using the Together method.
The Together method computes the CRC-8/ROHC checksum of the following ASCII string:
"{PROTOCOL}/{version}"
where:
- PROTOCOL - protocol identifier written in uppercase.
- version - sequential protocol version number.
The resulting CRC-8/ROHC value becomes the Magic field of every frame.
The Together method serves two purposes:
- Explicit protocol filtering - frames belonging to other protocols are immediately rejected because their Magic value differs.
- Automatic version discrimination - different protocol versions produce different Magic values, allowing incompatible versions to be distinguished without transmitting the version number separately.
This approach eliminates the need to transmit the protocol identifier and version separately, reducing frame overhead while preserving reliable identification.
Example
For protocol FINK version 1:
Input string: "FINK/1"
CRC-8/ROHC: 0xDB
Therefore, every frame of FINK v1 begins with the following Magic byte:
Magic = 0xDB
The Flags field is a one-byte bitmask that contains frame attributes and control information. Each bit represents an independent flag and may be set or cleared without affecting the others.
| Flag | Bit | Description |
|---|---|---|
URGENT |
0 | Marks the frame as high priority. The receiver should process it as soon as possible. |
REQUIRE_ACK |
1 | Requests an acknowledgment from the receiver. After successful processing, an ACK frame should be sent in response. |
ACK |
2 | Indicates that the frame is an acknowledgment for a previously received frame. The payload may be empty unless the protocol extension defines otherwise. |
| Reserved | 3–7 | Reserved for future protocol extensions. These bits must be transmitted as 0 and ignored by receivers. |
- Multiple flags may be set simultaneously unless explicitly prohibited by a protocol extension.
- Reserved bits should always remain cleared to ensure forward compatibility with future protocol versions.
Important: The Fink protocol itself is stateless and does not implement reliability mechanisms (retransmission, timeouts, sequence numbers). It only provides the signaling flags (REQUIRE_ACK, ACK) and integrity checks.
Reliability is an application-layer responsibility. However, to ensure interoperability, deterministic behavior, and to prevent network congestion or battery drain on resource-constrained devices, any implementation utilizing the ACK mechanism MUST adhere to the following guidelines:
| Parameter | Value | Requirement | Rationale |
|---|---|---|---|
| ACK Transmission Delay | ≤ 250 ms | The receiver MUST transmit the ACK frame within 250 ms after successful Magic and CRC validation. |
Prevents unnecessary retransmissions. The delay must not include application-level processing time; ACK confirms receipt, not execution. |
| Initial Retransmission Timeout | 250 ms | The sender SHOULD use 250 ms as the initial timeout for waiting for an ACK. | Matches the receiver's maximum response time. |
| Maximum Retries | 3 | The sender MAY retransmit a frame up to 3 times if no ACK is received. | Limits network flooding and battery consumption. After 3 failures, the application should treat the delivery as failed. |
| Backoff Strategy | Exponential | On each retry, the timeout SHOULD be doubled (250 ms → 500 ms → 1 s). | Reduces collision probability in lossy channels. |
| ACK Frame Priority | Mandatory | All ACK frames MUST be sent with the URGENT (bit 0) flag set. |
Ensures low-latency delivery of acknowledgments, preventing the sender from triggering premature retransmissions. |
This split design preserves the minimal overhead of the Fink protocol (4 bytes) while ensuring consistent behavior across heterogeneous implementations (microcontrollers, gateways, cloud services).
- For constrained devices: The strict limits (3 retries, capped delays) protect against infinite loops and excessive radio duty cycle.
- For high-performance systems: The exponential backoff and priority flag optimize throughput without requiring complex congestion control algorithms.
- Interoperability: By fixing these values in the standard, different vendors' implementations will behave predictably when communicating over the same channel.
The protocol is licensed under Apache-2.0.