A real-network perspective — no marketing, no theory fluff

1. What Is 5G Transport — The Simple Version

Transport is everything that sits between the radio hardware and the core network. Most people in telecom think of it as just a pipe. That pipe is actually a highly engineered stack of Ethernet, IP routing, MPLS labels, synchronisation protocols, and QoS mechanisms — all working in milliseconds, all invisible to the end user.

In 5G, the transport network is split into three distinct segments, each with fundamentally different requirements: fronthaul (RU to DU), midhaul (DU to CU), and backhaul (CU to UPF and beyond). Get any one of these wrong and your RAN KPIs collapse — even if the radio hardware is perfect.

2. Real Network Architecture — How Operators Deploy It

The 5G RAN Split and Its Transport Implications

Modern 5G networks use a disaggregated RAN architecture. The traditional monolithic base station is split into three logical functions:

• RU (Radio Unit) — sits on the tower, handles RF and low-PHY. Generates raw IQ samples or eCPRI frames depending on the split option.
• DU (Distributed Unit) — typically at the tower base, a street cabinet, or a centralised aggregation site. Handles high-PHY, MAC, and RLC. Latency-sensitive.
• CU (Centralised Unit) — can sit at a regional hub or directly at the data centre. Handles PDCP, RRC, and SDAP. Splits further into CU-CP (control plane) and CU-UP (user plane).

The transport segments that connect these are:

Segment	Path	Latency Budget	Typical Tech
Fronthaul	RU → DU	≤ 100 µs (Option 7-2x)	25GE / eCPRI over dedicated fibre or DWDM
Midhaul	DU → CU	≤ 1–2 ms	10GE / 25GE, IP/Ethernet, SyncE + PTP
Backhaul	CU → UPF → Internet	10–30 ms acceptable	IP/MPLS core, 10GE/100GE spine

NSA vs SA — The Topology Changes Everything

In NSA (Non-Standalone) deployments, the LTE eNB acts as the anchor. 5G NR is a secondary node. All control plane traffic — including RRC — rides on the LTE anchor. The NR gNB’s backhaul carries only user plane data via the X2-U interface (or Xn-U after upgrade). The UPF is reached via the LTE core (EPC/SGW-PGW), not a standalone 5G core.

In SA (Standalone), there is no LTE dependency. The gNB connects directly to the 5GC AMF (control plane) via N2 and to the UPF via N3. This flattens the architecture, reduces handoffs, and enables true network slicing — but demands a clean, well-engineered transport network because there is no fallback.

Field Note: In Oman, most operators began with NSA using existing LTE backhaul. The challenge was that existing 1GE/10GE links to sites were fine for LTE but undersized for 5G NR user plane when mmWave or massive MIMO kicked in. The upgrade path to SA required new fibre and IP/MPLS rearchitecture at aggregation hubs.

3. Step-by-Step Real Flow — What Actually Happens

A Packet’s Journey: UE Downloads a Video in Muscat

Here is what happens end-to-end when a subscriber in Muscat CBD connects to a streaming server:

Step 1 — Radio to RU

The UE transmits on the NR air interface. The RU captures the RF signal, digitises it, and forwards IQ samples or eCPRI frames over a 25GE fronthaul link to the DU. At this stage, the ‘packet’ is not yet a packet — it’s raw digitised radio signal. Latency here is sub-50 µs. Any jitter in this segment directly degrades HARQ timing and can cause retransmissions before data even enters the IP world.

Step 2 — DU Processing

The DU performs high-PHY processing (FFT, channel estimation, equalisation), then passes decoded data up through MAC and RLC. Here it reassembles RLC PDUs into PDCP SDUs and sends them up to the CU-UP over the midhaul F1-U interface (GTP-U encapsulated over UDP/IP). This hop typically traverses a ring or hub aggregation switch.

Step 3 — CU-UP to UPF (N3 Interface)

The CU-UP encapsulates the user payload in another GTP-U tunnel and sends it over N3 to the UPF. This is where your IP/MPLS core takes over. The packet gets labelled at the PE (Provider Edge) router, rides LSPs through the core, and arrives at the data centre hosting the UPF. The UPF strips the GTP tunnel, applies policy (QoS, charging, UE IP assignment) and forwards the inner IP packet toward the internet.

Step 4 — UPF to Internet

The UPF connects to the internet via the DN (Data Network) interface (N6). This is a standard IP routing hop — BGP to peering partners or upstream ISPs. For local content (cached CDN, local breakout), the UPF can be placed closer to the RAN (MEC/edge deployment) to cut latency significantly.

Key insight: Every GTP tunnel adds overhead. RU→DU is eCPRI. DU→CU is GTP-U on F1-U. CU→UPF is GTP-U on N3. Each encapsulation layer requires MTU planning — if you don’t set jumbo frames (9000 bytes) correctly, you’ll get fragmentation-induced latency and throughput degradation that looks like a radio problem.

4. Practical Example — Muscat City Scenario

Consider a typical Ooredoo-style 5G SA deployment in central Muscat. The gNB is installed on a rooftop in MQ (Muttrah Qurayat area). The RU is on the mast, the DU sits in a cabinet at the tower base, and the CU is centralised at the Seeb hub site.

Network Element	Physical Location	Transport Link	Protocol
RU	Tower — Muttrah	Fronthaul: 25GE fibre	eCPRI Option 7-2x
DU	Cabinet — Tower Base	Midhaul: 10GE Ethernet ring	GTP-U / F1-U
CU-UP / CU-CP	Seeb Hub DC	Backhaul: IP/MPLS 10GE PE	GTP-U / N3, SCTP / N2
UPF	Muscat Core DC	N6 to Internet	Native IP / BGP
Internet CDN	Peering / CDN Cache	—	—

A video streaming packet from this user travels: RU → DU (25GE, ~50 µs) → CU at Seeb hub (10GE ring, ~500 µs) → UPF at Muscat DC (MPLS core, ~2 ms) → CDN cache (~5 ms total). Total perceived latency: under 10 ms. If the CDN cache is not warm or if the UPF is placed at a remote DC in Salalah instead of Muscat, that last hop alone adds 20+ ms and your video streaming app switches to a lower resolution tier.

5. Key Parameters and Configurations

Parameter	Where Configured	Typical Value	Impact if Wrong
MTU / Jumbo Frames	All transport switches and routers	9000 bytes	GTP fragmentation → high latency, low throughput
PTP Profile	Grandmaster + all BCs	ITU-T G.8275.1 (full timing support)	Phase error → handover failures, HARQ desync
DSCP Marking	DU, CU, PE router ingress	EF (46) for real-time, AF31 for data	QoS not enforced, VoNR drops under congestion
MPLS EXP / TC bits	PE router ingress policy-map	Mapped from DSCP	Wrong queue assignment in core
GTP-U TEID	CU-UP and UPF	Auto-negotiated via N4 (PFCP)	Tunnel mismatch → total traffic loss
BFD Timers	PE routers on all links	Min interval 300ms, multiplier 3	Slow failure detection → prolonged outage

6. Common Issues in the Field

Where Things Actually Go Wrong

• Fronthaul latency spikes — caused by PTP boundary clock misconfiguration, typically after a software upgrade on an aggregation switch. Manifests as intermittent HARQ failures and RRC setup latency spikes. Hard to attribute because it looks like a radio issue.
• MTU mismatch — the most common silent killer. Transport team sets 1500 byte MTU on a new link segment. GTP-U packets (with outer IP + UDP + GTP headers) exceed this. Packets fragment silently. RAN team sees high retransmission rates and blames coverage.
• QoS policy not applied at PE ingress — DU marks packets correctly with DSCP EF for VoNR, but the PE router’s ingress policy-map is not configured or overwrites markings. VoNR packets sit in the same queue as bulk data. Under congestion, jitter spikes and calls drop.
• NSA X2 interface latency — in NSA, X2 between the LTE anchor eNB and the NR gNB needs to be below 10 ms for smooth dual connectivity. If they’re on different transport rings without direct interconnect, you get excessive X2 RTT and PDCP reordering delays.
• Asymmetric timing — PTP can synchronise frequency well but fail on phase if the forward and return paths have different latency (e.g., traffic crosses different physical paths). Phase error on TDD NR is catastrophic — adjacent-cell interference spikes immediately.

7. Troubleshooting Approach

Systematic Transport Debugging

Layer your investigation — always start from timing, not traffic

When RAN performance degrades and the radio team has already ruled out coverage and interference, suspect transport in this order:

• Check PTP sync status — TE (time error) should be < 1.5 µs end-to-end. Use router CLI: show ptp clock, show ptp parent. Look for excessive PDV (packet delay variation) on the GM-to-BC path.
• Check interface utilisation — sustained >70% on any fronthaul or midhaul link causes queue-induced latency. Pull SNMP counters or use streaming telemetry if available.
• Verify DSCP markings end-to-end — run a traffic capture at the PE ingress and egress. Confirm EF-marked packets from DU are still EF when they hit the UPF-facing interface.
• Trace GTP tunnels — confirm TEID mapping between CU-UP and UPF via N4 interface logs (PFCP session establishment messages). A mismatched TEID causes silent traffic blackhole for that specific bearer.
• Run TWAMP — use TWAMP (Two-Way Active Measurement Protocol) between DU and CU endpoints. Measures RTT, jitter, and packet loss on the live transport path with minimal overhead.

Pro tip: Always check if the issue is correlated with a config change in the transport domain. Transport teams often push router software upgrades or QoS policy changes during maintenance windows that directly affect RAN performance the next business day. Establish a change log cross-reference process.

8. Design Recommendations — Consultant Level

What to Specify and What to Watch Out For

• Architect fronthaul as dedicated infrastructure — never share fronthaul with corporate IT traffic on the same physical links. eCPRI is extremely latency-sensitive. Any burst from IT side causes buffer bloat that manifests as fronthaul jitter.
• Deploy UPF close to the RAN — for low-latency use cases (gaming, enterprise, MEC), placing UPF at regional hubs (not just the central DC) cuts N3 RTT from 15–20 ms to under 5 ms. This is a design decision made in the initial architecture phase; retrofitting is expensive.
• Insist on end-to-end QoS spec from day one — transport RFP/contracts must specify DSCP trust boundaries, per-hop queue configs, and traffic policing at each segment. Vague ‘best effort with QoS’ language in vendor contracts means nothing will be properly configured.
• Use SRv6 or SR-MPLS for flexible traffic engineering — traditional MPLS-TE tunnel configuration does not scale when you have hundreds of DU/CU endpoints. Segment Routing provides source-based path control without per-hop state, making it far more manageable.
• Plan for asymmetric growth — fronthaul capacity must be engineered for peak simultaneous user throughput, not average. A massive MIMO 64T64R antenna can generate 20+ Gbps of eCPRI traffic per sector under load. Dimension accordingly.
• Synchronisation redundancy — deploy at least two PTP grandmasters in geographically diverse locations, with automatic switchover tested quarterly. A single GM failure in a TDD network causes an immediate and widespread service outage.

9. Summary — Practical Takeaways

Transport is not a passive pipe in 5G. Every segment from RU to UPF has specific latency budgets, QoS requirements, and synchronisation dependencies. Get one segment wrong and the impact shows up in RAN KPIs — usually misattributed to coverage or radio configuration.

The most common operator mistakes are: treating fronthaul like normal enterprise Ethernet, failing to enforce QoS at PE ingress, under-dimensioning MTU, and placing UPF too far from the RAN edge. These are all preventable with proper transport architecture reviews before deployment.

For operators transitioning from NSA to SA, the transport changes are more significant than the RAN changes. SA removes the LTE anchor dependency but demands a clean, correctly-engineered 5GC connectivity path for every gNB — there is no fallback. Transport teams need to be involved in RAN planning from day one, not brought in as an afterthought.

Takeaway	Action
Fronthaul latency is the tightest constraint	Dedicate fibre, enforce PTP G.8275.1, monitor PDV continuously
MTU must be set to 9000 bytes end-to-end	Audit every switch and router in the transport path during commissioning
QoS must be enforced at PE ingress	Specify and verify DSCP trust + queue config in transport acceptance testing
UPF placement drives user experience	Architect regional UPF breakout for latency-sensitive services
Timing failure = immediate service impact	Dual GM, quarterly failover test, real-time TE monitoring

Muhammad Tahir Riaz  |  trmtelcocloudai.com  |  Telecom Transport Series — Article 1 of 10