📑 Table of Contents

1. Introduction

2. SIM Types Deep Dive

3. How SIM Choice Shapes Your IoT System Architecture

4. Common Engineering Mistakes (Learned the Hard Way)

5. Reference Decision Framework: Choosing Your SIM Strategy

6. Key Takeaways for IoT Engineers & Architects

7. Future Trends: What's Coming in 2025+

8. Further Reading & Resources

💡 What You'll Learn:

• How to choose between different SIM types for your deployment

• Why your SIM decision impacts power consumption by up to 60%

• SGP.32 (2025-2026) and why it changes everything for long-lifecycle devices

• Real-world failure modes and how to avoid them

• A reference decision framework based on geography, lifecycle, and scale

🎯 Who This Is For:

• IoT Hardware/Firmware Engineers

• IoT Product Managers & Architects

• Systems Engineers designing cellular IoT products

• Technical Decision Makers evaluating connectivity strategies

---

1. Introduction

Why SIM Strategy Is a Core Architectural Decision in IoT Systems

When engineers talk about Cellular IoT, the discussion usually revolves around radio modules, antennas, power optimization, LTE Cat-M vs NB-IoT, MQTT vs HTTP, OTA/FOTA, and cloud architecture.

Yet there's one foundational layer that's consistently treated as a procurement afterthought rather than the critical architectural component it truly is:

The SIM.

In reality, SIM selection in Cellular IoT represents a first-order architectural decision that cascades through every layer of your system. It directly influences:

• ✅ Connectivity reliability and geographic coverage

• ✅ Scalability across markets and regulatory boundaries

• ✅ Roaming behavior and network selection logic

• ✅ Security posture and authentication mechanisms

• ✅ OTA/FOTA deployment strategies

• ✅ Regulatory compliance pathways

• ✅ Total cost of ownership over 5-15 year device lifecycles and many more.

This article provides a 360-degree, engineering-level overview of the different SIM types used in Cellular IoT, their importance, use cases, and the practical considerations engineers must account for.

📡 Understanding SIMs in the Cellular IoT Context

In consumer mobile devices, a SIM card is largely invisible to the end user. It's a credential that "just works." In IoT deployments, a SIM transforms into something far more critical. It becomes:

1. A Network Policy Enforcement Point: The SIM determines which networks your device can attach to, what quality of service it receives, and how traffic is routed through operator infrastructure.

2. A Security Boundary: Authentication keys (Ki), encryption algorithms, and secure elements all reside in the SIM. It's your first line of defense against unauthorized network access.

3. A Scalability Constraint or Enabler: Choosing the wrong SIM can force you to maintain dozens of SKUs for different markets. The right choice enables single-SKU global deployments.

4. A Long-Term Operational Dependency: IoT devices often remain deployed for 5-15 years. They must survive:

• Network technology transitions (3G sunset → 4G → 5G)

• Operator mergers and infrastructure changes

• Evolving regulatory requirements

• Geographic expansion into new markets

This fundamentally changes how SIMs must be evaluated compared to consumer use cases.

---

SIM Types Deep Dive

🏢 SIM Type #1: Operator-Grade SIMs (MNO SIMs)

Definition

SIMs issued directly by “Mobile Network Operators (MNOs)” that provide native access to a single operator's network infrastructure.

Real-World Examples

• Global: Vodafone, Orange, AT&T, T-Mobile, Telefonica, Telia

• Regional: Dialog, Mobitel, MTN, Airtel, China Mobile

Key Characteristics

✅ Direct attachment to a single MNO network
✅ Strong QoS guarantees and SLA commitments
✅ Full access to operator-specific services (dedicated APNs, SMSC, USSD)
✅ Deep regulatory compliance for local markets
❌ Limited or no international roaming support
❌ Requires multiple SIM SKUs for multi-country deployments

Optimal Use Cases

• Utility meters (electricity, water, gas) with fixed locations

• Government and public sector deployments with strict data sovereignty requirements

• Industrial equipment that never moves across borders

• Domestic IoT products with no roaming requirements

Engineering Considerations

⚠️ APN Configuration: Operator-specific and often requires manual provisioning
⚠️ Coverage Changes: If the operator's network degrades or coverage gaps emerge, 
   SIM replacement may be the only option
⚠️ OTA Timing: Plan firmware rollouts around operator maintenance windows
⚠️ Scaling Friction: International expansion requires new SIM procurement, 
   logistics, and SKU management per market

Bottom Line: MNO SIMs provide maximum stability and predictability for fixed, domestic deployments but severely limit flexibility.

---

🌍 SIM Type #2: IoT MVNO SIMs (Multi-Network Connectivity)

Definition

SIMs issued by IoT-focused Mobile Virtual Network Operators that operate across multiple underlying MNO networks through roaming agreements.

Real-World Examples

• Soracom (Japan-based, global coverage)

• 1NCE (Germany-based, flat-rate global pricing)

• Hologram (US-based, developer-friendly)

• EMnify (Cloud-native connectivity platform)

