26  Cellular Power & Cost

In 60 Seconds

Achieving 10+ year cellular IoT battery life requires configuring PSM (10 uA deep sleep) or eDRX (1.5 mA light sleep) via AT commands, with the choice depending on how quickly the device must respond to downlink messages. Total cost of ownership over 5-10 years depends heavily on data plan selection: flat-rate plans (1NCE at $10/10 years) suit low-data sensors, while usage-based plans suit variable workloads but risk overage charges from firmware updates and retry storms.

For Beginners: Battery Life and Cost Matter

Cellular IoT devices often run on batteries for years without replacement. This chapter teaches you:

• Power Saving Modes: How PSM and eDRX reduce power consumption by 1,500x
• Battery Life Calculations: How to estimate if your battery will last 10+ years
• Cost Planning: How to choose data plans that minimize total cost over 5-10 year deployments

These skills are essential for designing practical, cost-effective IoT solutions.

Sensor Squad: The Power and Money Balancing Act

“Two things keep IoT project managers awake at night,” said Max the Microcontroller, “battery life and monthly bills. Let us tackle both!”

Bella the Battery took center stage. “PSM is my best friend. In Power Saving Mode, I draw only 5 microamps – that is 1,500 times less than eDRX mode! With a 3,600 milliamp-hour battery and one transmission per hour, I can last over 10 years. The catch? Nobody can reach the device while it sleeps. If you need the server to send commands, eDRX wakes up every few seconds to check.”

Sammy the Sensor asked about configuration. “You set the timers with AT commands,” Max explained. “AT+CPSMS sets the TAU timer – how long the device sleeps – and the Active Timer – how long it stays awake after transmitting. AT+CEDRXS configures the eDRX cycle length. Get these wrong, and you drain the battery 100 times faster than necessary.”

Lila the LED brought up the money side. “A flat-rate plan like 1NCE at 10 dollars for 10 years sounds cheap, but it only includes 500 MB. That is fine for a sensor sending 100 bytes per hour, but a firmware update could burn 1 MB in minutes. Always budget for retransmissions, keep-alive messages, and occasional large uploads. The cheapest plan on paper might be the most expensive in practice.”

26.1 Learning Objectives

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

• Configure Power Modes: Implement PSM and eDRX via AT commands to achieve 10+ year battery life
• Calculate Battery Life: Model power consumption across Idle, eDRX, and PSM operating modes using energy budgets
• Evaluate Data Plans: Compare flat-rate, pay-as-you-go, and pooled connectivity providers for cellular IoT deployments
• Optimize TCO: Justify cost-effective data plan selection based on fleet size, data volume, and deployment duration
• Decode PSM Timers: Interpret and construct binary-encoded TAU and Active Time values for AT+CPSMS commands

26.2 Prerequisites

Required Chapters:

• Cellular IoT Technology Selection - Technology comparison
• Cellular IoT Fundamentals - Core concepts

Technical Background:

• Basic understanding of NB-IoT and LTE-M
• Familiarity with battery capacity (mAh)
• Understanding of data transmission concepts

Estimated Time: 35 minutes

26.3 Key Concepts

• Power Saving Mode (PSM): Deep sleep mode with periodic wakeup for ultra-low power
• eDRX (Extended DRX): Extended discontinuous reception for longer sleep cycles
• TAU Timer: Tracking Area Update timer - how long device sleeps in PSM
• Active Window: Brief period after transmission when device is reachable
• AT Commands: Standard interface for controlling cellular modules
• APN: Access Point Name for connecting to carrier’s packet data network
• TCO: Total Cost of Ownership over deployment lifetime

26.4 Power Saving Modes for Cellular IoT

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P09.C21.U02

Understanding power modes is critical for achieving 10+ year battery life:

Figure 26.1: Cellular IoT Power Saving Modes: Idle, eDRX, and PSM Comparison

Power Mode Comparison:

Mode	Power Consumption	Reachability	Battery Life	Use Case
Standard Idle	15 mA continuously	Always	14 days (5000 mAh)	Real-time messaging
eDRX	1.5 mA (sleep), 15 mA (wake)	Every wake cycle	1-2 years	Hourly sensor updates
PSM	10 µA (deep sleep)	Only during active window	10+ years	Daily smart meter readings

eDRX (Extended Discontinuous Reception) Details:

Parameter	Value
Wake Cycle	Every 5.12s - 163 min (configurable)
Sleep Current	1.5 mA (light sleep)
Active Current	15 mA (listening for pages)
AT Command	AT+CEDRXS=1,4,'0101'

PSM (Power Save Mode) Details:

Parameter	Value
TAU Timer	Hours to days (configurable)
Deep Sleep Current	10 µA (ultra-low power)
Active Window	6-60 seconds after TX
AT Command	AT+CPSMS=1,,,'00100100','00000011'

Timeline Examples:

Mode	Pattern
eDRX (1 hour update)	Wake 5s -> Sleep 81.92s -> Wake 5s -> Sleep…
PSM (Daily update)	TX + Active 10s -> Deep Sleep 24h -> Wake for TX -> Deep Sleep…

Power Comparison:

• PSM (10 µA) = 1,500x less than Idle (15 mA)
• eDRX (1.5 mA) = 10x less than Idle (15 mA)

Try It: Power Mode Battery Life Explorer

Adjust the battery capacity and see how different power modes (Idle, eDRX, PSM) affect estimated battery life. This visualizes why PSM is essential for multi-year deployments.

viewof batteryCapacity = Inputs.range([1000, 20000], {
  value: 5000,
  step: 500,
  label: "Battery capacity (mAh)"
})

viewof txPerDay = Inputs.select([1, 4, 12, 24, 48, 96], {
  value: 1,
  label: "Transmissions per day"
})

