15 Edge and Fog Gateways

15.1 Place Each Task Where the Evidence Survives

Place One Task, Then Keep Its Trail

Picture a delivery phone that reads a package sensor. It may need to warn the driver now, join records at the depot, and send a smaller history to a central service. Those jobs do not all belong in the same place.

A gateway is a bridge that moves or changes data between systems. Edge work happens on or very near the source. Fog work joins nearby devices or sites. Central work keeps long history and supports work across many sites.

Choose a place for each task. Keep urgent safe action near the source. Put shared site rules where local devices can reach them during an outside outage. Put fleet-wide learning and long records where one team can govern them. State what each step receives, removes, adds, and sends.

Reduction is useful only when the result stays explainable. Keep source time, rule version, quality state, and the reason an event was kept. Test loss, delay, repeat upload, low power, and movement between sites.

Use Practitioner for placement and hand-off records. Use Under the Hood for model, time, identity, and audit limits.

A mobile gateway can do more than relay data. It can act as an edge node that processes at or very near the source, as a fog node that coordinates several sources before cloud handoff, or as the cloud handoff point for fleet-wide work. These are not a single either-or choice. A real release usually uses several layers at once: a sensor performs a threshold check, the phone computes a local feature, a nearby gateway reconciles records from several phones, and the cloud trains models and keeps the long-term history.

The key idea is that placement is a per-task decision that must be reviewable, not a slogan. "Local is always faster" and "the cloud is always easier" are both wrong as universal rules. Each processing task belongs wherever its freshness, privacy, volume, battery, offline, and audit needs can actually be proven. And because a mobile gateway moves and reduces data, the claim "we process this at the edge" stays a claim until a reviewer can trace one raw reading through its local summary to the cloud exception it produced.

Think of a delivery phone deciding whether to alert now, summarize for a depot, or wait for the cloud. The right answer is not simply the closest computer; it is the place where the learner can still explain what happened after the upload returns, so data reduction and traceability are treated as the same review problem rather than separate paperwork.

Four roles keep the discussion precise. The sensor edge runs the smallest local rule — thresholds, sampling, debouncing, and immediate safety interlocks that must happen at the source. The mobile gateway handles protocol, timestamping, local validation, feature extraction, short-term buffering, and user or site context. The nearby fog layer does shared local coordination — reconciling several gateways, applying site policy, serving local dashboards, and tolerating outages. The cloud owns long-term retention, cross-site analytics, governance, model training, and reporting.

How It Works: Place Each Task Where Its Evidence Can Survive

The placement decision starts with the task, not the hardware label. Freshness, privacy, volume, offline behavior, and audit needs decide whether the work belongs at the sensor edge, on the phone gateway, in nearby fog, or in the cloud. The handoff record then keeps the decision reviewable after data has been reduced.

The One-Minute View

Beginner Examples

Read the Beginner Examples material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter's running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.

• A phone classifying a reading during a network outage is doing edge work, because the result must be available without the cloud.
• A depot server reconciling duplicate uploads from several delivery phones is doing fog work, coordinating across gateways.
• Training a model across an entire fleet and keeping a year of history is cloud work; no single phone has the data or the governance role for it.

Overview Knowledge Check

If you can tell the four layers apart and see placement as a per-task decision, you have the core idea. Continue to Practitioner for the placement decision and the data-reduction pipeline.

15.2 Choose the Layer Task by Task

Read the Choose the Layer Task by Task material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter’s running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.

Make the placement decision explicit for each task. As a rule of thumb, a task belongs closer to the source when it has strict freshness, privacy, bandwidth, offline, or safety requirements, and farther away when it needs broad history, cross-device context, heavy training data, central governance, or long-term audit. Turn that rule into seven concrete questions per task:

• What is the maximum acceptable delay before the result becomes stale?
• Does the task need raw personal, location, image, audio, or health data?
• What data volume would be sent if the task moved to the cloud?
• What battery and thermal cost does local processing add?
• Can the task continue while the gateway is offline?
• Does the task need fleet-wide data, long history, or central governance?
• What evidence will prove the task actually ran in the intended location?

The Data-Reduction Pipeline Must Preserve Evidence

Mobile gateways often reduce data before upload to save bandwidth and battery, but reduction is useful only when it preserves the evidence downstream reviewers need. A reviewable pipeline records six things: a raw sample window with enough original data to reproduce a feature or event when needed; a validation rule for invalid, stale, missing, duplicate, or out-of-range records; a feature definition stating exactly how a summary, statistic, classification, or flag is computed; a decision threshold that turns a feature into an event, alert, or rejection; an upload contract for what is sent versus kept local; and an evidence retention rule for how long raw windows, features, events, and rejection logs are kept. If the cloud receives only a summary, the gateway still needs enough traceability to explain how that summary was produced.

Practitioner Knowledge Check

If you can place each task with its seven questions and design a data-reduction pipeline that keeps evidence, you can stop here. Continue to Under the Hood for local-inference limits, the cloud handoff contract, and traceability.

15.3 Keep Reduced Data Traceable

The deeper layer covers the parts that most often turn a tidy edge/fog diagram into an unauditable system: treating local inference as a final decision, an underspecified cloud handoff, and reduction that quietly destroys traceability.

Local Inference Is a Stage, Not a Verdict

A mobile device can run a model, but a model result is not automatically a release decision. Treat local inference as one controlled stage with clear boundaries. It is appropriate when the result must be available during an outage, the raw input should not leave the device, the upload path cannot carry the raw volume, the model is small enough to run within battery and thermal limits, and false positives and false negatives have a documented response path. It is not enough when the result changes safety, health, financial, or access-control outcomes without review; when the model needs fleet-wide retraining or drift monitoring; when the device cannot prove which model version ran; when input conditions fall outside the model's tested range; or when the release cannot explain rejected, uncertain, or missing records.

The Cloud Handoff Is a Contract

The handoff to the cloud should be an explicit contract, not a side effect, because the cloud needs to know whether a gateway result is trustworthy. A complete handoff carries source identity and gateway identity; the sensor time, gateway-receipt time, and upload time; the processing location and the software or model version; the data quality state and stale threshold; the feature or event definition; a confidence or uncertainty value when local inference was used; and the retry count, duplicate marker, rejection reason, and upload state. It should also state whether the cloud may reprocess the record, request the retained raw evidence, or override a local decision.

Reduction Without Traceability Destroys Auditability

The quiet failure of edge/fog design is shipping summaries that cannot be explained. A summary is reviewable only if the cloud can trace who produced it, from what inputs, using which rule or model version, and under what quality state — which means the gateway must retain the raw window, the feature rule, and the processing version long enough to reproduce the result. A number with no identity, time window, quality, or version cannot be audited, no matter how much bandwidth it saved.

The minimum evidence pack therefore includes the task placement record, the data-reduction contract, the local model or rule version with test conditions and accepted limitations, battery and thermal measurement under the target duty cycle, offline behavior for inference and upload, the privacy boundary for raw data and identity, the cloud handoff schema, and acceptance drills for outage, model update, stale data, duplicate upload, device loss, and rollback.

Under-the-Hood Knowledge Check

At this depth, mobile edge and fog work is a placement discipline backed by evidence. Place each task where its needs can be proven, treat local inference as a reviewable stage rather than a verdict, make the cloud handoff an explicit contract, and never let data reduction outrun traceability, so that "processed at the edge" is something a reviewer can reconstruct rather than take on trust.