34 IoT Domain Requirements: Data, Regulation, and Selection

34.1 Start With the Story

A device meets its response and battery targets, but its data volume can still overload the chosen path and regulation can delay the whole project. The team now needs to size storage and processing, account for compliance work, and choose technology from the full requirement set.

34.2 Overview

This route carries data volume into edge decisions, regulation, comparison matrices, failure modes, and a repeatable domain-selection framework.

This is part 2 of 2. Review IoT Domain Requirements: Latency, Scale, and Power when you need the first route.

34.3 Learning Objectives

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

• size an IoT data path from volume and timing evidence
• include regulatory cost and delay in requirements
• select domain technology with explicit trade-offs

34.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

34.5 Data Volume Shapes Architecture

How much data you generate determines where you can process it and how much it costs:

• Very low, under 1 kB per device per day: Environmental sensors such as temperature and soil moisture can use LoRaWAN or Sigfox, and edge processing is usually unnecessary.
• Low, 1-100 kB per day: Smart parking and occupancy sensors can use NB-IoT or Wi-Fi, with cloud processing usually fine.
• Medium, 100 kB-10 MB per day: Wearable biometrics and building automation may use Wi-Fi or cellular, with either cloud or edge processing.
• High, 10-100 MB per day: Industrial vibration analysis and traffic monitoring often need wired Ethernet or 4G/5G, with edge processing preferred.
• Very high, 100+ MB per day: Video surveillance and high-frequency sensors usually require wired Ethernet and edge processing.

34.6 Manufacturing PdM Data Volume

Vibration sensor sampling at 100 Hz:

• Per sensor: 100 samples/sec x 4 bytes = 400 bytes/sec
• 500 sensors: 200 kB/sec = 17 GB/day raw data
• Edge processing: Compress to 1% (only anomalies sent to cloud) = 170 MB/day
• Cloud cost (raw): 17 GB/day x $0.10/GB = $1.70/day
• Cloud cost (edge-processed): 170 MB/day x $0.10/GB = $0.017/day
• Annual savings: $620/year vs. $6/year — a 100x cost reduction through edge processing!

Key Insight: High data volumes make edge computing economically necessary, not just technically optimal.

34.7 Data Volume and Edge Calculator

Calculate daily data volume and edge processing savings:

34.8 Regulatory Complexity Adds Cost and Time

Some domains face stringent regulations that dramatically increase project complexity:

• Healthcare: FDA Class II medical device and HIPAA privacy work can add 12-24 months and 200-500% development cost.
• Automotive: ISO 26262 functional safety and NHTSA expectations can add 18-36 months and 300-800% testing and validation cost.
• Utilities and smart grid: NERC CIP cybersecurity and utility commission approval can add 6-18 months and 100-200% compliance overhead.
• Industrial: OSHA safety and OT security standards can add 3-12 months and 50-150% implementation cost.
• Agriculture: Regulation is usually minimal or voluntary, often adding 0-3 months and 0-25% cost for environmental certifications.
• Consumer: FCC radio, UL electrical, and voluntary privacy expectations often add 3-6 months and 20-50% testing cost.

Example: Why healthcare wearables cost more than fitness trackers:

• Regulatory approval: Fitness trackers usually need FCC radio certification; medical wearables need FDA Class II medical-device approval plus FCC.
• Development timeline: Fitness trackers often take 6-12 months; medical wearables often take 18-36 months.
• Clinical validation: Fitness trackers usually do not require clinical trials; medical wearables require IRB studies or clinical validation.
• Data accuracy: Fitness trackers can be “best effort”; medical wearables may need accuracy such as +/-0.1C temperature or +/-2 bpm heart rate.
• Privacy compliance: Fitness trackers often follow voluntary company policy; medical wearables require HIPAA controls with severe violation penalties.
• Liability and price: Fitness trackers have limited consumer liability and retail around $50-200; medical wearables face medical malpractice exposure and may retail around $500-2,000.

