1115  Sigfox Message Flow and Communication

1115.1 Introduction

⏱️ ~12 min | ⭐⭐ Intermediate | 📋 P09.C11.U02

Understanding Sigfox’s message flow is crucial for designing efficient IoT applications. This chapter covers the uplink and downlink communication patterns, power consumption implications, and common pitfalls that developers encounter.

NoteLearning Objectives

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

• Explain the Sigfox uplink and downlink message flow
• Calculate power consumption for different messaging patterns
• Avoid common pitfalls in payload design and message budgeting
• Design applications that work within Sigfox’s constraints

1115.2 Prerequisites

Before this chapter, ensure you’ve completed:

• Sigfox Technology Overview: Core technology and architecture understanding
• LPWAN Fundamentals: Basic LPWAN concepts and trade-offs

---

1115.3 Sigfox Message Flow: Uplink and Downlink

The Sigfox communication protocol follows a carefully orchestrated sequence for uplink (device-to-cloud) and optional downlink (cloud-to-device) messaging:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant D as Device
    participant BS as Base Station
    participant Cloud as Sigfox Cloud
    participant App as Customer App

    Note over D: Prepare 12-byte message
    D->>BS: Transmit (100 bps, ~6 sec)
    Note over D: TX: 40 mA × 6 sec = 0.067 mAh
    BS->>Cloud: Forward + metadata (RSSI, SNR)
    Cloud->>Cloud: Deduplication<br/>Geolocation
    Cloud->>App: HTTPS callback

    Note over D,App: Optional Downlink (4 max/day)

    alt Downlink requested
        D->>BS: Uplink with downlink flag
        BS->>Cloud: Message received
        Cloud->>BS: Downlink data (8 bytes, 600 bps)
        Note over D: Open RX window (20-25 sec)
        Note over D: RX: 50 mA × 25 sec = 1.25 mAh
        BS->>D: Send downlink
        Note over D: Power cost: 17× uplink!
    else No downlink
        Note over D: Return to sleep immediately
        Note over D: Sleep: 1 µA
    end

Figure 1115.1: Sigfox uplink and downlink message flow with power consumption

{fig-alt=“Sigfox message flow sequence diagram illustrating the complete uplink and optional downlink communication protocol with power consumption analysis.”}

1115.3.1 Uplink Characteristics (Device to Cloud)

• Transmission: 6 seconds at 40 mA current
• Energy cost: ~0.067 mAh per message
• Frequency: Up to 140 messages per day
• Payload: 12 bytes maximum
• Reliability: Fire-and-forget (no acknowledgment by default)
• Reception: Multiple base stations receive simultaneously
• Processing: Backend performs deduplication and geolocation

1115.3.2 Downlink Characteristics (Cloud to Device)

• Frequency: Maximum 4 messages per day
• Payload: 8 bytes maximum
• Timing: Only sent immediately after uplink with downlink request flag
• RX window: Device must listen for 20-25 seconds at 40-50 mA
• Energy cost: ~1.2 mAh per downlink (17x more than uplink!)
• Use cases: Configuration updates, firmware triggers, critical alerts
• Limitation: Not suitable for frequent bidirectional communication

1115.3.3 Energy Impact Comparison

Operation	Duration	Current	Energy	Impact
Sleep	23h 59m	1 µA	0.024 mAh/day	Minimal
Uplink only	6 sec	40 mA	0.067 mAh	1x (baseline)
Uplink + Downlink RX	26 sec	45 mA	0.325 mAh	5x more
Daily operations	24 msg/day	Mixed	1.6 mAh/day	7.4 year battery
With 4 downlinks	24 up + 4 down	Mixed	2.9 mAh/day	2.4 year battery

Design recommendation: Use downlink sparingly (monthly configuration updates) rather than frequently (daily commands) to preserve battery life.

