When we started piloting an ORAN-based microcell deployment in three Beirut neighbourhoods six months ago, we knew the textbook tradeoffs going in. What we didn't know was how unevenly those tradeoffs would actually distribute across cells that looked, on paper, almost identical.
The three sites — call them A, B, and C — sit within four kilometres of each other. All three are 4G/5G NSA, all three use the same RU vendor, and all three connect to the same DU/CU stack running on commodity x86 hardware. Yet the operational picture from the first quarter of running them looks startlingly different.
Site A, in a dense mixed-use street, has been the closest to what the vendor brochures imply. Throughput tracks the link budget closely, handovers are clean, and the only operational pain has been a recurring x2 reconfiguration glitch we eventually traced to a misbehaving NTP source on the timing reference.
Site B, on a hill with line-of-sight to two other macros, has been a master class in interference. The CU's interference coordination logic, which works well in our simulator, turned out to be operating on stale neighbour-list data the moment a competing operator activated a new cell on an adjacent band. We worked around it by feeding the CU a manually curated neighbour list daily, while we waited for the vendor to ship a fix.
Three cells within four kilometres, identical hardware. The only one that matched our model was the one with the simplest environment.
Site C is the one we still don't fully understand. By every measurement we have, the radio side is healthy — RSRP, RSRQ, SINR all in normal ranges. But sustained throughput drops by roughly 30% during business hours, and recovers overnight, in a pattern that does not correlate with any obvious load metric. We've ruled out the obvious — neither the backhaul, the DU, nor the CU shows resource pressure during these windows. Our current best hypothesis is a thermal envelope issue on the RU itself, but we haven't been able to reproduce it on the bench.
Three takeaways for anyone considering a similar pilot:
Trust your timing source absolutely or have a backup plan. Site A's x2 issue ate roughly 40 hours of engineer time before we located it, and it would have been invisible to a non-ORAN deployment because a vendor-integrated stack would have handled it transparently.
Neighbour-list management is not a solved problem. It is the kind of thing your CU does for you in a managed deployment, and the kind of thing you discover you have to think about when you are running disaggregated.
Field unknowns dominate. Of the three sites, the only one that matched our pre-deployment model is the one that was simplest to deploy. The cells with more complicated environments produced operational surprises we are still cataloguing.
Subscribe at edgesignal.example for next week's deep-dive on neighbour-list curation.