1108  Sigfox Deployment and Best Practices

1108.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.

NoteLearning Objectives

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

• Evaluate whether Sigfox is suitable for specific use cases
• Calculate total cost of ownership compared to alternatives
• Perform pre-deployment coverage verification
• Design payload structures that fit Sigfox constraints
• Plan for device lifecycle and firmware updates

1108.2 Prerequisites

Before this chapter, ensure you’ve completed:

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

---

1108.3 Sigfox Use Case Suitability Assessment

Before choosing Sigfox, evaluate your application against these criteria:

1108.3.1 Decision Framework

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    START(["Is Sigfox Right<br/>for Your Use Case?"])
    Q1{"Payload size<br/>≤12 bytes?"}
    Q2{"Messages needed<br/>≤140/day?"}
    Q3{"Bidirectional<br/>communication?"}
    Q4{"Sigfox coverage<br/>in region?"}
    Q5{"Own infrastructure<br/>preferred?"}

    SIGFOX_YES["SIGFOX<br/>Recommended"]
    SIGFOX_MAYBE["SIGFOX<br/>Consider carefully"]
    LORAWAN["LoRaWAN<br/>Better choice"]
    NBIOT["NB-IoT/LTE-M<br/>Better choice"]

    IDEAL["Ideal Sigfox Use Cases:<br/>Simple sensors, temp/humidity<br/>Utility metering<br/>Asset tracking low freq<br/>Leak detection<br/>Environmental monitoring"]

    AVOID["Avoid Sigfox For:<br/>Real-time control<br/>Firmware updates OTA<br/>Rich data payloads<br/>Frequent communication<br/>Critical downlinks"]

    START --> Q1
    Q1 -->|"No (>12 bytes)"| LORAWAN
    Q1 -->|"Yes"| Q2
    Q2 -->|"No (>140/day)"| LORAWAN
    Q2 -->|"Yes"| Q3
    Q3 -->|"Frequent downlinks"| LORAWAN
    Q3 -->|"Rare/none"| Q4
    Q4 -->|"No coverage"| NBIOT
    Q4 -->|"Good coverage"| Q5
    Q5 -->|"Yes"| SIGFOX_MAYBE
    Q5 -->|"No"| SIGFOX_YES

    SIGFOX_YES --> IDEAL
    SIGFOX_MAYBE --> AVOID
    LORAWAN --> AVOID

    style START fill:#7F8C8D,color:#fff
    style Q1 fill:#2C3E50,color:#fff
    style Q2 fill:#2C3E50,color:#fff
    style Q3 fill:#2C3E50,color:#fff
    style Q4 fill:#2C3E50,color:#fff
    style Q5 fill:#2C3E50,color:#fff
    style SIGFOX_YES fill:#16A085,color:#fff
    style SIGFOX_MAYBE fill:#E67E22,color:#fff
    style LORAWAN fill:#3498db,color:#fff
    style NBIOT fill:#9b59b6,color:#fff
    style IDEAL fill:#d4efdf,color:#2C3E50
    style AVOID fill:#fadbd8,color:#2C3E50

Figure 1108.1: Sigfox use case decision flowchart

{fig-alt=“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.”}

1108.3.2 Detailed Use Case Evaluation

Question: A smart agriculture company wants to monitor soil moisture in 1000 fields, sending readings every 4 hours (6 messages/day). Each message contains: soil moisture (2 bytes), temperature (2 bytes), battery voltage (2 bytes), field ID (2 bytes), and timestamp (2 bytes) = 10 bytes total. They’re choosing between Sigfox and LoRaWAN. What is the PRIMARY technical limitation if they choose Sigfox?

Explanation: This demonstrates Sigfox message constraints and suitability assessment:

Analyzing the Scenario:

Payload Check:

Required payload:
- Soil moisture: 2 bytes
- Temperature: 2 bytes
- Battery voltage: 2 bytes
- Field ID: 2 bytes
- Timestamp: 2 bytes
Total: 10 bytes

Sigfox uplink limit: 12 bytes

10 bytes < 12 bytes - Payload fits!

Message Frequency Check:

Readings per day: 4 hours per reading
Messages per day: 24 hours / 4 = 6 messages/day

Sigfox uplink limit: 140 messages/day

