33 IoT Domain Requirements: Latency, Scale, and Power

33.1 Overview

This first route turns domain differences into latency, downtime, scale, availability, and battery calculations that can shape a system boundary.

This is part 1 of 2. Continue with IoT Domain Requirements: Data, Regulation, and Selection for the second focused route.

33.2 Start With the Story

Let the Hardest Field Limit Shape the Design

Picture three teams buying the same connected unit. A farmer wants ten years between battery visits. A hospital wants a warning before a patient is harmed. A factory wants a machine stopped before a tool breaks. The same feature list cannot prove all three jobs.

Begin with the field outcome. Name the person or system that acts, the event that starts the need, and the harm if the result is late, lost, wrong, or exposed. Turn each concern into a number or a clear pass rule.

Latency means the time from an event to the result that needs it. The hospital may need a short limit for an alarm. The farm may accept a later soil report. State the limit for each traffic class instead of calling the whole design real time.

Bandwidth means how much data a link can carry in a given time. Count message size, send rate, device count, bursts, updates, and retries. Test the narrowest shared link. A calm average can hide the hour when every unit reports at once.

A protocol is an agreed set of rules for an exchange. Choose it after the power, range, message, delay, and ownership needs are clear. A familiar name is not evidence that the rules fit the site.

Now compare power. Write every state in a normal day and a bad day: sleep, wake, sense, send, listen, retry, update, and recover. Use measured current and time. Add the cost of travel when a person must replace a battery.

Compare reliability next. Name which missed facts are tolerable. For a control action, say what safe state remains when the result is unknown. Test a lost link, dead unit, wrong time, full store, and late message. Show doubt instead of guessing.

Add the people and law around the system. Record who can see each fact, how long it is kept, who supports the site, and which proof an audit or safety review needs. A cheap part may create costly review or service work.

Use a one-page envelope for each domain. It should list outcome, scale, place, power, time, data, loss, safety, privacy, support, cost, owner, and rejection test. Put the envelopes side by side. The tightest limit will often rule out a tempting choice.

Run a small pilot against that limit. If battery life is hardest, measure the worst radio day. If delay is hardest, load the shared path. If audit proof is hardest, trace one fact and one action from source to record. Keep both pass and fail evidence.

Reopen the envelope when the site, rule, device count, software, or service promise changes. A design that fits one domain today may not fit a wider job next year.

Give the envelope to a person from another team. Ask them to name the hardest limit and the evidence that can reject the plan. If they choose a different limit, find the missing fact before buying parts.

Keep the first pilot small enough to change. Use real places and work, but avoid tying the whole service to an untested choice. Record what passed, what failed, and what remains unknown.

Review the record with a field worker and the person who pays. Both should see the same claim, limit, and next test. If their views differ, fix the promise before the plan grows.

Keep the final choice short and clear.

This comparison does not remove trade-offs or replace expert review. Practitioner builds the scorecard and cost tests. Under the Hood works through reliability, scale, distance, and energy calculations that support the final choice.

Begin with two projects that both say they need IoT, then notice that one needs battery life, another needs audit trails, and another needs millisecond recovery. This chapter teaches domain comparison as evidence work: requirements are not generic wishes, they are consequences of where the system operates.

33.3 Learning Objectives

By the end of this chapter, you will be able to:

• Compare domain requirements across latency, reliability, scale, power, and data volume dimensions
• Explain regulatory impacts on IoT project cost and timeline
• Match technology choices to domain-specific constraints
• Evaluate trade-offs when selecting IoT solutions for different applications

Domain Requirements Vary

Estimated Time: 25 min | Complexity: Intermediate

Key Concepts

