22 IoT Requirements: Connectivity Costs and Trade-Offs

22.1 Start With the Decision

Two radio choices may meet the same need but hide very different costs. Count gateways, battery life, and service fees before choosing.

22.2 Route Overview

This is part 1 of 2. Continue with IoT Requirements: Five-Layer and Seven-Layer Models.

22.3 Part Objectives

• Calculate five-year TCO for cellular and LoRaWAN sensor fleets.
• Score ideal IoT characteristics without hiding mandatory requirements.

22.4 Start With the Story

A warehouse team has narrowed its connectivity choices to two technologies that both appear to meet the radio requirement. Purchase price makes one look cheaper. The team now has to include subscriptions, gateways, maintenance, battery life, and the other system characteristics before choosing what ‘meets the requirement’ really means.

22.5 Overview

This route starts with connectivity total cost, then turns battery life and eleven ideal-system characteristics into weighted, testable design decisions.

This is part 2 of 2. Review IoT Requirements: Classification and Connectivity when you need the first route.

22.6 Learning Objectives

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

• calculate and compare connectivity total cost of ownership
• translate a battery-life claim into a current budget
• prioritize IoT system characteristics as measurable trade-offs

22.7 Chapter Roadmap

• Start With the Story
• Overview
• Connectivity Technology TCO
• Phoebe’s Field Notes: What “10-Year Battery” Actually Budgets
• Bex’s Math Bridge: Turn Years into a Current Budget
• Checkpoint: Classification and Connectivity
• Knowledge Check: Minimum Requirements
• Characteristics of Ideal IoT Systems
• The Eleven Characteristics of Ideal IoT
• Characteristics as Tradeoffs
• IoT Priority Scoring
• Characteristic Dependencies
• Why These Characteristics Matter
• Evaluate IoT Products
• Checkpoint: Characteristic Priorities
• Knowledge Check: Eleven Characteristics
• Common Pitfalls
• Checkpoint: Avoiding Requirements Traps

22.8 Connectivity Technology TCO

Given: 50-sensor deployment, 5-year horizon

• Cellular TCO: $18K hardware + $12K installation + $25K operations = $55K
• LoRaWAN TCO: $16K hardware + $3K installation + $15K operations = $34K
• Cost savings: ($55K - $34K) / $55K = 38%

Scaling impact: At 1,000 sensors, the gap widens:

• Cellular: $360K + $240K + $500K = $1.1M
• LoRaWAN: $320K + $20K + $300K = $640K, about 42% savings

Lower operational costs (10-year batteries, no SIM management) drive LoRaWAN ROI despite higher initial gateway investment.

Why 10-Minute Intervals Suffice:

• Pharmaceutical storage temperature changes gradually (hours, not seconds)
• Refrigeration systems have thermal mass - temperature drifts slowly
• 10-minute intervals provide ample warning (regulations require hourly checks)
• Real-time creates data overload: 1,051,200 readings/year vs 52,560

LoRaWAN Advantages:

• Single gateway covers entire warehouse (vs dense Wi-Fi AP deployment)
• 10-year battery eliminates power infrastructure ($15K savings)
• Excellent signal penetration through metal racking
• Dedicated IoT network isolated from business Wi-Fi

22.9 Knowledge Check: Minimum Requirements

Question 1: A fitness tracker that records steps locally and only syncs to your phone via Bluetooth (no cloud connection) is:

a) A full IoT device because it has sensors and connectivity b) A connected device because Bluetooth enables device-to-device communication but not internet c) An embedded device because it has no connectivity at all d) An IoT device because it can track health metrics

Reveal Answer Answer: b) A connected device because Bluetooth enables device-to-device communication but not internet

Explanation: The tracker has:

• Thing: The physical wristband
• Computation: Processor counting steps
• Connectivity: Bluetooth only (not internet)

Bluetooth alone provides local wireless communication but not internet connectivity. The device becomes IoT only when the phone acts as a gateway to upload data to the cloud. Without that cloud connection, it’s “connected” but not truly “IoT.”

The Gateway Distinction: Many devices achieve IoT status indirectly through a smartphone gateway. If this tracker’s companion app uploads to the cloud, the SYSTEM is IoT, but the tracker alone is just connected.

Question 2: Which of the following is the MOST accurate way to describe the “Internet” requirement in IoT?

a) The device must use Wi-Fi b) The device must connect to the World Wide Web c) The device must be able to communicate with remote systems via IP-based networks d) The device must have a mobile app

