protocol-design

name	Protocol Design
department	sentinel
description	Wireless protocol selection, stack design, and interoperability
version	1
triggers	["BLE","MQTT","Matter","Thread","Zigbee","LoRa","CoAP","protocol","wireless","radio"]

Protocol Design

Purpose

Select and design the communication protocol stack for an IoT/embedded system, including physical layer selection, transport protocol, application protocol, and security layer.

Inputs

• Device hardware capabilities (radio modules available)
• Communication requirements (range, bandwidth, latency, power)
• Network topology (star, mesh, point-to-point)
• Security requirements (encryption, authentication, integrity)
• Ecosystem requirements (Matter certification, HomeKit, Alexa)

Process

Step 1: Define Communication Requirements

Quantify what the protocol must deliver:

• Range: Indoor (10m), building (50m), campus (500m), wide-area (km+)
• Bandwidth: Bytes/second needed for typical and peak traffic
• Latency: Maximum acceptable end-to-end delay
• Power budget: mA available for radio operations, duty cycle
• Topology: Star (hub-spoke), mesh (multi-hop), point-to-point
• Device density: How many devices in one radio neighborhood

Step 2: Select Physical/Link Layer

Choose the radio technology:

Protocol	Range	Bandwidth	Power	Topology	Best For
BLE 5.0	50m	2Mbps	Low	Star/mesh	Wearables, sensors, phones
Thread	50m	250kbps	Low	Mesh	Home automation (Matter)
Zigbee	100m	250kbps	Low	Mesh	Legacy home automation
Wi-Fi	50m	High	High	Star	High-bandwidth, powered devices
LoRaWAN	15km	0.3-50kbps	Very low	Star	Wide-area, low-frequency
Cellular (LTE-M/NB-IoT)	km+	Moderate	Medium	Star	Asset tracking, remote

Step 3: Select Application Protocol

Choose how data is structured and exchanged:

• MQTT: Pub/sub, lightweight, great for telemetry. Needs TCP (Wi-Fi/cellular).
• CoAP: REST-like over UDP, ideal for constrained devices. Built-in discovery.
• HTTP/REST: Universal but heavy. Only for powered devices with good connectivity.
• Custom binary: Maximum efficiency but maintenance burden. Use Protobuf or CBOR instead of raw binary.

Step 4: Design Security Layer

Layer security into the stack:

• Transport encryption: TLS 1.3 (TCP), DTLS (UDP), or link-layer encryption (BLE bonding)
• Authentication: Device certificates, pre-shared keys, or OAuth 2.0 device flow
• Integrity: Message signing, sequence numbers to prevent replay
• Key management: How are keys provisioned, rotated, and revoked?

Step 5: Design Message Format

Define the wire format:

• Serialization: JSON (readable, large), CBOR (compact, schemaless), Protobuf (compact, schema-required)
• Envelope: Header (device ID, message type, sequence, timestamp) + payload
• Size budget: Maximum message size for the chosen transport
• Fragmentation: How to handle messages larger than MTU

Step 6: Design Error Handling and Resilience

Plan for communication failures:

• Retry strategy: Exponential backoff with jitter
• QoS levels: At-most-once, at-least-once, exactly-once — which is needed?
• Offline queuing: Buffer messages during disconnection, sync on reconnect
• Connection management: Keepalive intervals, reconnection strategy

Output Format

# Protocol Architecture

## Requirements Summary
| Requirement | Value |
|-------------|-------|
| Range | [X meters/km] |
| Bandwidth | [X bytes/sec] |
| Latency | [X ms max] |
| Power budget | [X mA avg] |
| Topology | [Star/Mesh/P2P] |

## Protocol Stack
| Layer | Choice | Rationale |
|-------|--------|-----------|
| Physical/Link | [BLE/Thread/Wi-Fi/etc.] | [Why] |
| Transport | [TCP/UDP/none] | [Why] |
| Security | [TLS/DTLS/link-layer] | [Why] |
| Application | [MQTT/CoAP/custom] | [Why] |
| Serialization | [JSON/CBOR/Protobuf] | [Why] |

## Message Format

[Header: device_id (4B) | msg_type (1B) | seq (2B) | timestamp (4B)] [Payload: CBOR-encoded application data] [Total: ~128 bytes typical, 512 bytes max]

## Security Design
| Aspect | Approach |
|--------|----------|
| Encryption | [Method] |
| Authentication | [Method] |
| Key management | [Provisioning and rotation strategy] |

## Error Handling
| Scenario | Strategy |
|----------|----------|
| Message lost | [Retry/QoS approach] |
| Disconnection | [Offline queue + sync] |
| Server unreachable | [Backoff + local operation] |

Quality Checks

• Protocol selection is justified against requirements (not just "we always use MQTT")
• Power consumption of radio operations is calculated against battery budget
• Security covers encryption, authentication, and key management
• Message format fits within the chosen transport's MTU
• Error handling addresses disconnection, retry, and offline operation
• Ecosystem requirements (Matter, HomeKit) are satisfied by protocol choice

Evolution Notes