35 Sigfox Technology Overview
35.1 Introduction
Sigfox is both a proprietary LPWAN technology and the name of the French company that developed and operates it. Unlike other LPWAN technologies where you can deploy your own network, Sigfox operates as a network operator providing connectivity services globally. Sigfox pioneered the concept of ultra-narrow band (UNB) modulation for IoT, enabling billions of low-power devices to communicate with minimal infrastructure and energy consumption.
By the end of this chapter, you will be able to:
- Explain how Sigfox’s ultra-narrow band (UNB) modulation achieves long range with minimal power
- Analyze the Sigfox network architecture and evaluate its operator-managed business model
- Compare Sigfox’s UNB spectral density with LoRa CSS, FSK, and Wi-Fi OFDM modulation schemes
- Assess the trade-offs between operator dependency and zero-infrastructure deployment
Key Concepts
- Sigfox Technical Overview: End-to-end summary of Sigfox architecture including UNB physical layer, base station network, cloud backend, and application integration.
- Coverage Architecture: Sigfox deploys base stations on existing infrastructure (towers, buildings); typically 3–5 base stations needed per urban km², 1 per 50–100 km² rural.
- Device Architecture: Sigfox end device contains microcontroller, Sigfox RF module (or SoC), power management, and application sensors; minimal protocol stack complexity.
- Cloud Services: Sigfox backend provides device registry, message store, callback routing, statistics API, and network diagnostic tools.
- Connectivity Options: Sigfox operates in Europe (868 MHz), Americas (902 MHz), and Asia (923 MHz); international roaming available in covered countries.
- Integration Patterns: Common application integration architectures using Sigfox callbacks to cloud platforms (AWS IoT, Azure IoT Hub, Google Cloud IoT) and time-series databases.
- Performance Characteristics: Typical uplink range 10–50 km rural, 3–10 km urban; 140 messages/day maximum; 12-byte payload; ~1–5 second cloud delivery latency.
Core Concept: Sigfox’s ultra-narrow band design enforces strict message limits: 140 uplink messages/day (12 bytes each) and only 4 downlink messages/day (8 bytes each). These constraints are non-negotiable and define which applications Sigfox can support.
Why It Matters: Unlike other LPWAN technologies where you can trade battery life for more messages, Sigfox’s limits are regulatory and network-imposed. A smart meter sending hourly readings (24/day) works perfectly, but an asset tracker needing updates every 5 minutes (288/day) exceeds the limit by 2x. Choosing Sigfox for the wrong use case wastes development time and subscription fees.
Key Takeaway: Calculate your exact daily message count before selecting Sigfox. If your application needs more than 140 messages/day or requires frequent firmware updates via OTA, choose LoRaWAN or cellular IoT instead. Sigfox excels at infrequent, tiny messages from devices that run for 10+ years on batteries.
35.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- LPWAN Fundamentals: Understanding the LPWAN technology class, design trade-offs, and positioning relative to other wireless technologies provides essential context for Sigfox’s ultra-narrow band approach
- Networking Basics: Familiarity with network topologies (especially star topology), frequency bands, and wireless modulation concepts helps you grasp Sigfox’s network architecture
- LoRaWAN Fundamentals: Comparing Sigfox with LoRaWAN’s spread spectrum approach highlights the unique characteristics and trade-offs of ultra-narrow band modulation
Imagine you need to send very simple messages—“the door opened,” “temperature is 22°C,” “water level is low”—from thousands of sensors spread across a city. You don’t need to send photos or videos, just tiny bits of information. You want these sensors to run on batteries for 10+ years without replacement. And you want them to work everywhere without setting up your own antennas.
Sigfox solves this exact problem. It’s both a technology and a company that operates a global wireless network specifically for the Internet of Things. Think of it like a cellular network (like Verizon or AT&T), but instead of smartphones sending emails and videos, it’s designed for IoT devices sending tiny messages.
What makes Sigfox special?
Sigfox uses ultra-narrow band (UNB) radio technology—imagine squeezing your radio signal into an extremely thin channel, like a laser beam instead of a flashlight. This narrow signal can travel very long distances (up to 50 km in rural areas!) and uses incredibly little power. Your sensor might send only 140 messages per day, each containing up to 12 bytes of data (about 12 characters).
The trade-off is simplicity: Sigfox is perfect for “send temperature once per hour” but terrible for “stream live video.” It’s like choosing between sending postcards (Sigfox) vs video calls (Wi-Fi)—different tools for different jobs.
| Term | Simple Explanation |
|---|---|
| Ultra-Narrow Band (UNB) | Radio signal squeezed into a very thin frequency channel for long range |
| LPWAN | Low-Power Wide-Area Network—sends data long distances on little power |
| Base Station | Sigfox antenna tower that receives messages from nearby devices |
| Payload | The actual data you send (max 12 bytes per message for Sigfox) |
| Message Limit | Sigfox allows 140 uplink messages per day per device |
| Global Coverage | Single subscription works across countries where Sigfox operates |
| ISM Band | Unlicensed radio frequencies (868 MHz Europe, 902 MHz USA) anyone can use |
Sigfox is like a postal service for tiny sensor messages!
35.2.1 The Sensor Squad Adventure: Whisper Network
Welcome to the world of Sigfox, where sensors have learned to whisper instead of shout!
Narrow Nellie is a special sensor who knows a secret. “I can send messages REALLY far,” she whispers, “but I have to keep them super tiny - just 12 letters at a time!” She’s placed on a water tank in a farmer’s field, 40 kilometers away from the nearest town. Every day, she sends a tiny message: “TANK 85% FULL” - that’s all the farmer needs to know.
Postman Pierre works at the Sigfox base station tower. “My job is easy,” he explains. “I don’t have to remember anything complicated. Nellie just whispers her message, and I forward it to the cloud. I don’t even need to whisper back most days!” Pierre is like a one-way mailman - he mostly just listens.
Battery Betty is amazed. “I’ve been powering Nellie for 8 years now, and I’m not even tired! That’s because whispering tiny messages uses so little energy. If Nellie had to shout like Wi-Fi sensors, I would have died after just a few months.”
But Download Dan looks a bit sad. “The problem is, I can only send 4 messages back to Nellie each day. If the farmer wants to change her settings or update her software, it takes forever. That’s the trade-off for using so little power.”
Network Nadia from the Sigfox Cloud Center explains: “We have thousands of Pierres (base stations) all over the country. When Nellie whispers her message, THREE different Pierres might hear it! We pick the best copy and send it to the farmer’s app. No setup needed - it just works!”
35.2.2 Key Words for Kids
| Word | What It Means |
|---|---|
| Ultra-Narrow Band | Sending messages in a super-thin radio lane, like whispering through a tiny tube that goes really far |
| Base Station | A tall antenna that listens for sensor whispers and sends them to the internet |
| Payload | The actual message inside the sensor’s whisper (max 12 characters for Sigfox) |
| Operator Network | A company that owns all the antenna towers so you don’t have to build your own |
35.2.3 Try This at Home!
Be a Sigfox Message Designer!
Sigfox sensors can only send 12 bytes (roughly 12 characters). What information can you fit?
- Try describing the weather in 12 characters: “SUNNY 72F OK” (11 chars - perfect!)
- Try describing a parking spot: “SPOT7:TAKEN” (11 chars - works!)
- Try sending your whole address… oops! It doesn’t fit!
This is why Sigfox is great for simple sensor data but not for sending emails or photos!
35.3 Sigfox Technology Overview
35.3.1 The Company and Vision
Sigfox is a French company founded in 2009 with a vision to connect billions of IoT devices using a dedicated low-power wide-area network. Rather than selling equipment for customers to build their own networks, Sigfox operates as a network service provider—similar to how cellular carriers operate.
Key philosophy:
35.4 Sigfox Technology Summary
| Property | Details |
|---|---|
| Name | Sigfox |
| Standard protocol is based on | Ultra Narrow Band (UNB) ISM radio band |
| Designed for | Uses Ultra Narrow Band (UNB) to transmit information between low power devices operating at 868 MHz frequency band, that divides the spectrum into 400 of 100 Hz channels |
| Connection range | 30-50 km for rural areas, and 3-10 km for urban areas |
| Data rate | 100bps, with a limit of 140 messages per day for each end device |
- Software-based solution: Network and computing complexity managed in the cloud
- Simple devices: All intelligence in the network, not the endpoints
- Global coverage: Single subscription works across countries
- Ultra-low cost: Minimal device complexity reduces hardware costs
35.4.1 Sigfox Network Architecture
The Sigfox network follows a star topology with operator-managed infrastructure handling all complexity:
Key architectural features:
- Star topology: Devices communicate directly with base stations (no mesh routing)
- Operator-owned infrastructure: All base stations and backend managed by Sigfox Network Operator
- Redundant reception: Multiple base stations receive each message for reliability
- Cloud processing: Geolocation computed from signal strength across base stations
- Simple devices: No network stack complexity, minimal power consumption
- Asymmetric communication: Heavy uplink (140 msg/day), limited downlink (4 msg/day)
35.4.2 Ultra-Narrow Band Modulation
Sigfox uses Ultra Narrow Band (UNB) modulation, which is fundamentally different from spread spectrum techniques used by LoRa or frequency hopping used by Bluetooth.
UNB Characteristics:
- Extremely narrow channel bandwidth: 100 Hz per channel
- Multiple channels across the ISM band
- Low data rate: 100 bps uplink, 600 bps downlink
- High receiver sensitivity: -126 to -142 dBm
- Robust against interference and jamming
The following diagram illustrates how Sigfox’s ultra-narrow band approach differs from other wireless technologies in terms of bandwidth utilization:
Comparison with other modulation schemes:
| Technology | Bandwidth | Data Rate | Sensitivity |
|---|---|---|---|
| Sigfox (UNB) | 100 Hz | 100 bps | -142 dBm |
| LoRa (CSS) | 125-500 kHz | 250-5,470 bps | -148 dBm |
| FSK (Cellular) | 200 kHz | 1-100 kbps | -110 dBm |
| Wi-Fi (OFDM) | 20-40 MHz | 1-600 Mbps | -90 dBm |
Ultra-narrow bandwidth concentrates transmit power into a tiny slice of spectrum. For 14 dBm (25 mW) transmit power, spectral density is \(PSD = P/BW = 25\,\text{mW} / 100\,\text{Hz} = 0.25\,\text{mW/Hz}\). Compare to LoRa: \(25\,\text{mW} / 125000\,\text{Hz} = 0.0002\,\text{mW/Hz}\)—1250× lower. Worked example: This 31 dB spectral density advantage directly contributes to Sigfox’s -142 dBm sensitivity (vs LoRa -148 dBm, which uses spreading gain instead).
35.4.3 Sigfox vs LoRaWAN Protocol Stack Comparison
Understanding the architectural differences between Sigfox and LoRaWAN helps inform technology selection:
Technology trade-offs:
| Feature | Sigfox | LoRaWAN |
|---|---|---|
| Deployment complexity | Very simple (Operator handles all) | Moderate (Deploy gateways) |
| Infrastructure control | None (Operator only) | Full (Private networks) |
| Device cost | $5-15 (Lowest) | $10-25 (Low) |
| Operational cost | $6-10/year subscription | Gateway CapEx + power |
| Data rate | 100 bps (Very low) | 250-5,470 bps (Low-Medium) |
| Payload size | 12 bytes (Tiny) | 243 bytes (Small) |
| Message frequency | 140/day limit | No daily limit |
| Bidirectional | Limited (4 downlink/day) | Full (after each uplink) |
| Coverage dependency | Operator network | Self-deployed |
| Best for | Simple sensors, metering | Flexible IoT, moderate data |
35.5 Videos
Expand Your Learning:
- Knowledge Map: Visualize how Sigfox fits within the broader LPWAN ecosystem and its relationship to cellular IoT, LoRaWAN, and application protocols
- Quizzes Hub: Test your understanding with LPWAN technology comparison quizzes and Sigfox deployment scenario questions
- Videos Hub: Watch curated videos on LPWAN positioning, operator network models, and UNB vs spread spectrum modulation techniques
35.6 Sigfox Message Structure and Encoding
Understanding how Sigfox messages are structured helps you design efficient payloads that maximize the value of each precious 12-byte uplink:
Example: 12-byte Environmental Sensor Payload
Byte Layout:
[0] Temperature (1 byte) → 0x50 = 80 → 80-40 = 40°C
[1] Humidity (1 byte) → 0x45 = 69%
[2-3] Pressure (2 bytes) → 0x03F2 = 1010 hPa
[4] Battery % (1 byte) → 0x5A = 90%
[5] Status flags (1 byte) → 0x05 = motion + door open
[6-8] Latitude (3 bytes) → scaled from float
[9-11] Longitude (3 bytes) → scaled from float
Total: 12 bytes (maximum utilization)
DON’T: Send ASCII text like "TEMP:25.5C" (11 bytes for one value!)
DO: Send binary-encoded 0x19 (1 byte = 25°C with proper scaling)
A single Sigfox message using efficient encoding can carry 6-8 sensor values. Using ASCII wastes 80%+ of your precious payload space.
35.7 Common Pitfalls and Mistakes
1. Ignoring Message Limits During Design
Many projects fail because engineers design assuming “we’ll optimize later.” Calculate your exact message budget BEFORE selecting Sigfox:
| Application | Messages/Hour | Messages/Day | Fits Sigfox? |
|---|---|---|---|
| Hourly temperature | 1 | 24 | ✅ Yes (17% of 140) |
| 15-min asset track | 4 | 96 | ✅ Yes (69% of 140) |
| 5-min monitoring | 12 | 288 | ❌ No (206% over!) |
| Event-driven alerts | Variable | 0-50 | ✅ Usually yes |
2. Planning OTA Firmware Updates
A 50 KB firmware update via Sigfox downlink: - 50,000 bytes ÷ 8 bytes/message = 6,250 messages - 6,250 messages ÷ 4 messages/day = 1,562 days (4.3 years!)
Solution: Use Bluetooth for local updates, or accept firmware is fixed at deployment.
3. Expecting Acknowledgments
Sigfox is primarily uplink-only. If you need confirmation that every message was received: - You’ll consume your 4 daily downlinks quickly - Consider LoRaWAN Class A with confirmed uplinks instead
4. Underestimating Coverage Gaps
Sigfox coverage varies significantly by region. Always: - Check official coverage maps before committing - Test with actual devices at deployment locations - Have a fallback plan for areas with weak/no coverage
35.8 Worked Example: Smart Parking Deployment
Let’s walk through a real-world Sigfox deployment calculation:
Scenario: Deploy 500 parking sensors in a city center with Sigfox coverage.
Key Calculations:
| Metric | Value | Notes |
|---|---|---|
| Messages per sensor/day | 9 | 8 state changes + 1 heartbeat |
| Daily message utilization | 6.4% | 9/140 = well within limits |
| Payload per message | 4 bytes | status(1) + timestamp(2) + battery(1) |
| Annual subscription cost | $4,000 | 500 × $8/year |
| 5-year TCO | $47,500 | Year 1: $14,300 + Years 2-5: $4,200/year × 4 |
Verdict: Sigfox is IDEAL for this use case because: - Low message frequency (9/day << 140 limit) - Tiny payload (4 bytes << 12 byte limit) - No OTA updates needed (parking sensors are simple) - Coverage exists in city center - No infrastructure budget required
35.9 Decision Framework: Is Sigfox Right for Your Application?
Use the following decision tree to evaluate whether Sigfox is appropriate for your IoT application:
Quick Reference - Sigfox Sweet Spots:
| Application Type | Suitability | Reason |
|---|---|---|
| Smart parking sensors | Excellent | 1-2 messages/hour, tiny payload, no OTA needed |
| Agricultural soil monitors | Excellent | Few readings/day, simple data, battery life critical |
| Asset trackers (low-frequency) | Good | Location updates every 30+ min work well |
| Industrial leak detection | Good | Alert-based, infrequent messages |
| Smart meters (basic) | Good | Daily/hourly readings, simple telemetry |
| Real-time asset tracking | Poor | Needs >140 updates/day |
| Video/audio streaming | Incompatible | Data rate far too low |
| Devices needing OTA updates | Poor | 4 downlink/day makes OTA impractical |
35.10 Regional Frequency Allocations
Sigfox operates in different ISM (Industrial, Scientific, Medical) bands depending on the region, which affects device design and cross-regional deployment:
Regional Configuration Summary:
| Region Code | Frequency | Max Power | Coverage Area | Key Regulation |
|---|---|---|---|---|
| RC1 | 868.0-868.6 MHz | 14 dBm | Europe, Middle East, Africa | ETSI EN 300 220 |
| RC2 | 902-928 MHz | 22 dBm | USA, Mexico, Brazil | FCC Part 15 |
| RC3 | 923.0-923.5 MHz | 14 dBm | Japan | ARIB STD-T108 |
| RC4 | 920-928 MHz | 22 dBm | APAC, Australia, NZ, South America | Various |
| RC5 | 920-923 MHz | 14 dBm | South Korea | KC Certification |
| RC6 | 865-867 MHz | 14 dBm | India | WPC Regulations |
| RC7 | 920-925 MHz | 14 dBm | Singapore, Taiwan | Various |
If your devices must operate across multiple regions (e.g., global asset tracking), you need:
- Multi-band RF modules: Single-band modules only work in one region
- Region detection: Firmware must detect/configure the correct RC
- Antenna considerations: Antenna efficiency varies by frequency
- Certification costs: Each region requires separate regulatory approval
For global deployments, budget 3-6 months and $15-30K per region for certifications.
35.11 Sigfox Network Evolution: The 0G Transition
In 2022, Sigfox (the company) was acquired by UnaBiz, a Singapore-based IoT company. The technology continues under the “0G Network” branding:
- 0G Network: Emphasizes the ultra-low power, low-data-rate design philosophy
- Continued Operations: Global network infrastructure remains operational
- Technology Unchanged: UNB modulation, message limits, and specifications remain the same
- Expanded Integration: UnaBiz is combining Sigfox with other LPWAN technologies
For deployment planning, the technical specifications in this chapter remain accurate. Check UnaBiz/Sigfox coverage maps for current regional availability.
35.12 Security Considerations
Sigfox implements security at the network level, but understanding its security model is essential for IoT deployments:
Sigfox Security Features:
| Security Layer | Mechanism | Protection Provided |
|---|---|---|
| Device Authentication | Unique 32-bit ID + symmetric key | Prevents device impersonation |
| Message Authentication | AES-128 MAC (Message Auth Code) | Ensures message integrity |
| Anti-Replay | Sequence number tracking | Prevents message replay attacks |
| Callback Security | HTTPS with TLS | Secures cloud-to-application link |
1. No Native Payload Encryption: Sigfox authenticates messages but does NOT encrypt the 12-byte payload by default. Sigfox (and now UnaBiz) can see your data in transit. For sensitive data, implement application-layer encryption.
2. Shared Symmetric Keys: The same key authenticates device-to-network communication. If a device is physically compromised, the key is exposed.
3. No Downlink Verification: Devices cannot cryptographically verify that downlink messages originated from your application (vs. Sigfox network).
Best Practice: For sensitive IoT data (health, financial, personal), add AES-128 encryption at the application layer before the Sigfox transmission. Using AES-CTR mode, the ciphertext matches the plaintext length (12 bytes), but the nonce/IV (8-16 bytes) must be synchronized or pre-shared. With a pre-shared counter scheme, encryption adds zero payload overhead but requires careful nonce management.
Use this practical framework to evaluate whether Sigfox fits your IoT deployment:
Step 1: Calculate Your Daily Message Budget
Count every transmission type: - Periodic sensor readings: (24 hours / reporting_interval_hours) = messages/day - Event-driven alerts: estimate worst-case (e.g., 20 door open/close events/day) - Heartbeat messages: (24 hours / heartbeat_interval_hours) - Add 10% buffer for retries and diagnostics
Example: Temperature sensor reporting hourly with 2 alerts/day: - Hourly readings: 24 messages - Alerts: 2 messages - Total: 26 messages/day (19% of 140 limit) ✓ Sigfox works
Step 2: Design Your 12-Byte Payload
Map your data to binary encoding: - GPS coordinates: 8 bytes (4 lat + 4 lon, ~1m precision) - Temperature: 1 byte (-40°C to +85°C scaled) - Status flags: 1 byte (8 binary flags) - Battery: 1 byte (0-100%) - Timestamp: 1 byte (hour of day 0-23) - Total: 12 bytes exactly
If your data doesn’t fit in 12 bytes with efficient encoding, Sigfox won’t work.
Step 3: Verify Coverage at Deployment Sites
Check Sigfox coverage map, then validate with test units: - Deploy 5-10 test devices at actual locations for 1 week - Measure delivery ratio (target: >98%) - If <95%, plan for external antennas or alternative technology
Step 4: Calculate 5-Year Total Cost of Ownership
| Cost Item | Calculation | Example (1,000 devices) |
|---|---|---|
| Modules | devices × $15 | $15,000 |
| Installation | devices × $25 | $25,000 |
| Subscription | devices × $8/year × 5 years | $40,000 |
| Antenna upgrades (10%) | 0.1 × devices × $25 | $2,500 |
| Total 5-Year | $82,500 | |
| Per device/month | total / devices / 60 | $1.38 |
Compare with LoRaWAN (~$0.50/device/month with gateway investment) or NB-IoT (~$3/device/month no infrastructure).
Decision Matrix:
| Requirement | Sigfox | LoRaWAN | NB-IoT |
|---|---|---|---|
| Messages <140/day | ✓ Yes | ✓ Yes | ✓ Yes |
| Payload ≤12 bytes | ✓ Yes | ✓ 242 bytes | ✓ 1500 bytes |
| No OTA firmware updates | ✓ Required | ✓ Possible | ✓ Possible |
| Zero infrastructure | ✓ Yes | ❌ Need gateways | ✓ Yes |
| Budget <$3/device/month | ✓ Yes | ✓ Depends | ❌ Usually $3+ |
| Global roaming | ✓ Yes | ❌ Gateway limited | ✓ Yes with eSIM |
| Deployment <3 months | ✓ Yes | ❌ 3-6 months | ✓ Yes |
Final Question: Can You Accept Operator Dependency?
Sigfox is a single global operator. If Sigfox exits your market (has happened in some regions), your devices become paperweights. If this risk is unacceptable for mission-critical applications, choose LoRaWAN (private network) or NB-IoT (multiple carrier options).
Verdict Template:
“We chose [Sigfox/LoRaWAN/NB-IoT] because our [application] requires [key constraint: message frequency/payload size/coverage/cost], and [chosen technology] provides [specific advantage] while [alternative technologies] would require [unacceptable trade-off].”
35.13 Concept Relationships
| Core Concept | Builds On | Leads To | Contrasts With | Prerequisites |
|---|---|---|---|---|
| Operator Network Model | Cellular carrier architecture | Zero infrastructure cost, subscription pricing | LoRaWAN user-deployable gateways | Network topologies |
| UNB 100 Hz Channels | Shannon capacity theorem, ISM bands | -142 dBm sensitivity, 30-50 km range | LoRa 125 kHz, Wi-Fi 20 MHz | RF modulation basics |
| Message Constraints | Duty cycle regulations, network design | 140/day uplink, 4/day downlink hard limits | LoRaWAN unlimited (duty cycle only) | LPWAN fundamentals |
| Payload Encoding | Binary encoding, fixed-point scaling | 12-byte uplink, 8-byte downlink | ASCII text (wasteful for IoT) | Data representation |
| Sigfox Atlas | RSSI triangulation, propagation models | 1-10 km geolocation without GPS | GPS (5-10 m accuracy, higher cost) | Signal strength, path loss |
35.14 See Also
- Sigfox Message Flow - Understand uplink/downlink operations and common deployment pitfalls
- LoRaWAN Architecture - Compare operator model with user-deployable gateway infrastructure
- NB-IoT Fundamentals - Cellular LPWAN alternative for higher data rates
- LPWAN Comparison - Side-by-side analysis of Sigfox, LoRaWAN, NB-IoT
- Network Economics - TCO calculations for LPWAN deployments
35.15 Try It Yourself
Challenge: Sigfox vs LoRaWAN TCO Analysis
You’re deploying 1,000 smart waste sensors across a city. Each sensor reports fill level once per hour (24 messages/day) with an 8-byte payload. Expected lifetime is 10 years.
Your Task:
- Calculate Sigfox TCO (10 years):
- Device cost: $12 each
- Subscription: $8/year per device
- Verify message budget: 24/day within 140/day limit?
- Calculate LoRaWAN TCO (10 years):
- Device cost: $18 each
- Gateway coverage: 1 gateway per 200 sensors at $600 each
- Gateway backhaul: $20/month per gateway
- Compare Results:
- Which is cheaper at 1,000 devices?
- At what device count does LoRaWAN become cheaper?
- Factor in: What if Sigfox coverage doesn’t reach 10% of locations?
What to Observe:
- How does infrastructure CapEx vs. subscription OpEx affect the crossover point?
- What happens to LoRaWAN TCO if you need only 3 gateways instead of 5?
- If reporting interval increases to every 5 minutes (288/day), can Sigfox still work?
Extension: Add a third option - NB-IoT at $15/device + $24/year subscription. When does cellular IoT make economic sense?
35.16 How It Works
Sigfox Star Topology: Message Flow from Sensor to Application
When a Sigfox device transmits, the following steps occur:
Step 1: Device Transmission (Uplink)
- Device wakes from sleep mode (10 µA idle current)
- Selects random 100 Hz channel from 192 kHz ISM band
- Transmits 12-byte payload using DBPSK modulation at 100 bps
- Transmission repeated 3 times on different frequencies (~6 seconds total airtime)
- Device returns to sleep - no acknowledgment expected
Step 2: Base Station Reception
- Multiple base stations (typically 2-4 within 30-50 km) receive the signal
- Each base station records: RSSI, SNR, timestamp, frequency offset
- Base stations operate in “always listening” mode (no device registration needed)
- All receptions forwarded to Sigfox cloud via IP backhaul
Step 3: Cloud Backend Processing
- Deduplication: Identify the 3 redundant transmissions from the same device
- Best-copy selection: Choose reception with highest SNR for payload extraction
- Geolocation (Atlas): Triangulate device position using RSSI from multiple base stations
- Callback delivery: Forward message to customer application via HTTPS webhook
Step 4: Application Server
- Receives JSON payload:
{"device": "1A2B3C", "data": "0x48656C6C6F", "rssi": -98, "lat": 51.5074, "lng": -0.1278} - Decodes binary payload to sensor readings
- Updates database, triggers alerts, or displays on dashboard
Downlink Path (Rare - 4 messages/day max):
- Application sends downlink request to Sigfox API
- Sigfox cloud schedules transmission in 20-second RX window after next uplink
- Device must transmit uplink first to open RX window
- Base station transmits 8-byte downlink using GFSK at 600 bps
- Device listens for 25 seconds (significant battery cost: ~50 mA vs. 10 µA sleep)
Key Insight: The entire network intelligence lives in the cloud. Devices are ultra-simple transmitters with no network stack, no authentication handshake, and no downlink expectation. This radical simplicity enables $5-15 module costs and 10-20 year battery life.
35.17 Summary
In this chapter, you learned about Sigfox’s core technology and when to use it:
Technology Fundamentals:
- Company and Vision: Sigfox operates as a network-as-a-service provider, handling all infrastructure while customers focus on devices
- Network Architecture: Star topology with operator-managed base stations and cloud backend
- Ultra-Narrow Band (UNB): 100 Hz channel bandwidth enables exceptional range and interference immunity
- Cost Model: Low device cost ($5-15) with annual subscription ($6-10/year) versus LoRaWAN’s infrastructure investment
Critical Specifications (memorize these!):
| Parameter | Uplink | Downlink |
|---|---|---|
| Data rate | 100 bps | 600 bps |
| Payload size | 12 bytes max | 8 bytes max |
| Daily limit | 140 messages | 4 messages |
| Range (urban) | 3-10 km | — |
| Range (rural) | 30-50 km | — |
| Sensitivity | -142 dBm | — |
Decision Criteria - Choose Sigfox when:
- ✅ Messages ≤ 140/day AND payload ≤ 12 bytes
- ✅ No OTA firmware updates required
- ✅ Sigfox coverage exists in your region
- ✅ No budget for network infrastructure
- ✅ Global roaming needed with single subscription
Avoid Sigfox when:
- ❌ Need >140 messages/day
- ❌ Require frequent firmware updates
- ❌ Need real-time bidirectional communication
- ❌ Deploying in areas without Sigfox coverage
- ❌ Require private network control
35.18 What’s Next
Now that you understand Sigfox’s technology foundations, continue with the following chapters:
| Order | Chapter | Focus |
|---|---|---|
| Next | Sigfox Message Flow | Uplink/downlink operations and common pitfalls |
| Then | Sigfox Deployment | Coverage considerations and real-world deployment strategies |
| Then | Sigfox Hands-On | Interactive lab and Python implementations |
| Related | LoRaWAN Architecture | Compare with user-deployable gateway model |
| Related | NB-IoT Fundamentals | Cellular LPWAN alternative for higher data rates |