Stack selection is routinely settled on throughput, coverage maps, and cost per device, all of which describe the stack working as intended. Deployments rarely fail because the data rate was too low. They fail because one layer degraded in a way the design did not anticipate, and nothing above it had an answer.

A connectivity stack should be selected based on how it behaves when it degrades, not on how it performs when everything works.

What an IoT Stack Actually Is

The IoT stack is the full set of hardware, software, protocol, and cloud components a connected product needs to operate. It is a per-product construction rather than something a vendor sells complete, and two deployments sending similar payloads routinely arrive at different stacks because their power budgets and coverage conditions differ.

The layers run from the hardware that senses and transmits, through the device software that governs behaviour, to the protocol layer that carries the data and the cloud layer that interprets it. A change at one layer propagates through the others: moving from a cellular module to a low-power radio changes the antenna, the power design, the firmware retry logic, and the cloud ingestion path. Each layer also has its own failure mode, and a stack is only as reliable as the layer that degrades first, which is what aggregate throughput figures hide.

The IoT technology stack has four layers:

1. Hardware: sensors, processing, radio module, antenna, and power design, which set the physical ceiling on what can be measured and sent.
2. Device software and firmware: the operating system, drivers, and application logic that decide how the device behaves under load, loss, and recovery.
3. Protocol and connectivity: the radio technology, network, and messaging protocols that move the payload from device to infrastructure.
4. Cloud and application: ingestion, storage, analytics, and the interface through which the deployment is actually used.

How IoT Stack Layers Work Together, and How They Fail Apart

The Hardware Layer

Sensor selection determines what can be measured, the radio and antenna set the link margin available, and the power design determines whether a transmit burst completes without disturbing the rest of the board. 

Several hardware failures then present as software problems. Antenna detuning against an enclosure appears as poor connectivity on a subset of units, brownout under transmit current appears as random reboots, and thermal throttling appears as latency that grows through a session. 

In each case, the firmware team spends weeks on a defect that was fixed on the board or not at all.

The Device Software Layer

Firmware decides what happens when conditions stop being ideal. Retry logic determines whether a device floods a marginal link or backs off, buffering determines how much data survives an outage, and recovery from unexpected power loss determines whether an interrupted write leaves a device operable or needing a site visit. 

Over-the-air (OTA) update capability belongs in the stack evaluation rather than the project backlog, because a device that cannot be updated in the field inherits every future protocol change and security disclosure as a hardware problem, paid in truck rolls across the installed base.

The Protocol and Connectivity Layer

Compared on throughput, connectivity options separate cleanly. Compared on degradation, they separate differently. 

• A cellular link at the edge of coverage does not stop; it retries, and each retry raises current draw, so a battery-powered device in a marginal cell can exhaust its power budget months early while still reporting normally. 
• A low-power wide-area link depends on gateway availability, and gateway loss removes a geographic cluster at once. 
• A mesh degrades gracefully when a node drops, provided the routing has enough neighbours to re-form. 

The cost variables here are power per message, the latency floor, and dependency on third-party infrastructure. Dense deployments make the point, since smart cities run thousands of endpoints whose economics are set by energy per message rather than peak data rate. 

A gateway aggregates traffic efficiently and concentrates risk with it, and remains a single point of failure unless designed not to be.

The Cloud and Application Layer

The cloud layer contributes aggregation, storage, cross-fleet analytics, and model training at a scale no device can hold, which makes it the right home for anything that needs the whole population of devices to be useful. 

The design consequence is plain: any function placed in the cloud stops working when the link does, which makes the placement of decision-making a reliability decision rather than an architectural preference. Local inference is the counterweight, since a device that interprets its own data keeps acting through a disconnection and sends conclusions rather than raw feeds. 

The same reasoning drives edge AI for HMI applications, where a round trip to a server is a failure mode rather than a design option.

Evaluating IoT Platforms by What They Assume

IoT platforms bundle device management, connectivity, ingestion, and a data model together. The bundling shortens development and transfers assumptions into the design: which protocols are supported, how updates are delivered, and what a device may do while offline. 

Those assumptions are rarely on the feature list, because they are not features. Test a platform against its degradation cases instead: what the device does after 12 hours offline, and what changing a module or network operator costs once 20,000 units are deployed. Lock-in is an engineering risk before it is a commercial one, since leaving is paid in firmware rewrites and requalification against an installed base that has to keep running throughout.

• What happens at the edge of coverage: whether the device degrades predictably or burns its power budget retrying.
• What happens when the link drops entirely: what the device still does locally, and how much data it holds.
• What happens when a module goes end of life: whether a replacement is drop-in, or forces layout, certification, and firmware work.
• What happens when a protocol or security standard changes: whether the fleet updates in place, and how long a rollout takes.
• What the recovery path looks like after a failed update: whether a device rolls back on its own, or becomes a site visit.

The Layer Most Stack Decisions Underweight

Protocol choice, platform choice, and cloud architecture are all executed by a physical board, and the board decides whether the chosen stack performs as designed. RF layout and antenna integration set the link margin that determines how often the connectivity layer runs at its edge. Power delivery determines whether transmit bursts complete without sagging the supply feeding the processor. 

Thermal design determines whether sustained edge processing holds its throughput or throttles into the latency the architecture was chosen to avoid. A stack selected on paper still has to be realised in hardware, and that translation is where most of the engineering risk sits.

Building the Hardware Layer of an IoT Stack With PCI

PCI is an electronics manufacturing services (EMS) specialist with over 50 years of experience turning connectivity architectures into hardware that performs in the field. Early involvement is the point at which stack assumptions can still be tested against a board, rather than discovered after production.

• Electronic hardware design: power delivery, signal integrity, and thermal behaviour planned around the radio and processing load.
• RF and radio-wave engineering: antenna integration and link margin verified in the production enclosure, not on an open bench.
• Embedded firmware: retry, buffering, store-and-forward, and OTA paths built into the device design rather than added later.
• Single-board computers: compute platforms sized to the inference and protocol workload assigned to the device.
• Telematics platforms: connected hardware proven across marine, land, and fleet deployments where coverage cannot be relied upon.
• Printed circuit board assembly: process control that holds RF and thermal performance consistent across a production run.

Conclusion

Data rate describes the best case, and stack decisions should be made on the worst one. Selecting an EMS partner for your IoT solutions early gives the hardware layer a say in the stack while both are still open, the only period in which a protocol assumption and a board layout can be reconciled without cost. 

Talk to PCI about validating a connectivity architecture against the board that has to deliver it.

Frequently Asked Questions

What Is an IoT Stack?

An IoT stack is the combined set of hardware, device software, connectivity protocol, and cloud components that make a connected product work. It is assembled for that product rather than bought as a unit, because the right combination depends on the power budget, coverage conditions, and service life of the deployment. Stacks also change over that service life, as modules go end of life and network technologies are retired, which is why upgrade paths belong in the original evaluation.

What Are the Layers of the IoT Stack?

There are four. Hardware covers sensors, processing, radio, antenna, and power, and sets the physical ceiling for the rest. Device software covers firmware and the operating system, and governs behaviour under load, disconnection, and recovery. Protocol and connectivity carry the payload. Cloud and application cover ingestion, storage, analytics, and the interface. The layers are interdependent, so changing a radio module alters the antenna and power design beneath it, the firmware above it, and often the payload format the cloud expects.