Skip to content
All articles
Telecom and WAN

How we test 5G transport: GTP-U, delay per class, a cut link

Alexander Zemskov 4 min read
How we test 5G transport: GTP-U, delay per class, a cut link

A router for 5G transport arrives with a datasheet that says "5G ready": 100G ports, hierarchical QoS, a PTP boundary clock. The operator needs other numbers. Does the URLLC class stay inside its delay budget when the backhaul is full of video? How many milliseconds do the tunnels lose when a ring link fails? Does the box keep its clock while both happen? Those are the numbers we measure.

The bench

The device under test is a cell-site router, an aggregation router or a fronthaul switch, on 8 to 32 ports at 10G and 100G, 400G and faster per project. The radio is not on the bench: no radio units, no air interface. The generator plays both ends. On the RAN side it emulates gNBs with GTP-U tunnels and the session mix of your cells, on N3 and on F1-U where the RAN is split; on the core side it receives every tunnel and measures every flow. Both ends sit on one generator, so one-way delay is read against one clock. This is the transport class of the 5G and mobile core page.

Fronthaul is a case of its own: the radio signal over eCPRI with a one-way budget of about 100 µs. The stream profile comes from your design, and the number that counts is one-way delay against that budget. The QoS, routing, protection and sync settings are yours.

What we check

  • GTP-U throughput: tunnels from emulated gNBs at 10G to 100G per port, with tunnel overhead and your frame sizes
  • Delay and jitter per class: URLLC, voice, eMBB, signalling and sync each in its own queue, at load steps such as 30, 70 and 90%, against the budget of the segment
  • QoS end to end: the outer DSCP of each tunnel mapped to the right queue on every hop, remarking where the design asks for it
  • Load sharing: thousands of tunnels between a few gNB and UPF addresses spread over ECMP paths and LAG members, with the imbalance per link
  • Loss window: a ring link pulled, a node rebooted, the protection path taken; the gap per class and per flow in milliseconds
  • Sync: PTP emulated on our generators, whether the box keeps the sync class ahead of user traffic at full load and stays locked through a failure
  • Soak: 24 hours at 80% of the measured capacity with every class running

What we do not measure yet: time error in nanoseconds against the clock class of the box. That needs a dedicated timing analyser, which the bench does not have yet; full timing analysis is arranged per project, and we are collecting such projects. Per-class acceptance can follow Y.1564.

What usually breaks

QoS marking. The gNB marks the inner packet and leaves the outer header at zero, and transport routers read only the outer one. Every class, URLLC included, rides in best effort. At 90% the low-latency class shows the same delay as video.

Second: load sharing. Tunnels between one gNB and one UPF share the outer addresses and often the UDP ports too, so a router that hashes on those fields puts them all on one link. An example: one 100G member at 95%, three near idle, loss in a network a quarter full. Hashing on the tunnel ID fixes it where the box supports it.

Third: sync under load. PTP messages share a queue with user traffic, and at full load their delay varies enough for the box to drop out of lock. On the bench this is a state change at a known load step. In the field it reaches the TDD radios as interference between cells, a fault that is hard to trace back to a queue.

What is in the report

Throughput per port and per mix. Delay and jitter per class at each load step, next to the budget of the segment. The loss window as a table: event, class, gap in milliseconds, worst flow and median flow. Load sharing per link. The sync section with the lock state per scenario, marked as a check with emulated PTP. The device configuration, the emulated gNB and tunnel settings, firmware and ports, so the vendor can repeat any item. The same routers also run the BGP, IS-IS and segment routing cases of routing and switching.

Where to start

Send us the router or switch model, the firmware you plan to run and the transport design: segments, QoS mapping, protection and the sync plan. We answer with a draft plan: what we check, how the bench is built and the dates. The report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.

Written by

Alexander Zemskov

Alexander Zemskov leads network and security testing at TEST4NET, an independent, vendor-neutral testing lab in Yerevan, Armenia. With 19+ years in performance and load testing on IXIA, Spirent, Keysight, Xena and Xinertel platforms, he runs NGFW, WAF, IPS, DLP and SASE evaluations for telecom operators, banks and system integrators.

Blog

Keep reading