{
  const container = document.getElementById('kc-sigfox-msg-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A smart agriculture company deploys 500 Sigfox soil sensors, each sending 6 readings per day. After 6 months, battery life projections show sensors will deplete in 3 years instead of the designed 10 years. Investigation reveals each sensor also requests a downlink after every uplink to check for configuration updates. What is the root cause of the excessive battery drain?",
      options: [
        {text: "The 6 uplink messages per day exceed Sigfox's power-optimized duty cycle", correct: false, feedback: "Incorrect. 6 messages/day is well within Sigfox's 140 message limit and is power-efficient. Each uplink consumes ~0.067 mAh (40 mA × 6 sec). The problem lies elsewhere in the device operation."},
        {text: "Opening the RX window for downlink (20-25 seconds at 50 mA) after every uplink consumes 17× more energy than uplink-only operation", correct: true, feedback: "Correct! The energy math: Uplink only = 0.067 mAh. With downlink RX window = 0.067 + 1.25 mAh = 1.317 mAh per message cycle. That's ~20× more energy per transmission! For 6 messages/day, daily consumption jumps from 0.4 mAh to 7.9 mAh. The fix: Only request downlink once per week or month, not every message."},
        {text: "Sigfox's triple transmission per uplink (3× redundancy) triples energy consumption", correct: false, feedback: "Partially correct about the triple transmission, but this is standard Sigfox behavior and already accounted for in the 6-second TX time specification. Triple transmission is not the cause of unexpected battery drain in this scenario."},
        {text: "The Sigfox module's GPS for geolocation tracking drains additional power", correct: false, feedback: "Incorrect. Sigfox's geolocation doesn't use GPS in the device. Geolocation is computed cloud-side using RSSI from multiple base stations. No GPS power consumption occurs at the device level for Sigfox geolocation."}
      ],
      difficulty: "medium",
      topic: "sigfox"
    }));
  }
}

---

1115.4 Common Pitfalls and Solutions

1115.4.1 Pitfall 1: Sigfox Downlink Limitation

WarningCommon Pitfall: Designing for Bidirectional Communication

The mistake: Designing IoT applications that require frequent bidirectional communication, assuming Sigfox supports downlink messaging comparable to uplink capacity.

Symptoms:

• Configuration updates to devices take days instead of hours
• Remote firmware updates are practically impossible (64KB firmware / 8 bytes per downlink / 4 downlinks per day = 2,048 days!)
• Devices cannot receive acknowledgments for critical alerts
• Actuator control commands fail or arrive too late to be useful

Why it happens: Sigfox is fundamentally asymmetric by design:

• Uplink: 140 messages/day, 12 bytes each (1,680 bytes/day capacity)
• Downlink: Only 4 messages/day, 8 bytes each (32 bytes/day capacity)
• Downlink is 52x more constrained than uplink

This asymmetry exists because downlink requires the device to stay awake in receive mode for 20-25 seconds after requesting a downlink window, consuming 17x more energy than uplink-only operation.

The fix:

1. Design for uplink-only: Treat Sigfox as a sensor reporting network, not a command-and-control system
2. Batch configuration changes: Accumulate settings and send in monthly firmware updates via physical access or alternative channel
3. Use downlink sparingly: Reserve 4 daily downlinks for critical alerts (alarm acknowledgments, emergency shutoff)
4. Hybrid architecture: Pair Sigfox with cellular fallback (NB-IoT) for devices requiring frequent commands

Prevention: Before choosing Sigfox, count your downlink requirements. If devices need more than 4 commands/day or firmware updates more than annually, consider LoRaWAN (unlimited downlinks after each uplink) or NB-IoT (full bidirectional TCP/UDP). Sigfox excels at “sensors that report” but struggles with “actuators that receive commands.”

