The vendor manual for our distributed antenna system has a section on beam-management thresholds that, if you skim it, looks like a handful of small parameters with sensible-sounding defaults. We deployed those defaults in a 12-floor mid-rise office building. Within a week we were getting tickets from users on the centre floors complaining that calls dropped every time they walked between rooms. The cause was beam-management oscillation. The fix took three site visits and a lot of patience.
The vendor's defaults are not wrong, exactly — they are tuned for macro deployments where antennas serve large open areas with relatively few overlap points. A DAS deployment is the opposite of that. You have many small antennas, deliberately overlapping, intentionally creating handover boundaries inside corridors and stairwells. The hysteresis values that prevent ping-pong between two macros 200 metres apart do not prevent ping-pong between two DAS antennas 8 metres apart with overlapping coverage cones.
The first symptom we saw was a handover-attempt rate that, in our centre floors, was three times higher than on the perimeter floors of the same building. Most attempts succeeded. Some attempts succeeded and then immediately re-handed-back. A small fraction failed outright and dropped the call. The default time-to-trigger of 256 ms was being met, then violated, then met again, on a roughly one-second cycle as users walked.
Vendor defaults assume macro overlap geometry. DAS antennas are 8 metres apart. The math doesn't transfer.
We hand-tuned three parameters per cell: time-to-trigger up from 256 ms to 640 ms, A3 offset from 3 dB to 5 dB, and hysteresis from 1 dB to 2 dB. The combination triples the dwell time required before a UE will switch antennas, which in DAS context simply means the UE has to be solidly on the new antenna's cone before the handover fires. The handover-attempt rate dropped to roughly the perimeter-floor baseline within an hour. Dropped calls in those zones went to zero in our follow-up week.
The deeper lesson, which we keep relearning, is that the vendor parameter defaults are documented as if they were universal but were chosen against a specific deployment archetype. If your geometry differs from that archetype, the defaults will be wrong, and they will be wrong in ways that the vendor's monitoring tools may not flag prominently. You have to know to look.
Three takeaways:
Vendor defaults are not universal. They were tuned against a specific deployment style. If your geometry is different, expect to retune.
Handover-attempt rate is the leading indicator. Not dropped calls — by the time you see those, you've been losing users. Watch the attempt rate.
Time-to-trigger is the most useful single knob. Doubling or tripling it eliminates most DAS oscillation without breaking macro behaviour.
Subscribe at edgesignal.example — next month's deep-dive: a parameter-tuning playbook for new DAS rollouts.