3 Reviewing a Wireless Design
mobile wireless design considerations, IoT wireless design review, wireless deployment validation, RF site validation, wireless technology fit
3.1 Start With the Wireless Story
A wireless design is ready only when its claims have records behind them. Start with the application promise, then ask what spectrum evidence, topology notes, power measurements, security choices, operations handoff, and validation tests would convince a reviewer.
3.2 In 60 Seconds
Mobile wireless design is not a technology shopping exercise. A design is credible only when the application claim, site evidence, radio behavior, network access, energy behavior, security needs, operations plan, and validation record agree with each other.
The useful review question is not “which wireless family is best?” It is “what does this device class need to prove, in this place, under these operating states, before the wireless path can be approved?”
Phoebe’s Why
As the EM waves chapter derives, an isotropic antenna’s effective aperture is fixed by wavelength alone, \(A_e=\lambda^2/(4\pi)\). A real, physically sized antenna can do better than that isotropic reference by collecting energy over more of its own physical area – but never all of it, because surface currents, edge effects, and feed losses mean only a fraction of the physical aperture behaves like useful electrical aperture. That fraction is the antenna’s aperture efficiency, and it is what turns a corridor-facing sector panel’s physical size into a specific, calculable gain in dBi – not a marketing number, a consequence of how much of the panel’s face actually participates in collecting or radiating the field.
The Derivation
Effective aperture from physical aperture and efficiency:
\[A_e = \eta_{ap}\,A_{phys}\]
Gain from effective aperture and wavelength (the general form of the isotropic relationship above):
\[G = \frac{4\pi A_e}{\lambda^2}\]
The same gain concentrates radiated power into a smaller solid angle, trading coverage angle for reach:
\[\Omega = \frac{4\pi}{G} \ \text{(steradians)}, \qquad \mathrm{EIRP(dBm)} = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
Worked Numbers: A Corridor Sector Panel At 2.4 GHz
- Panel: \(15.0\times15.0\) cm sector antenna, \(A_{phys}=0.150\times0.150=0.0225\ \text{m}^2\); catalog-typical aperture efficiency \(\eta_{ap}=0.550\) gives \(A_e=0.01238\ \text{m}^2\)
- Gain at \(\lambda=0.125\) m (the 2.4 GHz wavelength from the EM-waves chapter): \(G = 4\pi(0.01238)/0.125^2 = 9.95 \approx 10.0\) dBi
- Coverage angle traded away: \(\Omega=4\pi/9.95=1.26\) sr \(=4{,}140\) deg\(^2\), an equivalent symmetric beamwidth of roughly \(73^{\circ}\) – a fraction of the full sphere an omni antenna covers
- EIRP-limited conducted power: an omni reference antenna (0 dBi) needs \(P_t=20.0\) dBm (\(100\) mW) to reach a 20 dBm EIRP cap; the 10.0 dBi sector panel reaches the same cap at \(P_t=10.0\) dBm (\(10.0\) mW) – a \(10\times\) reduction in RF-stage power for covering one corridor instead of the whole floor
- The review question this settles: “the sector antenna has more gain” is not evidence by itself; the panel’s physical size, efficiency, and the resulting beamwidth are what tell a reviewer whether that gain actually reaches the intended aisles or cabinets, or whether it has aimed the signal past them
3.3 Design Approval Is An Evidence Contract
A mobile wireless design is approved only for the claim and conditions that were actually tested. A lab connection, a coverage map, or a familiar technology name can support an early hypothesis, but none of them proves the installed radio path, device power behavior, service ownership, application delivery, or recovery process by itself.
The design record should connect seven pieces: the application claim, the installed environment, the device and antenna state, the radio and spectrum choice, the topology and service path, the operations owner, and the validation evidence. Missing evidence does not always mean the design is wrong, but it does mean the approval must stay limited. 
Use the loop as a scope-control tool. If the application claim changes from hourly telemetry to immediate command response, the old validation record no longer covers the new claim. If the constraints change because the enclosure, route, operator, gateway location, or duty cycle changed, the candidate design must be rechecked under those new conditions. If the evidence changes because a pilot found retries, missed downlinks, or an operations gap, the decision record should narrow the approval rather than hiding the uncertainty.
The strongest overview review is therefore short but explicit: what behavior is being approved, where it was tested, which device state was used, which service owner is responsible, and what change forces retest. That prevents the common mistake of treating a wireless family name as the approval. Wi-Fi, BLE, 802.15.4, LoRaWAN, or cellular may all be defensible in the right claim; none is defensible without the matching evidence boundary.
If you only need the intuition, use this rule: approve the wireless design only as far as the evidence reaches, and write the retest trigger before the field deployment depends on it.
3.3.1 Core Review Gates
3.3.2 Application Claim
Payload pattern, delay tolerance, command need, outage behavior, mobility, and the end-to-end success state.
3.3.3 Radio And Site Fit
Band, channel, antenna, enclosure, mounting, representative locations, coexistence, route, and movement evidence.
3.3.4 Topology And Energy
Gateway, AP, operator, coordinator, parent, backhaul, join, retry, sleep, command window, and recovery behavior.
3.3.5 Operations And Validation
Credentials, updates, monitoring, ownership, support records, acceptance limits, and retest triggers.
3.3.6 Beginner Review Questions
- What useful result must the wireless path support: report, command, alert, update, ranging, setup, or operator action?
- Where was the final device, antenna, enclosure, mount, and power state tested?
- Who owns the AP, gateway, coordinator, operator service, subscription, credentials, and incident response?
- Which layer first fails or remains unproven: radio path, link access, service route, application delivery, energy, or operations?
- What future change should reopen the approval?
3.4 Build The Design Review Record
A practical review record turns a wireless recommendation into something another engineer can audit. It should separate measured behavior from assumptions, name the first unproven layer, and state whether the decision is accepted, accepted with limits, retest required, redesigned, or escalated.
Keep the record short enough to use during pilot work. It should still cover application need, site and movement context, device state, spectrum fit, topology, service path, power sequence, security, updates, operations, and validation evidence. Long firmware listings are less useful than repeatable evidence tied to the installed points and routes.
3.4.1 Review Workflow
- Define the claim. Record payload, reporting urgency, command need, acceptable delay, outage behavior, and success state.
- Capture installed context. Record site, route, mounting, enclosure, antenna, firmware, power source, service identity, and owner responsibilities.
- Check spectrum and propagation. Review band, channel, antenna placement, obstruction, coexistence, regional settings, and representative measurements.
- Check topology and service path. Review gateway, AP, coordinator, parent, operator service, backhaul, roaming, application path, and recovery behavior.
- Check energy and operations. Review wake, attach, join, retry, sleep, downlink, credential, update, support, rollback, and replacement behavior.
- Make a bounded decision. Record approval scope, limitations, first failing layer, and retest trigger.
3.4.2 Worked Review: Building Sensor Retrofit
A building team wants environmental sensors across several floors. Some sensors are battery powered, some are mains powered, and several are mounted inside equipment rooms or cabinets. The review should split device classes, test representative floors and cabinets, record AP or gateway ownership, capture application publish evidence, and define what changes require retest.
The decision might be: “Accept with limits for tested floors, enclosures, gateway locations, firmware, and reporting interval. Retest after gateway move, enclosure change, channel-plan change, firmware update, credential rotation, or occupancy change that affects channel pressure.”
3.4.3 Review Record Template
Application claim: Device class and power state: Site, route, and mounting context: Technology, band, channel, gateway, AP, or operator: Topology and service path: Radio and coexistence evidence: Join, association, registration, or packet-service evidence: Energy and reachability evidence: Application delivery evidence: Security, update, and recovery plan: First failing or unproven layer: Decision and limitation: Retest trigger:
3.5 Under The Hood: Wireless Failures Cross Boundaries
Under the hood, a mobile wireless design crosses physical, link, service, application, energy, and operations boundaries. A packet can fail because the antenna is shadowed, the channel is busy, the device cannot rejoin, the gateway backhaul is down, the operator profile changed, the application rejected the message, the device slept through a command, or the support team cannot rotate credentials safely.
The implementation review should keep those boundaries separate. A successful association is not the same as an application acknowledgement. A signal measurement is not the same as battery-life evidence. A service plan is not the same as an operations process. Separating the evidence prevents a vague failure report from turning into an unsupported technology replacement.
The boundary order should follow the symptom. A missing measurement starts at product evidence, then walks backward through application acknowledgement, service route, link access, and physical radio evidence until the first unsupported claim appears. A battery complaint starts at the energy sequence, then checks retry count, reconnect behavior, command windows, sleep timing, and the physical causes that might be forcing extra airtime. A support incident starts at ownership, credentials, update, rollback, monitoring, and escalation records before blaming the radio layer.
Good under-the-hood evidence is comparative. Record the same device class in normal, weak, busy, and recovery cases, because a design can look correct only in the easy case. The review should name which variable changed between cases: enclosure, antenna orientation, channel plan, gateway owner, operator profile, firmware version, payload cadence, sleep policy, route, or application endpoint. Without that one-variable discipline, a later failure cannot tell whether the fix came from RF margin, service routing, retry policy, or operations repair.
3.5.1 Physical Boundary
Antenna, enclosure, mounting, body loss, cabinet loss, floor plan, route, and interference determine whether the radio path is usable.
3.5.2 Link Boundary
Join, association, registration, retry, roaming, reconnect, downlink window, and packet-service behavior determine whether the link behaves as required.
3.5.3 Service Boundary
Gateway, AP, coordinator, operator service, subscription, backhaul, routing, monitoring, and ownership determine whether the path survives operations.
3.5.4 Product Boundary
Application acknowledgement, freshness state, command execution, updates, credential recovery, and support workflow determine whether users can trust the result.
3.5.5 Failure Patterns To Test
- Installed enclosure loss: the bench radio works, but the production enclosure or cabinet changes antenna behavior.
- Moving-route gap: a stationary test passes, but a vehicle, handheld, or asset route loses service at expected operating points.
- Retry-driven energy drain: weak coverage or channel pressure makes joins, retries, or reconnects dominate battery use.
- Command reachability mismatch: aggressive sleep saves power but prevents timely downlink or configuration updates.
- Operations drift: AP profiles, gateway placement, subscriptions, credentials, firmware, or owner responsibilities change without retest.
3.5.6 Acceptance Evidence
Acceptance should include normal, weak, busy, moving, retry, reconnect, service-loss, command, update, and recovery cases where they matter to the claim. Record the device state, site or route, firmware, antenna, enclosure, owner, network path, application outcome, and retest trigger for each case. Approve only the scope that those records actually support.
3.6 Summary
Mobile wireless design review starts with a bounded application claim, then tests whether the installed device, radio path, topology, energy behavior, security model, operations owner, and application delivery can support that claim. The result should be an approval with limits, a retest decision, a redesign request, or an escalation, not a broad technology label.
3.7 Key Takeaway
Approve mobile wireless designs only as far as the installed evidence reaches, and define the retest trigger before firmware, enclosure, route, service, or ownership changes invalidate the decision.
3.8 See Also
- Mobile Wireless Technologies Basics for the earlier family-selection record.
- IoT Frequency Bands and Licensing for band, regional, and coexistence evidence.
- Wireless Propagation and Design for link-margin and installed-site evidence.
- Cellular Architecture for IoT for traffic-path, identity, radio/core, and reachability review.