Key Insight: Regulatory compliance isn’t just bureaucracy—it ensures safety and privacy, but adds 50-500% to project cost and timeline.

34.9 Domain Requirements Comparison Matrix

• Autonomous vehicles: Under 10 ms latency, 99.999% reliability, personal scale, vehicle power, very high data volume, and very high regulation.
• Healthcare monitoring: Under 1 s latency, 99.99% reliability, personal-to-building scale, battery or mains power, medium data volume, and very high regulation.
• Industrial M2M: Under 50 ms latency, 99.9% reliability, building-to-campus scale, mains power, high data volume, and high regulation.
• Smart cities: Under 1 minute latency, 99% reliability, city scale, battery or solar power, low-to-medium data volume, and medium regulation.
• Smart agriculture: Under 1 hour latency, 95% reliability, campus or field scale, solar or battery power, very low data volume, and low regulation.
• Smart home: Under 1 s latency, 99% reliability, home scale, mains or battery power, low data volume, and low regulation.
• Environmental monitoring: Under 1 hour latency, 95% reliability, city or regional scale, solar power, very low data volume, and low regulation.

34.10 Technology Selection Decision Tree

With the six dimensions named, the workflow becomes a narrowing exercise rather than a technology popularity contest.

When selecting IoT technologies for a domain, follow Figure 34.1:

Before technology selection decision tree, inspect Figure 34.1: Technology Decision Tree must be considered with TIGHTEST CONSTRAINT?. That visual pairing grounds iot technology selection decision tree guiding choices based on latency, power, scale, and data volume requirements in named evidence.

Figure 34.1 places Technology Decision Tree alongside TIGHTEST CONSTRAINT?. Treat LATENCY as the diagram qualifier for iot technology selection decision tree guiding choices based on latency, power, scale, and data volume requirements. That labelled limit reconnects the visual to technology selection decision tree. Figure 34.1 follows five key questions in sequence:

1. What's the latency requirement?
   • <50 ms: Edge computing required, wired connectivity preferred
   • <1 s: Edge or cloud, Wi-Fi/cellular acceptable
   • <1 min+: Cloud processing fine, LPWAN acceptable
2. What's the power source?
   • Mains power: Wi-Fi, Ethernet, cellular -- no constraints
   • Long-life battery: LoRaWAN, NB-IoT, Sigfox only
   • Solar: LoRaWAN or Sigfox with careful power budget
3. What's the deployment scale?
   • <50 devices: Consumer protocols (Wi-Fi, Bluetooth, Zigbee)
   • 50-5,000 devices: LoRaWAN gateways or Wi-Fi infrastructure
   • 5,000+ devices: Carrier networks (NB-IoT) or city-scale LoRaWAN
4. What data volume per device?
   • <1 kB/day: Any LPWAN works
   • 1-100 kB/day: NB-IoT or Wi-Fi preferred
   • High-volume workloads (100+ kB/day): Wi-Fi, cellular, or wired required
5. What's the regulatory environment?
   • Healthcare/Automotive: Budget 2-3x timeline and cost
   • Industrial: Plan for OT security integration
   • Consumer: Standard compliance sufficient

34.11 One-Size IoT Pitfall

The Myth: “I can use Wi-Fi for everything” or “LoRaWAN solves all IoT problems”

Why It’s Wrong: No single technology works across all domains because requirements are fundamentally incompatible:

Wi-Fi Works Great For:

• Smart homes (existing infrastructure, mains power)
• Healthcare (hospital Wi-Fi already deployed)
• Industrial (high data volume, wired power available)

Wi-Fi Fails For:

• Agriculture (50-100m range means 100+ APs for 50 hectares, power consumption drains batteries in weeks)
• Environmental monitoring (remote areas lack infrastructure, power constraints)
• Smart cities (deployment cost prohibitive: 50,000 streetlights x 1 AP per 100m = 500+ APs)

Similarly, LoRaWAN Fails Where Wi-Fi Excels:

