Chapters

3 Edge Acquisition: Control Paths and Bandwidth

analytics-ml
edge
acq

3.1 Start With the Decision

This section: Start With the Decision — A cloud command travels to a remote service, while an edge alarm is checked near the device.

A cloud command travels to a remote service, while an edge alarm is checked near the device. Their control paths, the steps from a reading to an action, do not share the same safe delay. Map both paths before deciding where data and control should live. An actuator is the device that carries out the action.

3.2 Route Overview

This section: Route Overview — This is part 2 of 3.

This is part 2 of 3. Review Edge Acquisition: Device Architecture for the preceding evidence.

3.3 Learning Objectives

This section: Learning Objectives

  • Trace cloud and edge control paths with failure states.
  • Calculate bandwidth saved by local aggregation.

3.4 Chapter Roadmap

This section: Chapter Roadmap

  • Cloud and Edge Control Paths
  • Checkpoint: Device Categories
  • Data Generation Patterns
  • Mobile figure summary
  • Mobile comparison summary
  • Data Volume by Device Type
  • Inertial Measurement Example
  • Mobile figure summary
  • Putting Numbers to It
  • Edge Bandwidth Calculator

3.5 Cloud and Edge Control Paths

This section: Cloud and Edge Control Paths — Before assigning computation, inspect Figure 3.1 to see why a cold-store control loop can become dependent on its wide-area path.

Before assigning computation, inspect Figure 3.1 to see why a cold-store control loop can become dependent on its wide-area path.

Cloud-centric IoT sequence: temperature sensor reading 7.8 degrees Celsius, IP gateway with TLS and device identity, cloud rule with a 5 degree limit, and compressor actuator, followed by a WAN fallback warning.
Figure 3.1: Cloud-centric cold-store path from a temperature sensor through an IP gateway and cloud rule to an actuator, with WAN continuity called out as the trade-off.

Read TEMP SENSOR through CLOUD RULE to ACTUATOR in Figure 3.1. The DESIGN INFERENCE explains that central history is simple, but a WAN failure interrupts the decision unless a safe fallback exists.

In Figure 3.2, the gateway evaluates the threshold before the event leaves the site.

Edge-centric IoT split path: sensor to edge gateway, local compressor actuation, event record, and non-urgent cloud analytics, with gateway buffering and replay responsibilities.
Figure 3.2: Edge-centric cold-store path with a local gateway and actuator loop plus a separate evidence record sent to cloud analytics.

Read Figure 3.2 from EDGE GATEWAY through LOCAL ACTUATOR, while EVENT RECORD carries rule and quality evidence to CLOUD ANALYTICS. That split improves continuity but makes gateway update and replay ownership explicit.

Inspect Figure 3.3 next to classify events before choosing local or remote processing and to expose the evidence each placement requires.

Data-in-motion gateway with RFID, speed, motion, and Wi-Fi events; authenticate, normalise, decide, and buffer stages; local response and remote replay paths.
Figure 3.3: Four IoT event streams entering a gateway that authenticates, normalises, decides, and buffers before routing to local response or a remote path.

Trace RFID and SPEED into AUTHENTICATE and NORMALISE in Figure 3.3, then compare LOCAL RESPONSE with REMOTE PATH. The latency chips and continuity ledger show why urgency, sensitivity, and replay needs—not data volume alone—set placement.

Finally, inspect Figure 3.4 to see how the same responsibilities scale across multiple physical zones without erasing their failure boundaries.

Physical farm zones retain individual gateway failure domains beneath one accountable platform.
Figure 3.4: Separate zone gateways contain field failures while a farm platform coordinates approved irrigation plans and records each command’s expiry and outcome.

Read Figure 3.4 from the separate physical zones toward their gateways. Each sensor station reaches its own gateway, so one failed field link can isolate a zone without blinding the entire farm. The MQTT or TLS backhaul then joins those bounded domains at the farm platform. That platform supplies shared context and rules, but it does not erase local ownership of buffering and replay. Finally, pair each command with an expiry and each audit entry with an outcome. As the number of zones grows, those two records prevent a delayed irrigation instruction from being mistaken for a current one and show whether approved control actually reached the field.

This section:

Data Dora, Data and analytics domain expertCheckpoint: Device Categories

You now know:

  • Big Things have a full IP stack and high processing capability, so they can usually upload structured data directly.
  • Small IP Things have their own Wi-Fi or cellular connectivity, but still benefit from local filtering when data rates rise.
  • Non-IP Things use links such as Zigbee, BLE, or Modbus and need a gateway for translation and aggregation.

This section: — Once the connectivity path is clear, ask how much evidence each path would move without edge filtering.

Once the connectivity path is clear, ask how much evidence each path would move without edge filtering.

3.6 Data Generation Patterns

This section: Data Generation Patterns — Understanding data generation patterns is essential for designing efficient edge acquisition systems.

