31 IoT Domains: Constraints and Collection Paths

31.1 Start With the Decision

A farm sensor may wait minutes; a safety stop may not. Domain limits shape the network, store, and collection route.

31.2 Route Overview

This is part 2 of 2. Review IoT Domains: Shared Patterns for the preceding evidence.

31.3 Learning Objectives

• Compare latency, battery, scale, rule, and outage limits.
• Choose store, gossip, or direct collection from site evidence.

31.4 Chapter Roadmap

• Compare Domains by Constraints
• Telemetry Semantics Differ
• Checkpoint: Domain Fit
• The Five Pillars of IoT Impact
• IoT Application Domains Taxonomy
• Environmental Monitoring Beyond Fixed Infrastructure
• Practitioner Decision: Design the Collection Path First
• Under the Hood: Store, Gossip, Collect
• Domain Requirements at a Glance
• Continue to Part 2

31.5 Compare Domains by Constraints

When you evaluate a domain, build a small comparison table before choosing a platform. Include latency, battery life, expected device count, data volume, network availability, regulation, ownership, and the cost of missed or false alerts. The right answer often changes before hardware is discussed.

Real technologies make the tradeoffs visible. LoRaWAN can suit low-rate farm or city sensors where battery life and range matter. NB-IoT or LTE-M can help when managed cellular coverage and carrier operations are acceptable. OPC UA and MQTT Sparkplug appear in industrial contexts because equipment identity, tag semantics, and plant integration matter. HL7 FHIR may matter in healthcare because device data has to land in clinical workflows, not just a dashboard.

A useful practitioner artifact is a one-page domain profile. It should name the primary user, the operational decision, the physical environment, the integration target, the data owner, the support team, the success metric, and the unacceptable failure mode. For a city deployment that may mean a public works dispatcher, a GIS asset registry, an open-data rule, and a field maintenance SLA. For a hospital device it may mean a nurse workflow, an EHR interface, a clinical safety review, and privacy controls. For a factory it may mean a maintenance planner, an MES or CMMS integration, a plant-network boundary, and a production downtime threshold.

1. Start with a domain scenario. For example, compare cold-chain vaccines, fleet tire pressure, and greenhouse irrigation rather than comparing “sensors” in general.
2. Mark the non-negotiables. Safety response time, patient privacy, seasonal access, uptime windows, calibration, and auditability can eliminate attractive-looking stacks.
3. Choose a pilot boundary. Test one site, route, ward, field, or production cell deeply enough to reveal operations work before scaling.

Then translate the comparison into tests. A fleet pilot should prove location quality, driver workflow, tire-pressure or temperature sensor durability, cellular coverage gaps, and repair handoff. A precision agriculture pilot should prove gateway placement, battery life through the crop cycle, sensor calibration, and whether operators actually change irrigation or treatment. A healthcare pilot should prove alert routing, device cleaning, data minimization, identity matching, and what happens when a reading is outside expected clinical context.

The final review should be cross-functional. Engineering can explain protocols, payloads, uptime, and integration cost. Operations can explain who acts on alerts and who maintains devices. Legal, privacy, safety, or compliance staff can explain retention, consent, audit, and incident obligations. Finance can decide whether the value of the changed decision justifies the ongoing service cost. If any group is absent, the pilot may still work technically while failing as a domain deployment.

31.6 Telemetry Semantics Differ

A temperature reading means different things in different domains. In a smart building, it may tune comfort and energy use. In a cold-chain route, it may decide whether a shipment is usable. In a factory, it may forecast bearing failure. In healthcare, it may trigger escalation rules and record retention requirements.

That difference changes the system underneath the chart. Sampling interval, timestamp source, calibration history, retention period, data owner, alarm threshold, and fallback action all become domain-specific. Even the same transport protocol can carry different obligations depending on who relies on the result.

The data contract should therefore carry domain context, not just a value. A temperature event may need device identity, asset identity, location, unit, timestamp source, calibration version, firmware version, quality flag, enclosure state, and the rule that interpreted the value. Industrial deployments may encode asset and tag meaning through OPC UA information models or MQTT Sparkplug B birth certificates. Healthcare integrations may need patient or device identity to map safely into HL7 FHIR resources. Smart-city systems may need geospatial identifiers, public-release rules, and retention metadata before an observation can be shared beyond the operating team.