• Healthcare patient monitors (0.3-50 kbps insufficient for continuous ECG/video)
• Industrial video analytics (need Mbps, not Kbps)
• Smart home real-time control (1-2 second latency too slow for voice control)

The Truth: Every domain has 3-5 viable technology options based on specific constraints.

34.12 Requirements Trade-Off Map

Real-world IoT projects rarely satisfy all six dimensions optimally. Understanding common trade-off patterns helps engineers make informed compromises:

Inspect Figure 34.2 before this decision: IoT Requirements Trade-offs must be judged beside Improving one dimension often weakens another. Together IoT Requirements Trade-offs and Improving one dimension often weakens another bound this claim.

IoT Requirements Trade-offs begins the diagram in Figure 34.2; locate IoT Requirements Trade-offs, compare Improving one dimension often weakens another, and verify LOW LATENCY. IoT Requirements Trade-offs states the starting condition; Improving one dimension often weakens another supplies its counterpart; LOW LATENCY limits the conclusion; retain its labelled boundary. Understanding the trade-offs in Figure 34.2 explains why no single IoT platform dominates every domain. Each application must decide which dimensions to prioritize and which to compromise on.

34.13 Domain Requirements Pitfalls

Pitfall 1: Ignoring Worst-Case Latency Designers often specify average latency (e.g., “200 ms average cloud round-trip”) but forget tail latency. A system averaging 200 ms may spike to 2-5 seconds under load — catastrophic for industrial safety. Always specify P99 (99th percentile) latency, not just average.

Pitfall 2: Confusing Sensor Accuracy with System Accuracy A medical-grade temperature sensor rated at +/-0.1C still produces inaccurate readings if the signal conditioning, ADC resolution, or firmware rounding introduces errors. System-level accuracy must account for the entire measurement chain, not just the sensor datasheet.

Pitfall 3: Underestimating Battery Replacement Cost at Scale A 2-year battery life sounds acceptable until you deploy 10,000 sensors across a city. Replacing 5,000 batteries per year at $15 each (battery + labor) costs $75,000 annually. A 10-year battery at $5 more per sensor saves $350,000 over the deployment lifetime.

34.14 Parking Sensor Battery-Replacement Math

Compare two parking sensor options for a 10,000-sensor smart city deployment:

Option A: Wi-Fi-based sensor with 2-year battery

• Initial cost: $40/sensor = $400,000
• Battery replacement: $15/sensor × 5,000 sensors/year × 10 years = $750,000
• Total 10-year cost: $1,150,000

Option B: LoRaWAN sensor with 10-year battery

• Initial cost: $60/sensor = $600,000
• Battery replacement over 10 years: $0
• Total 10-year cost: $600,000

Total savings over 10 years are $1,150,000 - $600,000 = $550,000. The lifetime savings from choosing the right power architecture are $550,000 / 10,000 = $55 per sensor. This 48% cost reduction demonstrates why power source and battery life dominate TCO analysis for large-scale deployments.

34.15 Domain Selection Framework

Use this scoring system to evaluate IoT domains for a project:

Weighted Scoring (100 points total):

• Requirements Fit (50%): How well does the technology match domain needs?
• Cost Alignment (30%): Is the solution within budget constraints?
• Complexity Match (20%): Can your team implement this complexity level?

Example Calculation for Smart Agriculture Project:

• Requirements fit: 50% weight, score 85/100, weighted contribution 42.5.
• Cost alignment: 30% weight, score 90/100, weighted contribution 27.0.
• Complexity match: 20% weight, score 80/100, weighted contribution 16.0.
• Total: 85.5 out of 100.

Projects scoring above 75 are strong candidates; 60-75 require careful evaluation; below 60 should be reconsidered.

34.16 Domain Selection Scorecard

Evaluate IoT projects using the weighted scoring framework:

34.17 Knowledge Check: IoT Domain Requirements

34.18 LoRaWAN vs NB-IoT TCO