6 messages/day < 140 messages/day - Well within limit!

Usage Analysis:

Daily quota utilization:
- Used: 6 messages
- Available: 140 messages
- Utilization: 6/140 = 4.3%
- Spare capacity: 134 messages (95.7%)

Conclusion: Massive headroom for alerts or additional readings

Why Option B is CORRECT:

• Payload size: 10 bytes ≤ 12 bytes (fits comfortably)
• Message frequency: 6/day ≤ 140/day (only 4.3% utilization)
• Range: Sigfox rural range 30-50 km (excellent for agriculture)
• Battery life: Infrequent transmission ideal for multi-year deployment
• Cost: $6-10/device/year subscription (economical for 1000 devices)

This is an IDEAL Sigfox use case - all requirements perfectly met!

Why Other Options Are Wrong:

A: 10-byte payload exceeds Sigfox’s 8-byte limit: - Confuses uplink and downlink limits! - Uplink (device → network): 12 bytes - Downlink (network → device): 8 bytes - The scenario uses UPLINK only: 10 bytes < 12 bytes

C: 6 messages/day exceeds Sigfox’s 4 message limit: - Confuses uplink and downlink daily limits! - Uplink (device → network): 140 messages/day - Downlink (network → device): 4 messages/day - The scenario sends 6 UPLINK messages/day: 6 < 140

D: Sigfox cannot reach agricultural fields: - Sigfox has EXCELLENT rural range! 30-50 km - Agricultural fields typically have minimal RF interference - Single Sigfox base station covers ~5,000 km²

---

1108.4 Total Cost of Ownership Analysis

1108.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

1108.4.2 Cost Components Breakdown

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph Sigfox["Sigfox Cost Structure"]
        SF_HW["Device Hardware<br/>$5-15 each"]
        SF_SUB["Annual Subscription<br/>$6-10/device/year"]
        SF_INFRA["Infrastructure<br/>$0 (Operator handles)"]
        SF_MAINT["Maintenance<br/>$0 (Operator handles)"]
    end

    subgraph LoRaWAN["LoRaWAN Cost Structure"]
        LW_HW["Device Hardware<br/>$10-25 each"]
        LW_GW["Gateways<br/>$500-2,000 each"]
        LW_NS["Network Server<br/>$200-1,000/month"]
        LW_BACK["Backhaul<br/>$30-100/gateway/month"]
        LW_MAINT["Maintenance<br/>Staff/contractor costs"]
    end

    SF_TOTAL["Sigfox Total<br/>Predictable OpEx"]
    LW_TOTAL["LoRaWAN Total<br/>Higher CapEx, Lower OpEx"]

    SF_HW --> SF_TOTAL
    SF_SUB --> SF_TOTAL
    SF_INFRA --> SF_TOTAL
    SF_MAINT --> SF_TOTAL

    LW_HW --> LW_TOTAL
    LW_GW --> LW_TOTAL
    LW_NS --> LW_TOTAL
    LW_BACK --> LW_TOTAL
    LW_MAINT --> LW_TOTAL

    style SF_HW fill:#E67E22,color:#fff
    style SF_SUB fill:#E67E22,color:#fff
    style SF_INFRA fill:#16A085,color:#fff
    style SF_MAINT fill:#16A085,color:#fff
    style LW_HW fill:#2C3E50,color:#fff
    style LW_GW fill:#2C3E50,color:#fff
    style LW_NS fill:#2C3E50,color:#fff
    style LW_BACK fill:#2C3E50,color:#fff
    style LW_MAINT fill:#2C3E50,color:#fff

Figure 1108.2: Cost structure comparison between Sigfox and LoRaWAN