{
  const container = document.getElementById('kc-sigfox-msg-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A home automation company wants to build a Sigfox-based smart thermostat that receives temperature setpoint commands from a mobile app. Users expect to adjust temperature 5-10 times per day. Why is Sigfox fundamentally unsuitable for this application?",
      options: [
        {text: "Sigfox's 12-byte payload cannot encode temperature setpoint values", correct: false, feedback: "Incorrect. A temperature setpoint only needs 1-2 bytes (e.g., 0-40°C in 0.5° increments = 80 values = 1 byte). Payload size is not the issue here."},
        {text: "Sigfox base stations cannot route messages to specific devices for targeted commands", correct: false, feedback: "Incorrect. Sigfox can send downlink messages to specific devices using device IDs. The network can target individual devices. This is not the fundamental limitation."},
        {text: "Sigfox's 4 downlink messages/day limit makes 5-10 daily temperature adjustments impossible", correct: true, feedback: "Correct! With only 4 downlink messages per day maximum, users cannot adjust temperature 5-10 times daily. On day 1, after 4 adjustments, the thermostat becomes unresponsive until tomorrow. This asymmetric design makes Sigfox unsuitable for actuator control. Use LoRaWAN or Wi-Fi for bidirectional control applications."},
        {text: "Sigfox's 100 bps data rate causes unacceptable latency for thermostat control", correct: false, feedback: "Incorrect. A 2-byte temperature command at 600 bps downlink takes only ~0.03 seconds. Latency is not the issue. The hard limit of 4 downlinks/day is the fundamental constraint."}
      ],
      difficulty: "easy",
      topic: "sigfox"
    }));
  }
}

1115.4.2 Pitfall 2: Message Size Constraint

WarningCommon Pitfall: Sigfox Message Size Constraint

The mistake: Designing payload formats without considering Sigfox’s strict 12-byte uplink limit, leading to either data truncation or message fragmentation across multiple transmissions.

Symptoms:

• Critical sensor data is dropped or rounded excessively to fit payload
• Multi-message sequences arrive out of order or with gaps (lost messages)
• Application logic becomes complex trying to reassemble fragmented payloads
• Message quota exhausted mid-day due to payload fragmentation

Why it happens: Sigfox enforces a hard 12-byte payload limit for uplink messages. Developers accustomed to MQTT (256MB), HTTP (unlimited), or even LoRaWAN (243 bytes) often design payloads that exceed this:

• GPS coordinates: 8-12 bytes (latitude + longitude as floats)
• Timestamp: 4-8 bytes (Unix epoch or ISO format)
• Device ID: 4-8 bytes (UUID or serial number)
• Sensor readings: 2-8 bytes per sensor

A “simple” GPS tracker with timestamp and battery level easily reaches 16-20 bytes in naive encoding.

The fix:

1. Compact binary encoding: Replace floats with scaled integers (GPS: 4 bytes for lat/lon combined at 10m resolution)

2. Eliminate redundant data: Device ID is already in Sigfox frame header; don’t repeat in payload

3. Relative timestamps: Send seconds-since-last-message (2 bytes) instead of full epoch (4 bytes)

4. Data prioritization: Send critical values every message, less critical values in rotation

5. Payload design template:

   Bytes 0-1: Primary sensor (scaled integer)
   Bytes 2-3: Secondary sensor (scaled integer)
   Bytes 4-5: Battery/status flags (packed bits)
   Bytes 6-11: GPS or additional data (compressed)

Prevention: Design payloads on paper before coding. Use bit-packing for boolean flags, scaled integers instead of floats, and delta encoding for slowly-changing values. Validate that typical and worst-case payloads fit in 12 bytes. If 12 bytes is insufficient even with optimization, consider LoRaWAN (243 bytes) or NB-IoT (1600 bytes per message).