Scenario: A city plans to deploy 10,000 smart parking sensors across downtown. They must choose between LoRaWAN (private network) and NB-IoT (carrier network).

Given:

LoRaWAN Option:

• Sensor hardware: $185/unit (includes LoRa radio, magnetic sensor, 10-year battery)
• Gateways needed: 25 gateways at $2,400 each (covers 5 km² city center)
• Gateway installation: $800 per gateway (mounting, power, networking)
• Network server license: $12,000/year (self-hosted)
• No per-device connectivity fees (unlicensed spectrum)
• Maintenance: 2% sensor replacement annually, 5% gateway failures

NB-IoT Option:

• Sensor hardware: $165/unit (includes NB-IoT modem, magnetic sensor, 10-year battery)
• Connectivity: $3/device/month (carrier subscription, includes data allowance)
• No gateway infrastructure needed (uses existing cellular towers)
• Cloud platform: $8,000/year (carrier-provided management)
• SIM management fees: $0.50/device/year
• Maintenance: 2% sensor replacement annually

Step 1: Initial Capital Expenditure (Year 0)

LoRaWAN:

• Sensors: 10,000 × $185 = $1,850,000
• Gateways: 25 × $2,400 = $60,000
• Gateway installation: 25 × $800 = $20,000
• Network server setup: $15,000 (one-time)
• Total CapEx: $1,945,000

NB-IoT:

• Sensors: 10,000 × $165 = $1,650,000
• No infrastructure needed
• Total CapEx: $1,650,000

Initial advantage: NB-IoT saves $295K upfront

Step 2: Annual Operating Costs (Years 1-5)

LoRaWAN (per year):

• Network server license: $12,000
• Sensor replacements (2%): 200 × $185 = $37,000
• Gateway replacements (5%): 1.25 × $2,400 = $3,000
• Network maintenance: $8,000 (monitoring, updates)
• Power/connectivity for gateways: 25 × $300/year = $7,500
• Annual OpEx: $67,500

NB-IoT (per year):

• Connectivity: 10,000 × $3/month × 12 = $360,000
• SIM management: 10,000 × $0.50 = $5,000
• Cloud platform: $8,000
• Sensor replacements (2%): 200 × $165 = $33,000
• Annual OpEx: $406,000

Step 3: 5-Year Total Cost of Ownership

LoRaWAN:

• Initial: $1,945,000
• 5 years operations: $67,500 × 5 = $337,500
• 5-Year TCO: $2,282,500

NB-IoT:

• Initial: $1,650,000
• 5 years operations: $406,000 × 5 = $2,030,000
• 5-Year TCO: $3,680,000

Result: LoRaWAN saves $1,397,500 over 5 years (38% lower TCO)

Step 4: Breakeven Analysis

When does LoRaWAN’s higher upfront cost pay off?

Annual savings: $406,000 (NB-IoT OpEx) - $67,500 (LoRaWAN OpEx) = $338,500/year

Payback period: $295,000 (upfront difference) / $338,500 (annual savings) = 0.87 years (10.4 months)

LoRaWAN breaks even in under 11 months, then saves $338K annually thereafter.

Step 5: Sensitivity Analysis

What if NB-IoT carrier fees drop to $1.50/device/month?

New NB-IoT annual OpEx:

• Connectivity: 10,000 × $1.50 × 12 = $180,000
• Other costs: $46,000
• New annual: $226,000

5-year NB-IoT TCO: $1,650K + ($226K × 5) = $2,780,000

LoRaWAN still wins, saving $497,500 (18% lower)

What if deployment scales to 50,000 sensors?

LoRaWAN (50K sensors, 100 gateways):

• Initial: 50K × $185 + 100 × $2,400 + 100 × $800 = $9,570,000
• 5-year ops: ($12K + 185K + 12K + 8K + 30K) × 5 = $1,235,000
• 5-year TCO: $10,805,000

NB-IoT (50K sensors):