{
  const idleCurrent = 15;
  const edrxCurrent = 1.5;
  const psmCurrentUA = 10;
  const txCurrentMA = 220;
  const txDurationS = 3;

  const txEnergyPerDay = (txDurationS / 3600) * txCurrentMA * txPerDay;
  const idleHours = 24 - (txDurationS * txPerDay) / 3600;

  const idleDaily = txEnergyPerDay + idleHours * idleCurrent;
  const edrxDaily = txEnergyPerDay + idleHours * edrxCurrent;
  const psmDaily = txEnergyPerDay + idleHours * (psmCurrentUA / 1000);

  const idleLifeDays = batteryCapacity / idleDaily;
  const edrxLifeDays = batteryCapacity / edrxDaily;
  const psmLifeDays = batteryCapacity / psmDaily;

  const modes = [
    { name: "Idle (15 mA)", days: idleLifeDays, color: "#E74C3C" },
    { name: "eDRX (1.5 mA)", days: edrxLifeDays, color: "#E67E22" },
    { name: "PSM (10 µA)", days: psmLifeDays, color: "#16A085" }
  ];

  const maxDays = Math.max(...modes.map(m => m.days));
  const barWidth = 420;
  const barHeight = 36;
  const labelWidth = 120;
  const valueWidth = 140;
  const totalWidth = labelWidth + barWidth + valueWidth + 20;

  const formatLife = (days) => {
    if (days < 1) return `${(days * 24).toFixed(1)} hours`;
    if (days < 365) return `${days.toFixed(0)} days`;
    return `${(days / 365).toFixed(1)} years`;
  };

  return html`<div style="font-family: Arial, sans-serif; padding: 12px 0;">
    <div style="font-size: 13px; color: #7F8C8D; margin-bottom: 12px;">
      Battery: <strong>${batteryCapacity} mAh</strong> | Transmissions: <strong>${txPerDay}/day</strong>
    </div>
    ${modes.map((m, i) => {
      const w = Math.max(4, (m.days / maxDays) * barWidth);
      return html`<div style="display: flex; align-items: center; margin-bottom: 10px;">
        <div style="width: ${labelWidth}px; font-size: 13px; font-weight: 600; color: #2C3E50; text-align: right; padding-right: 10px;">${m.name}</div>
        <div style="width: ${barWidth}px; background: #ecf0f1; border-radius: 4px; height: ${barHeight}px; position: relative;">
          <div style="width: ${w}px; height: 100%; background: ${m.color}; border-radius: 4px; transition: width 0.4s;"></div>
        </div>
        <div style="width: ${valueWidth}px; font-size: 13px; font-weight: 700; color: ${m.color}; padding-left: 10px;">${formatLife(m.days)}</div>
      </div>`;
    })}
    <div style="font-size: 12px; color: #7F8C8D; margin-top: 8px; border-top: 1px solid #ecf0f1; padding-top: 8px;">
      PSM achieves <strong>${(idleLifeDays > 0 ? psmLifeDays / idleLifeDays : 0).toFixed(0)}x</strong> longer battery life than Idle mode for this configuration.
    </div>
  </div>`;
}

26.5 PSM Configuration and Battery Life Calculation

26.5.1 Configuring PSM via AT Commands

The PSM AT command format:

AT+CPSMS=<mode>,<Requested_Periodic-RAU>,<Requested_GPRS-READY-timer>,<Requested_Periodic-TAU>,<Requested_Active-Time>

Binary encoding (8 bits): First 3 bits = unit, Last 5 bits = value

TAU (T3412) Units:

• 000 = 10 minutes
• 001 = 1 hour
• 010 = 10 hours
• 011 = 2 seconds
• 100 = 30 seconds
• 101 = 1 minute

Active Time (T3324) Units:

• 000 = 2 seconds
• 001 = 1 minute
• 010 = decihours

Example: 24-hour TAU, 30-second Active Time:

// TAU: 010 (10-hour units) + 00100 (4 decimal) = 4×10h = 40h → "01000100"
// (For exactly 24h: 001 (1-hour units) + 11000 (24 decimal) = 24×1h → "00111000")
// Active: 000 (2-second units) + 01111 (15 decimal) = 15×2s = 30s → "00001111"

sendAT("AT+CPSMS=1,,,\"00111000\",\"00001111\"");

26.5.2 Battery Life Calculation Example

Scenario: Smart water meter with daily readings

# Device parameters
battery_capacity_mah = 5000  # 2× AA batteries
transmissions_per_day = 1
payload_bytes = 50

# Current consumption
tx_current_ma = 220  # NB-IoT transmit
rx_current_ma = 60   # Receive acknowledgment
idle_current_ma = 15 # Connection overhead
psm_current_ua = 10  # Deep sleep (0.01 mA)

# Timing (seconds)
tx_duration_s = 3
rx_duration_s = 1
connection_overhead_s = 5
active_window_s = 6

# Calculate daily energy consumption
# Active phases (in mAh)
tx_energy = (tx_duration_s / 3600) * tx_current_ma * transmissions_per_day
rx_energy = (rx_duration_s / 3600) * rx_current_ma * transmissions_per_day
overhead_energy = (connection_overhead_s / 3600) * idle_current_ma * transmissions_per_day
active_energy = (active_window_s / 3600) * idle_current_ma * transmissions_per_day

# PSM sleep (remaining ~24 hours)
psm_hours = 24 - (tx_duration_s + rx_duration_s + connection_overhead_s + active_window_s) / 3600
psm_energy = psm_hours * (psm_current_ua / 1000)  # Convert µA to mA

