Why move the computer closer?
The first guide in this rung reinvented transport; the second moved the wire into the sky. This guide notices something all three frontiers share: they are dragging the network back toward the physical world, where milliseconds and joules are real things, not abstractions. Start with a stubborn truth from the foundations rung. Bandwidth, throughput, and latency are three different quantities, and more bandwidth does not cut latency — you cannot beat the speed of light. A round trip to a cloud datacenter 3000 km away costs at least about 20 ms of pure propagation each way, before any queuing or processing. For a video stream that is invisible; for a self-driving car's brake decision or a surgeon's haptic glove, 40 ms of unavoidable round-trip delay is a deal-breaker no upgrade can fix.
Edge computing is the honest response: if you cannot make the light faster, make the distance shorter. Instead of sending every request to a faraway cloud, you place small pools of compute and storage at the edge of the network — in the telco's local office, at the cellular base station, even inside the building — so the work happens a hop or two away. You have already met half of this idea. A CDN is a chain of local warehouses that caches content near users; edge computing is the same instinct extended from storing files to running code. The CDN answered "where do we keep the data?" with "close by"; the edge answers "where do we run the program?" the same way.
The Internet of Things, at the scale of billions
Much of what lives at the edge is the Internet of Things: not laptops and phones, but a swarm of tiny devices — a soil-moisture sensor, a door lock, a factory vibration probe, a parking meter. The defining facts are constraint and number. Each device may have a few kilobytes of memory, run on a coin cell that must last years, and connect over a slow, lossy radio. And there are billions of them. Two consequences fall straight out of earlier rungs. First, billions of always-on devices is exactly the pressure that finally justifies IPv6 and its 2^128 addresses, since the 2^32 addresses of IPv4 ran out long ago and NAT was only ever an address-exhaustion stopgap, not a home for trillions of sensors. Second, the protocols you learned for browsers are too heavy here.
Recall HTTP from the application rung: verbose text headers, a request-reply shape, and a fresh request for every exchange. For a battery sensor reporting one number a minute, that is wasteful — the headers can dwarf the data, and keeping a connection alive drains the cell. So the Internet of Things reaches for featherweight protocols. The most common is MQTT, and its key move is to drop request-reply for a publish-subscribe pattern. Devices do not call each other directly; instead a sensor publishes a message to a named topic on a central broker, and any client that subscribed to that topic gets a copy. The sensor never needs to know who is listening, and a listener never needs to know which sensor will speak. The broker is a post office sorting mail by subject line rather than by recipient.
MQTT publish/subscribe through a broker
--------------------------------------------------
sensor-A --publish--> topic: home/kitchen/temp = 21.4
sensor-B --publish--> topic: home/kitchen/co2 = 540
|
[ BROKER ] keeps last value, fans out copies
|
phone app --subscribe--> home/kitchen/# (gets temp AND co2)
logger --subscribe--> home/+/temp (gets every room's temp)
+ tiny binary header (~2 bytes), runs over TCP, optional TLS
+ 3 delivery levels: at-most-once / at-least-once / exactly-once
There is a sibling worth knowing: CoAP, the Constrained Application Protocol. Where MQTT mimics a message bus over TCP, CoAP mimics HTTP — it keeps the familiar GET, PUT, POST verbs and a URL-like address — but it runs over UDP with a compact binary header so it fits the smallest devices. This is a perfect example of an honest design choice you met earlier: UDP is not a broken TCP. CoAP deliberately gives up TCP's handshakes and reliable byte stream because for a sensor sending one short reading, a connection setup costs more than the data, and CoAP layers back just the little bits of reliability it actually needs. Different jobs, different transports — exactly the end-to-end principle in action.
When "usually fast" is not good enough
Now connect the edge and the things to a factory floor, a power grid, or a car's internal wiring, and a new requirement appears that the ordinary Internet was never built to meet. The Internet you have studied is a best-effort service: it tries hard to deliver every packet quickly, but it promises nothing about exactly when. A switch holds frames in a queue when traffic spikes, so a packet that usually crosses in 50 microseconds might take 5 milliseconds during a burst. For loading a web page, that variation — the jitter — is harmless. For a robot arm whose control loop must receive a command every millisecond, a single late packet is not slow; it is a fault that can crash the arm. The problem is not average latency. It is the worst case.
Time-Sensitive Networking, or TSN, is a set of extensions to ordinary Ethernet that turns best-effort into bounded delay — a guaranteed worst case — for the traffic that needs it, while still carrying everything else on the same cable. The headline trick is the time-aware shaper: every switch and device shares one synchronized clock (down to sub-microsecond agreement), and the network runs on a repeating schedule of tiny time slots, like traffic lights at a junction. During the slot reserved for the robot-arm stream, those packets get an open road and nothing else may enter; ordinary best-effort traffic waits its turn. Because the slot is reserved in advance, the critical packet never sits behind a queue of someone else's bulk transfer, and its arrival time is provable, not merely likely.
Three frontiers, one shape
Step back and the three threads braid together. Edge computing moves the compute near the data so the deadline is physically reachable. The Internet of Things is the flood of constrained devices generating that data, talking in lightweight protocols like MQTT and CoAP because they cannot afford the heavyweight web stack. Time-sensitive networking is what carries the most demanding of those flows when "usually fast" would be a failure. Put them on a factory floor and you get the picture: sensors publish over MQTT to a broker running at the edge, a control loop closes locally over a TSN-bounded link, and only summaries travel up to the distant cloud.
- A vibration sensor wakes, reads one value, and publishes it to a broker over a tiny MQTT message on the local network — battery barely touched.
- An edge server subscribed to that topic runs the analysis right there, so the dangerous-reading alert is decided in a millisecond, not after a round trip to the cloud.
- If that alert must stop a machine, the stop command travels over a TSN flow with a reserved time slot, so its arrival deadline is guaranteed even while the cable is busy with other traffic.
- Only afterward does a compact summary go up to the central cloud over ordinary best-effort Internet, for dashboards, history, and retraining the model.
Be honest about the costs, because they are the flip side of every benefit. Edge means many small sites to secure, update, and physically protect instead of one hardened datacenter — a firewall is not antivirus, and a thousand edge boxes are a thousand things to patch. The Internet of Things means billions of cheap devices that are notoriously under-secured; remember that a valid certificate proves identity, not honesty, and many things ship with no real security at all. And these always-on swarms run on power, which is why network sustainability — the energy and carbon cost of all this gear — has moved from an afterthought to a design constraint. The frontier is not just faster and closer; it is also more things to get right.