• IoT Architecture: Layered model comprising perception, network, and application tiers defining how sensors, gateways, and cloud services interact.
• Edge Computing: Processing data close to the sensor source to reduce latency, bandwidth costs, and cloud dependency.
• Telemetry: Time-stamped sensor readings transmitted from a device to a cloud or edge platform for storage, analysis, and visualisation.
• Protocol Stack: Set of communication protocols layered from physical radio to application message format that devices must implement to interoperate.
• Device Lifecycle: Stages from manufacture through provisioning, operation, maintenance, and decommissioning that IoT management platforms must support.
• Security Hardening: Process of reducing attack surface by disabling unused services, applying least-privilege access, and enabling encrypted communications.
• Scalability: System property ensuring performance and cost remain acceptable as the number of connected devices grows from prototype to mass deployment.

Chapter Roadmap

This chapter turns domain comparison into a repeatable selection workflow:

1. First we turn broad IoT ideas into requirement envelopes and learn why the tightest constraint wins.
2. Then we compare the six dimensions: latency, reliability, scale, power, data volume, and regulation.
3. Next we use decision trees, trade-off maps, pitfalls, and scorecards to narrow technology choices.
4. Finally we test the logic with knowledge checks, TCO math, and domain-specific next steps.

Checkpoints recap the selection decisions as you go; deep calculations and interactives let you inspect the numbers without losing the main path.

Before diving into each domain, it’s crucial to understand why we can’t use the same IoT solution everywhere. The answer lies in understanding what each domain actually needs—and why those needs differ so dramatically.

33.4 Minimum Viable Understanding

• Six Requirement Dimensions: Every IoT domain is defined by latency, reliability, scale, power, data volume, and regulation — no single technology satisfies all combinations, which is why domain analysis must precede technology selection.
• Requirements Before Technology: The leading cause of IoT project failure is choosing technology first; a hospital patient monitor needs 99.99% uptime, sub-second alerts, and FDA/HIPAA compliance ($500+ per sensor), while a vineyard frost sensor needs only 95% uptime and no regulation (<$50 per sensor).
• Constraint-Driven Elimination: The requirement with the tightest constraint (often power or regulation) typically eliminates 60-80% of technology options, narrowing viable choices to 3-5 candidates.
• Cost of Reliability: Higher availability can require redundancy, monitoring, tested recovery, and additional staffing. The cost depends on the service boundary and architecture; an uptime percentage alone does not determine a multiplier.

33.5 The Requirements Challenge

Not all jobs are the same — and neither are sensors!

33.5.1 Requirements Challenge

The Sensor Squad just got THREE new missions — but each one needs completely different tools!

Mission 1: Hospital Helper Thermo the Temperature Sensor is assigned to monitor a sick child in the hospital. “This is serious!” says Thermo. “I need to check the temperature EVERY SECOND and tell the nurse INSTANTLY if there’s a fever. I can NEVER take a break — not even for one minute!” Thermo gets a special medical-grade badge and a strong Wi-Fi connection so messages arrive in less than a blink of an eye.

Mission 2: Farm Friend Hydro the Humidity Sensor is sent to a big vineyard to watch for frost. “I don’t need to be as fast,” Hydro says. “Frost happens slowly over 30 minutes, so checking every few minutes is fine.” Hydro gets a tiny battery that lasts 10 YEARS and uses LoRaWAN, which sends tiny messages over really long distances. “I cost only $50 — the farmer needs hundreds of me!”

Mission 3: Race Car Referee Motion Mo the Motion Detector gets the toughest job — a self-driving car! “I have to see EVERYTHING in less than 10 milliseconds — that’s faster than you can blink!” Mo needs the fastest computer right inside the car, because there’s no time to send data to the cloud and wait for an answer.

The big lesson? Same type of sensor, completely different requirements! Thermo needs to be super reliable. Hydro needs a super long battery. And Mo needs to be super FAST.

33.5.2 Key Words for Kids

• Requirements: What a sensor must be able to do for its specific job.
• Latency: How quickly a sensor needs to send its message, like reaction time.
• Reliability: How often the sensor works without breaking; hospitals need near-perfect reliability.
• Battery Life: How long the sensor can run before needing a new battery.