# Total daily consumption
daily_consumption = tx_energy + rx_energy + overhead_energy + active_energy + psm_energy
# ≈ 0.183 + 0.017 + 0.021 + 0.025 + 0.240 = 0.486 mAh/day

# Battery life
battery_life_days = battery_capacity_mah / daily_consumption
battery_life_years = battery_life_days / 365
# ≈ 10,288 days = 28.2 years

Result: With PSM, a 5000 mAh battery can last 28+ years (theoretical). Real-world factors (self-discharge, temperature, retransmissions) reduce this to 10-15 years.

Try It: PSM Battery Life Calculator

Adjust the device parameters to model your own battery life scenario. See how each component (TX, RX, overhead, sleep) contributes to total daily energy consumption.

viewof calcBattery = Inputs.range([1000, 20000], {
  value: 5000,
  step: 500,
  label: "Battery capacity (mAh)"
})

viewof calcTxPerDay = Inputs.range([1, 96], {
  value: 1,
  step: 1,
  label: "Transmissions per day"
})

viewof calcTxCurrent = Inputs.range([100, 400], {
  value: 220,
  step: 10,
  label: "TX current (mA)"
})

viewof calcTxDuration = Inputs.range([1, 15], {
  value: 3,
  step: 0.5,
  label: "TX duration (seconds)"
})

viewof calcPsmCurrent = Inputs.range([1, 100], {
  value: 10,
  step: 1,
  label: "PSM sleep current (µA)"
})

{
  const rxCurrent = 60;
  const rxDuration = 1;
  const overheadCurrent = 15;
  const overheadDuration = 5;
  const activeWindowDuration = 6;

  const txEnergy = (calcTxDuration / 3600) * calcTxCurrent * calcTxPerDay;
  const rxEnergy = (rxDuration / 3600) * rxCurrent * calcTxPerDay;
  const overheadEnergy = (overheadDuration / 3600) * overheadCurrent * calcTxPerDay;
  const activeEnergy = (activeWindowDuration / 3600) * overheadCurrent * calcTxPerDay;

  const activeTotalSeconds = (calcTxDuration + rxDuration + overheadDuration + activeWindowDuration) * calcTxPerDay;
  const psmHours = 24 - activeTotalSeconds / 3600;
  const psmEnergy = psmHours * (calcPsmCurrent / 1000);

  const dailyTotal = txEnergy + rxEnergy + overheadEnergy + activeEnergy + psmEnergy;
  const batteryLifeDays = calcBattery / dailyTotal;
  const batteryLifeYears = batteryLifeDays / 365;

  const components = [
    { name: "TX Energy", value: txEnergy, color: "#E74C3C" },
    { name: "RX Energy", value: rxEnergy, color: "#E67E22" },
    { name: "Connection Overhead", value: overheadEnergy, color: "#3498DB" },
    { name: "Active Window", value: activeEnergy, color: "#9B59B6" },
    { name: "PSM Sleep", value: psmEnergy, color: "#16A085" }
  ];

  const maxComp = Math.max(...components.map(c => c.value));
  const barMaxW = 300;

  return html`<div style="font-family: Arial, sans-serif; padding: 12px 0;">
    <div style="display: flex; gap: 24px; flex-wrap: wrap; margin-bottom: 16px;">
      <div style="background: #f0faf7; border-radius: 8px; padding: 12px 18px; border-left: 4px solid #16A085;">
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase;">Battery Life</div>
        <div style="font-size: 24px; font-weight: 700; color: #16A085;">${batteryLifeYears.toFixed(1)} years</div>
        <div style="font-size: 12px; color: #7F8C8D;">(${batteryLifeDays.toFixed(0)} days)</div>
      </div>
      <div style="background: #fdf2e9; border-radius: 8px; padding: 12px 18px; border-left: 4px solid #E67E22;">
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase;">Daily Consumption</div>
        <div style="font-size: 24px; font-weight: 700; color: #E67E22;">${dailyTotal.toFixed(3)} mAh</div>
        <div style="font-size: 12px; color: #7F8C8D;">per day</div>
      </div>
    </div>
    <div style="font-size: 13px; font-weight: 600; color: #2C3E50; margin-bottom: 8px;">Energy Breakdown (mAh/day):</div>
    ${components.map(c => {
      const pct = dailyTotal > 0 ? ((c.value / dailyTotal) * 100).toFixed(1) : "0.0";
      const w = maxComp > 0 ? Math.max(2, (c.value / maxComp) * barMaxW) : 2;
      return html`<div style="display: flex; align-items: center; margin-bottom: 6px;">
        <div style="width: 140px; font-size: 12px; color: #2C3E50; text-align: right; padding-right: 8px;">${c.name}</div>
        <div style="width: ${barMaxW}px; background: #ecf0f1; border-radius: 3px; height: 18px;">
          <div style="width: ${w}px; height: 100%; background: ${c.color}; border-radius: 3px; transition: width 0.3s;"></div>
        </div>
        <div style="font-size: 12px; color: ${c.color}; padding-left: 8px; font-weight: 600; min-width: 100px;">${c.value.toFixed(4)} mAh (${pct}%)</div>
      </div>`;
    })}
    <div style="font-size: 12px; color: #7F8C8D; margin-top: 10px; border-top: 1px solid #ecf0f1; padding-top: 8px;">
      ${batteryLifeYears >= 10
        ? html`<span style="color: #16A085; font-weight: 600;">Target met: Battery life exceeds 10-year target.</span>`
        : html`<span style="color: #E74C3C; font-weight: 600;">Below target: Reduce transmissions or TX current to reach 10-year goal.</span>`}
      Real-world factors (self-discharge, temperature) typically reduce theoretical life by 50-70%.
    </div>
  </div>`;
}

