Constrained Devices: RFC 7228 Class 0, 1, 2 Definitions

Every embedded design for a battery-powered sensor node starts with a resource budget: how much RAM for buffers, how much flash for the stack, how much CPU headroom for TLS handshakes. RFC 7228 ("Terminology for Constrained-Node Networks") gives the industry a shared vocabulary for that budget. When a protocol spec, cloud vendor, or silicon datasheet says "Class 1 device," it's making a concrete claim about what that device can and cannot run — and that claim drives real architecture decisions: which protocol stack fits, whether the node can do its own TLS, and whether it needs a gateway at all.

Why This Classification Exists

Before RFC 7228 (2014, IETF), "constrained device" was a vague marketing term. The RFC ties constraint directly to two numbers — code/data memory and RAM — because those are what determine whether a device can run a full IP stack, a TLS/DTLS stack, or even a scheduler with multiple concurrent buffers. The classification isn't about clock speed or peripheral count; it's about memory footprint, because memory is what protocol and security software actually consumes.

The RFC also distinguishes constraints along three axes, not just memory:

• C1 — Maximum code complexity (constrained by flash/ROM for program storage)
• C2 — Maximum size of datasets (constrained by RAM for buffers, stacks, state)
• E — Energy limitation (battery, energy harvesting, or duty-cycled operation)
• M — Maximum bit rate / power of the transmission medium (the network, not the device itself)

Class 0/1/2 specifically addresses the memory axes (C1/C2), since that's the dominant factor in deciding what software can run on the device.

The Class Definitions

RFC 7228 gives approximate figures current at the time of writing (2014), explicitly noting these boundaries shift as memory gets cheaper, but the relative categories remain useful.

These are orders-of-magnitude boundaries, not hard spec limits — a device with 40 KiB RAM is still "Class 1-ish" in practical discussion, not a new category.

Working Through the Numbers

Take a concrete example: a battery-powered temperature/humidity sensor built around a low-end MCU with 96 KiB flash and 8 KiB RAM.

• Flash: 96 KiB < 100 KiB → Class 0/1 boundary on the code axis.
• RAM: 8 KiB < 10 KiB → Class 0 on the data axis.

Cross-checking against what needs to fit in that 8 KiB RAM: a minimal 6LoWPAN + UDP stack alone can consume 2–4 KiB of buffers and context state; add a DTLS session (record buffers, handshake state, cipher context) and you're commonly looking at another 4–8 KiB just for the crypto session — before the application even runs. That doesn't fit in 8 KiB with headroom for the sensor driver and application logic. The conclusion matches the classification: this device is Class 0, and the design must offload security and protocol termination to a border router or gateway rather than terminating DTLS/CoAP itself.

Now scale RAM up to 48 KiB and flash to 220 KiB on the same architecture. That crosses into Class 2 territory. A full mbedTLS-style TLS 1.2 stack with a single active session typically needs on the order of 20–35 KiB RAM depending on cipher suite and buffer sizing, plus tens of KiB flash for the TLS library and X.509 handling. It's tight but workable — consistent with Class 2's description as "not too constrained to use most of the same protocol stacks as notebooks/servers."

Design Implications by Class

• Class 0 → gateway-mediated. No end-to-end IP security is feasible on-device. Use a proprietary or minimal radio link (BLE advertising, proprietary sub-GHz) to a local gateway; the gateway does CoAP/MQTT, DTLS/TLS termination, and protocol translation to the cloud.
• Class 1 → CoAP/UDP with DTLS, or MQTT-SN. These devices justify their own IP identity on a constrained network (6LoWPAN over 802.15.4, for instance) but need protocols engineered for small headers and low state: CoAP instead of HTTP, DTLS with PSK or restricted cipher suites instead of full TLS negotiation.
• Class 2 → standard-ish stacks, still optimized. MQTT over TLS, CoAP over DTLS, even HTTPS in some cases. The RFC's caution still applies: "class 2 devices are the least constrained, but it is still recommended to use energy and network-bandwidth-conserving protocols."

Common Pitfalls

• Treating Class as a fixed spec. RFC 7228 is explicit that the numeric boundaries are illustrative and expected to move as hardware evolves; don't hardcode "Class 1 = exactly 10 KiB" into a requirements document.
• Confusing memory class with energy class. A Class 2 device (plenty of RAM/flash) can still be severely energy-constrained (E) if it's coin-cell powered — the classes don't imply anything about power budget.
• Ignoring the M constraint. A Class 2 device on a low-bitrate, high-latency LPWAN link (M constraint) still needs bandwidth-frugal protocols regardless of its memory headroom — CoAP over a satellite or NB-IoT link, not a chatty REST/JSON API.
• Sizing security after the fact. DTLS/TLS session state is often the single largest RAM consumer on a constrained node; size the crypto stack requirement before picking the MCU, not after.

Key Takeaways

• RFC 7228 classifies constrained devices primarily by RAM (data size, C2) and flash (code size, C1): Class 0 (<<10 KiB RAM, <<100 KiB flash), Class 1 (~10 KiB / ~100 KiB), Class 2 (~50 KiB / ~250 KiB).
• Class 0 devices can't run a secure IP stack themselves and depend on a gateway for protocol translation and security termination.
• Class 1 devices can run lightweight, purpose-built protocols (CoAP/UDP, DTLS with restricted cipher suites) directly, without a translating gateway.
• Class 2 devices can run near-standard stacks (TLS, MQTT, sometimes HTTPS) but still benefit from bandwidth- and energy-conserving protocol choices.
• The class boundaries are approximate and expected to shift over time; energy (E) and network bit-rate (M) are separate constraint axes not captured by the memory-based class number alone.
• Always size the security/crypto stack's RAM footprint against the target class before finalizing MCU memory selection — it's usually the largest single consumer of RAM on a constrained node.