Reveal Answer Answer: c) The device must be able to communicate with remote systems via IP-based networks

Explanation:

• (a) Wrong: Wi-Fi is just one connectivity option. Cellular, Ethernet, LoRaWAN are equally valid.
• (b) Partially wrong: IoT uses internet protocols (TCP/IP) but doesn’t necessarily access “web pages.”
• (c) Correct: The core requirement is IP-based communication enabling remote access, whether direct or through a gateway.
• (d) Wrong: Mobile apps are a user interface choice, not a connectivity requirement. Many IoT devices use web dashboards or machine-to-machine communication.

Key Insight: “Internet” in IoT means protocol-based network communication (typically IP), not specifically “browsing the web.”

Question 3: A smart door lock with Wi-Fi that allows remote unlocking from anywhere in the world demonstrates which IoT advantage over a Bluetooth-only lock?

a) Better security b) Lower power consumption c) Global accessibility instead of proximity-only control d) Faster response time

Reveal Answer Answer: c) Global accessibility instead of proximity-only control

Explanation: The fundamental difference between “connected” (Bluetooth) and “IoT” (Wi-Fi/Internet) is reach:

• Bluetooth: 10-100 feet range, requires physical proximity
• Wi-Fi/Internet: Global range, control from anywhere with internet access

Business Impact Example:

• Bluetooth lock: Can only unlock when standing at the door
• IoT lock: Can unlock remotely for delivery drivers (Amazon Key), grant temporary access to guests, or monitor who enters while you’re traveling

This global accessibility unlocks new use cases worth billions (package delivery, Airbnb key management, enterprise access control).

22.10 Characteristics of Ideal IoT Systems

What distinguishes a well-designed IoT system from a mediocre one? Understanding the characteristics of ideal IoT implementations helps engineers, designers, and product managers create systems that deliver real value. These eleven characteristics represent design goals that the best IoT solutions strive to achieve.

22.11 The Eleven Characteristics of Ideal IoT

Use Figure 22.1 to prepare the decision in the eleven characteristics of ideal iot. The diagram names The Eleven Characteristics of Strong IoT Systems and Experience, the two anchors needed to assess eleven characteristics of strong iot systems grouped by design goal.

Begin Figure 22.1 with The Eleven Characteristics of Strong IoT Systems, then distinguish Experience and Ubiquitous. The diagram separates The Eleven Characteristics of Strong IoT Systems from Experience within eleven characteristics of strong iot systems grouped by design goal. Keep both distinctions explicit in the eleven characteristics of ideal iot.

22.12 Characteristics as Tradeoffs

In Figure 22.2, This variant shows the 11 characteristics as a priority matrix - different IoT domains prioritize different characteristics:

In Figure 22.2, Why this variant helps: The original mindmap lists all 11 characteristics as equally important. This variant shows the design reality: different applications prioritize different characteristics. A factory needs millisecond response times (Fast), while a farm sensor can wait hours (Growing is more important). Understanding these trade-offs is essential for IoT product design.

• Ubiquitous: Available everywhere and integrated across environments, like smart lighting that works consistently at home, office, and hotel.
• Smart: Makes decisions from data and context, like a thermostat that learns a schedule and pre-heats before arrival.
• Agile: Adapts quickly to changing conditions, like factory sensors that detect anomalies and adjust process parameters.
• On Demand: Responds when requested, like a voice assistant that reacts within milliseconds.
• Blend into Background: Operates unobtrusively, like environmental sensors that work silently.
• Secure: Resists cyber threats through encryption, secure boot, and regular updates.
• Low Maintenance: Self-monitors and reduces human intervention through health reports and automatic updates.
• Fast: Delivers low-latency response, like industrial control loops responding in less than 10 ms.
• Upgradable: Evolves through OTA updates without hardware replacement, like vehicles gaining new software features.
• Growing: Scales from pilot to production fleet without redesign.
• Adaptable: Supports new use cases, protocols, and integrations as requirements change.

22.13 IoT Priority Scoring

Score your IoT project requirements against the eleven ideal characteristics:

How to use:

1. Select your project type for preset values, or choose “Custom”
2. Adjust sliders to reflect your specific requirements
3. Review your top 3 priorities - these should drive your design decisions
4. Accept trade-offs on bottom-ranked characteristics

22.14 Characteristic Dependencies

The eleven characteristics do not exist in isolation — several depend on or enable each other. Understanding these relationships helps you identify which foundational characteristics to invest in first.