Putting Numbers to It

For hourly transmissions instead of daily, energy per cycle (TX + RX + overhead + active) is:

\[E_{\text{cycle}} = \frac{220 \times 3 + 60 \times 1 + 15 \times 11}{3600} = 0.225 \text{ mAh}\]

With 24 cycles/day and PSM sleep for the remaining time:

\[E_{\text{daily}} = 24 \times 0.225 + 24 \times \frac{10}{1000} = 5.40 + 0.24 = 5.64 \text{ mAh/day}\]

With a 5,000 mAh battery: \(\frac{5000}{5.64} \approx 887\) days (2.4 years). PSM with T3412=1 hour and T3324=10s enables this. Switching to eDRX (1.5 mA average) reduces life to \(\frac{5000}{1.5 \times 24} = 139\) days.

Check Your Understanding: PSM vs eDRX Selection

Power Optimization Tips

• Always Enable PSM for Infrequent Updates: PSM (10 µA) vs Idle (15 mA) = 1,500x power reduction
• PSM Configuration: Set TAU (Tracking Area Update) >= transmission interval for maximum sleep
• eDRX for Moderate Frequencies: Use eDRX (1.5 mA) for 1-minute to 1-hour update intervals
• Optimize Transmission Time: Reduce payload size to minimize TX duration (220 mA for NB-IoT)
• Connection Caching: Maintain PDP context to avoid reconnection overhead (5-10 seconds)
• AT Commands for Monitoring:
  • PSM: AT+CPSMS=1,,,<TAU>,<Active>
  • eDRX: AT+CEDRXS=1,4,<eDRX_value>
  • Check status: AT+CPSMS? and AT+CEDRXS?

26.6 Data Plan Cost Analysis

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P09.C21.U03

26.6.1 Calculating Data Usage

Monthly data formula:

Monthly Data = Payload × (1 + Overhead%) × Transmissions/day × 30 days

Protocol overhead factors:

Protocol Stack	Overhead
MQTT over TCP/IP	~30%
CoAP over UDP	~15%
MQTT-SN	~10%

Example calculation:

# Sensor parameters
payload_bytes = 100
protocol_overhead = 1.3  # MQTT over TCP/IP (30%)
transmissions_per_day = 48  # Every 30 minutes

# Monthly data
data_per_transmission = payload_bytes * protocol_overhead  # 130 bytes
monthly_transmissions = transmissions_per_day * 30  # 1,440
monthly_data_bytes = data_per_transmission * monthly_transmissions  # 187,200 bytes
monthly_data_mb = monthly_data_bytes / (1024 * 1024)  # 0.178 MB

26.6.2 Provider Cost Comparison

Common IoT Connectivity Providers:

Provider	Pricing Model	Best For
1NCE	$10 flat for 10 years (500 MB)	Low-data, long-term deployments
Hologram	$0.60/month + $0.40/MB	Variable data usage, global roaming
Twilio	$2/month + $0.10/MB	Developer-friendly, API integration
Particle	$2.99/month (3 MB included)	Integrated device management

26.6.3 TCO Calculation Example

Scenario: 10,000 environmental sensors, 5-year deployment, 0.18 MB/month data usage

1NCE (Flat-rate):

Cost per device: $10 for 10 years
5-year pro-rated: $5/device
Fleet cost: $5 × 10,000 = $50,000
Monthly equivalent: $0.083/device

Hologram (Pay-as-you-go):

Monthly base: $0.60
Monthly data: 0.18 MB × $0.40/MB = $0.072
Monthly total: $0.672/device
5-year cost: $0.672 × 60 months = $40.32/device
Fleet cost: $40.32 × 10,000 = $403,200

Particle (Pooled with included data):

Monthly: $2.99 (data within 3 MB included)
5-year cost: $2.99 × 60 = $179.40/device
Fleet cost: $179.40 × 10,000 = $1,794,000

Comparison Summary:

Provider	Monthly/Device	5-Year/Device	Fleet 5-Year TCO
1NCE	$0.08	$5.00	$50,000
Hologram	$0.67	$40.32	$403,200
Particle	$2.99	$179.40	$1,794,000

Key Insight: For low-data IoT at scale, 1NCE is 8-36x cheaper than pay-as-you-go alternatives.

Try It: Fleet TCO Calculator

Configure your deployment parameters and compare total cost of ownership across providers. Adjust fleet size, data usage, and deployment duration to find the most cost-effective option.

viewof fleetSize = Inputs.range([100, 100000], {
  value: 10000,
  step: 100,
  label: "Fleet size (devices)"
})

viewof monthlyDataMB = Inputs.range([0.01, 10], {
  value: 0.18,
  step: 0.01,
  label: "Monthly data per device (MB)"
})

viewof deploymentYears = Inputs.range([1, 10], {
  value: 5,
  step: 1,
  label: "Deployment duration (years)"
})

viewof protocolChoice = Inputs.select(
  ["CoAP over UDP (15%)", "MQTT-SN (10%)", "MQTT over TCP/IP (30%)"],
  { value: "MQTT over TCP/IP (30%)", label: "Protocol overhead" }
)

