We test 5G core and EPC functions, IMS, private 5G and the transport under them on the CloudLAB bench: emulated gNBs, eNBs and subscribers, N3 and N6 traffic at 10G to 100G, attach storms, handovers and function restarts with sessions in flight. The report shows what each function holds with your profiles and your timers, in numbers the vendor, the integrator and your core team read the same way.
When the number is needed
A datasheet gives sessions held by an idle function with default timers. Each moment below asks what the function does with your subscriber profiles, your traffic mix and a restart at the wrong time.
Every candidate core, UPF or IMS runs the same registration, session and throughput cases with the same emulated RAN and subscribers. Vendors see the plan before the run and the numbers after it.
Ranked table per KPI, scale limit per vendor, 4–6 weeks for 3 candidates
The delivered functions with the production config: slices, QoS profiles, timers, policies and the dimensioning from your design. Measured against the design targets with your traffic mix, before the migration window opens.
Signed report with pass and fail per case, config exports, from 2 weeks
The acceptance cases run again on the new release, the new UPF site or the new slice profile. What moved, by how much, and whether the function still clears the targets it cleared last time.
Diff per KPI against the last run, 3–5 business days
What we test
The bench is the same, the emulated traffic and the pass criteria are not. The table is the starting point of the plan; your dimensioning and your subscriber profiles set the targets.
| Function class | Numbers in the report | Traffic and config on the bench | Typical size |
|---|---|---|---|
| 01UPF and user plane | N3 to N6 throughput and latency per session class, sessions before loss, pps per core, QoS flows | Emulated gNBs with GTP-U, eMBB, URLLC and mMTC from your mix, 10G to 100G, sessions ramped live | Sessions from your dimensioning, 10G–100G |
| 02Control plane: AMF, SMF or MME, SGW-C | Registrations and PDU setups per second, setup time p95, mobility success, sessions kept on restart | Emulated UEs and RAN with your timers and slices, a storm after a RAN outage, a function restart | Rates from your busy hour and outage plan |
| 03IMS core and VoLTE, VoNR | Registrations and calls per second, call setup time and success rate, media quality per codec | Emulated subscribers with SIP and RTP, your codec mix, calls through a loaded user plane | Registration and call rates from your traffic model |
| 04Transport: fronthaul, midhaul, backhaul | Throughput, latency and jitter per class, sync, loss window on link failure, QoS kept end to end | Routers and switches between emulated RAN and core, GTP-U at 10G to 100G, link failures under load | 8–32 ports, 10G and 100G |
| 05Private 5G and LTE core | Device registrations, throughput per cell, control latency, behaviour on WAN loss to the centre | Compact core on the bench or in your rack, industrial traffic profiles, WAN emulator to the centre | Device count of the site, 1G–10G |
Any vendor, physical or cloud-native. Mobile core and IMS emulation runs on partner test systems in CloudLAB; the tool behind each test is listed in the report.
Around the core
A session count only means something with the right things around the function: the RAN that brings the subscribers, the traffic mix they will carry, and the restart that happens on a bad day
Subscriber count, slice and QoS profile mix, attach pattern per hour and traffic per session class from your statistics. The bench emulates them, so the result holds for your network, not for an average one.
Timers, slices, QoS flows, policies and dimensioning from your export. The report shows which setting each session limit or setup delay traces back to.
Function restart, site loss, N3 or S1 link down, a RAN outage followed by a storm. Each one with the session table loaded and traffic on every session, timed from the last packet to the first one back.
Typical scenario
An operator hands over a new UPF pair for acceptance. With idle sessions the pair holds the datasheet count. With traffic on every session, forwarding breaks at 78 % of the design count. The counters point at one core carrying the GTP-U hashing. The vendor changes the flow distribution and the queue mapping; on day 6 the same ramp holds 108 % of the design with traffic on every session.
Composite scenario from projects of this type. Numbers are realistic and not from one client.
What you take away
The report is built for the meeting after the test: the vendor, the integrator and your core team read the same table, with the pass band from the design next to the measured value
Each number comes with its evidence: emulator statistics, session table and CPU counters from the function, captures on N3 and N6 and the config export of the run
| KPI | Pass band | Measured | Result |
|---|---|---|---|
| Registrations per second after RAN outage, % of design rate | ≥ 100 % | 120 % | Pass |
| PDU session setup time, p95 | ≤ 300 ms | 210 ms | Pass |
| Active sessions with traffic on each, % of design | ≥ 100 % | 108 % | Pass |
| N3 to N6 at 100G, 1,400 bytes | ≥ 90% | 93% | Pass |
| UPF latency, URLLC flows, p99 | ≤ 2 ms | 1.4 ms | Pass |
| SMF restart, sessions kept | 100% | 99.6% | Pass with a note |
Where it runs
Functions ship to the CloudLAB rack in Armenia or run as VMs and containers on the bench hypervisor; cloud-native cores run in your tenant with the bench connected to it. RAN, subscribers and IMS traffic come from emulators on the bench, L2-3 ports at 1G to 100G and L4-7 engines at 200G and above. You watch the run through the browser with an engineer on every session.
How a load run goes, step by step Protocol conformance: GTP, NAS, Diameter, SIP Cloud and NFV: the hosts under the functions CloudLAB: how the bench works
Before the brief
Any vendor, physical or cloud-native: 5G core and EPC functions (AMF, SMF, UPF, MME, SGW, PGW), IMS cores, private 5G and LTE cores, and the transport routers and switches between RAN and core. The function comes to the rack, runs on the bench hypervisor or stays in your tenant with the bench connected to it.
Yes. Subscriber count, slice and QoS mix, attach pattern and traffic per session class come from your statistics; timers, slices, policies and dimensioning come from an anonymised export. A vendor engineer can sit in on the run.
From your dimensioning. Subscribers, sessions, registration and call rates go into the plan with a margin and are checked on the bench before the run; N3 and N6 traffic runs at 10G to 100G. The report shows each figure as a share of the design, next to where the function stopped.
Handovers between emulated cells, 4G to 5G interworking over N26, EPC fallback for voice and roaming over emulated partner networks are run as mobility cases: the subscriber moves while traffic runs, and the report shows session continuity, setup time and loss per move.
Yes, as a separate area or in the same plan: the hypervisor or Kubernetes cluster, the SR-IOV or DPDK data path, storage and the overlay network. A UPF that loses sessions on a host restart is a platform finding as often as a software one; the plan separates the two.
Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one function role and 4–6 weeks for a shortlist of 3 candidates or a full core. You get the signed report with every case, the emulator statistics, counters and captures, and the config exports of each run.
No prices on the site: scope first, then the quote. The vendor and the integrator can sit in on the brief.
Send the shortlist
Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.
Prefer to chat? Message an engineer on WhatsApp
We use what you send only to answer you. See our Privacy Policy.