Communication and Networking
Communication and networking capabilities transform embedded systems from isolated devices into interconnected components of larger systems. Modern embedded applications increasingly need to exchange data with peer devices, cloud services, and enterprise software, which makes networking a fundamental skill for embedded developers rather than a specialty reserved for a few projects.
This category examines the protocols, architectures, and implementation techniques that let embedded systems communicate effectively. The range is wide: lightweight application protocols sized for microcontrollers with a few tens of kilobytes of RAM, full TCP/IP stacks running under a real-time operating system, simple point-to-point serial links, and self-healing mesh networks of hundreds of battery-powered nodes. The topics collected here provide the foundation for building connected embedded solutions across that spectrum.
Core Concepts
Embedded networking differs significantly from general-purpose computer networking. Constraints on memory, processing power, energy, and timing shape every aspect of protocol selection and implementation. A desktop or server can afford a general-purpose stack that buffers generously and retries freely; an embedded node usually cannot.
Memory is often the first binding constraint. A conventional BSD-derived TCP/IP implementation occupies on the order of a hundred kilobytes of code, whereas lwIP, the most widely deployed embedded stack, fits in roughly forty kilobytes of code and tens of kilobytes of RAM. Smaller stacks in the uIP tradition shrink into a few kilobytes by handling only one unacknowledged TCP segment at a time, trading throughput for footprint. Every buffer must be budgeted for the worst case, because a network stack that exhausts RAM under load fails in ways that are difficult to reproduce.
Energy is the second constraint. In a battery-powered wireless node, the radio typically dominates the power budget, so the design goal is not raw throughput but keeping the transceiver off. A sensor that reports a few bytes every fifteen minutes may transmit for a few milliseconds per hour and sleep for the rest, which forces choices such as short frames, infrequent handshakes, and session resumption instead of full renegotiation.
Timing is the third. A factory controller must deliver each frame within a bounded, predictable interval, so its network is judged by worst-case latency and jitter rather than average throughput. Frame size limits add a fourth pressure: IEEE 802.15.4 caps a physical-layer frame at 127 octets, while IPv6 requires links to carry datagrams of at least 1,280 octets, a gap that the 6LoWPAN adaptation layer bridges through header compression and fragmentation. Security and interoperability round out the list, since a constrained device still has to speak the same protocols as the infrastructure it joins. The subcategories below address these competing demands across different networking domains.
Articles in This Category
The Embedded Protocol Stack
Most connected embedded designs assemble a layered stack, and the useful skill is knowing which layer solves which problem. The layers below appear, in some form, in nearly every networked product.
Physical and Link Layers
The bottom layers determine reach, data rate, and energy cost. Wired options include Ethernet, commonly 10 or 100 Mbit/s on microcontroller-class media access controllers and gigabit on application processors; CAN and CAN FD for rugged multi-master buses in vehicles and machinery; and RS-485 for multi-drop links over twisted pair. Wireless options include IEEE 802.15.4, which carries 250 kbit/s in the 2.4 GHz band with a 127-octet maximum frame; Bluetooth Low Energy for short-range, low-duty-cycle links; Wi-Fi for high-bandwidth local connectivity; and low-power wide-area technologies for long-range telemetry.
Adaptation and Network Layers
Running IP over a constrained radio requires an adaptation layer. 6LoWPAN compresses IPv6 and UDP headers and fragments datagrams so that they fit within short 802.15.4 frames, which lets a sensor node hold a genuine IPv6 address instead of a proprietary short identifier. Thread builds on that foundation to form a self-healing IPv6 mesh with no single point of failure, and it serves as one of the transports beneath the Matter smart-home standard. Where IP is unnecessary, protocol families such as Zigbee define their own network layer over the same radio.
Transport Layer
TCP provides ordered, reliable byte streams, but its connection state, retransmission timers, and window management cost memory and energy, and its congestion control behaves poorly over lossy radio links. UDP is therefore the common choice on constrained networks, with reliability supplied selectively by the application protocol above it. Designs that need both often use TCP for firmware downloads and configuration and UDP for routine telemetry.
Application Layer
MQTT is an OASIS standard for publish-subscribe messaging through a broker. Version 3.1.1 was also published as ISO/IEC 20922:2016, and version 5.0, released in 2019, added properties, reason codes, topic aliases, session expiry, and shared subscriptions. Its fixed header is two bytes in the simplest case, which suits low-bandwidth links, and the MQTT-SN variant adapts the model to sensor networks that lack TCP/IP. CoAP, specified in RFC 7252, offers a REST-style request-response model over UDP with a four-byte header, along with observe subscriptions and block-wise transfer for payloads larger than a single datagram. OMA Lightweight M2M layers device management, firmware update, and a standard object model on top of CoAP; version 1.2 added HTTP and MQTT transport bindings.
Security Layer
Transport security normally comes from TLS 1.3, defined in RFC 8446, or its datagram counterpart DTLS 1.3, defined in RFC 9147, both of which shorten the handshake to a single round trip and remove legacy cipher suites. For CoAP deployments that traverse proxies, OSCORE (RFC 8613) protects messages at the object level so that the payload stays confidential end to end even when an intermediary re-frames the request, and EDHOC (RFC 9528) supplies a compact authenticated key exchange for the most constrained links.
Choosing a Communication Technology
Selecting a networking technology means matching the traffic profile, the physical environment, and the power budget against what each option can deliver. Four rough families cover most embedded products.
Wired Links
Wired connections offer stable bandwidth, reliable power, and predictable timing. Ethernet remains the default where a cable is acceptable, since it carries IP directly and integrates with existing infrastructure. CAN sacrifices bandwidth for robustness and non-destructive priority arbitration, which is why it persists in vehicles and machinery, and CAN FD raises the payload and data-phase rate while preserving that arbitration. RS-485 remains common in building automation and process instrumentation, most often carrying Modbus.
Short-Range Wireless
Bluetooth Low Energy suits intermittent links to a phone or a nearby hub and can run for years on a coin cell. IEEE 802.15.4 mesh stacks, including Zigbee and Thread, extend coverage across a building by relaying through mains-powered routers while battery-powered end devices sleep. Wi-Fi delivers the highest local bandwidth and connects directly to IP infrastructure, at a power cost that generally rules it out for long-lived battery designs.
Low-Power Wide-Area Networks
Where nodes are kilometers apart and send only occasional short messages, low-power wide-area technologies apply. LoRaWAN operates in unlicensed spectrum at data rates of roughly 0.3 to 50 kbit/s and lets an operator deploy private gateways. NB-IoT and LTE-M use licensed cellular spectrum and existing carrier coverage; NB-IoT favors deep indoor penetration at modest rates, while LTE-M supports higher rates and handover for mobile assets. The trade is coverage and battery life against bandwidth and per-message latency.
Deterministic and Industrial Networks
Motion control, robotics, and process safety require bounded delivery times rather than high averages. EtherCAT, PROFINET, and EtherNet/IP adapt Ethernet hardware to cyclic, scheduled traffic, with the fastest profiles reaching cycle times below one millisecond. Time-Sensitive Networking generalizes those ideas into IEEE 802.1 standards for ordinary bridged Ethernet: IEEE 802.1AS distributes a common time base as a profile of the IEEE 1588 Precision Time Protocol, IEEE 802.1Qbv gates queues on a repeating schedule through the time-aware shaper, frame preemption lets an urgent frame interrupt a long one, and IEEE 802.1CB replicates critical frames over disjoint paths so that a single link failure does not lose data.
Implementation Considerations
Several concerns cut across every embedded networking project regardless of the protocols chosen.
Memory and Buffer Management
Network buffers and protocol state consume the scarcest resource on a microcontroller. Practical designs size buffer pools statically, avoid dynamic allocation in the data path, and use zero-copy techniques so that a packet is not duplicated between the driver, the stack, and the application. Reassembly of fragmented datagrams deserves particular care, because an attacker can exhaust a small pool with incomplete fragments.
Power Management
Because the radio usually dominates energy use, power strategy is largely a matter of transmitting rarely and briefly. Effective measures include aggregating readings before sending, choosing keep-alive and reporting intervals deliberately rather than by default, resuming security sessions instead of repeating full handshakes, and letting the link layer schedule sleep so that the application does not poll.
Security by Design
Security must be part of the architecture from the outset, since retrofitting protection into a shipped, resource-constrained device is rarely practical. That means provisioning unique per-device credentials in manufacturing, storing keys in a secure element or protected memory rather than in general Flash, using hardware cryptographic accelerators where available, authenticating firmware updates so that a compromised network cannot install malicious code, and planning for key rotation across a fleet that may operate for a decade.
Testing, Debugging, and Interoperability
Networked embedded systems fail in ways that a debugger attached to one node cannot explain. Packet capture, protocol analyzers, and radio sniffers reveal what actually crossed the link; network emulation that injects loss, delay, and reordering exposes the retry logic that a clean bench never exercises. Interoperability testing and, where applicable, certification programs confirm that a device works with the wider ecosystem of equipment and services it will meet in the field.
Summary
The topics in this category span the full range of embedded networking, from byte-level protocol implementation to system architecture. The unifying theme is constraint: memory, energy, and timing budgets rule out the general-purpose answers that suffice elsewhere and reward designs that move the fewest bytes at the right moments. Whether the goal is a sensor node that reports a reading each hour or an edge gateway translating several protocol streams at once, the concepts and techniques presented here provide the foundation for building robust, efficient, and secure networked embedded systems.