33.5.3 Try This at Home!

Be a Requirements Detective!

1. Pick three “smart” devices in your house (thermostat, doorbell camera, smoke detector)
2. For each one, answer: How fast does it need to respond? What happens if it stops working?
3. Rank them: Which one is most important to NEVER break? Which can be slow?

What you’ll discover: Your smoke detector needs to be super reliable (life safety!), your doorbell can be a bit slow (a few seconds is OK), and your thermostat can even go offline for hours without a problem. Different jobs need different levels of speed and reliability!

33.6 Domains Turn Ideas Into Constraints

A domain requirement is a boundary condition, not a preference. Healthcare, agriculture, transportation, smart homes, smart cities, and factories can all use sensors, gateways, networks, and dashboards, but the acceptable latency, reliability, power budget, data volume, regulation, and maintenance model are different because the consequence of failure is different. A few seconds of delay in a smart-home leak alert may be acceptable if the device has multi-year battery life. The same delay in an industrial safety interlock or clinical alarm can be unacceptable because the user expects a local, auditable, fail-safe response.

The practical tool in this chapter is a requirement envelope. The envelope names the decision the IoT system supports, the constraints that are tight, the constraints that are flexible, and the trade-off that would make the application unsafe, unaffordable, or unmaintainable. It prevents a team from starting with a favorite radio, cloud platform, or dashboard and then forcing every domain to fit it. A farm frost monitor, a cold-chain shipment tracker, a city parking sensor, and an OPC UA-connected factory asset monitor may all report telemetry, but they do not carry the same response time, uptime, calibration, evidence, privacy, and support obligations.

Use the envelope as a comparison artifact:

• Healthcare monitoring: Safety workflow, privacy, identity matching, and auditability usually tighten first, so strong identity, retained evidence, and clinical integration such as HL7 FHIR can matter before dashboard features.
• Agriculture: Range, battery life, weather exposure, and seasonal maintenance usually tighten first, so LPWAN options such as LoRaWAN or cellular IoT may matter before visual analytics.
• Industrial automation: Uptime, deterministic response, asset context, and plant integration usually tighten first, so edge control, Ethernet, OPC UA, MQTT Sparkplug, or ISA-95 alignment may dominate.

If a requirement is tight, the design needs evidence: a latency budget, a battery calculation, a site survey, a retention rule, a failover test, or a maintenance plan. If a requirement is flexible, the design should say what flexibility is being used to reduce cost or complexity. That discipline makes later technology choices defensible instead of accidental.

33.7 Tightest Constraint Wins

The first stop is the eliminator: the requirement that rules out the most tempting but unsuitable design before the team spends time polishing it.

For project work, start with the hardest constraint and let it narrow the design. A vineyard frost sensor may eliminate high-power radios before data modeling matters because replacing batteries across distant fields is expensive and time-sensitive. A hospital monitor may eliminate best-effort connectivity before cost optimization matters because missed identity, delayed escalation, or unclear alarm ownership can create clinical risk. A factory control loop may require local edge control, deterministic networking, OPC UA context, or ISA-95 integration before cloud analytics is useful because production equipment cannot wait for a remote dashboard to decide whether a machine should stop.

Write the envelope with measurable language. Latency should name the response window, such as sub-second local action, under ten seconds for an operator alert, or daily reporting for planning. Reliability should name what happens during packet loss, gateway outage, drained battery, sensor fault, or unavailable cloud service. Scale should name device count, site count, onboarding rate, and replacement workflow. Power should name battery life, duty cycle, sleep behavior, and access for maintenance. Data should name sample rate, units, timestamp source, quality flags, retention, aggregation, and whether raw data or events must be preserved. Regulation and governance should name consent, tenant boundaries, audit logs, export controls, privacy reviews, or safety evidence when those apply.

