What makes a setting "resource-constrained", and why is that phrase doing more work than it looks?

Constrained means the device is limited in energy, compute, memory, storage and bandwidth simultaneously — so the usual engineering escape route of "throw more resources at it" is closed in every direction at once.

The constraint is never a single dimension:

• Energy — a fixed battery, possibly topped up by harvesting, that must last years.
• Compute — a microcontroller, often without a floating-point unit, sometimes without memory protection.
• Memory — RAM measured in kilobytes, not gigabytes.
• Storage — a small flash part holding firmware, configuration and a modest buffer.
• Bandwidth and duty cycle — a low-rate radio, sometimes legally capped in how often it may transmit.
• Physical access — no screen, no keyboard, and nobody nearby.

What makes this harder than ordinary optimisation is that the dimensions are coupled: saving energy by sleeping more costs you responsiveness; saving memory by not buffering costs you resilience to a dropped link; saving bandwidth by computing locally costs energy and memory. Every fix is a transfer, not a saving.

This is why "resource-constrained" recurs in three separate learning objectives — architectures, protocols and security each have to be rebuilt for it. Resource-constrained devices require special protocols, which is exactly why CoAP, MQTT, DTLS and 6LoWPAN exist instead of HTTP, TLS and plain IPv6, and why lightweight cryptographic primitives are a research field rather than a footnote.

Tip: a good self-test for any proposed IoT design: name which resource it spends and which it saves. If the answer is "it just works", the design has not been costed yet.

Go deeper:

• NIST — Lightweight Cryptography project — what "constrained" forces on cryptography specifically: NIST standardised the Ascon family because existing standards do not perform acceptably on this hardware.