{
  const overheadMap = {
    "CoAP over UDP (15%)": 1.15,
    "MQTT-SN (10%)": 1.10,
    "MQTT over TCP/IP (30%)": 1.30
  };
  const overhead = overheadMap[protocolChoice] || 1.30;
  const actualData = monthlyDataMB * overhead;
  const months = deploymentYears * 12;

  const providers = [
    {
      name: "1NCE",
      color: "#16A085",
      compute: () => {
        const perDevice = 10;
        const totalData = actualData * months;
        const withinLimit = totalData <= 500;
        return {
          monthly: perDevice / (10 * 12),
          total: perDevice,
          fleet: perDevice * fleetSize,
          note: withinLimit
            ? `${totalData.toFixed(1)} MB of 500 MB used`
            : `OVER LIMIT: ${totalData.toFixed(1)} MB > 500 MB`
        };
      }
    },
    {
      name: "Hologram",
      color: "#3498DB",
      compute: () => {
        const monthlyBase = 0.60;
        const dataRate = 0.40;
        const monthlyCost = monthlyBase + actualData * dataRate;
        const total = monthlyCost * months;
        return {
          monthly: monthlyCost,
          total: total,
          fleet: total * fleetSize,
          note: `$${monthlyBase}/mo base + $${dataRate}/MB data`
        };
      }
    },
    {
      name: "Twilio",
      color: "#9B59B6",
      compute: () => {
        const monthlyBase = 2.00;
        const dataRate = 0.10;
        const monthlyCost = monthlyBase + actualData * dataRate;
        const total = monthlyCost * months;
        return {
          monthly: monthlyCost,
          total: total,
          fleet: total * fleetSize,
          note: `$${monthlyBase}/mo base + $${dataRate}/MB data`
        };
      }
    },
    {
      name: "Particle",
      color: "#E67E22",
      compute: () => {
        const monthlyCost = 2.99;
        const total = monthlyCost * months;
        return {
          monthly: monthlyCost,
          total: total,
          fleet: total * fleetSize,
          note: "3 MB included per month"
        };
      }
    }
  ];

  const results = providers.map(p => ({ ...p, ...p.compute() }));
  const cheapest = results.reduce((a, b) => a.fleet < b.fleet ? a : b);
  const maxFleet = Math.max(...results.map(r => r.fleet));

  const formatCurrency = (v) => {
    if (v >= 1000000) return `$${(v / 1000000).toFixed(2)}M`;
    if (v >= 1000) return `$${(v / 1000).toFixed(0)}K`;
    return `$${v.toFixed(2)}`;
  };

  const barMaxW = 380;

  return html`<div style="font-family: Arial, sans-serif; padding: 12px 0;">
    <div style="font-size: 13px; color: #7F8C8D; margin-bottom: 14px;">
      Fleet: <strong>${fleetSize.toLocaleString()}</strong> devices |
      Data: <strong>${actualData.toFixed(2)} MB/mo</strong> (with ${protocolChoice}) |
      Duration: <strong>${deploymentYears} years</strong>
    </div>
    <div style="font-size: 13px; font-weight: 600; color: #2C3E50; margin-bottom: 10px;">Fleet TCO (${deploymentYears}-year):</div>
    ${results.map(r => {
      const w = maxFleet > 0 ? Math.max(4, (r.fleet / maxFleet) * barMaxW) : 4;
      const isCheapest = r.name === cheapest.name;
      return html`<div style="display: flex; align-items: center; margin-bottom: 10px;">
        <div style="width: 80px; font-size: 13px; font-weight: 600; color: #2C3E50; text-align: right; padding-right: 10px;">${r.name}</div>
        <div style="width: ${barMaxW}px; background: #ecf0f1; border-radius: 4px; height: 30px; position: relative;">
          <div style="width: ${w}px; height: 100%; background: ${r.color}; border-radius: 4px; transition: width 0.4s; opacity: ${isCheapest ? 1 : 0.6};"></div>
        </div>
        <div style="padding-left: 10px; min-width: 140px;">
          <div style="font-size: 14px; font-weight: 700; color: ${r.color};">${formatCurrency(r.fleet)}</div>
          <div style="font-size: 11px; color: #7F8C8D;">${formatCurrency(r.monthly)}/mo/device</div>
        </div>
      </div>`;
    })}
    <div style="margin-top: 12px; padding: 10px; background: #f0faf7; border-radius: 6px; border-left: 4px solid ${cheapest.color};">
      <div style="font-size: 13px; font-weight: 600; color: #2C3E50;">
        Best value: <span style="color: ${cheapest.color};">${cheapest.name}</span> at ${formatCurrency(cheapest.fleet)} total
      </div>
      <div style="font-size: 12px; color: #7F8C8D; margin-top: 4px;">
        ${cheapest.note} |
        Savings vs most expensive: ${formatCurrency(maxFleet - cheapest.fleet)}
        (${((1 - cheapest.fleet / maxFleet) * 100).toFixed(0)}% less)
      </div>
    </div>
  </div>`;
}

Cost Optimization Strategies

• Right-size Data Plan: Calculate actual data usage (payload × overhead × frequency × 30 days)
• Flat-rate for Predictable Loads: 1NCE $10/10yr unbeatable for <500 MB (smart meters, env sensors)
• Pay-as-you-go for Variable Loads: Hologram/Soracom better if monthly data varies 10x
• Optimize Protocol Overhead:
  • MQTT over TCP/IP: 30% overhead
  • CoAP over UDP: 15% overhead
  • MQTT-SN: 10% overhead
• Compression: gzip can reduce sensor data by 60-80%
• Batch Transmissions: Send 10 readings at once instead of 10x separate (reduces overhead)
• Monitor Usage: Most carriers offer APIs to track per-device data consumption
• Regional Considerations: Some carriers cheaper in specific regions (check roaming fees)

26.7 Knowledge Check

Question: PSM Configuration and Battery Life Optimization

A utility company is deploying 50,000 smart water meters. Each meter:

• Sends 1 reading per day (50 bytes)
• Installed in basements (deep indoor coverage needed)
• Must operate for 15+ years on 2x AA batteries (5000 mAh total)
• Using NB-IoT with SIM7020 module

Without power-saving features, the meter battery lasts only 14 days. You need to configure PSM (Power Save Mode) to achieve 15+ year battery life.