Only then compare candidate technologies. LoRaWAN Class A can be attractive for low-rate, battery-powered field sensors, but it limits downlink behavior and payload size. NB-IoT or LTE-M can remove gateway ownership for wide-area assets, but carrier coverage, SIM lifecycle, and recurring cost become requirements. Wi-Fi may suit mains-powered indoor devices with existing site networks, but provisioning and IT approval can dominate deployment. BLE may fit phone-assisted setup or local wearables, while Ethernet may fit industrial panels where power and cabling are available. MQTT, CoAP, HTTPS, OPC UA, and MQTT Sparkplug are not interchangeable labels; each brings different assumptions about message delivery, semantics, tooling, and integration.

End the practitioner pass with evidence tests. A good envelope points to a site survey, link-budget check, battery calculation, protocol trace, environmental test, accessibility review, security review, pilot success metric, or support drill. If the technology survives the test tied to the domain decision, it is a candidate. If it only works in a clean demo, the envelope has exposed the risk early.

33.8 Requirement Envelopes as Contracts

The deeper reason domain requirements matter is that they assign responsibility across the system. A latency requirement decides what must run on the device, gateway, edge server, cloud service, and user interface. A reliability requirement decides redundancy, watchdogs, monitoring, queueing, retry limits, idempotency, and failover. A regulation requirement decides identity, logging, retention, consent, deletion, audit boundaries, and who can view or export data. Without that allocation, the architecture may look complete while nobody owns the requirement when the deployment fails.

Consider a latency envelope. The user-facing number is not a single network measurement; it is the sum of sensor sampling, firmware filtering, radio wake time, gateway processing, broker delivery, stream processing, notification, and human response. If a factory interlock must act locally, the cloud may only record evidence after the fact. If a parking sensor can tolerate minutes, the design may batch messages to save power. If a medical alert has a safety escalation path, the system must distinguish a normal reading, stale reading, rejected reading, offline device, and acknowledged alarm because each state has a different operator meaning.

Reliability and data quality also cross layers. MQTT QoS can reduce message-loss risk, but it does not prove that the sensor was calibrated, the unit is correct, the timestamp is trustworthy, or the command is safe to retry. Store-and-forward can protect against outages, but the application still needs stale-data labels and sequence handling. OPC UA information models or MQTT Sparkplug birth certificates can preserve asset and tag context in industrial systems, but the receiving historian, rules engine, and dashboard must retain that meaning. Healthcare or regulated deployments may need patient or device identity matching, audit logs, and retention rules before data can enter clinical or compliance workflows.

For deeper review, test the envelope against failure modes: offline gateway, stale sensor, drained battery, delayed alert, duplicate command, denied credential, changed regulation, unavailable cloud service, bad calibration, and expensive maintenance visit. The test is not whether the page still draws a chart. The test is whether the system still supports the domain decision safely, visibly, and with enough evidence for the responsible operator. If the design still holds under those conditions, the technology choice is defensible.

33.9 Radio Remi’s Math Bridge: Band Choice and Reporting Duty

The mathematical gist. At equal distance, 915 MHz saves 8.38 dB of free-space loss relative to 2.4 GHz, while dropping from 150 mW to 35 mW gives up 6.32 dB; the net is still 2.06 dB in LoRaWAN’s favour. A 200 ms report every 10 minutes is active for 0.0333% of the time, not 1%, producing about 12.3 microamps average and an 8.42-year derated service-life screen.

Math Bridge · guided foundationsHow can the weaker radio keep more margin and run for years?Let Radio Remi separate frequency advantage, transmit power, and reporting duty. Learn the maths

33.10 Build a Requirement Envelope

1. Name the domain decision. State what action the IoT system must improve and who depends on it.
2. Rank the six dimensions. Mark latency, reliability, scale, power, data volume, and regulation as tight, moderate, or flexible.
3. Identify the eliminator. Choose the requirement that rules out the most tempting but unsuitable technologies.
4. Map technology candidates. Compare radios, protocols, compute placement, storage, and operations choices against the same envelope.
5. Write the evidence test. Define how you will prove the selected design meets the domain requirement before deployment.