{
  const container = document.getElementById('kc-sigfox-deploy-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A city government issues an RFP for 10,000 smart waste bin sensors. Requirements include: reporting fill levels every 6 hours, 7-year battery life minimum, and deployment across urban and suburban areas with verified Sigfox coverage. Which statement BEST describes why Sigfox is an excellent fit?",
      options: [
        {text: "Sigfox's bidirectional communication enables waste trucks to remotely lock bins after collection", correct: false, feedback: "Incorrect. Sigfox's limited downlink (4 messages/day) is inadequate for operational commands like locking bins. However, waste bin monitoring is primarily uplink (sensor - cloud), making this limitation irrelevant for the stated requirements."},
        {text: "Sigfox's 4 messages/day (every 6 hours) uses only 3% of the 140 message quota, and ultra-low power consumption enables 10+ year battery life", correct: true, feedback: "Correct! 4 messages/day = 2.9% of 140 limit. Each transmission: 0.067 mAh. Daily consumption: 0.27 mAh + sleep current. With a 2000 mAh battery: 7,400+ days = 20 years theoretical (12-15 years practical). Fill level data fits easily in 12 bytes. No infrastructure investment needed. This is a textbook Sigfox use case."},
        {text: "Sigfox provides built-in machine learning for predicting optimal collection routes", correct: false, feedback: "Incorrect. Sigfox is a connectivity layer only - it transmits raw data. Route optimization ML must be implemented in the customer's application layer. Sigfox cloud provides data delivery, not analytics."},
        {text: "Sigfox's mesh networking allows bins to relay messages for bins in RF shadow areas", correct: false, feedback: "Incorrect. Sigfox uses star topology, not mesh. Each device communicates directly with base stations. There is no device-to-device relay capability. For RF shadow areas, additional base station coverage or alternative technology would be needed."}
      ],
      difficulty: "easy",
      topic: "sigfox"
    }));
  }
}

---

1108.5 Payload Design Best Practices

1108.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

1108.5.2 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

{
  const container = document.getElementById('kc-sigfox-deploy-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A logistics company tracks 10,000 shipping containers globally. Each container reports GPS location (6 bytes), battery level (1 byte), temperature (2 bytes), and container ID (2 bytes) = 11 bytes total, 4 times per day. After 2 years, they want to add door sensor status (1 byte) to detect unauthorized access. What challenge will they face?",
      options: [
        {text: "Cannot update payload structure (requires device firmware change)", correct: true, feedback: "Correct! Sigfox devices require firmware updates to change payload structure. OTA updates via Sigfox are impractical (64KB firmware / 8 bytes per downlink / 4 downlinks per day = 5.6 years per device!). Physical access or Bluetooth secondary radio needed. Pre-planning with reserved bytes is crucial for future extensibility."},
        {text: "12-byte payload (11+1) exceeds Sigfox limit", correct: false, feedback: "Incorrect. 12 bytes is EXACTLY the limit! 11 + 1 = 12 bytes fits perfectly within Sigfox's uplink payload limit."},
        {text: "Adding sensor increases to 5 messages/day (exceeds limit)", correct: false, feedback: "Incorrect. Door sensor doesn't change message frequency. The door status is additional data in existing messages, not separate messages. Still 4 messages/day."},
        {text: "Door sensor requires bidirectional communication (unsupported)", correct: false, feedback: "Incorrect. Door sensor is unidirectional (sensor to cloud). Read GPIO, include status in uplink. No downlink required for simple status reporting."}
      ],
      difficulty: "hard",
      topic: "sigfox"
    }));
  }
}

---

1108.6 Firmware Update Considerations

1108.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

1108.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

1108.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!

---

1108.7 Deployment Verification Checklist

1108.7.1 Pre-Deployment Protocol

Before committing to Sigfox deployment, complete these verification steps:

1. Coverage Verification
   • Check sigfox.com/coverage for all target locations
   • Deploy 5-10 test devices in actual deployment sites
   • Run 30-day field trial measuring message success rate
   • Accept only if >95% message delivery achieved
   • Identify coverage gaps and plan alternatives
2. Technical Requirements
   • Verify payload fits in 12 bytes with optimization
   • Confirm message frequency ≤140/day (typically ≤40/day recommended)
   • Assess downlink needs (≤4/day for config/alerts only)
   • Calculate power budget for target battery life
   • Plan for firmware updates (Bluetooth secondary radio?)
3. Business Requirements
   • Calculate 5-year TCO including subscriptions
   • Compare with LoRaWAN alternative if >1,000 devices
   • Assess operator dependency risk (Sigfox SA acquisition history)
   • Verify coverage for expansion regions
   • Plan hybrid approach for global deployments
4. Operational Planning
   • Define payload structure with reserved bytes
   • Document encoding/decoding specifications
   • Set up Sigfox cloud callbacks to application
   • Configure alerting for message delivery failures
   • Plan device provisioning and activation workflow