{
  const container = document.getElementById('kc-sigfox-msg-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An asset tracking device needs to transmit: GPS latitude (float32, 4 bytes), GPS longitude (float32, 4 bytes), speed (uint16, 2 bytes), heading (uint16, 2 bytes), battery (uint8, 1 byte), and timestamp (uint32, 4 bytes) = 17 bytes total. The developer realizes this exceeds Sigfox's 12-byte limit. What is the BEST approach to fit this data?",
      options: [
        {text: "Split the data across two consecutive Sigfox messages and reassemble in the cloud", correct: false, feedback: "Suboptimal. This doubles message consumption (from 72 to 144 messages/day for hourly updates), wasting budget and increasing the chance of incomplete data if one message fails. Better encoding can fit all data in 12 bytes."},
        {text: "Remove timestamp since Sigfox backend adds server-side timestamp automatically", correct: false, feedback: "Good optimization (saves 4 bytes) but not sufficient. GPS coordinates as float32 still consume 8 bytes. Server timestamps may differ from actual measurement time by seconds due to transmission delay."},
        {text: "Encode GPS as scaled integers (6 bytes), use uint8 for speed/heading (2 bytes), eliminate redundant timestamp (server-side), battery (1 byte) = 9 bytes", correct: true, feedback: "Correct! Optimized encoding: GPS lat/lon as 3-byte integers each (6 bytes total, ~1m resolution), speed as uint8 0-255 km/h (1 byte), heading as uint8 0-255 mapping to 0-360° (1 byte), battery uint8 (1 byte). Total: 9 bytes with 3 spare. Server-side timestamp is accurate enough for tracking applications."},
        {text: "Use compression algorithms (gzip) to reduce the 17-byte payload to under 12 bytes", correct: false, feedback: "Incorrect. Compression algorithms add overhead headers that exceed any savings on small payloads. For 17 bytes of semi-random data (GPS coordinates), gzip would likely produce 25+ bytes output. Compression only works for larger, repetitive datasets."}
      ],
      difficulty: "medium",
      topic: "sigfox"
    }));
  }
}

1115.4.3 Pitfall 3: Exhausting Daily Message Budget

CautionPitfall: Exhausting Daily Message Budget with Retransmissions

The Mistake: Implementing aggressive retry logic that sends the same message multiple times when no acknowledgment is received, quickly consuming the 140 messages/day quota.

Why It Happens: Developers accustomed to TCP/IP or MQTT expect acknowledgments and implement retry patterns like “send up to 5 times until ACK received.” With Sigfox’s fire-and-forget model (no native ACKs) and 140 message/day limit, this approach exhausts the daily budget by mid-morning:

Scenario: Sensor sends every 15 minutes with 3 retries per reading
- Readings/day: 96 (24 hours × 4/hour)
- With 3 retries: 96 × 3 = 288 messages/day
- Sigfox limit: 140 messages/day
- Result: Device blocked by 10:30 AM, no data for rest of day

The Fix: Accept Sigfox’s inherent ~95-98% delivery rate without retries. Design your application to tolerate occasional missing messages:

1. No application-level retries: Trust Sigfox’s built-in triple transmission (each message sent 3× on different frequencies)
2. Backend interpolation: Fill missing readings using adjacent values
3. Delta encoding: Send only changes from last confirmed value
4. Critical alerts: Reserve 10-20 messages/day for burst alerts, use remaining 120-130 for scheduled readings
5. Budget monitoring: Track daily message count in firmware, throttle non-critical messages when approaching 100

1115.4.4 Pitfall 4: Missing the Downlink RX Window

CautionPitfall: Missing the Downlink RX Window Timing

The Mistake: Requesting a downlink but putting the device to sleep before the receive window opens, resulting in missed configuration updates or commands.

Why It Happens: The downlink window has strict timing requirements that developers often misunderstand:

Sigfox Downlink Timing:
1. Device sends uplink with downlink request flag = TRUE
2. Device MUST stay awake for 20-25 seconds in RX mode
3. Base station transmits 8-byte downlink during this window
4. If device sleeps early → downlink lost forever