33.11 Requirement Progression

• Beginner Example: A smart-home leak sensor prioritizes battery life, local alert clarity, and low maintenance because a delay of a few seconds is usually tolerable but missed alarms damage trust.
• Intermediate Example: A cold-chain shipment monitor balances battery life, cellular or LPWAN coverage, temperature accuracy, tamper evidence, and exception reporting because the evidence record matters as much as the sensor reading.
• Advanced Example: A factory safety interlock treats latency, deterministic behavior, local fail-safe action, maintenance ownership, and audit evidence as hard constraints before considering dashboards or predictive analytics.

33.12 Try It: Rank a Domain Envelope

Choose one IoT domain and write a six-line requirement envelope:

1. Domain decision: what action or decision the system supports.
2. Latency: how fast the response must be and why.
3. Reliability: what happens when the system misses data or goes offline.
4. Power and scale: how many devices are deployed and how they are maintained.
5. Data and regulation: what must be stored, protected, retained, or audited.
6. Technology eliminator: the first technology choice the envelope rules out.

33.13 Domain Requirement Envelopes

The layered domain-requirement workflow now lives in Application Domain Requirements Contracts, covering domain constraints, measurable requirement envelopes, latency, reliability, power, security, data, lifecycle, governance, and integration budgets.

33.14 One Size Fails in IoT

Understanding domain requirements is like understanding why you wouldn’t wear the same outfit to a beach and a job interview — context determines what’s appropriate.

Simple Analogy: Think of IoT technologies like vehicles:

• Ambulance (Healthcare IoT): Must be fast, reliable, expensive — lives depend on it
• Farm tractor (Agriculture IoT): Slow is fine, must be rugged and fuel-efficient over large areas
• Race car (Autonomous vehicles): Maximum speed, extreme precision, cost no object
• Bicycle (Smart home): Simple, affordable, good enough for short trips

You wouldn’t use a race car to plow a field, and you wouldn’t use a tractor in an emergency room!

The Six Key Questions before choosing any IoT technology:

1. How fast? (Milliseconds to hours — this is “latency”)
2. How reliable? (95% to 99.999% uptime)
3. How many devices? (10 in a house to 50,000 across a city)
4. What power source? (Wall outlet, battery, solar panel)
5. How much data? (A few bytes to gigabytes per day)
6. What rules apply? (Government regulations, safety standards)

Why This Matters for You: If you are building an IoT project, answering these six questions first will save you months of wasted work. The answers naturally narrow your technology options from hundreds to just 3-5 viable choices.

33.15 The Healthcare vs Agriculture Comparison

The next sections put numbers on those six questions. Watch how the same sensing task changes once the domain changes.

Consider two temperature monitoring scenarios that illustrate how the same measurement can have completely different requirements:

Hospital Patient Monitoring

• What’s measured: Patient body temperature
• Criticality: Life-threatening if measurement is missed or inaccurate
• Response needed: Immediate (seconds) for fever alerts
• Accuracy required: +/-0.1C (medical-grade precision)
• Reliability: 99.99% uptime (lives at stake—52 minutes downtime per year maximum)
• Compliance: HIPAA (patient data privacy), FDA (medical device approval)
• Cost tolerance: $500+ per sensor acceptable (patient safety justifies expense)

Vineyard Frost Monitoring

• What’s measured: Air temperature in agricultural fields
• Criticality: Crop damage if frost missed, but not life-threatening
• Response needed: Minutes (frost builds slowly over 30-60 minutes)
• Accuracy required: +/-1C (frost threshold is approximately 0C)
• Reliability: 95% uptime acceptable (redundant sensors compensate for failures)
• Compliance: None required (no regulations for agricultural sensing)
• Cost tolerance: <$50 per sensor (need hundreds, agriculture has tight margins)

