Solving the IoT Collision Problem

Synchronisation strategies for reliable communication in large-scale IoT networks.

---

Introduction

Imagine a room filled with 500 people, all trying to have a conversation at the same time. The result is chaos—nobody can hear anything clearly. This is precisely what happens in an IoT network when many devices transmit simultaneously. Packets collide, data is lost, and retransmissions waste precious battery life and bandwidth.

The IoT collision problem is one of the most critical challenges in scaling sensor networks. As you add more devices, the probability of simultaneous transmissions increases, leading to:

• Data loss – messages never reach the server
• Increased power consumption – retransmissions drain batteries
• Reduced network capacity – effective throughput plummets
• Unpredictable behavior – critical alarms may be missed

This article explores the causes of collisions, compares transmission strategies, and provides practical solutions—from simple chaotic timing to sophisticated synchronised scheduling. We’ll also look at how N3xar’s SyncMaster technology solves this problem in real-world deployments.

---

1. Understanding the Collision Problem

1.1 What Causes Collisions?

Collisions occur when two or more nodes transmit data on the same communication channel at the same time. In radio-based networks (LoRa, Wi-Fi, BLE), this means the signals overlap and become corrupted at the receiver.

Time:  |--- Node A TX ---|---|
       |--- Node B TX ---|---|  ← Collision!
       |--- Node C TX --------|---|  ← Another collision!

1.2 Why Collisions Are a Problem

Consequence	Impact
Data loss	Critical messages may never reach the server
Retransmissions	Waste battery life and bandwidth
Increased latency	Messages take longer to get through
Reduced network capacity	Effective throughput drops dramatically
Unpredictable behavior	System performance becomes erratic

1.3 The Mathematics of Collisions

In a simple network where nodes transmit randomly at a fixed interval, the probability of a collision follows this relationship:

Collision Probability ≈ 1 - e^(-2 * Nodes * TX_Duration / TX_Interval)

Where:
- Nodes = number of active transmitters
- TX_Duration = time to send one packet
- TX_Interval = time between transmissions (per node)

Example:

• 100 nodes, each transmitting every 60 seconds
• Each transmission takes 0.5 seconds
• Collision probability ≈ 1 - e^(-2 * 100 * 0.5 / 60) ≈ 81%

This means over 80% of transmissions could collide—a disaster for any system.

1.4 Key Factors Affecting Collisions

Factor	Impact on Collisions
Number of nodes	More nodes = more collisions
Transmission frequency	More frequent = more collisions
Packet duration	Longer packets = larger collision window
Channel capacity	Limited bandwidth = more contention
Physical environment	Reflections, interference = more errors

---

2. Transmission Strategies

2.1 Chaotic (Random) TX Period

Implementation: Each node transmits at random intervals. For example, instead of exactly every 60 seconds, a node might transmit every 45-75 seconds (random offset).

How It Works:

1. Each node generates a random delay before each transmission
2. Delays are typically within a defined range (e.g., ±30% of the base interval)
3. No coordination between nodes

Advantages:

• Simple to implement – no complex logic required
• No RX required – nodes don’t need to receive synchronization signals
• Works with small networks – fine for <20 nodes
• Low overhead – no extra communication for coordination

Disadvantages:

• High collision probability – especially as network grows
• Unpredictable behavior – can’t guarantee message delivery
• Wasted power – retransmissions drain batteries
• Does not scale – quickly becomes unusable beyond ~50 nodes

When to use:

• Small deployments (<20 nodes)
• Non-critical data (logging, trend analysis)
• Simple proof-of-concept installations

2.2 Synchronized Transmission

Implementation: A central coordinator sends a synchronization signal. Each node calculates its exact transmission time based on this signal and its unique identifier.

How It Works:

1. The gateway (SyncMaster) broadcasts a time sync signal
2. Each node calculates its allocated time slot:

   TX_Time = Sync_Time + (Node_ID × Slot_Duration)

3. Nodes transmit in their assigned slots
4. Slots are sized to accommodate the longest packet plus guard time

Advantages:

• No collisions – each node has its own time slot
• Predictable behavior – know exactly when data will arrive
• Energy efficient – no retransmissions wasted
• Scales well – supports thousands of nodes
• Deterministic – guarantee message delivery within known time

Disadvantages:

