13.4.2: Latency Budgets and Network Characteristics

When distributing workloads, architects often establish a latency budget for each component. For example, a remote surgery robot might require end-to-end control loop latency under 20 milliseconds. If the network round-trip to cloud alone is 50 ms (even in the best case of fiber optics over distance), then clearly the cloud cannot be in that loop – the edge (hospital-local server) must handle it. On the contrary, an agricultural sensor measuring soil moisture might only need to report every few minutes; a few seconds of cloud latency is inconsequential, so cloud processing is fine.

Network characteristics also influence design: If devices connect over cellular networks, latency might be higher or variable. Designers might push more logic to the edge to avoid uncertainty. Conversely, if devices are in a campus with excellent local networks to an edge server, they can offload more to that server confidently.

Workload partitioning strategies include:

• Filtering at edge: As noted, process raw data to reduce volume. E.g., audio sensors doing keyword spotting locally (“wake word detection” in smart speakers) and only sending relevant audio to cloud for full speech recognition. This ensures privacy and reduces uplink usage – the device only streams audio after hearing “Alexa” or “Hey Google,” for example.
• Edge aggregation: Combining data from multiple local sources. For instance, an edge gateway in a building could aggregate readings from hundreds of HVAC sensors and send a single summary to cloud (like average temperature per floor and any out-of-range values). The cloud then deals with summaries from many buildings rather than thousands of individual sensor readings per minute.
• Local actuations: If an IoT system has feedback loops (sensor triggers an actuator), keeping that loop local can be vital. Imagine a greenhouse: a sensor detects humidity drop and needs to turn on a mister. If it goes through the cloud, internet issues could delay the mist. Instead, an edge controller (or even the device itself through direct wiring) should handle it. The cloud can still log the event and perhaps adjust overall climate settings, but the immediate actuation is local.

The interplay between latency and reliability also surfaces: by having edge autonomy, systems can tolerate network disruptions gracefully. For example, a wind turbine’s edge controller can keep adjusting blade positions for optimal performance even if connectivity to cloud is lost for an hour; the cloud, when available, might provide higher-level optimization across an entire wind farm, but each turbine can run independently if needed.

---