What PSM configuration would achieve this goal, and how does it work?

1. Enable eDRX with 81.92-second wake cycle - sufficient for daily readings
2. Configure PSM with TAU=24 hours, Active Time=6 seconds
3. Use LTE-M instead because it has better power efficiency
4. Reduce reading frequency to once per week to save power

Click to reveal answer

Answer: B) Configure PSM with TAU=24 hours, Active Time=6 seconds

Why PSM is Required:

Without PSM, the module stays in Idle mode (connected, listening for pages):

• Idle current: ~15 mA
• Daily consumption: 15 mA × 24 hours = 360 mAh/day
• Battery life: 5000 mAh / 360 mAh/day = 13.9 days

PSM Solution:

PSM puts the module into deep sleep between transmissions:

• PSM sleep current: ~10 µA (0.01 mA) - 1,500x reduction!
• Only wakes briefly for transmission

Configuration:

// Configure PSM parameters
sendAT("AT+CPSMS=1,,,\"00111000\",\"00000011\"");

// TAU (T3412): "00111000"
// Bits 5-7 (001): Time unit = 1 hour
// Bits 0-4 (11000): Value = 24
// TAU = 24 × 1 hour = 24 hours

// Active Time (T3324): "00000011"
// Bits 5-7 (000): Time unit = 2 seconds
// Bits 0-4 (00011): Value = 3
// Active = 3 × 2 seconds = 6 seconds

Power Budget with PSM:

• TX energy: 0.183 mAh/day (39.7%)
• RX energy: 0.017 mAh/day (3.7%)
• Connection: 0.021 mAh/day (4.6%)
• PSM sleep: 0.240 mAh/day (52.1%)
• Total: 0.461 mAh/day

Battery Life: 5000 mAh / 0.461 mAh/day = 10,847 days = 29.7 years

Why other options are incorrect:

• Option A (eDRX): eDRX current ~1.5 mA, battery life only ~139 days
• Option C (LTE-M): LTE-M PSM is 15 µA (slightly worse than NB-IoT’s 10 µA)
• Option D (Weekly): Still requires PSM; weekly readings insufficient for leak detection

Quiz: Power and Cost Optimization

Common Mistake: Configuring PSM Without Understanding Downlink Trade-offs

The Error: Developers enable PSM with aggressive timers (T3412=24h, T3324=5s) on ALL devices to maximize battery life, then discover firmware updates and configuration changes become impossible to deliver.

Real-World Example: A utility company deployed 10,000 NB-IoT water meters with T3412=24 hours and T3324=10 seconds. Six months later, they needed to push a critical firmware update to fix a billing bug. Result:

• Meters only reachable for 10 seconds every 24 hours
• Update window missed by 99.99% of devices
• Required 30+ days for full fleet update (vs 2-3 days with eDRX)
• Emergency fix required physical truck rolls to reset 3,000 meters

Why It Happens: PSM maximizes battery life (10+ years) but makes devices completely unreachable except during brief active windows. Developers optimize for battery without considering operational needs.

The Numbers:

Configuration	Battery Life	Downlink Window	Update Time (10K devices)
PSM only (T3412=24h)	15 years	10s/24h (0.01%)	30-90 days (probabilistic)
eDRX only (cycle=81.92s)	5-7 years	2.56s/82s (3.1%)	2-4 hours (scheduled paging)
PSM + eDRX hybrid	10-12 years	2.56s window every 20min	1-2 days (acceptable)
Always connected	3-6 months	100%	2-3 hours

Correct Approach: Configure power modes based on device lifecycle needs, not just battery optimization.

Device classification:

1. Uplink-only sensors (no remote management)

// Meters, env sensors - max battery, no updates needed
AT+CPSMS=1,,,00111000,00000010  // TAU=24h (001=1h, 11000=24), Active=4s (000=2s, 00010=2)
AT+CEDRXS=0                       // Disable eDRX
// Battery: 15+ years, Update capability: None (firmware burnt during manufacturing)

2. Managed fleet (occasional updates)

// Smart meters, asset trackers - balance battery and updates
AT+CPSMS=1,,,00100110,00000110  // TAU=6h (001=1h, 00110=6), Active=12s (000=2s, 00110=6)
AT+CEDRXS=1,4,0101              // eDRX: wake every 81.92s during active window
// Battery: 10-12 years, Update window: 12s every 6h (4x daily opportunities)

3. Mission-critical devices (frequent commands)

// Industrial controllers, medical devices
AT+CPSMS=1,,,00100001,00001111  // TAU=1h (001=1h, 00001=1), Active=30s (000=2s, 01111=15)
AT+CEDRXS=1,4,0010              // eDRX: wake every 20.48s
// Battery: 5-7 years, Update window: 30s hourly (24x daily opportunities)

Firmware Update Strategy:

Option A: Aggressive PSM + Scheduled Maintenance Windows

• Disable PSM temporarily for maintenance: AT+CPSMS=0
• Push updates during 4-hour window
• Re-enable PSM: AT+CPSMS=1
• Requires advance planning but preserves battery life

Option B: PSM + eDRX Hybrid (Recommended)

• Devices wake every 10-20 minutes in eDRX mode
• Update server pages device during eDRX paging window
• Device receives update notification, downloads firmware
• Returns to deep PSM after update
• Update completes in 24-48 hours without manual intervention

Option C: Context-Aware PSM

// Short TAU during deployment/testing, long TAU in production
if (deployment_phase) {
    configureActiveMode(TAU_1h, Active_30s);  // Easy updates
} else {
    configureDeepSleep(TAU_24h, Active_10s);  // Max battery
}