{
  const container = document.getElementById('kc-sigfox-deploy-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A cold chain logistics company deploys Sigfox temperature sensors in refrigerated trucks. Each sensor sends temperature readings every 30 minutes. After 1 year, they want to add real-time alerts when temperature exceeds thresholds (potentially 10-20 alerts per day during equipment failures). What design flaw becomes apparent?",
      options: [
        {text: "Sigfox's 12-byte payload cannot include both temperature value and alert flag", correct: false, feedback: "Incorrect. Temperature (2 bytes) + alert flag (1 byte) + timestamp (2 bytes) = 5 bytes easily fits in the 12-byte limit. Payload size is not the constraint here."},
        {text: "Event-driven alerts (10-20 bursts) plus scheduled readings (48/day) approach the 140 message/day limit, risking quota exhaustion during failures", correct: true, feedback: "Correct! Scheduled messages: 48/day (every 30 min). Alert bursts during failure: 10-20/day. Total: 58-68 messages normally, but failures can spike higher. Multiple trucks with simultaneous failures could push individual sensors over 140 limit. Design fix: Implement message budgeting - reserve 50 messages for alerts, use remaining 90 for scheduled readings. Or switch to LoRaWAN for unlimited messaging."},
        {text: "Sigfox cannot differentiate between regular readings and urgent alerts in the cloud backend", correct: false, feedback: "Incorrect. Sigfox payloads can include message type flags or use different message structures. The backend callback receives all data and can distinguish alerts based on payload content. Message differentiation is a software design choice."},
        {text: "Sigfox's 100 bps data rate causes unacceptable delay for time-critical temperature alerts", correct: false, feedback: "Incorrect. At 100 bps, a 12-byte message takes 6 seconds to transmit. For cold chain alerts, 6-second transmission delay is negligible compared to typical response times. The message quota is the real constraint, not transmission speed."}
      ],
      difficulty: "hard",
      topic: "sigfox"
    }));
  }
}

---

1108.8 Sigfox vs LoRaWAN Architecture Comparison

Question: What is the MOST significant architectural difference between Sigfox and LoRaWAN that impacts operational control?

Option A is the fundamental architectural difference:

Sigfox Architecture (Operator-Only):

Devices → Sigfox Base Stations → Sigfox Backend → Your Application
           ↑                       ↑
      Operator Owned          Operator Owned
      (You have NO control)   (Managed service)

LoRaWAN Architecture (Private Network Option):

Devices → Your Gateways → Your Network Server → Your Application
           ↑                ↑
      You Own & Control   You Own & Control
      (Full flexibility)  (Full flexibility)

Operational Impact:

Scenario 1: Coverage gap discovered

Sigfox: 1. Discover 30% of sensors in building basement have poor connectivity 2. Contact Sigfox operator to request additional base station 3. Operator response: “Business case insufficient, request denied” 4. Result: Accept 30% message loss OR switch to alternative technology 5. Timeline: Months (if operator agrees), never (if denied)

LoRaWAN: 1. Discover 30% of sensors in building basement have poor connectivity 2. Purchase additional gateway ($1,500) 3. Install in building (power + internet backhaul) 4. Configure network server to include new gateway 5. Result: 100% coverage achieved 6. Timeline: 1-2 weeks

Decision Matrix:

Choose Sigfox when: - Want zero infrastructure responsibility - Small scale (<1,000 devices) where OpEx < CapEx - Coverage exists in target area - Acceptable to depend on operator

Choose LoRaWAN when: - Need infrastructure control (coverage optimization) - Large scale (>1,000 devices) where CapEx amortizes - Operator coverage unavailable or unreliable - Require data privacy (no third-party network)

Why Other Options Are Less Fundamental:

• B - Modulation difference: Technical performance detail, not control/ownership
• C - Data rate difference: Application suitability detail, not operational control
• D - Message limit difference: Protocol constraint, not infrastructure control

---

1108.9 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

1108.10 What’s Next

Continue with hands-on experience:

• Next: Sigfox Hands-On Lab - Interactive ESP32 simulation
• Then: Sigfox Assessment - Comprehensive review and quizzes
• Alternative: LoRaWAN Overview - Compare with user-deployable LPWAN