• Requires RX capability – nodes must listen for sync signal
• Sync dependency – nodes rely on sync signal timing
• Complex implementation – more code and testing required
• Frequent sync overhead – sync transmissions consume bandwidth
• Dead time – slots may be empty if nodes are not transmitting

When to use:

• Medium to large deployments (>20 nodes)
• Critical data that cannot be lost
• Low-power networks where every transmission counts
• Applications needing deterministic behavior

2.3 Carrier Sense Multiple Access (CSMA)

Implementation: Nodes listen before transmitting and only send if the channel is clear.

How It Works:

1. Node checks if channel is busy (carrier sense)
2. If clear, node transmits
3. If busy, node waits a random backoff time and tries again
4. Optional: Listen while sending to detect collisions (CSMA/CD)

Advantages:

• Adaptive – responds to network load
• Reduces collisions – nodes don’t trample each other
• Simple to implement – supported by many radio modules

Disadvantages:

• Hidden node problem – two nodes may not hear each other
• Exposed node problem – nodes may defer unnecessarily
• Wasted listening time – powered on but not transmitting
• Not suitable for battery-powered – listening consumes power

When to use:

• Wi-Fi networks (CSMA/CA is standard)
• Mains-powered nodes
• Networks where listening power isn’t a concern

---

3. Collision Resolution Strategies

3.1 Backoff Algorithms

When a collision occurs, nodes must retransmit. How they decide when to retry is critical.

Exponential Backoff (Wi-Fi Standard):

• Wait random time between 0 and 2^n slots (where n = retry count)
• Increases the wait time with each retry
• Reduces likelihood of repeated collisions

def exponential_backoff(retry_count):
    max_slots = 2 ** retry_count
    delay = random.randint(0, max_slots) * SLOT_TIME
    wait(delay)
    retry_transmission()

Random Backoff:

• Wait random time between 0 and max_delay
• Simpler but less effective under load

3.2 Retransmission Policies

Policy	Description	Best For
No retry	Drop packet, move on	Non-critical data, rate-limited sensors
Limited retry	Retry N times, then drop	Most IoT applications
Infinite retry	Retry until success	Critical alarms, control commands
Store and forward	Cache data, retry later	Offline-capable nodes

3.3 Quality of Service (QoS) Prioritization

Not all messages are equal. Critical messages should have higher priority.

QoS Levels (MQTT):

QoS	Description	Collision Handling
0 (At most once)	Send once, no confirmation	No retries, can be lost
1 (At least once)	Confirm receipt	Retry on failure
2 (Exactly once)	Four-way handshake	Multiple retries until confirmed

Prioritization:

• Alarms: QoS 2, immediate priority
• Routine data: QoS 0 or 1, normal priority
• Configuration updates: QoS 1, scheduled priority

---

4. LoRa-Specific Considerations

4.1 LoRa Physical Layer

LoRa is particularly sensitive to collisions because of its long transmission times.

Factors:

• Spreading Factor (SF): Higher SF = longer range, longer TX time, more collisions
• Bandwidth (BW): Wider BW = shorter TX time, shorter range
• Payload size: Larger payload = longer TX time

TX Duration vs. Spreading Factor:

SF	TX Duration (50 bytes)	Range	Collision Risk
SF7	40 ms	Short	Low
SF8	80 ms	Medium	Medium
SF9	160 ms	Medium	Medium-High
SF10	320 ms	Long	High
SF11	640 ms	Very Long	Very High
SF12	1,280 ms	Extreme	Extreme

4.2 LoRa’s Duty Cycle Limits

In many regions, LoRa is restricted by duty cycle regulations:

Region	Duty Cycle Limit
Europe (EU868)	1% (max 36 seconds per hour)
US (US915)	No duty cycle limit (FCC)
Asia (AS923)	1% (varies by country)

Implication: With duty cycle limits, collisions waste not just battery but also the limited airtime available.

4.3 LoRa Collision Solutions

Diversity (Multi-channel):

• Use multiple frequencies (channels)
• Avoid channels with known interference
• Distribute nodes across channels

Spreading Factor Distribution:

• Use different SFs for different nodes
• Orthogonal spreading factors (SF7 and SF8 don’t interfere)
• Increase network capacity

Synchronized Transmission (SyncMaster):

• Single best solution for high-density LoRa networks
• Eliminates collisions entirely
• Maximizes duty cycle usage

---