Lesson: PSM configuration is a design decision, not just a power optimization. Always document the update strategy before finalizing timer values. For production fleets, hybrid PSM+eDRX provides 80% of battery gains with 10× better manageability.

Try It: PSM Timer Encoder/Decoder

Decode or build PSM AT command binary timer values. Select a target TAU (sleep duration) and Active Time to see the binary encoding, or explore how the 3-bit unit + 5-bit value system works.

viewof tauUnit = Inputs.select(
  [
    { label: "000 = 10 minutes", value: 0 },
    { label: "001 = 1 hour", value: 1 },
    { label: "010 = 10 hours", value: 2 },
    { label: "011 = 2 seconds", value: 3 },
    { label: "100 = 30 seconds", value: 4 },
    { label: "101 = 1 minute", value: 5 }
  ],
  { value: 1, label: "TAU unit (bits 7-5)", format: d => d.label }
)

viewof tauValue = Inputs.range([0, 31], {
  value: 4,
  step: 1,
  label: "TAU multiplier (bits 4-0, 0-31)"
})

viewof activeUnit = Inputs.select(
  [
    { label: "000 = 2 seconds", value: 0 },
    { label: "001 = 1 minute", value: 1 },
    { label: "010 = 6 minutes (decihour)", value: 2 }
  ],
  { value: 0, label: "Active Time unit (bits 7-5)", format: d => d.label }
)

viewof activeValue = Inputs.range([0, 31], {
  value: 15,
  step: 1,
  label: "Active Time multiplier (bits 4-0, 0-31)"
})

{
  const tauUnitSeconds = [600, 3600, 36000, 2, 30, 60];
  const tauUnitLabels = ["10 min", "1 hour", "10 hours", "2 sec", "30 sec", "1 min"];
  const activeUnitSeconds = [2, 60, 360];
  const activeUnitLabels = ["2 sec", "1 min", "6 min"];

  const tauUnitIdx = tauUnit.value;
  const activeUnitIdx = activeUnit.value;

  const tauSeconds = tauUnitSeconds[tauUnitIdx] * tauValue;
  const activeSeconds = activeUnitSeconds[activeUnitIdx] * activeValue;

  const toBin3 = (n) => n.toString(2).padStart(3, '0');
  const toBin5 = (n) => n.toString(2).padStart(5, '0');

  const tauBinary = toBin3(tauUnitIdx) + toBin5(tauValue);
  const activeBinary = toBin3(activeUnitIdx) + toBin5(activeValue);

  const formatDuration = (s) => {
    if (s < 60) return `${s} seconds`;
    if (s < 3600) return `${(s / 60).toFixed(1)} minutes`;
    if (s < 86400) return `${(s / 3600).toFixed(1)} hours`;
    return `${(s / 86400).toFixed(1)} days`;
  };

  const bitBox = (bit, idx, isUnit, color) => {
    const bg = isUnit ? color : "#ecf0f1";
    const fg = isUnit ? "#ffffff" : "#2C3E50";
    return html`<span style="display: inline-block; width: 28px; height: 28px; line-height: 28px; text-align: center; font-family: monospace; font-size: 16px; font-weight: 700; background: ${bg}; color: ${fg}; border: 1px solid ${isUnit ? color : '#bdc3c7'}; border-radius: 3px; margin: 1px;">${bit}</span>`;
  };

  return html`<div style="font-family: Arial, sans-serif; padding: 12px 0;">
    <div style="display: flex; gap: 32px; flex-wrap: wrap; margin-bottom: 16px;">
      <div style="flex: 1; min-width: 280px;">
        <div style="font-size: 14px; font-weight: 700; color: #2C3E50; margin-bottom: 8px;">TAU Timer (T3412)</div>
        <div style="margin-bottom: 6px;">
          ${Array.from(tauBinary).map((b, i) => bitBox(b, i, i < 3, "#3498DB"))}
        </div>
        <div style="font-size: 12px; color: #7F8C8D; margin-bottom: 4px;">
          <span style="color: #3498DB; font-weight: 600;">Unit: ${toBin3(tauUnitIdx)}</span> (${tauUnitLabels[tauUnitIdx]}) |
          Value: ${toBin5(tauValue)} (${tauValue})
        </div>
        <div style="font-size: 16px; font-weight: 700; color: #3498DB;">
          = ${tauValue} x ${tauUnitLabels[tauUnitIdx]} = ${formatDuration(tauSeconds)}
        </div>
        <div style="font-size: 12px; font-family: monospace; color: #2C3E50; background: #f8f9fa; padding: 6px 10px; border-radius: 4px; margin-top: 6px;">
          "${tauBinary}"
        </div>
      </div>
      <div style="flex: 1; min-width: 280px;">
        <div style="font-size: 14px; font-weight: 700; color: #2C3E50; margin-bottom: 8px;">Active Time (T3324)</div>
        <div style="margin-bottom: 6px;">
          ${Array.from(activeBinary).map((b, i) => bitBox(b, i, i < 3, "#E67E22"))}
        </div>
        <div style="font-size: 12px; color: #7F8C8D; margin-bottom: 4px;">
          <span style="color: #E67E22; font-weight: 600;">Unit: ${toBin3(activeUnitIdx)}</span> (${activeUnitLabels[activeUnitIdx]}) |
          Value: ${toBin5(activeValue)} (${activeValue})
        </div>
        <div style="font-size: 16px; font-weight: 700; color: #E67E22;">
          = ${activeValue} x ${activeUnitLabels[activeUnitIdx]} = ${formatDuration(activeSeconds)}
        </div>
        <div style="font-size: 12px; font-family: monospace; color: #2C3E50; background: #f8f9fa; padding: 6px 10px; border-radius: 4px; margin-top: 6px;">
          "${activeBinary}"
        </div>
      </div>
    </div>
    <div style="background: #f8f9fa; border-radius: 6px; padding: 12px; border-left: 4px solid #2C3E50; margin-top: 8px;">
      <div style="font-size: 13px; font-weight: 700; color: #2C3E50; margin-bottom: 4px;">Generated AT Command:</div>
      <code style="font-size: 14px; color: #16A085; font-weight: 600;">AT+CPSMS=1,,,"${tauBinary}","${activeBinary}"</code>
      <div style="font-size: 12px; color: #7F8C8D; margin-top: 6px;">
        Device sleeps for <strong>${formatDuration(tauSeconds)}</strong>, then wakes and stays reachable for <strong>${formatDuration(activeSeconds)}</strong>.
        Reachability: ${activeSeconds > 0 && tauSeconds > 0 ? ((activeSeconds / (tauSeconds + activeSeconds)) * 100).toFixed(3) : 0}% of time.
      </div>
    </div>
  </div>`;
}

