A parks department 5 GHz PTP bridge link fails when a construction crane swings into the Fresnel zone. What is the most accurate expert diagnosis?
Select an answer to reveal the explanation.
Short Explanation
A crane in the Fresnel zone is like putting a dump truck in the middle of your driveway — the RF path is physically blocked, not 'misrouted.' Clear the line or move the antennas. Bigger TCP windows and random DFS myths won't lift steel out of the beam.
Full Explanation
A parks-department 5 GHz PTP bridge that fails when a construction crane swings into the Fresnel zone is suffering physical path degradation, not a routing or TCP-tuning problem. The Fresnel zone around the line-of-sight path must remain sufficiently clear; metal obstruction raises path loss, multipath, and fade, collapsing SNR and link availability. Expert diagnosis is to restore LOS clearance or redesign geometry (height, aiming, path) so the municipal backhaul remains clear of the crane’s swing envelope.
Calling the failure a Layer-3 routing loop caused by the crane’s steel mass invents a network-layer fault from a physical RF blockage. Treating the crane as DFS radar proof and disabling DFS citywide misattributes a mechanical obstruction to regulatory radar detection. Increasing TCP window size on the bridge endpoints cannot overcome Fresnel blockage; transport windows do not restore a physically impaired RF path.
Exam caveat: outdoor PTP/PTMP designs must protect Fresnel clearance against temporary construction and foliage; DFS and TCP settings are separate concerns. Operational check: map Fresnel radius at the parks link mid-point, confirm crane intrusion with path survey or signal drop timing, then raise/relocate antennas or schedule crane exclusion—not tweak TCP or blank DFS.