Use Figure 22.3 to prepare the decision in characteristic dependencies. The diagram names Some Characteristics Depend on Others and Experience, the two anchors needed to assess characteristic dependencies among foundation, enablement, and experience qualities.

Figure 22.3 places Some Characteristics Depend on Others alongside Experience. Treat Enablement as the diagram qualifier for characteristic dependencies among foundation, enablement, and experience qualities. That labelled limit reconnects the visual to characteristic dependencies.

Reading the diagram: Arrows show dependency direction. “Secure” enables “Upgradable” because OTA updates require authenticated, encrypted channels. “Fast” enables “On Demand” because instant user response requires low-latency infrastructure. Investing in foundation-layer characteristics unlocks the enabler and experience layers.

22.15 Why These Characteristics Matter

Trade-off Reality: No single IoT system perfectly achieves all eleven characteristics. Designers must prioritize based on use case:

• Medical wearable: Prioritize Secure, Fast, and Low Maintenance; it may be acceptable to sacrifice Ubiquitous if the device works only in supported regions.
• Smart agriculture: Prioritize Low Maintenance, Growing, and Adaptable; it may be acceptable to sacrifice Fast because hourly updates are often sufficient.
• Industrial control: Prioritize Fast, Secure, and Agile; it may be acceptable to sacrifice Blend into Background because operators need visibility.
• Consumer smart home: Prioritize On Demand, Upgradable, and Blend into Background; it may be acceptable to sacrifice Growing because a home has a fixed practical size.

Design Principle: Identify your 3-4 must-have characteristics and ensure they’re exceptional, rather than achieving mediocrity across all eleven.

22.16 Evaluate IoT Products

Scenario: You’re evaluating two smart thermostat products for a commercial building deployment (500 units across 50 floors):

Product A: Fast response (2-second latency), excellent mobile app, requires manual firmware updates via USB, single-building deployment limit, proprietary protocol.

Product B: Slower response (8-second latency), basic web interface, automatic OTA updates, unlimited scalability, supports multiple protocols (Wi-Fi, Zigbee, BACnet).

Question: Which product better meets ideal IoT characteristics for this commercial deployment?

Answer: Product B wins because:

• Growing: Unlimited scalability handles future expansion (Product A’s single-building limit is disqualifying)
• Low Maintenance: OTA updates across 500 devices vs. USB updates (500 x manual visits = untenable)
• Upgradable: Automatic firmware ensures security patches reach all devices
• Adaptable: Multi-protocol support integrates with existing BACnet building management systems

Speed Trade-off is Acceptable: HVAC systems have thermal mass - 8-second response is adequate for temperature control (rooms don’t heat/cool in seconds). 2-second advantage provides no practical benefit.

Product A’s mobile app is irrelevant for commercial building operators who use centralized building management dashboards, not individual phone apps.

This illustrates why prioritizing the right characteristics for your use case matters more than raw feature comparison.

22.17 Knowledge Check: Eleven Characteristics

Question 1: A smart irrigation system for a large farm needs to scale from a 10-sensor pilot to 10,000 sensors across multiple fields. Which characteristic is MOST critical?

a) Fast (low latency) b) Growing (scalability) c) On Demand (instant response) d) Blend into Background (invisible operation)

Reveal Answer Answer: b) Growing (scalability)

Explanation: For agricultural IoT deployments that start small and expand:

• Growing (b) is critical because the platform must handle 1000x growth without architectural changes
• Fast (a) is not critical because soil moisture changes over hours, not milliseconds
• On Demand (c) is nice-to-have but farmers don’t need instant response for irrigation decisions
• Blend into Background (d) is expected but not the primary concern

Design Implication: Choose a platform architecture (cloud, protocols, data storage) that scales horizontally from day one, even if the pilot is small.

Question 2: An IoT pacemaker must prioritize which characteristics above all others?

a) Growing and Adaptable b) Secure and Fast c) Ubiquitous and On Demand d) Low Maintenance and Blend into Background

Reveal Answer Answer: b) Secure and Fast

Explanation: For life-critical medical devices:

• Secure: A hacked pacemaker could kill the patient. Security is non-negotiable.
• Fast: Cardiac events happen in milliseconds. The device must respond instantly.

Why others are lower priority:

• Growing: One pacemaker per patient, no scaling needed
• Adaptable: Regulatory approval limits changes; stability > flexibility
• Ubiquitous: Works in one patient’s body, not everywhere
• Blend into Background: Yes, but security and speed come first