5. The SyncMaster Solution (N3xar)

5.1 What Is SyncMaster?

SyncMaster is N3xar’s time coordination system that synchronizes transmission timing across all nodes to eliminate collisions and optimize airtime usage.

5.2 How It Works

┌─────────────────────────────────────────────────────────────────┐
│                   SyncMaster Operation                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Gateway broadcasts sync pulse every N seconds               │
│                         │                                       │
│                         ▼                                       │
│  2. All nodes receive sync pulse and sync their internal        │
│     clocks                                                      │
│                         │                                       │
│                         ▼                                       │
│  3. Each node calculates its unique TX time:                    │
│     TX_Time = Sync_Time + (Node_ID × Slot_Duration)             │
│                         │                                       │
│                         ▼                                       │
│  4. Nodes transmit in their allocated slots                     │
│                                                                 │
│  5. No collisions → reliable, efficient communication           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

5.3 Key Features

Feature	Description
Zero collisions	Each node has its own time slot
Predictable timing	Data arrives on schedule
Battery efficient	No retransmissions wasted
Scales to thousands	Support for large networks
Adaptive slot sizing	Adjusts based on packet size
Fallback mode	Random backoff if sync signal lost

5.4 Implementation Example (Pseudo-code)

Node Side:

// SyncMaster node implementation
void syncmaster_node_init() {
    // Configure radio for RX
    radio.set_mode(RX_MODE);
    
    // Listen for sync pulse
    sync_time = wait_for_sync_pulse();
}

void syncmaster_node_loop() {
    // Calculate TX time
    uint32_t slot = node_id * SLOT_DURATION;
    uint32_t tx_time = sync_time + slot;
    
    // Wait for our slot
    while (current_time() < tx_time) {
        sleep();
    }
    
    // Transmit data
    radio.set_mode(TX_MODE);
    radio.send(packet);
    radio.set_mode(RX_MODE);
}

Gateway Side:

// SyncMaster gateway implementation
void syncmaster_gateway_loop() {
    while(1) {
        // Send sync pulse
        radio.set_mode(TX_MODE);
        radio.send_sync_pulse();
        radio.set_mode(RX_MODE);
        
        // Calculate slot count and duration
        // Optionally receive data
        for (int slot = 0; slot < total_slots; slot++) {
            wait_for_slot(slot);
            receive_data();
        }
        
        // Wait until next sync cycle
        wait_until_next_cycle();
    }
}

5.5 Benefits of SyncMaster

Benefit	Impact
Collision elimination	Zero packet loss due to collisions
Predictable bandwidth	Know exactly how many packets per minute
Battery life extension	No retransmissions, efficient sleep
Scalability	Add hundreds of nodes without performance loss
Reliability	Critical messages always get through
Airtime efficiency	Maximize data per minute of airtime

---

6. Protocol-Specific Considerations

6.1 LoRa vs. Wi-Fi

Aspect	LoRa	Wi-Fi
Collision handling	Must be designed in	CSMA/CA built-in
TX duration	Long (40-1,280ms)	Short (microseconds)
Duty cycle	Limited (1%)	Unlimited
Power	Very low	High
Sync required	Highly recommended	Not required
Hidden node problem	Significant	Addressed via RTS/CTS

6.2 When to Use Synchronization

Synchronization is essential when:

• You have >50 LoRa nodes in the same area
• Nodes are battery-powered and can’t afford retransmissions
• Critical messages must be delivered reliably
• Duty cycle is limited (Europe/Asia)
• Predictable data delivery is required

Synchronization is less critical when:

• Node count is low (<20)
• Data is non-critical
• Nodes are mains-powered
• CSMA/CA is already provided (Wi-Fi)
• Random collisions are acceptable

---

7. Practical Implementation Guide

7.1 Step 1: Assess Your Network

Parameter	Value	Impact
Number of nodes	___	Higher = more collision risk
TX interval	___	Shorter = more collision risk
Packet size	___	Larger = longer TX = more collision risk
Battery powered?	Yes / No	Yes = synchronization beneficial
Critical messages?	Yes / No	Yes = synchronization essential

7.2 Step 2: Choose Your Strategy

Node Count	Critical Data	Battery-Powered	Recommended Strategy
<20	No	No	Chaotic (simple)
<20	Yes	Yes	Chaotic (optimized)
20-100	No	No	CSMA (if supported)
20-100	Yes	Yes	Synchronized
>100	Any	Any	Synchronized

