Protocol Design

Step 2: Select Physical/Link Layer

Choose the radio technology:

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