One misaligned parameter and two neighboring 5G sites start jamming each other

RAN
, , ,
1

TDD synchronization gets treated as a one-time deployment checkbox — set the frame structure, move on. But the special slot configuration inside that frame structure is one of the most under-audited parameters in live NR networks, and when it drifts between neighbors, the symptom looks like classic interference when it isn’t.
Here’s the mechanism:

→ NR TDD uses a special slot (format like DDDSU) containing a Downlink pilot (DwPTS), a Guard Period (GP), and an Uplink pilot (UpPTS) — this guard period exists specifically to absorb propagation delay so one cell’s downlink transmission doesn’t collide with a neighbor’s uplink reception window.

→ The GP length has to account for the distance between interfering sites — a guard period sized for tight urban ISD becomes insufficient once you have a macro site with wider coverage nearby, because the propagation delay from that far-off DL transmission bleeds into the neighbor’s UL receive window.

→ If two neighboring sites run different special slot configurations, or even the same config but aren’t frame-aligned at the network level, you get cross-slot interference: one cell’s DL symbols land inside another cell’s expected UL symbols.

This isn’t classic co-channel interference from overlapping coverage — it’s a timing/config mismatch, and it shows up as UL SINR degradation and RACH failures that spike specifically near cell borders with mismatched neighbors.

Field pattern I’ve seen repeatedly: multi-vendor boundary sites (Huawei-Nokia, Huawei-ZTE) where each vendor’s default TDD config differs slightly, or where GPS sync drift on one site isn’t caught until UL KPIs degrade. Standard interference troubleshooting — PCI planning, power tuning — does nothing here because the problem isn’t RF geometry, it’s timing alignment.

Before writing off a UL degradation cluster as interference, pull TDD frame config and GPS sync status across the cluster first, especially at multi-vendor boundaries.

Has anyone chased a “ghost interference” ticket that turned out to be a TDD config or sync mismatch instead?

image
image1384×629 194 KB

image
image1373×491 138 KB

image
image1366×456 124 KB

image
image1365×509 148 KB

LinkedIn: :backhand_index_pointing_down:

2

Yes — chased exactly this. The tell that separates it from RF interference, which your post implies
but is worth making explicit for anyone triaging:

RF interference degrades UL SINR roughly symmetrically across the cell and scales with load. TDD
cross-slot degrades geometrically — worst at the cell edge facing the mismatched neighbour, near-zero
at cell centre, and it’s load-independent (the aggressor’s DL is there whether or not your cell is
busy). So the fingerprint is: UL SINR bad at the border, fine deep in the cell, and it doesn’t move
with traffic. If PRB utilisation is low but edge UL SINR is trash, stop looking at interference.

Two additions to your “pull frame config + GPS” step:

  • It’s not just the special-slot ratio — check the reference/pattern periodicity too (2.5ms
    single vs 2.5ms dual vs 5ms). Two sites can both read “DDDSU” and still collide if one runs a 5ms
    pattern and the other 2.5ms, because the U/D symbols land in different absolute positions per
    frame. Same-format, different-periodicity is the sneakiest version of this.
  • GPS “locked” isn’t enough — check holdover state and the actual phase error (1PP S offset). A site
    in extended holdover after losing GPS reads “sync OK” on a coarse status but has drifted past the
    ~3µs air-interface phase budget. The UL degradation ramps slowly over hours/days as it drifts,
    which is the giveaway vs an instant config mismatch (which appears the moment the neighbour is
    integrated).

So the triage order that catches all of it: edge-only + load-independent UL SINR → suspect timing →
compare special-slot format AND periodicity across the cluster → then phase error / holdover, not
just lock status. The multi-vendor boundary you flagged is where format-vs-periodicity mismatch hides
because each vendor’s “default” is a different periodicity, not just a different ratio.