3 Reviewing a Wireless Design

3.4 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. Before signing that record, use Figure 3.1 to see where evidence can send a plausible candidate back for redesign.

Follow Figure 3.1 from application claim to constraints and candidate design, then through evidence and validation to the decision record. The return path matters most: failed or incomplete validation reopens the candidate instead of allowing a technology preference to masquerade as approval. This loop is the chapter’s scope-control mechanism. A changed traffic deadline, enclosure, route, operator, gateway position, or duty cycle changes an earlier box and therefore triggers a new pass through the evidence contract.

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.

3.5 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.

Application claim:

3.6 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.