5G Mid-Band Cell: Throughput Collapse Six Weeks After Launch
Northbridge Mobile launched 5G on n78 (3.5 GHz, 100 MHz, TDD pattern DDDSU) six weeks ago from a single rooftop site: 25 m height, three sectors, 64T64R active antenna units, mechanical downtilt 4 degrees, no electrical tilt applied, 3 Gbps backhaul. At launch the median busy-hour downlink throughput measured at 700-900 m from the site was 420 Mbps. It is now 180 Mbps while PRB utilisation on the busiest sector sits at 38%. Drive tests at 800 m show SS-RSRP between -98 and -106 dBm and SS-SINR between 1 and 4 dB. Uplink grants and backhaul show no congestion. A competing site 1.2 km away uses the same 100 MHz and its sectors overlap the Northbridge footprint; PCI planning was inherited from the LTE grid with the mod-3 rule applied by hand. Twenty-two customers have complained in three weeks and two have escalated to the regulator, which publishes a 30 Mbps busy-hour cell-edge commitment.
1. Is this a capacity problem or a coverage/interference problem? Set out the evidence and state what you would rule out before touching the radio parameters.
Read the worked answer
Verdict: interference-limited at the edge, not capacity-limited.
- PRB utilisation of 38% in the busy hour is inconsistent with a capacity ceiling. A 100 MHz n78 carrier on 64T64R should sit above 80% utilisation before throughput collapses; confirm with per-QCI scheduler queue and drop statistics, not just the PRB counter.
- The fall from 420 to 180 Mbps median with no reported demand change points to radio quality, and the quality metric confirms it: SS-SINR 1-4 dB while SS-RSRP is -98 to -106 dBm. RSRP at 800 m from a 25 m rooftop with correct tilt should be roughly -85 to -92 dBm, so the serving signal is weaker than the geometry implies.
- Kestrel had 3 Gbps of backhaul and clean uplink grants, which rules out transport, core and uplink congestion as the cause.
Rule out, in this order: backhaul/transport counters, uplink interference (check PUSCH SINR and RSSI per PRB), core and UPF throughput limits, and device capability mix. None of these should be accepted as the answer until the radio data is in.
Then gather before acting: per-beam RSRP/SINR from the 64T64R grids of best effort, timing-advance distribution (to see how many users sit beyond the intended cell radius), neighbour cell RSRP at the same test points, and a PCI mod-3 / mod-30 conflict check against the co-channel site 1.2 km away. If the strongest neighbour is within 3 dB of the server at 800 m, the cell is overshooting and the PCI plan may also be colliding.
2. Give the remediation sequence you would follow, and explain why adding capacity first would be the wrong call.
Read the worked answer
Sequence:
- Baseline the evidence (48 hours): per-beam RSRP/SINR, timing advance histogram, neighbour lists, PCI/PRACH audit. Without this you cannot tell overshoot from PCI collision.
- Fix the vertical radiation pattern first. The site has 4 degrees of mechanical tilt and no electrical tilt. On a 64T64R AAU the broadcast beam is set digitally; adding mechanical tilt moves the whole pattern, including the grid-of-beams used for traffic. Apply electrical/digital tilt so the SSB coverage edge lands at the planned cell radius (roughly 500-600 m in this clutter), then use mechanical tilt only for fine adjustment. Target: SS-RSRP at 800 m falling to about -100 dBm or lower from the serving cell while the neighbour becomes dominant, which is exactly what triggers a clean handover.
- Re-plan PCI and PRACH. Remove mod-3 (and mod-30 for PRACH) conflicts with the co-channel site; the inherited LTE plan was never re-validated for the new grid. A mod-3 collision alone can suppress SINR by several dB regardless of tilt.
- Re-measure after 48 hours against the same drive route and the same busy hour; compare 5th-percentile SINR, not the median.
- Only then add capacity - a second carrier, a small cell, or sector splitting.
Why not capacity first: at 38% PRB the scheduler is not the bottleneck. Adding a carrier would raise the peak rate of already-good users and leave the 180 Mbps edge users untouched, while spending capex and consuming spectrum. You would then have the same complaints and no remaining explanation.
3. The regulator has received two escalations. Draft the substance of what you report and how you would define the 30 Mbps cell-edge commitment in your measurement.
Read the worked answer
Report the measured truth, not the drive-test best case.
Content of the report:
- Definition used: busy hour (state the hour), outdoor pedestrian/vehicular route, 5th-percentile user throughput per cell, per the regulator's published methodology if one exists - and say explicitly which methodology you applied.
- Current position: median busy-hour throughput 180 Mbps at 700-900 m is healthy; the 5th percentile is expected to fall under the 30 Mbps commitment, which is the actual breach, and it should be disclosed as such.
- Root cause: overshoot from mechanical-only tilt plus PCI/PRACH reuse inherited from LTE, producing SS-SINR of 1-4 dB at 800 m. Say plainly that it is an engineering configuration issue, not a spectrum or backhaul shortage.
- Interim mitigation and dates: electrical tilt change (day 0-7), PCI/PRACH re-plan (day 7-14), re-measurement and report (day 21), capacity action if the 5th percentile is still short (day 30-60).
- Customer handling: proactive credit or remedy for the 22 complainants and the affected postcode grid squares.
What not to do: do not re-define cell edge to the 800 m contour that flatters the result, do not report the drive-test median as if it were the commitment metric, and do not claim the issue is resolved before the post-change measurement. A professional submission that admits a 5th-percentile breach and gives dated remediation is far defensible than a delayed or re-scoped one.