• Twilio Super SIM (Integrated with Twilio's communication APIs)

• Tata Communications MOVE (Enterprise-grade global IoT)

• Aeris (Veteran IoT connectivity provider)

Key Characteristics

✅ Multi-network roaming across 600+ operator networks globally
✅ Single SIM SKU for worldwide deployments
✅ Centralized SIM lifecycle management via cloud portals
✅ Optimized for MTC (Machine-Type Communication)
✅ API-first architectures for programmatic control
❌ Network selection complexity (automatic vs manual PLMN steering)
❌ Variable latency based on data breakout location

Optimal Use Cases

• Global IoT products sold across multiple countries

• Asset tracking & logistics (containers, vehicles, pallets)

• Smart agriculture across distributed farms

• Pilot-to-scale deployments where market testing is required

• OTA-heavy devices needing reliable cloud connectivity

Engineering Considerations

// Network selection logic must handle edge cases
typedef enum {
    AUTO_PLMN_SELECT,    // MVNO decides best network
    MANUAL_PLMN_SELECT,  // Device firmware controls
    HYBRID_FAILOVER      // Auto with manual override
} network_selection_mode_t;

// Your firmware must gracefully handle:
- Unstable network transitions (PLMN switching mid-session)
- Shared APNs across countries (no dedicated per-region APNs)
- SMS availability varies (some MVNOs restrict or charge extra)
- Data breakout location affects latency (EU vs US vs Asia)

Engineering Reality Check: MVNO SIMs reduce operational complexity but shift more responsibility to your firmware and backend systems to handle network variability.

---

🏙️ SIM Type #3: Regional/Local M2M SIMs

Definition

SIMs optimized for country-specific or regional IoT deployments, often provided by regional operators or IoT divisions of national MNOs.

Real-World Examples

• Bouygues Telecom IoT (France)

• SFR IoT (France)

• Telefonica Kite (Spain/Latin America)

• Regional M2M offerings from local carriers worldwide

Key Characteristics

✅ Cost-effective for high-volume domestic traffic
✅ Strong local network performance and coverage
✅ Direct operator support for local regulatory compliance
❌ Limited international expansion capability
❌ Risk of vendor lock-in
❌ APN and IP addressing portability challenges

Optimal Use Cases

• Smart city infrastructure (street lighting, parking sensors)

• Local fleet tracking (municipal vehicles, delivery fleets)

• Environmental monitoring networks

• Domestic industrial systems (factory automation, warehouse IoT)

Engineering Considerations

• Plan for migration complexity if you expand internationally

• Evaluate exit strategy: Can you port devices to another provider?

• Understand data sovereignty implications (critical for government projects)

---

🔄 SIM Type #4: Multi-IMSI / Multi-Profile SIMs

Definition

SIMs containing multiple IMSIs (International Mobile Subscriber Identities) that enable dynamic network switching without changing the physical SIM.

Technical Deep Dive

A traditional SIM has one IMSI tied to one operator. Multi-IMSI SIMs contain multiple IMSIs from different operators, allowing the device to:

1. Scan for available networks

2. Select the best signal/QoS option

3. Switch IMSI to attach to that network

This happens at the modem firmware level, often transparent to the application layer.

Optimal Use Cases

• Cross-border logistics (trucks, trains, shipping containers)

• Maritime IoT (vessels moving through international waters)

• Mobile industrial assets (construction equipment, rental fleets)

• Border-area deployments where devices straddle multiple coverage zones

Engineering Considerations

⚠️ Power Consumption: PLMN scanning and re-registration drain battery faster
⚠️ Complex Debugging: Which IMSI is active? Network logs get complicated
⚠️ OTA Reliability: Must tolerate mid-update network switches
⚠️ Firmware Stability: Avoid aggressive re-registration loops that waste power

Power Impact Example: Continuous PLMN scanning can increase baseline current draw by 15-30% compared to static network attachment.

---

🆕 SIM Type #5: eSIM/eUICC for IoT (The Game Changer)

Understanding the Terminology

eSIM = Physical form factor (MFF2 chip soldered to PCB)
eUICC = Software capability (remote SIM provisioning)
SGP.02 = Legacy M2M eSIM standard (2014)
SGP.22 = Consumer eSIM standard (2016, used in iPhones)
SGP.32 = New IoT eSIM standard (2023, commercially rolling out 2025-2026)

Key Innovation: Remote SIM Provisioning (RSP)

Traditional SIMs have fixed operator profiles burned in at manufacturing.

eUICC-enabled eSIMs can:

• Download new operator profiles over-the-air

• Switch between operators without physical SIM replacement

• Support multiple profiles that can be enabled/disabled remotely

SGP.32: The Future of IoT Connectivity (2025+)

According to industry analysts, over half of the expected six billion IoT connections by 2030 will rely on eSIM and remote SIM provisioning, with SGP.32 being the enabling standard.

Why SGP.32 Matters for IoT

The Problem with SGP.02 (Old M2M eSIM):

• ❌ Complex SMS-based provisioning

• ❌ Locked to one RSP (Remote SIM Provisioning) platform provider

• ❌ Heavy protocols unsuitable for low-power devices

• ❌ Requires tight integration between donor and recipient operators

SGP.32 Solutions:

• ✅ No RSP platform lock-in: Switch between any certified SM-DP+ servers

• ✅ Lightweight CoAP/DTLS protocols: Perfect for NB-IoT and LTE-M

• ✅ No SMS dependency: Eliminates SMS activation costs and delays

• ✅ Server-driven provisioning: Zero-touch deployment at scale

• ✅ eIM (eSIM IoT Remote Manager): Centralized fleet orchestration

The standard was set to be released in 2024, meaning the market became ready in 2025, and vendors began announcing certifications starting from April 2025.

SGP.32 Architecture Components

eUICC: The secure element chip on the device
IPA (IoT Profile Assistant): Lightweight on-device software
eIM (eSIM IoT Remote Manager): Cloud-based orchestration platform
SM-DP+: Profile server that stores and delivers operator credentials

Optimal Use Cases

• Next-generation automotive (connected cars with 10-15 year lifecycles)

• Smart meters (electricity, water, gas requiring regulatory flexibility.

• Industrial IoT (factory equipment, remote infrastructure)

• Future-proof deployments launching in 2025-2026

Real-World Integration Costs (from industry data):

• Small deployments (<1,000 devices): $25,000-50,000 total

• Medium deployments (1,000-10,000): $50,000-150,000

• Large deployments (>10,000): $150,000+ with economies of scale

Adoption Timeline:

• Certified devices expected to be commercially available end of 2025 at the earliest

• Broader ecosystem maturity: 2026-2027

• Legacy device migration solutions already emerging (NuvoLinQ, Kigen partnerships)

---

🏭 SIM Type #6: Private LTE/5G SIMs

Definition

SIMs are designed for private cellular networks deployed within enterprise facilities (factories, ports, mines, campuses).

Key Characteristics

• Tight coupling with private core networks

• No public internet breakout by default (air-gapped security)

• Security handled internally (enterprise controls all elements)

• Custom OTA infrastructure required

Optimal Use Cases

• Smart factories (Industry 4.0 automation)

• Ports and logistics hubs (yard management, crane automation)

• Mining operations (underground communications)

• Campus networks (universities, military bases)

---

🎯 How SIM Choice Shapes Your IoT System Architecture

Your SIM decision ripples through every layer of your IoT stack. Here's how it constrains or enables critical system behaviors:

1. OTA/FOTA Update Strategy & Reliability

The Problem: Firmware updates are mission-critical, yet they're uniquely vulnerable to connectivity disruptions.

MNO SIM Scenario:

// Predictable, but inflexible
- Schedule updates during known operator maintenance windows (typically 02:00-04:00 local time)
- Single network attachment means no mid-update network switches
- Higher success rate: 95-98% first-attempt completion
- But: Cannot push updates if operator has unannounced outage

MVNO SIM Reality:

// Flexible, but requires robust firmware
void ota_update_handler(void) {
    // MVNO can switch networks mid-download
    // Your firmware MUST handle:

    // 1. Resume capability with chunk verification
    if (update_interrupted()) {
        resume_from_last_verified_chunk();
    }

    // 2. Network transition detection
    if (plmn_changed_during_download()) {
        log_network_switch();
        verify_downloaded_chunks();  // Corruption risk
        continue_or_restart();
    }

    // 3. Aggressive retry with exponential backoff
    retry_count = 0;
    while (retry_count < MAX_RETRIES) {
        if (download_chunk(next_chunk)) break;
        sleep(exp_backoff(retry_count++));
    }
}

Real Failure Mode: MVNO device in a rural area switches from Operator A (strong signal) to Operator B (weak signal) during a 2MB firmware download. Without resume capability, the update fails, device rolls back, wastes 300KB of expensive data, and delays the critical security patch by 24 hours.

eSIM/eUICC Consideration:

• Profile switching during OTA is catastrophic—your firmware loses network attachment

• Solution: Lock profile changes during update window

• SGP.32 allows server-side orchestration to prevent profile changes during critical operations

2. Power Budget & Battery Lifecycle

The numbers that matter (nRF9160 SiP reference, real-world field tested):

Real-World Battery Impact Example:

• Scenario: Asset tracker, 5000 mAh battery, reporting every 15 minutes

MNO SIM:
- Average current: 8 mA (incl. GNSS, transmission, sleep)
- Battery life: 5000 mAh / 8 mA = 625 hours ≈ 26 days

Multi-IMSI SIM (aggressive scanning):
- Average current: 18 mA (PLMN scanning adds 10 mA average)
- Battery life: 5000 mAh / 18 mA = 277 hours ≈ 11.5 days

• Result: Multi-IMSI reduces battery life by 57% in mobile scenarios.

Firmware Optimization Strategies:

// CRITICAL: Limit PLMN scans for Multi-IMSI
#define MAX_SCAN_FREQUENCY_MS  3600000  // Max once per hour

// Cache last successful network for 24 hours
typedef struct {
    uint16_t mcc_mnc;
    uint32_t timestamp;
    int8_t rsrp_when_cached;  // Using RSRP (correct metric for LTE)
    int8_t rsrq_when_cached;  // Added RSRQ for quality check
} network_cache_t;

network_cache_t cached_network;

void intelligent_network_selection(void) {
    int8_t current_rsrp = get_rsrp();  // Use RSRP, not RSSI
    int8_t current_rsrq = get_rsrq();  // Also check signal quality

    // Signal quality thresholds based on 3GPP:
    // RSRP: -120 dBm = edge of LTE coverage (verified by 3GPP TS 36.133)
    // RSRQ: -15 dB = poor quality with high interference
    // 
    // Trigger scan at -105 dBm RSRP (before reaching edge at -120 dBm)
    // This gives enough margin to find better network before losing connection

    bool signal_acceptable = (current_rsrp > -105 && current_rsrq > -15);
    bool cache_valid = (time_now() - cached_network.timestamp < 86400000);
    bool connection_stable = (consecutive_failures < 3);

    if (signal_acceptable && cache_valid && connection_stable) {
        // Stay on current network, don't scan
        return;
    }

    // Additional intelligence: Check for significant degradation
    if (current_rsrp < (cached_network.rsrp_when_cached - 10)) {
        // Signal dropped by 10+ dBm from cached value
        log_event("Signal degradation detected, initiating PLMN scan");
    }

    // Only now perform expensive PLMN scan
    scan_and_select_best_network();
}

3. MQTT Broker Placement & Network Latency

The Problem: Your SIM choice determines where your cellular data exits to the internet (the "breakout point"), which directly impacts application-level latency and reliability.

Understanding Cellular Data Routing: When your IoT device sends data over cellular, it doesn't travel directly to your server. The typical path is:

Device → Cell Tower → MNO Core Network → [BREAKOUT POINT - Where data enters internet] → 
    Internet → Your MQTT Broker

The breakout point is controlled by your SIM provider, and this creates fundamental architectural differences between SIM types.

Solutions & Architectural Strategies:

• Strategy 1: Match Broker Location to SIM Breakout

• Strategy 2: Use MVNO Regional Breakouts (If Available)

• Strategy 3: Distributed MQTT Brokers with Geo-Routing

  • For global deployments with mixed SIM types:

Architecture:
- MQTT brokers in multiple regions (US, EU, Asia)
- DNS-based routing or connection URL per device
- Devices connect to nearest broker based on SIM breakout

Example:
- Devices with MNO SIMs in Germany → mqtt-eu.yourcompany.com (Frankfurt)
- Devices with US MVNO SIMs → mqtt-us.yourcompany.com (Virginia)
- Devices in Asia → mqtt-asia.yourcompany.com (Tokyo)

Backend synchronization:
- Regional brokers forward messages to central processing (Kafka, Kinesis)
- Or use MQTT bridge between regional brokers

• Strategy 4: Latency-Tolerant Protocol Design

  • If you cannot optimize broker placement (e.g., single global backend):

    • Design MQTT topics and QoS for high latency

    • Use MQTT persistent sessions, which reduce reconnection overhead

4. Security Architecture & Data Sovereignty

The Core Issue: Your SIM type determines how your data flows through cellular networks, which directly impacts security posture and regulatory compliance.

Understanding the Data Path - When your IoT device communicates, data doesn't go directly to your server:

Device → Cell Tower → Carrier's Core Network → Breakout Point (Data exits cellular network) → 
    → Internet → Your Server/Cloud

Your SIM choice controls:

• Where data breaks out to the internet (and which country's laws apply)

• Whether data ever touches the public internet

• What encryption is applied at which layers

• Who has potential access to your data stream

4.1 Security Models by SIM Type

a) MNO SIM with Private APN

Data path: Device → MNO core → Your VPN endpoint (never public internet)

Security characteristics:

• ✅ Data never exposed to public internet

• ✅ Isolated network tunnel (similar to enterprise VPN, but carrier-grade)

• ✅ Optional static IP addresses for device whitelisting

• ✅ Highest security: Air-gapped from internet threats

Best for:

• Healthcare devices handling patient data

• Financial services (payment terminals, ATMs)

• Critical infrastructure (utility SCADA systems)

• Any application requiring data never leaves specific network boundaries

Trade-off: Requires an enterprise contract with MNO, higher cost, single-country limitation

b) MVNO SIM with Public APN

Data path: Device → MVNO tunnel → Public internet → Your server

Security characteristics:

• ⚠️ Data traverses public internet after cellular breakout

• ⚠️ Data may route through multiple countries (MVNO's home country, then destination)

• ✅ Requires TLS 1.3 encryption for all communications (non-optional)

• ✅ Application-layer security becomes critical (certificate pinning, mutual TLS)

Best for:

• Non-sensitive telemetry (temperature, motion sensors)

• Applications where end-to-end encryption is implemented

• Global deployments where private APN isn't feasible

Requirements:

// Minimum security baseline for public APN
- TLS 1.3 for all HTTPS/MQTT connections
- Certificate validation (prevent MITM attacks)
- Application-layer payload encryption for sensitive data
- Device authentication (mutual TLS or token-based)

c) eSIM/eUICC Security

Additional layer: Profile provisioning infrastructure

Security characteristics:

• ✅ Secure Element (tamper-resistant hardware) stores credentials

• ✅ Profiles encrypted during over-the-air provisioning

• ⚠️ Profile metadata flows through SM-DP+ servers (third-party infrastructure)

• ⚠️ Dependency on GSMA-certified provisioning ecosystem

Critical consideration: Profile provisioning itself becomes part of your threat model

4.2 Data Sovereignty: Why It Matters

Data sovereignty is the principle that data is subject to the laws of the country where it's physically stored. For IoT, this becomes complex because devices transmit data across borders.

Regulatory Frameworks You Must Consider

a) GDPR (European Union):

• Personal data of EU citizens must stay within EU or "adequate" countries

• GDPR standards must be adhered to when IoT products are manufactured, tested and deployed

• Violations: Fines up to 4% of global revenue or €20 million (whichever is higher)

b) Impact on SIM choice:

• If deploying in EU with health/personal data → MNO with private APN or MVNO with EU-only breakout

• Cannot use MVNO that routes data through non-EU countries without adequate safeguards

c) CCPA (California, USA):

• Similar to GDPR but California-specific

• Affects devices deployed in California collecting consumer data

d) Data Localization Laws (China, Russia, India, Brazil):

• Require certain data types to be stored within national borders

• China prohibits the transfer of certain data outside mainland China

• Permanent roaming restrictions compound this (see Mistake #2 in Common Mistakes section)

e) Healthcare-Specific (HIPAA - USA):

• Private APNs help meet HIPAA compliance standards by ensuring patient data transmission is secure

• Medical IoT devices typically require private APN or equivalent isolation

4.3 Key Security Questions to Ask Your SIM Provider

Before selecting a SIM type, explicitly ask:

1. "Where does data break out to the internet for devices in [your target countries]?"

   • Answer determines data sovereignty compliance

2. "Do you offer private APN, and what are the requirements?"

   • Critical for healthcare, finance, and critical infrastructure

3. "Which countries' laws govern the data while in your network?"

   • MVNO data may be subject to MVNO's home country laws (e.g., US CLOUD Act)

4. "Can you provide a detailed network topology showing the data path?"

   • Needed for compliance audits (GDPR DPIAs, HIPAA risk assessments)

5. "What encryption is applied at the cellular layer, and do I need additional encryption?"

   • Cellular encryption (LTE/5G) protects over-the-air, but not end-to-end

   • Always implement TLS/DTLS for complete security

4.4 Bottom Line

Security isn't just about the device; it's about the entire data path.

• MNO + Private APN = Highest security, isolated network, regulatory compliance

• MVNO + Public APN = Requires robust application-layer security, verify data routing

• eSIM = Additional provisioning infrastructure in your threat model

• Always implement TLS 1.3 regardless of SIM type (cellular encryption ≠ end-to-end encryption)

According to industry research, 59% of IoT connectivity providers identified regulatory compliance as one of their top three business challenges, ranking higher than cost or technical complexity.

Your SIM choice is a compliance decision, not just a connectivity decision.

5. Modem Configuration & Firmware Complexity

Your SIM choice directly impacts the complexity of modem firmware and the testing burden.

5.1 MNO SIM: Simplest Firmware

What your firmware needs to handle:

• ✅ Single network attachment (predictable MCC/MNC)

• ✅ Static APN configuration

• ✅ No PLMN scanning logic required

• ✅ Predictable signal quality and handover behavior

Firmware complexity: Low

Testing burden: Low (test with one operator in one country)

5.2 MVNO SIM: Moderate Firmware Complexity

What your firmware needs to handle:

• ⚠️ Network switching (device may switch between underlying MNOs mid-session)

• ⚠️ APN configuration must be dynamic (cannot hardcode)

• ⚠️ PLMN selection logic (automatic vs manual, depends on MVNO setup)

• ⚠️ Variable signal quality (roaming on different MNOs)

Firmware requirements:

// Must handle network switching gracefully
void handle_network_event(network_event_t event) {
    switch(event) {
        case NETWORK_SWITCHED:
            // Verify APN still correct
            verify_apn_configuration();
            // Re-establish MQTT/CoAP sessions
            reconnect_application_layer();
            break;

        case PLMN_SELECTION_FAILED:
            // Retry with different PLMN
            trigger_manual_plmn_scan();
            break;
    }
}

Firmware complexity: Medium

Testing burden: High (must test across multiple underlying MNOs, in multiple countries)

5.3 Multi-IMSI SIM: High Firmware Complexity

What your firmware needs to handle:

• ❌ Frequent PLMN scanning (power budget impact)

• ❌ Network selection logic (which IMSI/network to prefer?)

• ❌ Debugging complexity (which IMSI is active? Hard to troubleshoot remotely)

Firmware complexity: High

Power impact: 15-30% higher average current (PLMN scanning overhead)

5.4 eSIM: Highest Firmware Complexity

What your firmware needs to handle:

• ❌ Profile management (IPA implementation)

• ❌ Bootstrap profile (initial connectivity before provisioning)

• ❌ Profile switching logic (when to switch, how to verify success)

• ❌ Fallback strategies (if profile download fails)

Firmware complexity: Very High (but complexity is a one-time investment)

Testing burden: Very High (must test provisioning flows, profile switching, edge cases)

5.5 Key Takeaway

Your SIM choice determines:

• How much modem-specific code do you write

• How many edge cases you must handle

• How complex does your field troubleshooting becomes

Trade-off: Higher firmware complexity = more flexibility and future-proofing

6. Regulatory Compliance & Certification Burden

Different SIM types trigger different regulatory requirements. Depending on your SIM strategy, you may need to comply with:

a) Permanent Roaming Restrictions

• Regulations related to permanent roaming continue to be a critical issue for cellular-based IoT

• Countries like China, India, and Brazil ban permanent roaming (typically 90-180 day limits)

• Impact on SIM choice: MVNO SIMs may be illegal for long-term deployments in these markets

b) Data Residency Laws

• Local breakout servers ensure that sensitive information never crosses restricted borders, with 79% of IoT service providers viewing local or regional breakouts as very or extremely important

• Requires understanding where your SIM provider breaks out data

c) Security Certifications

• Healthcare: HIPAA (USA), MDR (EU Medical Device Regulation)

• Automotive: UN R155 (cybersecurity), UN R156 (software updates)

• Finance: PCI DSS

• Industrial: IEC 62443

Each may impose requirements on:

• Network isolation (private APN required)

• Data encryption standards

• Audit trail requirements

Summary: How SIM Choice Cascades Through Architecture

Your SIM decision is architectural because it constrains or enables choices across every layer of your IoT stack.

---

⚠️ Common Engineering Mistakes (Learned the Hard Way)

🚨 Mistake #1: Treating SIM as a Late-Stage Decision

What teams do:

• Complete hardware schematic design

• Finalize PCB layout

• Order first prototype batch

• Then ask: "Which SIM should we use?"

Why this fails:

The SIM decision impacts fundamental hardware choices that cannot be changed without board redesign:

Form Factor Constraints:
- Nano-SIM (4FF): Requires physical SIM socket (~15mm² PCB area)
- MFF2 eSIM: Soldered chip (3mm × 2.3mm, saves PCB space)
- iSIM: Integrated into modem SoC (no additional components)

Modem Chipset Compatibility:
- Not all modems support eUICC/eSIM
- Multi-IMSI requires specific modem firmware support
- Some chipsets lock to specific SIM form factors

Real impact:

• PCB redesign: 6-8 week delay + $15K-30K NRE costs

• Re-certification: Additional FCC/CE/regulatory testing

• Inventory waste: Unusable prototype batch

Correct approach:

Design Phase Checklist (Before Schematic):

□ Define deployment geography (single country vs. multi-region)
□ Estimate device lifecycle (5 years? 10 years? 15 years?)
□ Determine if remote SIM provisioning is needed
□ Select SIM type based on requirements
□ Choose modem chipset that supports selected SIM type
□ Design for appropriate form factor (socket vs. soldered)
□ Plan for future flexibility (e.g., dual-SIM capability)

Engineering lesson: SIM strategy must be decided during the requirements phase, not the procurement phase.

🚨 Mistake #2. Hardcoding APN Parameters

What teams do:

// ❌ BAD: Hardcoded APN
#define APN "iot.operator.com"
#define APN_USER "iotuser"
#define APN_PASS "iotpass123"

Why it fails:

• Operators change APN naming conventions

• MVNO providers switch underlying carrier networks

• Geographic expansion requires different APNs per region

• No way to update without firmware OTA

Consequences: When APN configuration changes, devices cannot connect:

• Firmware OTA required (if devices can still connect via fallback)

• Worst case: Devices become bricks requiring RMA (Return Merchandise Authorization - physical return to manufacturer for repair/replacement) or complete product recall

• Customer support is overwhelmed with connectivity issues

Correct approach:

// ✅ CORRECT: Cloud-configurable with fallback
typedef struct {
    char apn[64];
    char username[32];
    char password[32];
    uint32_t config_version;
} apn_config_t;

apn_config_t config;

void boot_sequence(void) {
    // Try cached config first
    if (load_cached_apn(&config)) {
        if (test_apn_connectivity(&config, TIMEOUT_30SEC)) {
            log_info("Using cached APN config");
            return;  // Success
        }
    }

    // Fallback: Fetch from provisioning server
    // Use Bootstrap APN or fallback connectivity method
    if (fetch_apn_from_cloud(&config)) {
        cache_apn_config(&config);
        log_info("Updated APN from cloud");
    } else {
        log_error("Failed to fetch APN, using last known config");
        // Attempt with stale cache or factory default
    }
}

Design principle: Never hardcode connectivity parameters that can change outside your control.

💡 What is a Bootstrap APN?

A bootstrap APN (also known as a fallback APN or factory default APN) is a pre-configured, minimal connectivity pathway that enables a device to establish a connection to a provisioning server even when the primary APN configuration is unknown, outdated, or invalid.

How it works:

Device boots → Primary APN fails → Switch to bootstrap APN
→ Connect to provisioning server (minimal connectivity)
→ Download correct APN configuration
→ Switch to operational APN → Full connectivity restored

Key characteristics:

• Intentionally hardcoded in firmware (this is one of the few cases where hardcoding is acceptable)

• Minimal functionality - typically only allows HTTPS to a specific provisioning endpoint

• Globally accessible - provided by MVNO/platform provider, works across regions

• Fallback safety net - ensures devices can always self-recover

Example bootstrap flow:

// Bootstrap APN is intentionally hardcoded - it's your safety net
#define BOOTSTRAP_APN "bootstrap.iot-platform.com"

if (!connect_with_cached_apn()) {
    log_warning("Primary APN failed, using bootstrap");

    // Limited connectivity via bootstrap
    connect_to_apn(BOOTSTRAP_APN);

    // Fetch correct APN config from cloud
    fetch_production_apn_config();

    // Disconnect bootstrap, connect with proper APN
    reconnect_with_production_apn();
}

Important: Not all SIM providers offer bootstrap APNs. Verify this capability when selecting MVNO/platform provider.

🚨 Mistake #3: Testing Only in Strong Signal Conditions

Lab testing environment:

• Signal strength: -70 dBm (excellent)

• Stable connection, no handovers

• OTA success rate: 100%

• Battery life: Matches theoretical calculations

Field reality:

• Signal strength: -110 to -120 dBm (poor to very poor)

• Frequent connection drops and cell reselections

• OTA success rate: 60-70%

• Battery life: 40-50% worse than expected

What breaks in weak signal:

• MQTT Keepalive Issues

Lab: 60-second keepalive works perfectly
Field: Device in basement, -115 dBm signal
→ Frequent reconnections due to dropped pings
→ Excessive power consumption from reconnection overhead
→ Battery drains 2x faster than expected

• OTA Update Failures

Lab: 2MB firmware downloads in 45 seconds
Field: Basement deployment, intermittent connectivity
→ Download fails at 95% completion (connection lost)
→ No resume capability, starts from 0%
→ 300KB data wasted, update delayed 24 hours

• Power Consumption Surprise

Lab calculation: 8 mA average → 26 days battery life
Field measurement: 18 mA average → 11.5 days battery life
Root cause: Constant network re-registration, high TX power in weak signal

Correct testing approach:

• Simulate hostile environments

Test Scenarios to Include:

1. Weak Signal Testing:
   - Use Faraday cage with variable attenuators
   - Test at -110 dBm, -115 dBm, -120 dBm
   - Measure power consumption at each level
   - Verify OTA success rates

2. Mobile/Handover Testing:
   - Drive test with device active
   - Force handovers between cells
   - Measure connection stability during movement
   - Verify MQTT reconnection behavior

3. Network Congestion Simulation:
   - Test during peak hours in real network
   - Simulate packet loss (network simulator if available)
   - Verify retry logic and timeouts

4. Edge of Coverage:
   - Deploy test devices at coverage boundaries
   - Monitor over 7+ days
   - Identify failure modes

Firmware hardening for weak signal:

• Adaptive keepalive based on signal quality

void configure_mqtt_for_signal_conditions(void) {
    int8_t rssi = get_rssi();
    uint16_t keepalive_seconds;

    if (rssi > -90) {
        keepalive_seconds = 60;    // Strong signal: 1 minute
    } else if (rssi > -105) {
        keepalive_seconds = 300;   // Weak signal: 5 minutes
    } else {
        keepalive_seconds = 600;   // Very weak: 10 minutes
    }

    mqtt_set_keepalive(keepalive_seconds);
    log_info("MQTT keepalive adjusted to %d sec (RSSI: %d dBm)", 
             keepalive_seconds, rssi);
}

• Robust OTA with resume capability

typedef struct {
    uint32_t total_size;
    uint32_t downloaded_bytes;
    uint16_t last_verified_chunk;
    uint8_t chunk_hashes[MAX_CHUNKS][32];  // SHA-256 per chunk
} ota_state_t;

ota_state_t ota_state;

void ota_download_with_resume(void) {
    // Resume from last verified chunk, not from beginning
    uint16_t start_chunk = ota_state.last_verified_chunk + 1;

    for (uint16_t chunk = start_chunk; chunk < total_chunks; chunk++) {
        uint8_t retry = 0;
        bool chunk_success = false;

        while (retry < MAX_CHUNK_RETRIES && !chunk_success) {
            if (download_chunk(chunk)) {
                if (verify_chunk_hash(chunk)) {
                    ota_state.last_verified_chunk = chunk;
                    save_ota_state();  // Persist progress
                    chunk_success = true;
                }
            }

            if (!chunk_success) {
                retry++;
                sleep_exponential_backoff(retry);
            }
        }

        if (!chunk_success) {
            log_error("Chunk %d failed after retries, aborting", chunk);
            return;  // Resume on next attempt from last_verified_chunk
        }
    }

    // All chunks verified, apply firmware
    apply_firmware_update();
}

Design principle: Design for worst-case field conditions, not best-case lab conditions.

🚨 Mistake #4. Assuming SMS Works for Critical Functions

What teams assume:

• "SMS is part of cellular, so it just works"

• "We'll use SMS for OTA triggers, device commands, and 2FA"

Reality check:

• SMS Reliability Issues:

  • Typical delivery rate: 95-98% in good conditions

  • Can drop to 85-90% in poor signal or network congestion

  • Delivery latency: Ranges from seconds to hours (occasionally never)

  • No guaranteed delivery confirmation

• Cost Surprises:

  • Many IoT MVNOs charge $0.05-0.15 per SMS

  • "Unlimited data" plans often exclude SMS

  • Costs add up quickly for device fleets

• Technical Limitations:

  • NB-IoT deployments on some networks: SMS not supported (data-only)

  • LTE Cat-M: SMS support varies by operator

  • Roaming devices: SMS routing can be unreliable

What breaks:

• SGP.02 eSIM provisioning failure:

Device boots → Attempts SMS-based profile download
→ SMS never arrives (NB-IoT, no SMS support)
→ Device stuck, cannot provision network profile
→ Total deployment failure

• OTA firmware trigger unreliability:

Cloud sends SMS: "Update available, download now"
→ SMS arrives 4 hours later (network congestion)
→ Device already sleeping in PSM
→ Missed update window, device remains on vulnerable firmware version

Correct approach: Use IP-based communication for critical functions

// ❌ NEVER rely on SMS for critical functions
void trigger_ota_update_WRONG(void) {
    send_sms(device_number, "UPDATE_NOW");
    // No delivery guarantee, no ACK, no retry logic
}

// ✅ CORRECT: IP-based with retry and ACK
void trigger_ota_update_CORRECT(void) {
    command_t cmd = {
        .type = CMD_OTA_UPDATE,
        .timestamp = get_timestamp(),
        .firmware_version = "v2.1.3",
        .download_url = "https://cdn.example.com/fw_v2.1.3.bin"
    };

    // CoAP or HTTPS with retries
    for (int retry = 0; retry < MAX_RETRIES; retry++) {
        if (send_command_over_ip(&cmd)) {
            if (wait_for_ack(TIMEOUT_60SEC)) {
                log_info("OTA trigger confirmed");
                return;
            }
        }
        sleep_exponential_backoff(retry);
    }

    log_error("Failed to trigger OTA after retries");
}

// SMS only for optional low-power wake-up hints
void send_wakeup_hint_via_sms(void) {
    // This is just a hint, failure is acceptable
    send_sms(device_number, "DATA_READY");
    // Device will check server on next scheduled wakeup anyway
}

Design principle: SMS is best-effort only. Never depend on it for critical operations.

🚨 Mistake #5: No Fallback Connectivity Strategy

Single SIM = Single Point of Failure

Common scenario:

All 15,000 devices deployed with single MNO SIM
→ Network outage (fiber cut, equipment failure, maintenance)
→ Entire fleet goes offline
→ No visibility, no control, no data collection
→ SLA violations, revenue loss, regulatory issues

Why this is critical for IoT: Unlike consumer devices, where a few hours of downtime is inconvenient, IoT deployments often have:

• Safety implications: Medical devices, industrial monitoring

• Regulatory requirements: Utility meters, environmental sensors

• Financial impact: Asset tracking, fleet management

• Legal liability: Contractual SLAs with customers

Real impact:

• Smart grid deployment: 18-hour outage → Regulatory fine

• Cold chain monitoring: 6-hour outage → spoiled inventory

• Industrial safety: Outage during critical event → Near-miss incident

Production-grade solutions:

• Option A: Dual-SIM with automatic failover

• Option B: Multi-IMSI SIM (automatic network switching at modem level)

  • The modem automatically scans and selects the best available network

  • Transparent to the application layer

  • Trade-off: Higher power consumption due to scanning

• Option C: eSIM with multiple profiles (SGP.32)

  • Multiple operator profiles stored in eUICC

  • Server-initiated profile switching

  • No hardware changes required

Hardware design consideration: If designing new hardware, allocate PCB space for dual-SIM:

Recommended approach:
- Primary SIM: Soldered MFF2 eSIM (main operational profile)
- Backup SIM: Nano-SIM socket (emergency failover)

Benefits:
- Primary SIM: No socket failure risk, remote provisioning
- Backup SIM: Can be changed in field if needed
- Redundancy without complex eUICC orchestration

Design principle: For mission-critical deployments, a single-SIM is an unacceptable risk.

🚨 Mistake #6: Ignoring Regional Regulatory Restrictions

The problem: Different markets have vastly different regulations around permanent roaming, data sovereignty, and SIM usage. What works in one region may be illegal or technically blocked in another.

Common regulatory constraints:

Real-world failure scenario: A company deployed global asset trackers with single-SKU MVNO SIMs worldwide:

• Months 1-3: ✅ Working globally

• Month 4: ⚠️ Devices in certain markets start disconnecting

• Month 5: ❌ 60-70% of devices in restricted markets permanently blocked

• Recovery: Expensive device recalls, emergency local SIM procurement, legal complications

Cost impact:

• Device recalls: $150-250 per device (logistics + labor)

• Local SIM contracts: Emergency pricing (2-3x normal cost)

• Regulatory fines: Varies by market

• Total loss: Can exceed $1M for 10K device deployment

Correct approach:

• Research the regulatory landscape BEFORE deployment:

Market Entry Checklist:

□ Permanent roaming limits and enforcement mechanisms
□ Data sovereignty and localization requirements
□ Sector-specific regulations (medical, automotive, utility)
□ Device registration and type approval processes
□ Import/customs requirements for telecom equipment
□ Local business entity requirements

• SIM strategy adaptation:

Hybrid Approach:

Main markets (unrestricted):
→ Single MVNO SIM for operational efficiency

Markets with roaming restrictions:
→ Local MNO SIM specific to that market
→ Separate SKU (Stock Keeping Unit - unique product variant) 
  with local certifications

Result: 
- 1 primary SKU (80-90% of deployments)
- 2-4 regional SKUs (restricted markets)
- Total compliance, no regulatory risk

SKU Example:
- SKU-001: Global Tracker (MVNO SIM for unrestricted markets)
- SKU-002: Tracker - Market A variant (local MNO SIM)
- SKU-003: Tracker - Market B variant (local MNO SIM)

Engineering lesson: Geography and regulations determine SIM strategy, not just technical preferences.

🚨 Mistake #7: Underestimating SIM Lifecycle Management Complexity

What's overlooked in early design:

Operational complexity at scale:

• Activating/deactivating thousands of SIMs

• Tracking which physical SIM is in which device

• Managing multiple SIM SKUs across regions

• Handling SIM suspensions (payment issues, policy violations)

• Correlating device telemetry with SIM usage patterns

• SIM expiration dates (yes, SIMs can expire after 10-15 years)

Real problem at 50K+ devices - Without proper tooling, teams resort to:

• ❌ Spreadsheet tracking (error-prone, doesn't scale)

• ❌ No real-time visibility into SIM status

• ❌ Manual activation workflows (hours per batch)

• ❌ Cannot identify which SIMs are consuming excessive data

• ❌ Billing surprises due to a lack of usage monitoring

Consequences:

• Devices shipped but SIMs not activated → customer complaints

• SIMs suspended, but devices already deployed → connectivity loss

• Overage charges not detected until the monthly bill → budget overruns

• Cannot quickly disable compromised devices → security incidents

Correct approach: Require a SIM management platform from Day 1

Essential Platform Features:

□ REST API for programmatic SIM lifecycle control
  - Bulk activate/suspend/terminate operations
  - Individual SIM state management
  - Automated workflows based on device status

□ Real-time visibility dashboard
  - Active vs. inactive SIMs
  - Data consumption per SIM (hourly/daily/monthly)
  - Connection history (when/where devices connected)
  - Current network attachment (MCC-MNC, cell ID)

□ Alerting and automation
  - Usage threshold alerts (approaching data cap)
  - Anomaly detection (unusual data patterns)
  - Auto-suspend on overage or inactivity
  - Roaming alerts (unexpected location)

□ Device-to-SIM mapping
  - ICCID → Device ID → Customer correlation
  - Metadata tagging (deployment location, customer, product SKU)
  - Batch operations by tag/group

□ Usage analytics and forecasting
  - Historical trends
  - Predictive analytics for capacity planning
  - Cost allocation per customer/project

Design principle: SIM management platform is not optional; it's infrastructure.

🎓 Summary: The Pattern Behind All These Mistakes

Notice the common thread:

All these mistakes stem from treating connectivity as simple I/O:

• "Just insert a SIM and it connects."

• "Cellular is like WiFi, it just works."

• "We can figure out SIM details later."

Reality: Cellular IoT connectivity is a complex, distributed system:

• Multiple stakeholders (MNOs, MVNOs, regulators)

• Geographic and regulatory constraints

• Physical layer challenges (signal propagation, power)

• Lifecycle management over 5-15 years

• Changing technology landscape (3G sunset, 5G rollout, eSIM evolution)

The engineering mindset shift required:

Wrong: "Connectivity is an implementation detail"
Right: "Connectivity is a first-order architectural decision"

Wrong: "We'll handle SIM issues when they arise"
Right: "We design for SIM failure modes from day one"

Wrong: "Lab testing is sufficient"
Right: "Field testing in worst-case conditions is mandatory"

Wrong: "Choose the cheapest SIM option"
Right: "Choose the SIM that matches our risk/flexibility/cost profile"

Next: Armed with these lessons, let's look at how to make the right SIM decisions from the start.

---

📊 Reference Decision Framework: Choosing Your SIM Strategy

Decision Tree:

If deployment is...

1. Single country, fixed location, government/utility → MNO SIM (maximum stability, regulatory compliance)

2. Global product, 5-10 year lifecycle, moderate scale → IoT MVNO (balance of flexibility and maturity)

3. Global product, 10+ year lifecycle, launching 2025+ → eSIM/eUICC (SGP.32) (future-proof, maximum flexibility)

4. Cross-border mobile assets → Multi-IMSI SIM (automatic network optimization)

5. Private facility, air-gapped security required → Private LTE/5G SIM (complete control, high CapEx)

6. Regional/domestic, cost-sensitive, high volume → Regional M2M SIM (lowest per-unit cost)

---

🔮 Future Trends: What's Coming in 2025+

1. SGP.32 Mass Adoption

Industry experts expect accelerated adoption with billions of devices, driven by:

• Automotive mandates (connected car regulations)

• Smart meter rollouts requiring operator flexibility

• Emergence of eSIM Orchestrator (eSO) platforms as a new service category

2. iSIM (Integrated SIM)

• SIM functionality integrated directly into the device SoC

• Sub-1mm² footprint further reduces BOM cost

• Already shipping in some chipsets (Qualcomm, MediaTek)

3. 5G SA (Standalone) Network Slicing

• SIM becomes the credential for dedicated 5G network slices

• Ultra-low latency, guaranteed QoS for critical IoT

• Initially, for automotive and industrial automation

4. Zero-Touch Mass Provisioning

• Factory ships devices with bootstrap eSIM profiles

• Customer scans QR code, selects operator, and profiles download automatically

• No manual SIM insertion, configuration, or activation

---

🎓 Key Takeaways for IoT Engineers & Architects

1. SIM Strategy Is Architecture, Not Procurement

Treat your SIM decision with the same rigor as:

• Modem chipset selection (Qualcomm vs Nordic vs Sequans vs SIMCOM, etc)

• Wireless protocol choice (LTE-M vs NB-IoT vs LoRaWAN, etc)

• Cloud platform architecture (AWS vs Azure vs GCP, etc)

Why: Changing SIMs post-deployment ranges from expensive (truck rolls) to impossible (devices in inaccessible locations).

2. Start with Geography & Regulations, Then Choose Technology

Decision flowchart:

Are you deploying in China, India, or Brazil?
├─ YES → You MUST use local MNO SIMs (permanent roaming restrictions)
└─ NO → Proceed to next question

Will devices move between countries?
├─ YES → MVNO or Multi-IMSI (avoid multiple SIM SKUs)
└─ NO → MNO or Regional M2M (better cost/support)

Is device lifecycle > 10 years?
├─ YES → eSIM/eUICC (SGP.32 for 2025+ deployments)
└─ NO → Traditional SIM acceptable

Do you need private APN / air-gapped security?
├─ YES → MNO with enterprise contract
└─ NO → MVNO with public APN acceptable

3. Plan for the long term

IoT devices outlive network technologies. Choose SIMs that can adapt to change.

4. eSIM/eUICC is the future

If designing a new product in 2025:

• Chipset supports eUICC (most modern modules do: Quectel BG95-M5, Nordic nRF9161, u-blox SARA-R5)

• The deployment timeline allows waiting for certified solutions

• Device lifecycle is 7+ years

Then: Seriously evaluate SGP.32 eSIM

Benefits over traditional SIM:

• Zero truck rolls for SIM changes (save $150 per incident)

• Switch operators without hardware changes

• Future-proof against operator consolidation, network shutdowns

• Single SKU for global deployment

Cost: Higher upfront (eUICC chip + platform fees), but ROI at 5-10K+ devices due to operational savings.

5. Build Observability Into Connectivity From Day 1

Instrument your firmware:

// Log critical connectivity events
void log_connectivity_event(event_type_t type) {
    connectivity_log_t log = {
        .timestamp = rtc_get_timestamp(),
        .event = type,
        .rssi = get_rssi(),
        .rsrp = get_rsrp(),  // Reference Signal Received Power
        .rsrq = get_rsrq(),  // Reference Signal Received Quality
        .mcc_mnc = get_current_network(),
        .cell_id = get_serving_cell_id(),
        .sim_iccid = get_iccid(),
        .battery_voltage_mv = get_battery_voltage()
    };

    store_log_for_upload(&log);
}

// Call on every important event:
- Network attach
- Network detach/failover
- PLMN scan initiated
- OTA update started/completed/failed
- MQTT connect/disconnect

This data is gold when debugging:

• "Why did 5% of devices in France stop connecting on March 15?" → Answer: Operator X had outage in specific cells, devices failed over to Operator Y correctly

• "Why is battery life 40% worse than expected?" → Answer: Devices in weak signal areas are PLMN scanning every 10 minutes instead of hourly

6. Test the Entire Ecosystem, Not Just Your Device

What to validate:

✅ SIM vendor's network coverage in your target regions

• Don't trust marketing maps

• Deploy 5-10 test devices in actual deployment locations

• Measure RSSI, RSRP, RSRQ continuously for 7+ days

• Test during local peak hours (network congestion)

✅ PSM/eDRX support on target networks

• Different networks support different intervals

• Roaming devices may not get PSM at all

• Validate with your exact MVNO/MNO combination

✅ Roaming restrictions

• Permanent roaming limits (China, India, Brazil)

• Temporary blocks (some operators block roaming during natural disasters)

✅ MVNO breakout locations

• Where does your data exit the cellular network?

• Impacts latency and data sovereignty

✅ Design fallback strategies
No SIM strategy is perfect. Build redundancy into your architecture.

---

📚 Further Reading & Resources Standards & Specifications

Official Standards & Specifications

• GSMA eSIM Specifications:

  • SGP.32 v1.2 - eSIM IoT Technical Specification (June 2024) - The current standard

  • GSMA eSIM Compliance - eSIM Consumer and IoT Specifications

• 3GPP Technical Specifications:

  • TS 23.122 - Network Selection - PLMN selection procedures

  • TS 24.301 - NAS Protocol for EPS - PSM and eDRX mechanisms

  • TS 36.321 - MAC Protocol (LTE) - Power saving mode details

Industry Analysis & Market Research

• SGP.32 Adoption & Forecasts:

  • Trusted Connectivity Alliance - SGP.32 Benefits Whitepaper (September 2024)

  • Webbing Solutions - SGP.32 State of Play (November 2025) - Current certification status

  • ABI Research - eSIM in IoT Forecasts (updated quarterly, subscription required)

  • Kaleido Intelligence - SGP.32 Deployment Roadmap (subscription required)

Vendor Technical Documentation

• eSIM/eUICC Platform Providers:

  • Telenor IoT - SGP.32 Introduction - Commercial rollout Q1 2026

  • Onomondo - SGP.32 Deep Dive (August 2025)

• Cellular Module Manufacturers:

  • Nordic Semiconductor - Low Power Cellular IoT - nRF91 Series power analysis

  • Quectel - eSIM Solutions - BG95-M5, BG77 modules

  • u-blox - Cellular Modules - SARA-R5 series

Power Consumption & Optimization

• Real-World Testing:

  • Nordic DevZone - LTE-M vs NB-IoT Power Field Test (2022, updated 2024)

  • Memfault Interrupt - LTE and IoT - PSM/eDRX deep dive with measurements

  • Onomondo - eDRX and PSM Explained (February 2025)

• Developer Academies:

  • Nordic Developer Academy - Power Saving Techniques (Free course)

  • Connected Development - LTE-M Power Consumption

💬 Join the Discussion

What SIM strategy are you using in your IoT deployments? Have you encountered challenges that aren't covered here?

Share your experiences in the comments below. Let's build collective knowledge about what works (and what doesn't) in real-world Cellular IoT.

---

This article is part of "IoT Under the Hood: 360 Engineering View" — a series exploring the often-overlooked engineering decisions that make or break IoT deployments.

About the Author:

“Vimukthi Wathudura is an IoT and Embedded Systems Engineer with hands-on experience designing, deploying, and operating real-world IoT systems across device, connectivity, and cloud layers.

His work spans embedded firmware development, cellular IoT connectivity (GSM, HSPA, LTE/LTE-M, NB-IoT, 5G NR, M2M)*, **OTA/FOTA architectures, edge and cloud integration, and DevOps-driven IoT infrastructure**. He focuses on long-lifecycle, production-grade systems where architectural decisions directly impact scalability, reliability, and total cost of ownership.\

Through the blog “IoT Under the Hood: 360° Engineering View”*, he shares practical engineering insights that go beyond datasheets and marketing: covering standards, trade-offs, real-world constraints, and lessons learned from the field.”*

Connect: [LinkedIn: http://www.linkedin.com/in/vimukthi-wathudura]