• Time: Decide whether seconds, minutes, hours, or seasons are the meaningful unit for the domain.
• Trust: Track calibration, firmware version, operator override, and missing-data behavior when decisions depend on the reading.
• Integration: Connect the output to the receiving system people already use, such as a CMMS, EHR, fleet platform, irrigation controller, or city operations console.

Under the hood, domain semantics also shape storage and processing. A smart-building trend may be downsampled for energy analysis, while a regulated cold-chain record may need immutable audit history and exception review. A vehicle-safety signal may be evaluated at the edge because the response window is short. A soil-moisture reading may be most meaningful when joined with soil type, crop stage, valve state, rainfall, and forecast data. A vibration feature may need machine speed, bearing type, maintenance history, and production schedule before anomaly detection is useful.

This is why domain models matter even when platforms advertise generic device management. The registry, time-series database, event broker, rules engine, dashboard, and API can be shared, but they must preserve enough meaning for downstream action. If a pipeline drops units, calibration, identity, quality, or ownership metadata, it may still render a chart while making the operational decision less reliable. A good architecture lets common infrastructure handle ingestion, security, observability, and lifecycle management while domain schemas protect the meaning that operators need.

31.7 The Five Pillars of IoT Impact

A helpful framework for understanding IoT’s transformative potential organizes applications into five pillars, each representing a fundamental human need that IoT addresses:

The next claim about the five pillars of iot impact depends on Figure 31.1. Its diagram makes The Five Pillars of IoT Impact and SUSTAIN explicit within the five pillars of iot impact — each pillar links a human need to the domains and outcomes it prioritizes.

Within the diagram, The Five Pillars of IoT Impact opens Figure 31.1; SUSTAIN provides the counterpoint, and Efficiency closes the inspection. This reading constrains the five pillars of iot impact — each pillar links a human need to the domains and outcomes it prioritizes and supplies the visual evidence for the five pillars of iot impact.

31.8 IoT Application Domains Taxonomy

Understanding how the 14 application domains relate to each other helps in selecting appropriate technologies and architectures. The domains can be organized into six major categories based on their primary focus and requirements.

To test iot application domains taxonomy, open the diagram in Figure 31.2. IoT Application Domains Taxonomy supplies one named condition; Urban Infrastructure supplies the necessary comparison for iot application domains taxonomy organized into six major categories and their constituent domains.

Use Urban Infrastructure to test IoT Application Domains Taxonomy in the diagram at Figure 31.2. Then inspect Smart Cities as the final qualifier on iot application domains taxonomy organized into six major categories and their constituent domains. That sequence keeps iot application domains taxonomy tied to what is visibly labelled.

31.9 Environmental Monitoring Beyond Fixed Infrastructure

Environmental monitoring is not limited to fixed weather, fire, or pollution stations. Wildlife conservation can require the sensing system to move with the subject: a collar combines location, motion, biometric, storage, compute, and radio functions so researchers can observe movement and condition between direct sightings. The purpose is not merely to accumulate positions. Continuous records can expose changes in migration, population density, social interaction, injury, illness, or trapping early enough for a conservation team to investigate.

Other environmental targets change the path again. Forestry monitoring can look for illegal logging, land-use or species change, tree health, and fire risk while measuring characteristics such as tree height, stem diameter and density, canopy density, discoloration, or water content; the source flags sparse infrastructure and strong multipath as communication constraints and names longer-wave links, relays, and satellite as candidate paths. Marine monitoring can follow sea turtles, coral reefs, or mercury exposure in fish across migration, pollution, breeding, and nesting studies, but underwater communication moves the design toward sonar or long-wave links. The domain label stays the same while the collection mechanism changes with the environment.