Same measurement (temperature), completely different requirements!

This comparison reveals why domain requirements matter: the consequences of failure, the speed of decision-making, regulatory oversight, and economic constraints all vary dramatically based on context.

The visual evidence for the healthcare vs agriculture comparison sits in Figure 33.1. Find Six IoT Requirement Dimensions beside Every IoT system must balance these six competing before interpreting the six dimensions of iot domain requirements that drive technology selection.

Figure 33.1 places Six IoT Requirement Dimensions alongside Every IoT system must balance these six competing. Treat System as the diagram qualifier for the six dimensions of iot domain requirements that drive technology selection. That labelled limit reconnects the visual to the healthcare vs agriculture comparison.

33.16 Latency and Response Time

Different applications have fundamentally different time constraints based on what they’re controlling and the consequences of delays:

The visual evidence for latency and response time sits in Figure 33.2. Find Latency Requirement Spectrum beside From safety-critical real-time to relaxed batch processing before interpreting iot latency spectrum showing response time requirements across application domains.

Begin Figure 33.2 with Latency Requirement Spectrum, then distinguish From safety-critical real-time to relaxed batch processing and URGENT. The diagram separates Latency Requirement Spectrum from From safety-critical real-time to relaxed batch processing within iot latency spectrum showing response time requirements across application domains. Keep both distinctions explicit in latency and response time.

• Autonomous vehicles: Under 10 ms because avoiding collisions at highway speeds leaves almost no cloud round-trip budget.
• Industrial robotics: Under 50 ms because precise assembly operations require real-time coordination.
• Building automation: Under 1 second because HVAC response and lighting adjustments need to feel immediate to users.
• Smart agriculture: Under 1 minute because irrigation decisions are based on slowly changing soil conditions.
• Environmental monitoring: Under 1 hour because weather and air quality change gradually over time.

Key Insight: A 100 ms delay is catastrophic for autonomous vehicles but completely acceptable for environmental monitoring. Understanding these latency requirements drives architecture decisions—autonomous vehicles need edge computing (local processing), while environmental monitoring can use cloud platforms.

33.17 Latency-to-Distance Tool

Explore how latency translates to physical distance traveled at different vehicle speeds:

33.18 Downtime Cost Spectrum

System reliability requirements directly correlate with the human and economic cost of failure:

Ground downtime cost spectrum with the visual at Figure 33.3. Start from Reliability vs Cost Tiers, but keep Higher uptime demands exponentially increase visible while evaluating illustrative reliability profiles across four iot service scenarios.

Use Higher uptime demands exponentially increase to test Reliability vs Cost Tiers in the diagram at Figure 33.3. Then inspect COST as the final qualifier on illustrative reliability profiles across four iot service scenarios. That sequence keeps downtime cost spectrum tied to what is visibly labelled.

The percentages in Figure 33.3 are example service targets, not domain-wide requirements. The cost multipliers shown are also assumptions for a hypothetical design exercise. Real targets and costs come from the service’s harm model, operating window, failure dependencies, recovery time, staffing, and supplier commitments. In this comparison, healthcare uses 99.99% uptime, or at most about 52 minutes of downtime per year, because failure can harm patients. Traffic control uses 99.9%, or about 8.7 hours, because failure can cause accidents, disruption, and economic loss. Smart home uses 99%, or about 3.6 days, where failure is usually an inconvenience. Agriculture uses 95%, or about 18 days, for a scenario in which redundancy or manual response can recover some losses.

Real-World Implications:

Achieving 99.99% uptime generally requires redundancy, failover, continuous monitoring, and tested recovery, so the harm model must justify that infrastructure. A smart-home user may tolerate an occasional thermostat outage, whereas traffic control requires stronger failure isolation and recovery. There is no universal cost multiplier for each additional “nine”; the architecture and its common-cause failures determine the actual cost.

