Compare
SiteOps Command vs iBwave
iBwave is a benchmark for in-building wireless engineering. SiteOps Command treats cellular as one discipline among many on a single building model — so the conflict between a DAS remote and a Wi-Fi radio is analysed on the same geometry as the cameras, doors and cabling around them.
Where each tool fits
An honest frame beats a feature war. iBwave earns its standing in dedicated RF and DAS work. The question is what happens to the rest of the building.
If in-building wireless is the project — carrier coordination, deep RF, a building whose other systems are somebody else's problem — a dedicated RF suite is the correct instrument, and we will say so plainly.
Most integrators are not in that position. The DAS goes into a building that also needs Wi-Fi, cameras, access control, cabling and power, and in a point-tool stack each of those keeps its own interpretation of the building. The racking you model for cellular propagation does not exist in the camera tool. And the Wi-Fi radio that the cellular remote will interfere with is in a different application entirely.
We compare on capability and architecture only: no accuracy claims, no invented benchmarks, and no suggestion that our component library rivals a dedicated RF house's. What we do claim is that cellular here is computed from published standards on the same geometry as every other discipline — and that the interference between them is analysed rather than left to the commissioning engineer to discover.
Capability by capability
| Capability | SiteOps Command | iBwave |
|---|---|---|
| In-building cellular / DAS coverage design | ✓ | ✓ |
| Centre of gravity | Facility technology engineering — 11 disciplines on one building model | In-building wireless engineering |
| DAS engine basis | Public standards — 3GPP TS 36.214 (RSRP/SINR), TS 36.213 (uplink margin), IEC 62037 (passive intermodulation), FCC Part 20 (oscillation isolation) | Dedicated RF modelling suite |
| Feeder-tree solving with per-branch loss budget | ✓ | ✓ |
| Cross-domain interference between DAS and Wi-Fi | Both radios live on one model — adjacent-band leakage and donor-power desense are analysed between them, on the same geometry as the cameras, doors and cabling | Wi-Fi and DAS are both supported technologies in iBwave Design (vendor product page, verified 2026-09-19). Whether it analyses interference between them is not something we have verified, so this row does not claim it either way |
| Camera coverage on the same model (DORI, 3D POV, IR) | ✓ | — |
| Access control, doors and egress on the same model | ✓ | — |
| Conference A/V, paging and sound masking on the same model | ✓ | — |
| Structured cabling and PoE/electrical on the same model | ✓ | — |
| One obstacle model shared across every discipline | ✓ | — |
| Design → BOM → quote → install → as-built → renewal | ✓ | — |
| RF spectrum analysis | — | — |
| Survey-hardware capture | No — predictive, with optional calibration from readings you supply | Supports measured import |
The conflict a DAS-only tool cannot see
This is the difference that is architectural rather than incremental, and it is worth being concrete about.
A cellular remote and a Wi-Fi access point mounted in the same ceiling can each pass their own design review and still degrade one another — co-channel overlap, adjacent-channel leakage, or intermodulation products landing where a receiver is listening. Nothing in either design is wrong on its own. The failure exists only in the space between them.
A tool that holds the DAS design and not the Wi-Fi design cannot evaluate that, and neither can the Wi-Fi tool looking the other way. Here both radios read the same model, so the conflict is found on every analysis, carries a severity that counts against the design, and feeds the remediation list. The same machinery covers voice alarm against sound masking, electrical harmonics into RF, ground-loop hum into audio, and low-voltage separation from power — each checked against the standard that governs it.
This is not collision detection. None of these systems need to touch.
What the cellular numbers are built on
Named standards rather than a proprietary black box — and the honest limits published alongside them.
- 3GPP
- TS 36.214 · TS 36.213
- The standards our DAS downlink and uplink math is built on
- IEC 62037
- Passive intermodulation screening
- IM3 products checked against the deployed band plan
- DAS ↔ Wi-Fi
- Analysed as one problem
- Two radios on one model, not two tools with two models
- 11 disciplines
- On the same geometry
- DAS is one engine here, not the whole product
Questions about cellular and DAS
Is SiteOps Command an iBwave alternative?
For in-building cellular design inside a wider low-voltage project, yes. The difference is architectural rather than a feature count: our DAS engine reads the same building model as Wi-Fi, cameras, access control, cabling and power, so the design carries into a BOM, a scope and a renewal lifecycle. If your work is exclusively in-building wireless — carrier-facing, deep RF, nothing else in the building — a dedicated RF suite remains the right instrument, and iBwave is exceptionally mature at it. Public-safety radio is not covered: our DAS engine models carrier bands only, so an ERRCS or public-safety BDA design stays with a dedicated public-safety tool.
How does your DAS accuracy compare to iBwave?
We do not publish an accuracy comparison, because no independent measured-versus-computed benchmark exists and we will not invent one. What we publish is the basis of every number: downlink RSRP and SINR per 3GPP TS 36.214, uplink margin against source sensitivity per TS 36.213, passive-intermodulation screening per IEC 62037, and the FCC Part 20 required-isolation rule. The deterministic engines own every figure.
What can you do that a dedicated DAS tool structurally cannot?
Analyse the interference between DAS and everything else in the ceiling. A cellular remote and a Wi-Fi radio can desense each other through co-channel overlap, adjacent-channel leakage or intermodulation products landing in the wrong band — and that conflict is invisible to any tool that holds only one of the two designs. Because both radios sit on one model here, those conflicts are found, carry a severity that counts against the design, and feed the remediation list. The same applies to a variable-frequency drive raising the noise floor, or power cable run too close to low-voltage.
Do you have a component library as deep as theirs?
Almost certainly not, and we are not going to imply otherwise. A dedicated RF house has spent years on a component database, and the figures quoted for theirs are their own published numbers rather than anything we have measured. Our product library is built around the disciplines we compute, and controller and radio capacity is read from it rather than invented. If a specific part you need is missing, that is a fair question to put to us directly.
What happens to the cellular design when the building changes?
In a two-tool stack, racking added to the Wi-Fi model does not exist in the DAS model. Here there is one obstacle model — add the racking once and the affected engines re-compute, cellular included, along with the camera occlusion and the cable pathways that racking also changes.
Bring a building with cellular in it
Put a real floor plan in front of us and see the cellular design, the Wi-Fi design, and the interference between them computed on one model.