Key Insight: Medical IoT has different priorities than consumer or industrial IoT. Always map characteristics to the specific domain’s requirements.

Question 3: Which IoT characteristic does Tesla’s over-the-air (OTA) software updates best demonstrate?

a) Smart b) Upgradable c) Growing d) Agile

Reveal Answer Answer: b) Upgradable

Explanation: Tesla’s OTA updates exemplify Upgradable because:

• Cars receive new features years after purchase (Autopilot improvements, new games, performance boosts)
• No dealership visit required
• Hardware stays the same; software evolves

Why not the others:

• Smart (a): The car being intelligent is separate from its ability to receive updates
• Growing (c): Tesla’s fleet scaling is a company achievement, not an individual car characteristic
• Agile (d): Agile means quick adaptation to real-time conditions; OTA updates are periodic improvements

Industry Impact: Tesla’s OTA capability forced traditional automakers to add similar features. It’s now a competitive requirement in the automotive IoT market.

Question 4: A startup is designing a smart home hub. They can only excel at 3 characteristics. Which combination makes the most business sense?

a) Fast, Growing, Secure b) On Demand, Upgradable, Adaptable c) Ubiquitous, Smart, Blend into Background d) Low Maintenance, Fast, Growing

Reveal Answer Answer: b) On Demand, Upgradable, Adaptable

Explanation: For consumer smart home hubs:

• On Demand: Users expect instant response (“Alexa, turn on lights”)
• Upgradable: Smart home ecosystem evolves rapidly; hub must receive new features
• Adaptable: New device protocols emerge constantly (Thread, Matter); hub must integrate them

Why others are less critical:

• Fast (a, d): Home automation doesn’t need industrial-grade millisecond response
• Growing (a, d): Homes have finite size; scaling to millions isn’t the hub’s job
• Secure (a): Important but not a top-3 differentiator for consumers (sadly)
• Ubiquitous (c): Hub stays in one home; works in all rooms but not multiple locations
• Blend into Background (c): Nice aesthetically but not a purchase decision driver

Design Principle: Match your top 3 characteristics to what customers actually value and pay for.

22.18 Common Pitfalls

1. Confusing “Connected” with “IoT” A device with Bluetooth-only connectivity is a connected device, not an IoT device. True IoT requires internet reachability — either directly (Wi-Fi, cellular) or indirectly through a gateway. Marketing teams frequently label Bluetooth-only products as “IoT” or “smart,” misleading buyers who expect remote access and cloud intelligence.

2. Treating All Eleven Characteristics as Equally Important No single IoT system can excel at all eleven characteristics simultaneously. Attempting to optimize for everything leads to a mediocre product that excels at nothing. Successful teams identify 3-4 characteristics critical to their domain and design around those. A farm sensor optimized for “Fast” (millisecond response) wastes engineering effort — soil moisture changes over hours.

3. Choosing Technology Before Understanding Requirements Teams often select Wi-Fi because it is familiar, then discover it drains batteries in days, requires power infrastructure at every sensor node, and struggles with signal penetration in industrial environments. Always start with the application’s constraints (range, power, data rate, environment) and let requirements drive technology selection.

4. Ignoring the Gateway Distinction A fitness tracker that syncs only to a phone via Bluetooth is not IoT on its own. The system becomes IoT when the phone uploads data to the cloud. This distinction matters for reliability: if the phone is absent, the cloud connection breaks. Design decisions should account for whether a device depends on a gateway and what happens when that gateway is unavailable.

5. Overlooking Scalability Until It Is Too Late A prototype that works with 10 sensors often fails catastrophically at 10,000. Architecture choices made during prototyping (polling frequency, database schema, message broker capacity) become constraints at scale. Evaluate the “Growing” characteristic early, even if the pilot is small.

Checkpoint: Avoiding Requirements Traps

You now know:

• The five common pitfalls mostly come from treating labels, features, or prototypes as requirements evidence.
• The five-layer teaching model is useful first; the seven-layer reference view becomes useful when storage, abstraction, applications, and business processes need sharper boundaries.
• The practice section checks matching, ordering, labeling, and code so you can test concept meaning from more than one angle.

The visual bridge and interactive quizzes are a review lane: first map the architecture layers, then prove you can classify and sequence them.

22.19 Continue to the Next Part

Carry this evidence into IoT Requirements: Five-Layer and Seven-Layer Models, which begins with Visual Bridge: From 5 Layers to 7.