Common mistake:
- Uplink sent at T=0
- Device enters sleep at T=5 seconds (too early!)
- Downlink arrives at T=20 seconds → device asleep → lost

The downlink arrives 20 seconds after uplink, but many implementations only wait 5-10 seconds before sleeping.

The Fix: Implement proper downlink handling with conservative timing:

1. Wait full 25 seconds: After uplink with downlink flag, keep radio in RX mode for 25 seconds minimum
2. Power budget: Each downlink costs ~1.25 mAh (vs 0.067 mAh uplink-only)—factor this into battery calculations
3. Downlink scheduling: Only request downlinks when essential (firmware triggers, config changes)
4. Timeout handling: If no downlink received after 25 seconds, log the miss and continue
5. Daily limit awareness: Only 4 downlinks/day—request sparingly, not on every uplink

{
  const container = document.getElementById('kc-sigfox-msg-4');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A developer designs a Sigfox-based alarm sensor that sends alerts when motion is detected. The code retries each alert 3 times to ensure delivery. During testing in a busy office, the sensor detects motion 60 times per day. What happens by end of day?",
      options: [
        {text: "All 180 messages (60 × 3 retries) are sent successfully with 95% delivery rate", correct: false, feedback: "Incorrect. Sigfox has a hard limit of 140 messages per device per day. After 140 messages, the device is blocked until the next day. No additional messages can be sent regardless of retry logic."},
        {text: "The sensor exceeds its 140 message/day quota by mid-afternoon and stops sending alerts for the remainder of the day", correct: true, feedback: "Correct! With 60 detections × 3 retries = 180 messages attempted, the device hits its 140 message limit around 2:30 PM (after ~47 detections). The remaining 13 detections go unreported. Solution: Remove retries—Sigfox's triple transmission (built-in) achieves ~95-98% delivery without application-level retries."},
        {text: "Sigfox automatically queues excess messages for delivery the next day", correct: false, feedback: "Incorrect. Sigfox does not queue messages. When the daily limit is reached, messages are dropped. There is no carryover or queueing mechanism. The sensor simply goes silent until midnight reset."},
        {text: "The Sigfox backend rate-limits the sensor to 140 messages, delivering every third message evenly throughout the day", correct: false, feedback: "Incorrect. Sigfox does not rate-limit intelligently. Messages are accepted first-come-first-served until 140 is reached, then all subsequent messages are rejected. There is no smart distribution across the day."}
      ],
      difficulty: "easy",
      topic: "sigfox"
    }));
  }
}

---

1115.5 Global Coverage Misconception

WarningCommon Misconception: “Sigfox Works Everywhere Like Cellular”

The Misconception: Many companies assume Sigfox offers global coverage similar to cellular networks (190+ countries), leading to deployment failures in 20-40% of target markets.

Reality Check with Real-World Data:

Sigfox Coverage Reality (2024):

• Strong Coverage: 22 Western European countries (85-95% population coverage)
• Moderate Coverage: USA, Canada, Australia (60-70% population, concentrated in major cities)
• Limited Coverage: Latin America (Sao Paulo, Mexico City, Buenos Aires only), Eastern Europe (Poland, Czech Republic)
• Essentially No Coverage: China, Russia, India (>3 billion people excluded), most of Africa and Middle East

Case Study: Global Fleet Management Failure

• Company: European logistics firm with 10,000 shipping containers
• Assumption: “Sigfox operates in 70 countries, we operate in 30 countries, we’re covered”
• Reality: 8 out of 30 target countries had zero Sigfox coverage (China, Russia, India, Indonesia, Vietnam, Thailand, Kenya, Nigeria)
• Impact: 2,400 deployed devices (24% of fleet) became non-functional in coverage gaps
• Financial Loss: $24,000 hardware + $14,400/year subscriptions wasted = $86,400 over 5 years
• Resolution: Emergency deployment of dual-mode NB-IoT devices in gap countries, additional $72,000 cost

Why This Happens:

1. Operator-Dependent Model: Sigfox requires local Sigfox Network Operator (SNO) in each country
2. Business Case Limitations: SNOs only deploy where IoT market size justifies infrastructure investment
3. Competitive Landscape: In Asia, cellular IoT (NB-IoT/LTE-M) dominates; no business case for Sigfox SNOs
4. Regulatory Barriers: Some countries restrict unlicensed LPWAN or have national security concerns

Pre-Deployment Verification Protocol:

• Step 1: Check sigfox.com/coverage for each target country (not just “Sigfox exists”)
• Step 2: Deploy 10-20 test devices in actual deployment locations for 30-day field trial
• Step 3: Measure message success rate (accept only if >95% delivery)
• Step 4: For coverage gaps, design hybrid deployment (Sigfox + NB-IoT fallback) or choose cellular IoT for true global coverage

Bottom Line: Sigfox is excellent for European regional deployments but NOT a global solution like cellular networks. Always verify operator availability AND coverage quality per country before committing to Sigfox.

{
  const container = document.getElementById('kc-sigfox-msg-5');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A European logistics company successfully deploys 5,000 Sigfox trackers across Western Europe with 99% coverage. They plan to expand to Asia (China, India, Vietnam) with 3,000 additional trackers. What critical issue will they encounter?",
      options: [
        {text: "Sigfox uses different frequency bands in Asia (920 MHz vs 868 MHz) requiring new hardware", correct: false, feedback: "While frequency bands do differ by region, this is a manageable hardware issue. Multi-band Sigfox modules exist. The fundamental problem is more severe than frequency compatibility."},
        {text: "Asian countries have stricter LPWAN regulations that limit Sigfox message frequency to 50/day", correct: false, feedback: "Incorrect. Regional regulations vary, but the 140 message/day limit is a Sigfox protocol constraint, not regulatory. The issue lies in network availability, not regulatory message limits."},
        {text: "Sigfox has minimal to no operator coverage in China, India, and Vietnam, rendering the trackers non-functional", correct: true, feedback: "Correct! Sigfox coverage is fragmented globally. China has NO Sigfox coverage (government restrictions on unlicensed IoT). India has minimal coverage (3-4 cities). Vietnam has limited coverage. The company's 3,000 Asian trackers would be essentially paperweights. For global tracking, NB-IoT or satellite-based solutions provide better coverage."},
        {text: "Sigfox's 12-byte payload is insufficient for Asian language character encoding in tracking messages", correct: false, feedback: "Incorrect. Tracker payloads contain GPS coordinates and status bytes, not text strings. Character encoding is irrelevant for machine-to-machine tracking data. The coverage gap is the critical issue."}
      ],
      difficulty: "medium",
      topic: "sigfox"
    }));
  }
}

---

1115.6 Summary

In this chapter, you learned about Sigfox’s communication patterns and constraints:

Message Flow:

• Uplink: 6 seconds at 100 bps, 12-byte payload, 140 messages/day
• Downlink: 8-byte payload, 4 messages/day maximum, 20-25 second RX window

Power Impact:

• Uplink-only: 0.067 mAh per message (battery-efficient)
• With downlink: 1.25 mAh (17x more energy)
• Always request downlinks sparingly to preserve battery

Common Pitfalls to Avoid:

1. Designing for bidirectional communication (use uplink-only patterns)
2. Exceeding 12-byte payload limit (use compact binary encoding)
3. Aggressive retries exhausting daily quota (trust triple transmission)
4. Missing downlink RX window timing (wait full 25 seconds)
5. Assuming global coverage like cellular (verify per-country)

1115.7 What’s Next

Continue learning about Sigfox deployment:

• Next: Sigfox Deployment - Coverage verification and deployment best practices
• Then: Sigfox Hands-On - Interactive lab with ESP32 simulation
• Then: Sigfox Assessment - Comprehensive quizzes and review