33.19 Reliability Cost Reasoning

Consider two services with 10,000 sensors. One can tolerate a day-long outage during a non-critical operating window; the other must continue through a gateway, power, or network failure and restore service within minutes. The percentage targets describe outcomes, but they do not price the designs.

Build the estimate from concrete controls:

• identify independent failure domains, including power, gateways, backhaul, cloud services, and field devices
• decide which failures require redundancy and whether failover is automatic
• include monitoring, spares, maintenance access, incident response, and recovery testing
• model common-cause failures so duplicated components are not mistaken for independent protection
• price the complete service boundary, then test whether the proposed design can meet its target

A $50,000 baseline and a 99.99% target are therefore insufficient to calculate a hospital-system price. Two architectures with the same target can have very different costs and failure behaviour.

33.20 Interactive: Availability Budget Calculator

Use this calculator to translate an annual availability target into an outage budget. It deliberately does not estimate cost: the percentage does not specify the architecture or operating model.

33.21 Scale From Wearables to Cities

Latency and uptime decide response architecture; scale and power decide whether that architecture can be deployed and maintained in the real world.

Deployment scale fundamentally changes system architecture, cost structure, and technology choices:

• Personal, 1-10 devices: Fitness trackers and smartwatches usually use Bluetooth to a smartphone and need no site infrastructure.
• Home, 10-50 devices: Smart-home automation usually uses Wi-Fi or Zigbee mesh, a single gateway, and a consumer budget.
• Building, 50-500 devices: Office HVAC and security deployments need a building-wide network, IT staff, and professional installation.
• Campus, 500-5,000 devices: Universities, hospitals, and vineyards need dedicated network infrastructure plus gateway management.
• City, 5,000+ devices: Municipal parking and streetlights usually need LoRaWAN, NB-IoT, a city-scale backbone, and an operations center.

Technology Selection by Scale:

• Personal/Home (1-50 devices): Bluetooth, Wi-Fi, Zigbee (existing consumer infrastructure)
• Building/Campus (50-5,000 devices): Wi-Fi, LoRaWAN gateways, wired Ethernet (dedicated infrastructure)
• City (5,000+ devices): LoRaWAN, NB-IoT, Sigfox (carrier-grade networks, no per-site infrastructure)

33.22 Power Source Drives Everything

The availability of power fundamentally constrains connectivity and sensor choices:

• Mains power: Unlimited lifetime enables Wi-Fi, Ethernet, video, and high-power sensors in buildings, traffic cameras, and industrial deployments.
• Power over Ethernet: Unlimited lifetime over network cabling supports IP cameras, VoIP devices, and Wi-Fi access points in offices and warehouses.
• Rechargeable battery: One to seven days between charges supports Bluetooth and moderate sensors in wearables, smartphones, and patient monitors.
• Long-life battery: One to ten years supports LoRaWAN, NB-IoT, and ultra-low-power sensors in parking and environmental monitoring.
• Solar plus battery: Ten or more years supports LoRaWAN, Sigfox, and periodic sampling in agriculture and remote environmental sites.
• Energy harvesting: Unlimited lifetime when enough ambient energy exists, supporting BLE beacons and low-power sensors in indoor tracking or maintenance-free niches.

Example: Why agriculture uses LoRaWAN instead of Wi-Fi:

• Wi-Fi: 100-200 mW transmit power means battery drains in weeks
• LoRaWAN: 20-50 mW transmit power, only active about 0.03% of the time (a brief ~200 ms uplink every 10 minutes) means battery lasts 5-10 years
• Result: $50 sensor with 10-year battery vs. $200 sensor + solar panel or frequent battery replacement

33.23 Interactive: Battery Life Estimator

Calculate expected battery life based on power consumption and duty cycle:

33.24 Continue to Part 2

Continue with IoT Domain Requirements: Data, Regulation, and Selection.