PCell attempts increased post frequency reforming done in C-Band

5G NR
1

Hi Experts,

Recently frequency reforming done in C-Band, from 60MHz to C1-40MHz (Exsting frequency) & C2-20MHz (New frequency), after implementation observed raise in Pcell attempts in all sectors, all KPIs are normal no major degradation found. What could be the reason??

Thanks…

2

Expected, not a fault — you turned one carrier into two, so the number of PSCell/PCell addition attempts roughly doubles by design.

Before: one 60 MHz C-Band carrier = one candidate cell per sector, so one PCell/PSCell add attempt per UE.

After: 60 MHz split into C1 40 MHz + C2 20 MHz = two carriers per sector. Every UE that would have added the single carrier now has two candidate cells, and the network attempts addition on both (and re-attempts as UEs move between them, plus inter-carrier additions). So attempts rise across all sectors uniformly — which is exactly your symptom, “all sectors, no KPI degradation.”

The reason KPIs stay clean is the confirmation: attempts went up but success rate, drops, and throughput are stable, meaning the extra attempts are succeeding. If it were a real problem you’d see the attempt rise with a falling success rate or rising abnormal releases — you don’t.

Check two things to close it out, not because anything is wrong:

  • Attempt count roughly doubled but PCell/PSCell addition success ratio held → healthy, it’s just the new carrier count.
  • Watch load balancing between C1 and C2. With 40 vs 20 MHz, if idle/connected-mode distribution isn’t weighted toward the wider C1, C2 can take more UEs than its bandwidth warrants — no failure, but a throughput-per-UE imbalance worth tuning.

So: the raised PCell attempts are the direct arithmetic of splitting one carrier into two. Normal post-reforming behaviour, nothing to fix — just confirm the success ratio and the C1/C2 traffic split.

3

Check two things to close it out, not because anything is wrong:

  • Attempt count roughly doubled but PCell/PSCell addition success ratio held → healthy, it’s just the new carrier count–
  • Watch load balancing between C1 and C2. With 40 vs 20 MHz, if idle/connected-mode distribution isn’t weighted toward the wider C1, C2 can take more UEs than its bandwidth warrants — no failure, but a throughput-per-UE imbalance worth tuning.---- no chages observed in overal traffic (C1+C2) and No Change observed in RRC Active count.
4

That confirms it’s fully benign, not just benign-so-far. Total traffic (C1+C2) flat and RRC Active user count flat means the same users and the same load are now spread across two carriers instead of one — so nothing extra is on the network; the addition attempts simply doubled because each admitted UE now has two candidate carriers to be added on instead of one.

If traffic and RRC Active had been flat while attempts rose AND success ratio dropped, that would be churn — UEs bouncing between C1/C2. But you already confirmed KPIs and success are clean, so it’s not churn either. It’s pure accounting: one carrier’s worth of demand, counted as attempts across two carriers.

Close it as expected behaviour of the split, no action. The one thing still worth a glance for optimisation only (not a fault): per-UE throughput on C2 (20 MHz) vs C1 (40 MHz) — with load spread evenly by count, C2 users get half the spectrum, so if you want, bias idle/connected distribution toward C1 so users land more on the wider carrier. Purely efficiency, nothing broken.

5

a3 Threshold set for C1= -116 & for C2 = -114, given priority to C1 as we know it has more CBW, when there is a payload increase in C1, CA will handle accordingly.. but still how can we coclude it for justification, any better reason behind on Pcell rise.

6

The PCell-attempt rise is the arithmetic of the split, two benign effects:

  1. Carrier count: one 60 MHz carrier (one candidate PCell per sector) became two (C1 40 + C2 20). The same UEs now distribute PCell selection across two cells with the other added as SCell, so the attempt counter summed over both cells rises proportionally — no new users.
  2. New inter-carrier mobility: a second carrier that didn’t exist now generates C1↔C2 reselection/HO and CA (re)configuration events. New by construction, adds to the count — again no new users or load.

Proof it’s these two and not a fault is your own KPIs: aggregate traffic (C1+C2) flat, RRC Active flat, PCell/SCell add success ratio stable. Churn or degradation would show attempts up with success down, or RRC Active up, or abnormal releases up — none present. Same user population served across two carriers. No action needed.

Keep your A3 weighting (C1 -116, C2 -114, priority to C1) — it’s correct for steering load to the wider carrier. But report it as “load biased to the wider carrier for efficiency,” separate from the attempt-rise justification. The cause is carrier count + new inter-carrier mobility; the A3 setting only governs where load lands, not the count.