Use when selecting and designing communication protocol stacks for IoT or embedded systems. Covers physical layer selection, transport and application protocols, security layers, message format design, and error resilience. Do not use for firmware architecture (use embedded-architecture) or fleet-scale operations (use fleet-management).
Select and design the communication protocol stack for an IoT/embedded system, including physical layer selection, transport protocol, application protocol, and security layer.
Evaluates protocol options against device requirements and produces stack recommendations. Does not implement protocol drivers or radio firmware. Does not perform RF testing or spectrum analysis.
No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.
Quantify what the protocol must deliver:
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 |
Choose how data is structured and exchanged:
Layer security into the stack:
Define the wire format:
Plan for communication failures:
Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.
# 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] |