• Initial: 50K × $165 = $8,250,000
• 5-year ops: ($1.8M + 25K + 8K + 165K) × 5 = $9,990,000
• 5-year TCO: $18,240,000

At scale, LoRaWAN advantage increases to $7.4M (41% lower TCO)

Step 6: Additional Considerations

LoRaWAN Benefits:

• Data sovereignty: City owns all data, no carrier access
• No ongoing fees: Budget predictability, immune to carrier price increases
• Customization: Can modify network parameters, add features
• Resilience: Works during cellular outages
• Expansion: Can add more sensor types (air quality, waste, etc.) using same gateways

LoRaWAN Risks:

• Requires in-house RF expertise for troubleshooting
• City responsible for network uptime (no carrier SLA)
• Gateway hardware lifecycle (replace every 7-10 years)

NB-IoT Benefits:

• Zero infrastructure deployment: Faster time to value
• Carrier SLA: Guaranteed uptime, professional support
• Better building penetration: Works in underground parking
• Easier procurement: No RF expertise required

NB-IoT Risks:

• Carrier lock-in: Switching carriers requires replacing all SIMs
• Recurring fees subject to price increases (3-5% annually typical)
• Sunset risk: If carrier ends NB-IoT service, must replace all sensors
• Data flows through carrier infrastructure

Decision Recommendation:

Choose LoRaWAN when:

• Deployment >5,000 devices (economies of scale)
• Long-term project (5+ years)
• City has IT team capable of managing infrastructure
• Data sovereignty is important
• Want to expand to multiple sensor types using same infrastructure

Choose NB-IoT when:

• Deployment <2,000 devices (LoRaWAN infrastructure cost not justified)
• Short-term pilot (1-3 years)
• No in-house RF expertise
• Need fast deployment (no infrastructure setup time)
• Coverage includes underground/indoor areas where LoRa struggles

For this 10,000-sensor parking deployment: LoRaWAN is the clear winner, breaking even in 11 months and saving $1.4M over 5 years, with additional benefits of data sovereignty and multi-use infrastructure.

Key Takeaway: Per-device costs look attractive (NB-IoT $3/month seems cheap), but multiply by device count and time period to reveal true TCO. At city scale (5K+ devices, 5+ years), private LPWAN networks like LoRaWAN deliver 30-40% TCO savings despite higher upfront investment.

34.19 Concept Check: IoT Domain Requirements

34.20 Concept Check: Requirement Trade-Offs

34.21 See Also

Explore how different domains apply these requirement principles:

• Smart Cities - 80% sensor coverage threshold and LoRaWAN vs NB-IoT trade-offs for city-scale deployments
• Smart Agriculture - 10-year battery life requirements drive LoRaWAN adoption over cellular
• Healthcare IoT - 99.99% reliability and FDA compliance add 200-500% to development costs
• Transportation & V2X - <10 ms latency requirement for vehicle collision avoidance

34.22 Requirement Dimensions Quiz

34.23 Quiz: Domain Requirements

34.24 Label the Diagram

34.25 Code Challenge

34.26 Summary

Understanding domain requirements is essential for IoT project success:

• Latency ranges from <10 ms (autonomous vehicles) to hours (environmental monitoring)
• Reliability cost depends on the controls and operating model needed to meet the service target
• Scale determines infrastructure investment and technology choices
• Power constraints often eliminate entire technology categories
• Data volume drives edge vs. cloud processing decisions
• Regulations can add 50-500% to project cost and timeline

34.27 In 60 Seconds

This chapter covers domain selection, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

The key insight: Start with requirements, not technology. Understanding what each domain actually needs prevents the common mistake of force-fitting a favorite technology into an incompatible use case.

34.28 What’s Next

• Smart Cities: Urban infrastructure at scale with 80% coverage thresholds.
• Smart Agriculture: Remote, battery-powered deployments with LoRaWAN.
• Healthcare IoT: High-reliability, FDA-regulated environments.
• Smart Manufacturing: Real-time, high-data-volume industrial systems.