The source example makes the operating constraint concrete. A collar may combine GPS; an accelerometer, gyroscope, and magnetometer; biometric sensors; flash memory; wireless transceivers; and a CPU, while still working within a stated example weight limit of 3—5 pounds and an example lifetime of one year without human intervention. Those are case-study constraints, not universal collar specifications, but they show why sensing frequency, storage, radio use, and retrieval method must be designed together.

31.10 Practitioner Decision: Design the Collection Path First

In a reserve without pervasive antenna towers, a collar cannot be reviewed as though every reading will reach a gateway immediately. Record four decisions before choosing components:

1. Observation: which location, motion, or biometric evidence answers the conservation question?
2. Physical budget: what weight and unattended lifetime can the animal carry safely in this study?
3. Collection: will a directional antenna on a plane listen for collar pings, will another reachable receiver collect them, or will both paths be used?
4. Response: which finding should trigger a field check rather than wait for the next routine collection?

The zebra-monitoring example cited by the slides shows the value of connecting those decisions. The collected records distinguished grazing, graze-walking, and occasional fast movement; indicated that the monitored zebras did not tend to sleep deeply; and showed them seeking water about once a day and drinking relatively quickly. These are findings from that study, not thresholds to transfer blindly to another species.

31.11 Under the Hood: Store, Gossip, Collect

When a collar is outside direct receiver range, it can retain observations in local storage. During an encounter, peer-to-peer communication can opportunistically gossip and replicate information across collars. A later plane flyover can then listen for pings with a directional antenna and collect records from collars in radio range. Replication does not create continuous connectivity; it changes which collar may eventually carry a copy to a collection opportunity. A review should therefore distinguish the time an observation was made, the time it was copied between collars, and the time it reached the research team.

31.12 Domain Requirements at a Glance

Each application domain has fundamentally different technical requirements. This comparison highlights why “one-size-fits-all” approaches fail in IoT:

Before domain requirements at a glance, inspect Figure 31.3: Why IoT Domains Need Different Stacks must be considered with <10 ms. That visual pairing grounds latency and data-volume positions for major iot domains, showing why requirement profiles diverge so sharply in named evidence.

Trace the visual from Why IoT Domains Need Different Stacks to <10 ms in Figure 31.3; verify 100 ms before concluding. Together those labels make latency and data-volume positions for major iot domains, showing why requirement profiles diverge so sharply testable. Apply their boundary when working through domain requirements at a glance.

• Autonomous vehicles: Latency below 10 ms, 99.999% reliability, vehicle power, GB/day data volume, and safety-critical regulation.
• Industrial control: Latency below 100 ms, 99.99% reliability, mains power, MB/hour data volume, and industry standards.
• Healthcare monitoring: Latency below 1 s, 99.9% reliability, days-to-weeks battery life, kB-MB/hour data volume, and FDA/CE medical expectations.
• Smart grid: Latency below 1 s, 99.9% reliability, mains or battery power, kB-MB/hour data volume, and utility regulation.
• Smart cities: Minutes of latency, 99% reliability, years of battery life, bytes-kB/hour data volume, and municipal oversight.
• Agriculture: Hours of latency, 95% reliability, years of battery or solar life, bytes/hour data volume, and minimal formal regulation.
• Smart home: Seconds of latency, 95% reliability, months-to-years power budget, kB/hour data volume, and consumer safety expectations.

Pause at the diagram in Figure 31.4 while evaluating domain requirements at a glance. Two labels, Representative Connectivity Stacks by Domain and No single protocol wins everywhere, define the evidence behind representative connectivity stacks by domain: range, latency, power, and operating ownership narrow realistic protocol choices before vendor.

Use Representative Connectivity Stacks by Domain as the entry point to Figure 31.4, then test its meaning against No single protocol wins everywhere and Domain. Together the labels delimit representative connectivity stacks by domain: range, latency, power, and operating ownership narrow realistic protocol choices before vendor. That limit is the visual’s connection back to domain requirements at a glance.

31.13 Continue to Part 2

Continue with IoT Application Domains: Requirements and Navigation.

31.14 Continue Your Route

This final part closes the route from Compare Domains by Constraints through Continue to Part 2. Return to IoT Domains: Shared Patterns or continue from the applications module index.