7.3 Step 3: Implement Synchronization

Hardware Requirements:

• Nodes must have RX capability (listen mode)
• Gateway must have broadcast capability
• Accurate clock/timer on nodes

Software Requirements:

• Sync pulse detection
• Time slot calculation
• Accurate timer for TX slot
• Fallback mechanism if sync lost

7.4 Step 4: Test and Optimize

Testing Checklist:

• Verify all nodes receive sync pulse
• Measure actual TX times (are they on schedule?)
• Test with full network load
• Simulate loss of sync signal
• Measure battery life before/after

Optimization Options:

• Adjust slot duration for packet size
• Reduce sync frequency to save bandwidth
• Implement adaptive slot sizing
• Add error correction for sync signal

---

8. Real-World Example: N3xar SyncMaster

8.1 Deployment Scenario

• Network: 500 LoRa sensors in a smart agriculture deployment
• Range: Up to 5 km from gateway
• Battery life: Target 3 years on 2x AA batteries
• Data: 50 bytes per transmission, every 15 minutes

8.2 Before Synchronization

Metric	Value
Collision rate	30-40%
Retransmissions	1-3 per message
Battery life	1.5 years
Data loss	10-15%

8.3 After SyncMaster

Metric	Value
Collision rate	<1%
Retransmissions	<1 per message
Battery life	3+ years (target)
Data loss	<0.1%

8.4 N3xar’s Implementation

“Our SyncMaster (Time Coordinator) synchronizes transmission timing across all nodes to reduce signal collisions and optimize airtime usage.”

Key Features:

• Supports both LoRa and Wi-Fi networks
• Adaptive to network conditions
• Fallback modes for reliability
• Centralized management and monitoring

---

9. Advanced Techniques

9.1 Slotted ALOHA

A structured collision resolution protocol where time is divided into slots, and nodes must transmit at the beginning of a slot.

With SyncMaster, you can implement Slotted ALOHA perfectly:

1. Time is divided into equal slots
2. Each node is assigned a slot or range of slots
3. Nodes transmit at slot boundaries
4. No collisions within assigned slots

9.2 TDMA (Time Division Multiple Access)

Each node gets a dedicated time slot in a repeating frame.

Implementation:

Frame = [Slot 1] [Slot 2] [Slot 3] ... [Slot N]
Where each slot is allocated to a specific node.

Advantages:

• Zero collisions
• Predictable latency
• Guaranteed throughput

Disadvantages:

• Inefficient if nodes don’t have data to send
• Fixed frame length wastes bandwidth

9.3 Dynamic Slot Allocation

Slots are allocated dynamically based on node demand.

Approaches:

• Nodes request slots when they have data
• Gateway allocates slots based on requests
• Idle slots can be reused

9.4 Hybrid Approaches

Combining multiple strategies for robustness:

Hybrid Strategy	Description
Sync + CSMA	Nodes listen, then transmit in sync slot
Sync + Random	Sync for normal traffic, random for alarms
Multi-channel + Sync	Different channels for different node groups

---

10. Conclusion

The IoT collision problem is one of the most significant challenges in scaling sensor networks. As node counts grow into the hundreds and thousands, the traditional “random transmission” approach leads to unacceptably high packet loss, wasted battery life, and unreliable system behavior.

Key takeaways:

1. Collisions are inevitable in busy networks – but they can be managed
2. Chaotic transmission works for small networks (<20 nodes) but fails at scale
3. Synchronized transmission eliminates collisions and enables scaling to thousands of nodes
4. SyncMaster (N3xar’s time coordination system) is a proven solution for collision-free LoRa and Wi-Fi networks
5. Choose the right strategy based on your node count, power constraints, and data criticality

“The best time to solve the collision problem is before you deploy your network—not after you’ve lost critical data.”

---

Further Reading

• Overview of Wireless Communication Protocols for IoT — choosing the right protocol for your network.
• Ultra-Low-Power IoT: Achieving <1 µA Sleep Current – power optimisation for battery-powered nodes.
• Designing Scalable IoT Systems: A Practical Guide for Integrators – the main article providing a broad overview of IoT architecture.

---

This article is based on practical experience building the N3xar platform, which implements SyncMaster technology to eliminate collisions in large-scale IoT deployments.