Match: Power Mode Characteristics

Order: Steps to Calculate Cellular IoT Battery Life

🏷️ Label the Diagram

💻 Code Challenge

26.8 Summary

This chapter covered cellular IoT power and cost optimization:

• PSM (Power Save Mode): Reduces idle current from 15 mA to 10 µA (1,500x reduction), enabling 10+ year battery life with proper configuration
• eDRX: Intermediate power savings (1.5 mA) for applications requiring more frequent downlink reachability
• AT Command Configuration: Use AT+CPSMS=1,,,<TAU>,<Active> with binary-encoded timer values
• Battery Life Calculation: Factor TX/RX/overhead/sleep modes; PSM makes transmission energy dominant instead of idle listening
• Cost Optimization: Flat-rate providers (1NCE) offer 8-36x lower TCO than pay-as-you-go for low-data IoT at scale
• Protocol Overhead: Reduce overhead with CoAP (15%) instead of MQTT (30%); use compression and batch transmissions

26.9 Concept Relationships

PSM/eDRX power optimization connects to: Cellular IoT Overview network architecture (T3412/T3324 timers negotiated with MME), NB-IoT vs LTE-M Comparison technology selection (NB-IoT 10 µA vs LTE-M 15 µA PSM sleep impacts battery life calculations), and Cellular IoT Practical Knowledge AT command configuration. TCO analysis relates to LoRaWAN cost comparison and eSIM deployment multi-carrier strategies.

26.10 See Also

• Cellular IoT Practical Knowledge - AT commands and troubleshooting
• MQTT - Application protocol over cellular
• CoAP - Lightweight protocol for constrained devices
• LoRaWAN Overview - Alternative LPWAN cost comparison

Common Pitfalls

1. Calculating Battery Life from Peak Current Only

Summing peak current × active time to estimate battery life ignores the sleep current × sleep time contribution. For NB-IoT with 1 µA sleep, sleep current dominates total energy for low-duty-cycle applications. Use the energy-per-cycle model: E_cycle = (I_active × t_active) + (I_sleep × t_sleep). For a 1 µA sleep device reporting hourly: E_cycle = (200 mA × 0.1 s) + (1 µA × 3599.9 s) = 0.02 Ah + 0.001 Ah = 0.021 Ah/hour → 476 hours on 10 Ah battery (far less than the 10,000+ hours from sleep-only calculation).

2. Ignoring Operator Pricing Tiers in Cost Models

IoT data plan pricing is highly non-linear. Moving from 1 MB to 5 MB/month per device often costs <50% more, but exceeding plan limits triggers overages at 10–100× the plan rate. For a 1,000-device deployment, a single bad software update that sends 10× normal data for one month could generate $5,000–50,000 in overage charges. Implement device-side data caps (count bytes transmitted, stop non-critical traffic at 80% of monthly plan), monitor usage through carrier API, and set billing alerts.

3. Not Benchmarking Competing Technologies Before Committing

Committing to a cellular LPWAN technology without benchmarking alternatives (LoRaWAN, Sigfox, Wi-Fi HaLow, BLE+gateway) for the specific use case leads to suboptimal cost/performance. For a rural water meter deployment, LoRaWAN with private infrastructure may cost $2/device/year vs $10/device/year for NB-IoT. Compare: per-device hardware cost, per-device connectivity cost, gateway/infrastructure cost, coverage certainty, and management overhead across 3–4 technologies before finalizing.

4. Forgetting to Include Spectrum Costs for Private LTE Deployments

Private LTE-M or NB-IoT deployments require licensed spectrum. CBRS in the US requires priority access licenses (PAL) that can cost $5–50/MHz/MHz-pop, plus General Authorized Access (GAA) tier for best-effort usage. European countries have different national license-exempt spectrum programs. Spectrum licensing costs must be included in the TCO model for private cellular deployments, which are often 2–5× more expensive than leveraging public operator networks for <10,000 devices.

26.11 What’s Next

Continue with practical implementation and troubleshooting:

Next	Chapter	Description
1	Cellular IoT Practical Knowledge	AT commands, troubleshooting, and hands-on module selection exercises
2	MQTT	The most widely-used IoT messaging protocol for cellular connectivity
3	CoAP	Lightweight request-response protocol with lower overhead for constrained devices
4	LoRaWAN Overview	Alternative LPWAN technology for cost comparison with cellular IoT

Cross-Hub Connections

Interactive Learning Resources:

• Simulations Hub - Network topology explorer for cellular architectures
• Videos Hub - Cellular IoT deployment tutorials and case studies
• Quizzes Hub - NB-IoT vs LTE-M comparison assessments
• Knowledge Gaps Hub - Common PSM/eDRX configuration mistakes