Time: ~8 min | Difficulty: Intermediate | Reference: P10.C08.U02b

Understanding data generation patterns is essential for designing efficient edge acquisition systems. Different device types produce vastly different data volumes and require different handling strategies. Begin with the device-class diagram in Figure 3.5, then use Figure 3.6 to isolate the effect of sampling frequency.

Table comparing illustrative daily volume, transmission rhythm, and connectivity for three IoT device categories. Big Things include servers and industrial PLCs at gigabytes per day; Small IP Things include smart cameras and lights at megabytes per day. Non-IP Things include temperature sensors and door locks at kilobytes per day and require a gateway.
Figure 3.5: Data generation statistics for IoT devices

Read Figure 3.5 across each device row. Compare typical volume with transmission rhythm and connectivity: continuous, high-volume sources place a different burden on the edge than sparse event-driven sensors, even before fleet size is applied. Then compare rows vertically to see why direct IP connectivity does not automatically make raw upload economical. This carries the category model into the running acquisition narrative by turning device capability into a bandwidth, storage, and processing obligation.

3.7 Mobile figure summary

  • Big Things: Servers and PLCs have full IP connectivity, so they can upload structured data directly to the cloud.
  • Small IP Things: Smart cameras and other embedded devices connect over Wi-Fi or cellular and can pre-filter data before upload.
  • Non-IP Things: Simple sensors use Zigbee, BLE, Modbus, or similar buses and rely on a nearby gateway for translation and aggregation.
  • Connectivity path: Non-IP sensor -> gateway -> cloud, while Big Things and Small IP Things can usually reach the cloud without protocol translation.

The sampling-rate comparison diagram in Figure 3.6 holds record size constant so you can see the cost of changing only the acquisition interval.

Table showing IoT data storage requirements by sampling frequency. Rows compare rates from 1 per hour (480 bytes per day) through 1 per minute (28.8 KB), every 10 seconds (172.8 KB), every 1 second (1.73 MB), to 100 ms at 10 Hz (17.3 MB per day). Calculations assume 20 bytes per sample including timestamp, sensor value, and metadata. A color-coded scale bar at the bottom illustrates the exponential growth in daily data volume as sampling frequency increases.
Figure 3.6: Data generation rates and volumes comparison table

Read Figure 3.6 down the sampling-rate column and compare the daily totals. Each tenfold increase in frequency produces ten times as many 20-byte records, so the visual growth is arithmetic rather than a property of a particular sensor. Carry that daily number forward to the fleet and retention period before choosing a link. This connects sample timing to the chapter’s running design decision: faster acquisition must be justified by signal bandwidth or decision latency, then paid for with storage, radio energy, or local reduction.

Read Figure 3.5 across each device row: typical data rate, transmission rhythm, and connectivity together determine whether raw forwarding is plausible. Then read Figure 3.6 down the sampling-rate column while holding the 20-byte record size constant. Each tenfold increase in sample frequency produces a tenfold daily volume, so a modest single-node stream becomes a fleet storage and radio problem. The two comparisons advance the running narrative from device category to a measurable acquisition budget that can justify filtering, aggregation, or a different link.

3.8 Mobile comparison summary

  • Single sensor at 10 Hz: 20 bytes per sample becomes 200 bytes/sec, 12 KB/minute, 720 KB/hour, 17 MB/day, and 6.3 GB/year.
  • Fleet impact: 10 sensors generate about 63 GB/year, 100 sensors reach 630 GB/year, 1,000 sensors reach 6.3 TB/year, and 10,000 sensors reach 63 TB/year.
  • Design takeaway: Even a simple sensor becomes a storage problem at fleet scale, so edge filtering and aggregation matter early.
Data Volume by Device Type

This view shows how data generation rates vary dramatically by device type, driving different edge processing strategies. Inspect the comparison diagram in Figure 3.7 to locate the largest raw stream before selecting an edge reduction method.

Non-IP sensors produce KB/day and IP cameras GB/day. Sparse events, periodic measurements and continuous media need different forwarding choices; preserve raw evidence only where the decision needs it.

Read Figure 3.7 from low-volume Non-IP sensors toward high-volume IP devices such as cameras. The widening orders-of-magnitude gap means one forwarding policy cannot fit every source: sparse events may travel intact, periodic measurements may be batched, and continuous media often needs local selection or inference. The comparison connects the chapter’s device categories to its running budget argument: preserve raw evidence only where the downstream decision needs it, and measure the bandwidth, storage, energy, and privacy cost of that choice.

3.9 Inertial Measurement Example

This section: Inertial Measurement Example — High-frequency sensors like accelerometers and gyroscopes demonstrate why edge aggregation is critical.

High-frequency sensors like accelerometers and gyroscopes demonstrate why edge aggregation is critical. Inspect the paired traces in Figure 3.8 before reducing them so the retained summary remains tied to the motion evidence.

