This counter is related to Baseband Connections Intensity Control. It is a load protection mechanism. It ensures that only a predefined number of initial establishments and incoming handovers are processed within a certain time frame. To guarantee that the connections handling in eNB always works as intended, a load protection mechanism is included. This limits the number of simultaneous initial establishments and incoming handovers processed within a certain time
FIRGuY has the mechanism exactly right — pmRrcConnEstabFailDuIntens is the Baseband Connections
Intensity Control tripping, i.e. a deliberate rate limiter on initial establishments + incoming
handovers per baseband, not a generic DU-resource fault. So the counter is telling you the arrival
rate hit the cap. The open question it doesn’t answer is WHY the rate got that high — and that
splits into two very different root causes with opposite fixes:
Genuine busy-hour demand. Real subscriber load on a 6630 carrying a heavy cell/carrier count can
legitimately hit the intensity ceiling at peak. Check pmRrcConnEstabAtt against the failures over
the day — if the DuIntens fails track the attempt peaks and sit at busy hour, it’s real capacity
and the answer is dimensioning: how many cells/carriers this 6630 carries vs its licensed
connection-handling capacity, and whether the site needs load balancing or a baseband upgrade.
A signalling storm faking demand. If DuIntens fails are high while genuine RRC attempts are normal
— or attempts are spiking abnormally — you’re not capacity-limited, you’re being flooded. The
usual culprit is an RRC re-establishment / setup loop: check pmRrcConnReestabAtt and the
connection-drop counters. A cell dropping calls and having UEs pile back in via re-establishment
generates its own intensity spike, so the “overload” is a symptom of a coverage/drop problem
elsewhere, and adding capacity won’t fix it — you fix the drops.
Fast way to tell them apart: overlay pmRrcConnEstabFailDuIntens, pmRrcConnEstabAtt and
pmRrcConnReestabAtt on one timeline. Fails tracking real attempt peaks = capacity (dimension it).
Fails with a re-establishment spike but flat genuine attempts = a drop/coverage loop upstream
(fix that, the intensity clears on its own).
moshell to support it: pmx for the counter family side by side, alt for active baseband/DU alarms,
inv to confirm board type and licensed capacity, and check the configured cell/carrier count on the
6630. If load correlation is clean and it still trips, then it’s worth checking for a known TR against
your exact baseband SW release — but the counter genuinely fires on real intensity far more often
than on a defect, so rule load in or out first.
