As KNX RF systems grow beyond a few switches and sensors, network load becomes the defining factor for long-term performance. Many KNX RF projects appear stable during commissioning but develop delays, missed commands, or inconsistent behaviour months later. In most cases, the root cause is not range, battery, or ETS logic — it is uncontrolled telegram density.
This article is a deep technical guide for consultants and system integrators who design, review, or audit KNX RF systems. It explains how KNX RF traffic actually behaves, what practical limits exist, and how to design RF networks that remain stable as the system scales.
1. What “Network Load” Really Means in KNX RF
In wired KNX TP systems, network load is often discussed in terms of bus utilization. In KNX RF, the concept is similar but with additional constraints imposed by radio transmission and regulations.
KNX RF network load is determined by:
- Number of RF devices
- Frequency of telegram transmission
- Type of telegrams (event vs cyclic)
- Secure vs non-secure payload size
- RF retries due to poor signal quality
- Gateway processing capacity
Unlike TP, RF devices cannot transmit freely at any time. Every transmission consumes:
- Battery energy
- RF airtime
- Gateway processing resources
This makes load management essential.
2. Regulatory Limits That Shape RF Performance
KNX RF operates in the sub-GHz ISM band under regulations that enforce duty cycle limits. These limits restrict how long a device is allowed to transmit within a given time window.
The KNX RF standard, maintained by the KNX Association, is intentionally designed around these constraints.
Implications of duty cycle rules:
- Continuous communication is impossible
- Frequent cyclic updates are discouraged
- Event-based transmission is preferred
- Burst traffic must be avoided
KNX RF performance is therefore a traffic-engineering problem, not a raw bandwidth problem.
3. Telegram Types and Their Load Impact
Not all telegrams are equal. Understanding telegram behavior is critical.
3.1 Event-Based Telegrams (Low Load)
Examples:
- Button press
- Motion detected
- Window opened
Characteristics:
- Infrequent
- Short
- Predictable
- Power-efficient
These form the ideal traffic pattern for KNX RF.
3.2 Cyclic Telegrams (High Load)
Examples:
- Temperature updates every few minutes
- Periodic status reporting
- Repetitive sensor measurements
Characteristics:
- Regular
- Often unnecessary
- Battery-draining
- Major contributor to RF congestion
Key insight:
One cyclic sensor can generate more traffic than dozens of switches.
4. Telegram Density: Why “Few Devices” Can Still Mean “High Load”
A common misconception is:
“We only have 10 RF devices, so load cannot be a problem.”
In reality:
- 10 devices × frequent cyclic updates = high load
- 50 devices × event-only communication = low load
Telegram density (telegrams per hour) matters more than device count.
5. Secure vs Non-Secure Traffic (Measured Impact)
KNX RF Secure adds:
- Encryption
- Authentication
- Replay protection
This results in:
- Slightly larger telegrams
- Marginally longer transmission time
Technical reality:
- Secure overhead is small
- Poor design choices dominate load impact
- Secure is not a bottleneck when systems are engineered correctly
Avoid disabling security to “improve performance” — it rarely solves the real problem.
6. Gateway Processing Capacity (Often Overlooked)
RF gateways are not passive devices. They:
- Receive RF telegrams
- Decrypt (if Secure)
- Convert to KNX TP/IP format
- Forward traffic
- Handle acknowledgements and retries
As load increases:
- Gateway latency increases
- Queues form
- Telegrams may be delayed or dropped
Design implication:
Gateway capacity is a hard limit — not a suggestion.
Distributing RF devices across multiple gateways is often more effective than tuning parameters endlessly.
7. RF Retries: The Hidden Load Multiplier
Poor RF conditions cause:
- Missed acknowledgements
- Automatic retransmissions
- Increased airtime usage
Each retry:
- Consumes battery
- Increases network load
- Competes with other telegrams
Important insight:
A marginal RF link does not just affect one device — it degrades the entire RF network.
This is why coverage planning and load planning are inseparable.
8. Interaction Between RF Load and Battery Life
High network load affects batteries in two ways:
- More transmissions per device
- More retries due to congestion
This creates a feedback loop:
- Congestion → retries → battery drain
- Battery drain → weaker transmissions → more retries
Many “battery problems” are actually network load problems.
9. KNX RF vs KNX TP Load Behavior (Key Difference)
| Aspect | KNX TP | KNX RF |
|---|---|---|
| Power availability | Continuous | Limited |
| Retries impact | Minimal | High |
| Cyclic traffic tolerance | Moderate | Low |
| Burst traffic tolerance | Good | Poor |
This is why design habits from TP cannot be copied directly to RF.
10. ETS Configuration Choices That Increase Load
Common High-Load Mistakes
- Enabling cyclic transmission by default
- Broadcasting frequent status feedback
- Multiple group addresses per object
- Scene feedback on every action
Better Practice
- Event-only communication
- Feedback only where logic requires it
- Minimized group address fan-out
ETS allows flexibility — discipline creates performance.
11. Scaling KNX RF Systems Safely
Small Systems (Apartments)
- One gateway
- Mostly event-based devices
- Minimal cyclic traffic
Medium Systems (Villas)
- Gateways per floor
- RF zones aligned with usage
- Strict control of sensor updates
Large Systems (Commercial / Multi-floor)
- Multiple gateways mandatory
- RF used selectively
- Wired KNX preferred for heavy traffic
RF scales best horizontally, not densely.
12. Monitoring and Diagnosing Load Issues
ETS tools help identify symptoms:
- Delayed telegrams
- Missing acknowledgements
- Bursty traffic patterns
However, ETS shows effects, not causes. Root causes are usually:
- Excessive cyclic traffic
- Poor gateway placement
- Overloaded RF zones
13. Design Rules for Long-Term Performance
Always
- Prefer event-driven communication
- Distribute RF load across gateways
- Plan RF coverage generously
Avoid
- High-frequency cyclic updates
- Single-gateway designs for large areas
- Treating RF like wired bus
KNX RF rewards conservative, structured design.
14. Lifecycle Perspective (Why This Matters Years Later)
Systems rarely fail on day one. Load-related problems:
- Appear after configuration changes
- Grow as devices are added
- Become visible as batteries age
Designing below limits ensures:
- Predictable response
- Stable battery life
- Minimal service calls
Conclusion
KNX RF performance is governed not by range alone, but by network load and telegram density. Understanding how traffic is generated, processed, and constrained allows consultants and integrators to design RF systems that remain stable, responsive, and efficient as they grow.
High-performing KNX RF systems are not optimized aggressively — they are designed conservatively.
Network load is not something to “fix later”.
It is something to engineer from the beginning.