Accelerometer and gyroscope data showing motion events across multiple axes, emphasizing the need to preserve structure before summarization.
Figure 3.8: Accelerometer and gyroscope example sensor data

Read Figure 3.8 from the three accelerometer axes in the upper panel to the three gyroscope axes below, then move left to right through the shared time interval. Accelerometer changes combine motion and gravity; gyroscope changes record rotation. A motion event can therefore span several axes and both sensor types, which is why a single average may erase useful structure. This connects the example to the running volume argument: edge windows should retain the features required by the decision while replacing a continuous six-axis stream with an auditable summary.

3.10 Mobile figure summary

  • Session snapshot: 2017-06-30, approximately 5 Hz, with 6 recent samples shown from a wearable IMU session.
  • Accelerometer axes: X, Y, and Z linear acceleration are tracked together to capture movement and gravity.
  • Gyroscope axes: X, Y, and Z angular velocity show how the device rotates over time.
  • Edge takeaway: High-frequency six-axis data is useful locally, but the transmission layer should send aggregated summaries instead of every raw sample.

At 100 Hz sampling across 6 axes (3 accelerometer + 3 gyroscope), an IMU generates 600 samples/second. Transmitting raw data as 16-bit integers would require ~1.2 KB/s — unsustainable for battery-powered devices on LPWAN networks. Edge aggregation reduces this to statistical summaries at 1 Hz.

How much bandwidth does edge aggregation save for IMU data?

Raw transmission (no edge processing):

  • Sampling rate: 100 Hz per axis × 6 axes = 600 samples/sec
  • Data size: 2 bytes per sample (int16) × 600 = 1200 bytes/sec = 1.2 KB/s (decimal KB = 1000 B, used consistently through this section)
  • Daily volume: 1.2 KB/s×86400 s/day=103,680 KB/day≈103.7 MB/day1.2 \text{ KB/s} \times 86400 \text{ s/day} = 103{,}680 \text{ KB/day} \approx 103.7 \text{ MB/day}
  • LoRa constraint: 1% duty cycle at SF7 allows ~250 bytes/minute = 4.17 bytes/sec → Raw transmission exceeds capacity by 288×

Edge aggregation (1 Hz statistical summaries):

  • Window: 100 samples (1 second) per axis
  • Summary: 2 values per accel axis (RMS, peak) + 1 value per gyro axis (RMS) = 9 values
  • Data size: 2 bytes × 9 values = 18 bytes per second
  • Daily volume: 18 bytes/s×86400=1.56 MB/day18 \text{ bytes/s} \times 86400 = 1.56 \text{ MB/day}
  • Bandwidth reduction: 1200 B/s18 B/s=67×\frac{1200 \text{ B/s}}{18 \text{ B/s}} = 67\times

Practitioner Knowledge Check

For LoRa deployment: Transmit aggregated summaries every 10 seconds:

  • Payload: 18 bytes/s x 10s = 180 bytes per transmission
  • Frequency: 6x/minute = 360 transmissions/hour
  • Fits within LoRa 1% duty cycle? Each transmission ~0.6s airtime at SF7 -> 3.6 min/hour = 6% duty cycle (exceeds 1% limit!)
  • Further optimization: Sending the same 1 Hz stream less often does not help on its own: bundling 60 seconds of the 18-bytes/s summary into one frame is 18 x 60 = 1,080 bytes per transmission — over LoRa’s ~222-byte single-frame payload ceiling at SF7, and no better on duty cycle, since duty cycle tracks total bytes sent per hour, not how they’re chunked (~3.6s airtime x 60 tx/hour is still 6%). The fix that actually works is computing the same 9-value, 18-byte summary over a 60-second window instead of a 1-second one — fewer summaries per hour, not bigger ones: 1x/minute -> ~0.06s airtime (scaled from the 0.6s/180-byte figure above) -> 0.06s/60s = 0.1% duty cycle, comfortably within the 1% limit.
  • Extra margin: Aggregate to a 120-second window: still 18 bytes per transmission, 0.5x/minute -> ~0.05% duty cycle — more headroom if the radio shares airtime with other traffic.

Edge processing is mandatory for battery-powered IMU devices on LPWAN networks. The lesson generalizes: cutting transmission frequency alone does not reduce duty cycle if the same total bytes still go out — only cutting the number of values per summary, or computing that summary over a longer window, actually reduces the data volume.

3.11 Edge Bandwidth Calculator

This section: Edge Bandwidth Calculator — Use the sliders below to explore how sampling rate, number of axes, and aggregation window affect raw versus aggregated data rates.

Use the sliders below to explore how sampling rate, number of axes, and aggregation window affect raw versus aggregated data rates. Observe how quickly raw data exceeds LPWAN capacity.

3.12 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Edge Acquisition: Power Budgets and Pipelines, which begins with Power Budget Decision Framework.

Carry this evidence into Edge Acquisition: Power Budgets and Pipelines, which begins with Power Budget Decision Framework.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed