43 Sigfox Deployment and Best Practices

In 60 Seconds

Before deploying Sigfox, evaluate use case suitability against message limits (140/day), payload constraints (12 bytes), and coverage availability. This chapter covers pre-deployment coverage verification, total cost of ownership analysis, payload structure design, and device lifecycle planning for multi-year deployments.

43.1 Introduction

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P09.C11.U03

Successful Sigfox deployments require understanding when the technology fits your requirements and how to verify coverage before committing. This chapter covers deployment best practices, cost analysis, and use case suitability assessment.

Learning Objectives

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

Assess whether Sigfox is suitable for specific IoT use cases against payload, message, and coverage criteria
Calculate total cost of ownership and contrast Sigfox against LoRaWAN and NB-IoT alternatives
Conduct pre-deployment coverage verification using field trial methodology
Design payload structures that maximize efficiency within Sigfox’s 12-byte constraint
Architect device lifecycle strategies that account for firmware extensibility and reserved bytes

Key Concepts

Sigfox Coverage Map: Online tool showing Sigfox network coverage by country and region; essential first step when evaluating Sigfox for a new deployment area.
Operator Partners: Regional network operators (SNOs) licensed by Sigfox to operate networks in specific territories; provides coverage guarantees and SLAs.
Device Certification: Sigfox-certified hardware ensuring compliance with protocol specifications; certification required for commercial deployment on Sigfox network.
Backend Platform: Sigfox cloud platform providing device management, message routing, callback configuration, and network statistics for registered devices.
Deployment Geography: Sigfox coverage available in 70+ countries; coverage density varies significantly with urban areas better served than rural regions.
Migration Path: Following Unabiz acquisition, migration from Sigfox to alternative LPWAN (LoRaWAN, NB-IoT) considerations for risk management in new deployments.
Field Testing: Process of verifying Sigfox coverage in target deployment area using test devices and backend reception statistics before committing to technology.

For Beginners: Sigfox Deployment

Deploying Sigfox devices is designed to be simple – no gateway installation needed if you are in a Sigfox coverage area. Devices just transmit and the Sigfox network handles delivery. This chapter covers deployment best practices, including antenna placement, message optimization, and monitoring device health.

Sensor Squad: Planning a Sigfox Deployment!

“Before you deploy me, ask three questions,” Sammy the Sensor advised. “First, does my data fit in 12 bytes? Second, do I need fewer than 140 messages per day? Third, is there Sigfox coverage where I will be installed? If the answer to all three is yes, Sigfox is probably perfect. If any answer is no, look at LoRaWAN or NB-IoT instead.”

“I always remind people about the coverage trap,” Lila the LED warned. “Coverage maps show estimated outdoor coverage, but I might be installed in a basement or inside a metal cabinet. A signal that works perfectly at your desk can fail completely underground. Always do a pilot test – deploy 50 test devices in the actual locations for 30 days and measure the real message success rate before ordering thousands.”

Max the Microcontroller pulled out his calculator. “Cost is where Sigfox really shines for small deployments. For 100 devices over 5 years, Sigfox costs about $1,700 total – no gateways to buy, no servers to run. LoRaWAN would cost $2,000 or more with gateway infrastructure. But watch out at scale! Above 10,000 devices, LoRaWAN’s one-time gateway investment starts beating Sigfox’s recurring subscription fees.”

“My favorite deployment tip is reserved bytes,” Bella the Battery said. “If your payload only needs 10 bytes today, use all 12 anyway and leave 2 bytes reserved for future sensors. That way, when the boss wants to add a door sensor next year, you just start filling in byte 11 – no firmware update needed across thousands of devices. Planning ahead saves hundreds of thousands of dollars!”

43.2 Prerequisites

Before this chapter, ensure you’ve completed:

Sigfox Technology Overview: Core technology and architecture
Sigfox Message Flow: Understanding uplink/downlink constraints

43.3 Sigfox Use Case Suitability Assessment

Before choosing Sigfox, evaluate your application against these criteria:

43.3.1 Decision Framework

Sigfox decision flowchart. Starts with 'Payload ≤12 bytes?' If no, choose LoRaWAN. If yes, check 'Messages ≤140/day?' If no, choose LoRaWAN. If yes, check bidirectional needs: frequent downlinks leads to LoRaWAN. Rare/none checks Sigfox coverage: no coverage leads to NB-IoT/LTE-M. Good coverage asks 'Own infrastructure preferred?' Yes leads to 'Consider carefully' warning, No leads to Sigfox recommended. Ideal use cases: simple sensors, utility metering, asset tracking, leak detection. Avoid for: real-time control, OTA updates, rich data, frequent communication. — Figure 43.1: Sigfox use case decision flowchart

43.3.2 Detailed Use Case Evaluation

***

43.4 Total Cost of Ownership Analysis

43.4.1 5-Year TCO Comparison

Compare Sigfox against LoRaWAN for different deployment sizes:

Deployment Size	Sigfox 5-Year TCO	LoRaWAN 5-Year TCO	Winner
100 devices	$800 hardware + $3,000 subscription = $3,800	$1,500 hardware + $3,000 gateway + $6,000 server = $10,500	Sigfox (3x cheaper)
1,000 devices	$8,000 + $30,000 = $38,000	$15,000 + $15,000 + $30,000 = $60,000	Sigfox (1.6x cheaper)
10,000 devices	$80,000 + $300,000 = $380,000	$150,000 + $50,000 + $90,000 = $290,000	LoRaWAN (1.3x cheaper)

Key insights:

Small deployments (<1,000 devices): Sigfox is more cost-effective due to zero infrastructure investment
Large deployments (>5,000 devices): LoRaWAN becomes cheaper as gateway costs amortize across many devices
Hybrid approach: Use Sigfox for geographically dispersed sensors, LoRaWAN for dense campus deployments

43.4.2 Cost Components Breakdown

Cost structure comparison showing Sigfox subscription-based model (per-device annual fees, zero infrastructure) versus LoRaWAN infrastructure model (gateway CapEx, zero per-device fees), with crossover point where LoRaWAN becomes cheaper at scale. — Figure 43.2: Cost structure comparison between Sigfox and LoRaWAN

43.5 Payload Design Best Practices

43.5.1 Efficient Encoding Strategies

With only 12 bytes available, every bit matters. Here are optimization techniques:

Strategy 1: Scaled Integers Instead of Floats

Temperature: 22.5°C
- Float32: 4 bytes (wasteful)
- int16 × 0.1: 2 bytes (value: 225, decode: 225 × 0.1 = 22.5°C)
- Savings: 50%

GPS Latitude: 51.5074°
- Float64: 8 bytes (overkill)
- int24 × 0.0001: 3 bytes (value: 515074, decode: 51.5074°, ~10m accuracy)
- Savings: 63%

Strategy 2: Bit-Packed Status Flags

Instead of 5 separate bytes for booleans:
- Door open: 1 byte
- Motion detected: 1 byte
- Low battery: 1 byte
- Tamper alert: 1 byte
- Maintenance needed: 1 byte
Total: 5 bytes

Use 1 byte with bit flags:
Byte: 0b00011001 (bit 0: door, bit 3: low battery, bit 4: tamper)
- Bit 0: Door open (1)
- Bit 1: Motion detected (0)
- Bit 2: Unused (0)
- Bit 3: Low battery (1)
- Bit 4: Tamper alert (1)
Total: 1 byte (80% savings!)

Strategy 3: Eliminate Redundant Data

Redundant:
- Device ID: 4 bytes (already in Sigfox frame header!)
- Full timestamp: 4 bytes (server adds receipt timestamp)

Optimized:
- Omit device ID (Sigfox provides it)
- Use delta timestamp: 2 bytes (seconds since last message)
Savings: 4-6 bytes

43.5.2 Interactive: Payload Size Estimator

Show code

viewof plTemp = Inputs.select(["None (0B)", "1B int8 (1°C)", "2B int16 (0.1°C)"], {value: "2B int16 (0.1°C)", label: "Temperature"})
viewof plHumidity = Inputs.select(["None (0B)", "1B uint8 (1%)", "2B uint16 (0.01%)"], {value: "1B uint8 (1%)", label: "Humidity"})
viewof plGPS = Inputs.select(["None (0B)", "6B (lat+lon ~10m)", "8B (lat+lon ~1m)"], {value: "None (0B)", label: "GPS"})
viewof plBattery = Inputs.select(["None (0B)", "1B uint8"], {value: "1B uint8", label: "Battery"})
viewof plFlags = Inputs.select(["None (0B)", "1B (8 flags)", "2B (16 flags)"], {value: "1B (8 flags)", label: "Status Flags"})
viewof plTimestamp = Inputs.select(["None (0B)", "2B relative", "4B absolute"], {value: "None (0B)", label: "Timestamp"})

Show code

{
  function getBytes(s) { const m = s.match(/(\d+)B/); return m ? parseInt(m[1]) : 0; }
  const total = getBytes(plTemp) + getBytes(plHumidity) + getBytes(plGPS) + getBytes(plBattery) + getBytes(plFlags) + getBytes(plTimestamp);
  const remaining = 12 - total;
  const ok = remaining >= 0;
  const color = ok ? (remaining >= 2 ? "#16A085" : "#E67E22") : "#E74C3C";

  return html`<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); color: white; padding: 16px; border-radius: 8px; font-family: Arial, sans-serif; max-width: 400px;">
    <div style="font-size: 15px; font-weight: bold; margin-bottom: 10px;">Payload: ${total}/12 bytes used</div>
    <div style="background: #1a252f; border-radius: 4px; height: 20px; overflow: hidden;">
      <div style="background: ${color}; height: 100%; width: ${Math.min(100, total/12*100)}%; transition: width 0.3s;"></div>
    </div>
    <div style="margin-top: 8px; font-size: 13px; color: ${color}; font-weight: bold;">
      ${ok ? `${remaining} bytes remaining${remaining >= 2 ? " (reserve for future expansion!)" : " (tight -- consider reserved bytes)"}` : `EXCEEDS 12-byte limit by ${-remaining} bytes!`}
    </div>
  </div>`;
}

43.5.3 Example Payload Structure

Environmental Sensor Payload (12 bytes):

Byte	Field	Encoding	Range
0-1	Temperature	int16 × 0.01°C	-327.68 to +327.67°C
2-3	Humidity	uint16 × 0.01%	0-100% with 0.01% resolution
4-5	Pressure	uint16 - 50000 Pa	500-1155 hPa
6	Battery	uint8 × 0.02V	0-5.1V
7	Status flags	uint8 bitfield	8 boolean flags
8-11	Reserved	-	Future sensors

43.6 Firmware Update Considerations

43.6.1 The OTA Challenge

Sigfox’s limited downlink makes over-the-air firmware updates practically impossible:

Calculation:

Firmware size: 64 KB = 65,536 bytes
Sigfox downlink: 8 bytes per message, 4 messages/day max

Messages needed: 65,536 / 8 = 8,192 messages
Daily limit: 4 messages
Time required: 8,192 / 4 = 2,048 days = 5.6 years!

Conclusion: OTA firmware updates via Sigfox are IMPRACTICAL

43.6.2 Alternative Update Methods

Method	Time	Cost (10K devices)	Feasibility
OTA via Sigfox	5.6 years	$0	Impractical
Bluetooth OTA	10 days	$41,500	Feasible
Physical USB	3 months	$125,000	Expensive
Device replacement	6-12 months	$275,000	Very expensive
Pre-planned reserved bytes	0 days	$0	Ideal

43.6.3 Design for Future Extensibility

Best Practice: Include Reserved Bytes from Day 1

Original Payload Design (12 bytes):
Byte 0-1: Container ID
Byte 2-7: GPS coordinates
Byte 8: Battery level
Byte 9-10: Temperature
Byte 11: RESERVED / Status flags  <-- Planned for future!

Status byte bit allocation:
- Bit 0: Door open/closed (planned)
- Bit 1: Motion detected (planned)
- Bit 2: Low battery warning
- Bit 3: GPS fix quality
- Bit 4-7: Reserved for future use

With this design:
- Door sensor hardware can be added later
- Device ALREADY sends status byte
- Cloud ignores bit 0 initially
- After sensor added, device sets bit 0
- Cloud starts processing bit 0
- NO firmware update required!

43.8 Sigfox vs LoRaWAN Architecture Comparison

***

43.9 Real-World Failure: When Coverage Maps Lie

A European utility company deployed 5,000 Sigfox water leak sensors across a city in 2021 based on the operator’s coverage map showing “full outdoor coverage.” After installation:

Outdoor sensors (manhole covers, street-level): 96% message delivery – as expected
Indoor basement sensors (water meters): only 62% message delivery
Underground vault sensors (pipe junctions): 31% message delivery

What went wrong:

Coverage maps show outdoor signal strength at ground level. They do not account for:

Building penetration loss: 10-25 dB through concrete walls, reducing coverage class from 0 to 2
Basement depth: Each underground level adds 15-20 dB attenuation
Metal enclosures: Water meter cabinets add 10-15 dB shielding
Seasonal variation: Wet soil (winter) attenuates more than dry soil (summer)

How they fixed it:

Location	Original Delivery	Fix Applied	Final Delivery
Outdoor	96%	None needed	96%
Indoor basement	62%	External antenna routed to window	89%
Underground vault	31%	Switched 800 sensors to NB-IoT	98%

Lesson: Always pilot 50-100 devices in actual deployment locations for 30+ days before committing to full rollout. Coverage maps are a starting point, not a guarantee.

Worked Example: Sigfox vs LoRaWAN Cost Comparison for 2,000-Device Fleet Tracking Deployment

A logistics company needs to track 2,000 refrigerated trailers across Europe for 5 years. Each trailer reports GPS location, temperature, and door status every 15 minutes.

Payload design:

Field	Encoding	Bytes
Latitude	int24 × 0.0001°	3
Longitude	int24 × 0.0001°	3
Temperature	int8 × 0.5°C	1
Battery voltage	uint8 × 0.02V	1
Status flags (door, motion, low battery)	bitfield	1
Total		9 bytes

9 bytes < 12 bytes (Sigfox uplink limit) ✅

Message frequency:

24 hours / 15 minutes = 96 messages/day 96 < 140 (Sigfox daily limit) ✅

Sigfox 5-year TCO:

Cost Component	Calculation	Amount (EUR)
Hardware (Sigfox module + GPS)	2,000 × €18	36,000
Sigfox subscription	2,000 × €6/year × 5 years	60,000
Installation labor	2,000 × €50	100,000
Total 5-year cost		€196,000
Per-device		€98

LoRaWAN 5-year TCO:

Cost Component	Calculation	Amount (EUR)
Hardware (LoRa module + GPS)	2,000 × €22	44,000
Gateways (50 cities, 3 GW each)	150 × €1,200	180,000
Gateway installation	150 × €800	120,000
LTE backhaul	150 × €25/month × 60 months	225,000
Network server (ChirpStack self-hosted)	€15,000 setup + €8,000/year × 5	55,000
Installation labor (devices)	2,000 × €50	100,000
Total 5-year cost		€724,000
Per-device		€362

Cost comparison:

Sigfox: €196,000 (3.7× cheaper) LoRaWAN: €724,000

Winner: Sigfox for this scenario

Why Sigfox wins here:

Geographically dispersed: Trailers spread across Europe → Sigfox’s operator-managed network provides coverage without deploying infrastructure
Low message frequency: 96 messages/day well within Sigfox’s 140 limit
Small payload: 9 bytes fits comfortably in 12-byte limit
Rare downlinks: GPS configuration updates happen quarterly (4 downlinks/year < Sigfox’s 4/day limit)
5-year horizon: Sigfox subscription cost (€60k total) much lower than LoRaWAN infrastructure (€580k for gateways + backhaul + servers)

When LoRaWAN would win:

If payload was 40 bytes (vehicle diagnostics data): - Sigfox: Cannot support (12-byte limit) - LoRaWAN: Works perfectly (222-byte limit at SF7)

If message frequency was every 1 minute: - Sigfox: 1,440 messages/day exceeds 140 limit → Unusable - LoRaWAN: 1,440 messages/day easily supported

If deployment was confined to 10 company depots: - Sigfox: €196,000 (same) - LoRaWAN: €44,000 (devices) + €24,000 (20 gateways) + €55,000 (server) = €123,000 (cheaper than Sigfox!)

Lesson: Technology selection depends on deployment scale, geography, and message profile. Sigfox wins for dispersed, low-frequency applications. LoRaWAN wins for campus deployments or high-frequency/large-payload needs.

Putting Numbers to It

The TCO crossover analysis uses: $C_{total} = N \times C_{device} + C_{gateway} + N \times C_{sub} \times Y$

Setting LoRaWAN = Sigfox for $N$ devices over 5 years: \[N \times 22 + 150 \times 1,200 + 225,000 = N \times 18 + N \times 6 \times 5\] \[22N + 405,000 = 48N\] \[N = 15,577 \text{ devices}\]

At 2,000 devices (our fleet scenario): - Sigfox: $€196,000$ (wins by $€528K$) - LoRaWAN: $€724,000$

At 20,000 devices (10× scale): - Sigfox: $€1,960,000$ - LoRaWAN: $€1,069,000$ (wins by $€891K$)

The crossover demonstrates how gateway CapEx amortizes: Sigfox’s per-device OpEx dominates at scale.

Decision Framework: Choosing Between Sigfox, LoRaWAN, and NB-IoT for LPWAN Deployments

Criterion	Sigfox	LoRaWAN	NB-IoT	Decision Rule
Coverage availability	Operator-dependent (60 countries)	Self-deploy or TTN	Cellular coverage zones	If Sigfox unavailable → LoRaWAN or NB-IoT
Message frequency	≤140/day uplink	Unlimited (duty cycle limited)	Unlimited	If >140 msg/day → LoRaWAN or NB-IoT
Payload size	12 bytes up, 8 bytes down	51-242 bytes (SF-dependent)	1,600 bytes	If >12 bytes → LoRaWAN or NB-IoT
Bidirectional needs	Rare (4 downlinks/day)	Frequent (Class A/B/C)	Frequent	If frequent downlinks → LoRaWAN Class C or NB-IoT
Deployment scale	<5,000 devices	Any scale	Any scale	Small dispersed → Sigfox; Large campus → LoRaWAN; Cellular zones → NB-IoT
Infrastructure control	None (operator-managed)	Full control	None (carrier-managed)	Need control → LoRaWAN only
5-year cost (1,000 devices)	€40k (subscription)	€70k (self-deployed)	€50k (carrier plan)	Sigfox cheapest for small dispersed
Battery life (1 msg/hour)	10-15 years	8-12 years	5-10 years	Sigfox = LoRaWAN > NB-IoT
Latency	Seconds	Seconds (Class A/B/C)	1-10 seconds	All adequate for non-real-time IoT
Global roaming	Limited (operator agreements)	None (private networks)	Yes (cellular roaming)	NB-IoT best for international assets

Decision tree:

Does your payload exceed 12 bytes?
- YES → Eliminate Sigfox, choose LoRaWAN or NB-IoT
- NO → Continue to step 2
Do you need more than 140 messages/day?
- YES → Eliminate Sigfox, choose LoRaWAN or NB-IoT
- NO → Continue to step 3
Is Sigfox coverage available at ALL deployment locations?
- NO → Choose LoRaWAN (self-deploy) or NB-IoT (if cellular coverage exists)
- YES → Continue to step 4
Are devices geographically dispersed (>10 km² area)?
- YES → Sigfox (no infrastructure cost)
- NO → Calculate TCO:
  - Small campus (<1 km²): LoRaWAN (3-5 gateways cheaper than 5-year Sigfox subscription)
  - Urban cellular coverage: NB-IoT (if carrier offers IoT plan)
Do you need infrastructure control or data privacy?
- YES → LoRaWAN (only option with private network)
- NO → Use cost/coverage decision above

Worked decision example:

Scenario: 5,000 smart parking sensors, 50 km² city, 8-byte payload, 12 messages/day

Payload: 8 bytes ✅ (all three work)
Frequency: 12 msg/day ✅ (all three work)
Sigfox coverage: Available ✅
Geography: Dispersed (50 km²) → Favors Sigfox or NB-IoT

5-year TCO comparison:

Technology	Cost
Sigfox	5,000 × €6/year × 5 = €150,000
LoRaWAN	50 gateways × €1,500 + €80k backhaul + €40k server = €195,000
NB-IoT	5,000 × €4/year × 5 = €100,000

Winner: NB-IoT (€100k) if carrier coverage exists, otherwise Sigfox (€150k)

Common Mistake: Choosing Sigfox Based on “Free First Year” Promotional Pricing

What they did wrong: A startup deployed 10,000 soil moisture sensors for precision agriculture using Sigfox because the operator offered “first year free” promotion. After 12 months, they received a renewal bill for €80,000/year and discovered they were locked into a 3-year minimum contract.

Why this backfired:

Year 1 (promotional):

Sigfox subscription: €0 (free promotional year)
Hardware: 10,000 × €8 (module) = €80,000
Development: €40,000
Total Year 1: €120,000

Years 2-4 (contract obligation):

Sigfox subscription: €8/device/year × 10,000 × 3 years = €240,000
No alternative (vendor lock-in)

4-year total: €360,000

LoRaWAN alternative (calculated post-facto):

Year 1:

Hardware: 10,000 × €10 (module) = €100,000
Gateways: 50 farms × 2 GW/farm × €800 = €80,000
Network server (ChirpStack self-hosted): €12,000
Development: €40,000
Total Year 1: €232,000

Years 2-4:

Gateway LTE backhaul: 100 GW × €20/month × 36 months = €72,000
Server hosting: €6,000/year × 3 = €18,000
Total Years 2-4: €90,000

4-year total: €322,000

The realization: LoRaWAN would have cost €322k vs €360k for Sigfox over 4 years, AND provided: - Full data ownership (no third-party network) - Unlimited messages (not capped at 140/day) - Larger payload support (up to 242 bytes vs 12 bytes) - No vendor lock-in (can switch network servers)

The mistake breakdown:

Focused on Year 1 cost, ignored TCO: Promotional pricing distorted true cost
Didn’t read contract fine print: 3-year minimum commitment at full price from Year 2
No fallback plan: Migrating 10,000 deployed sensors to LoRaWAN would cost €200k (hardware swap + re-deployment labor)
Didn’t calculate break-even: At 10,000-device scale, LoRaWAN CapEx amortizes quickly (break-even at ~18 months)

Correct evaluation approach:

Always calculate 5-year TCO including: - Hardware (modules, gateways, installation) - Subscription fees (Sigfox, cellular) OR infrastructure (LoRaWAN gateways + backhaul) - Operational costs (gateway maintenance, network server) - Exit costs (what if you need to switch technologies?)

Decision matrix:

Deployment Scale	Break-Even Point	Recommendation
<500 devices	Sigfox always cheaper (no infrastructure)	Sigfox or NB-IoT
500-2,000 devices	Depends on geography (campus vs dispersed)	Evaluate TCO case-by-case
2,000-10,000 devices	LoRaWAN cheaper after ~24 months	LoRaWAN (unless ultra-dispersed)
>10,000 devices	LoRaWAN cheaper after ~12 months	LoRaWAN (CapEx amortizes quickly)

Lesson: Promotional pricing is a sales tactic. Always calculate long-term TCO, read contract terms carefully, and consider technology lock-in risks. “Free first year” often means “expensive forever after.”

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

43.10 Summary

In this chapter, you learned about Sigfox deployment best practices:

Use Case Suitability:

Ideal: Simple sensors, utility metering, infrequent asset tracking
Avoid: Real-time control, frequent bidirectional communication, OTA firmware updates

Cost Analysis:

Small deployments (<1,000 devices): Sigfox is more cost-effective
Large deployments (>5,000 devices): LoRaWAN becomes cheaper
Always calculate 5-year TCO including subscriptions

Payload Design:

Use scaled integers instead of floats
Pack multiple booleans into bit flags
Eliminate redundant data (device ID, timestamps)
Include reserved bytes for future expansion

Deployment Verification:

Always verify coverage before committing
Run 30-day field trials with test devices
Plan for firmware updates from the start

Common Pitfalls

1. Deploying Without Verifying Coverage in Target Area

Sigfox coverage maps are approximate. Building interiors, sub-urban environments, and areas at coverage edge may have insufficient signal. Always perform site survey with test devices before committing to deployment at new locations.

2. Not Registering Devices Before Deployment

Sigfox devices must be registered with the backend using Device ID and PAC before they can communicate. Deploying unregistered devices results in messages silently dropped. Always verify backend registration and test message reception before field deployment.

3. Ignoring Sigfox SA Operator Risk for Long-Term Deployments

Sigfox’s 2022 insolvency demonstrated real operator dependency risk. Long-term deployments (5+ years) on Sigfox should include contingency planning for technology migration. Consider this risk explicitly in deployment business cases.

4. Expecting Identical Coverage Indoors and Outdoors

Sigfox’s UNB modulation provides good building penetration compared to other radio technologies, but building penetration still reduces signal by 10–25 dB. Deep indoor locations (basements, metal enclosures) may lack coverage even in areas with good outdoor Sigfox signal.

43.11 What’s Next

Direction	Chapter	Description
Next	Sigfox Hands-On Lab	Interactive ESP32 simulation with Sigfox messaging
Then	Sigfox Assessment	Comprehensive review and quizzes
Alternative	LoRaWAN Overview	Compare with user-deployable LPWAN technology