What This Page Covers
URLLC testing verifies that a private 5G deployment delivers the latency (5QI 80: 10 ms packet delay budget) and reliability (3GPP TS 22.261: 10-5 packet loss for factory automation) required by industrial applications. It combines NAS-level 5QI verification with application-layer RTT and packet loss measurement under representative load conditions.
Private 5G: URLLC Testing
URLLC is the slice that justifies private 5G for industrial applications. A factory automation system, remote crane control, or power grid protection relay depends on the 5G network delivering packets in under 10 milliseconds, reliably, under full load. Testing URLLC performance is not optional: it is the validation that separates a marketed capability from a delivered one.
URLLC Requirements per 3GPP TS 22.261
3GPP TS 22.261 §7.3.1 defines the communication service requirements for factory automation use cases.
| Use Case | Max Latency (E2E) | Reliability | 5QI |
|---|---|---|---|
| Motion control — closed loop | 1 ms | 10-9 | 82 |
| Discrete automation — control | 10 ms | 10-6 | 82 / 83 |
| General factory automation | 10 ms | 10-5 | 80 |
| Remote control (non-critical) | 50 ms | 10-3 | 9 (eMBB) |
| Electricity distribution | 10 ms | 10-6 | 83 |
URLLC Test Procedure
Before any latency measurement, decode the PDU Session Establishment Accept for the URLLC slice. Extract the QoS Rules IE and confirm the 5QI value is 80, 82, or 83 as specified by the contract. A URLLC session receiving 5QI 9 (eMBB best-effort, 300 ms packet delay budget) will never meet the 10 ms latency requirement regardless of RF conditions. 5QI verification must precede all performance measurements.
At the location with best SS-RSRP and SS-SINR (identified during coverage validation), measure RTT to a local server on the UPF's N6 interface. Run 1 000 ICMP pings (64 bytes) and record: mean RTT, P95 RTT, P99 RTT, and packet loss rate. This is the baseline: the best possible performance from this deployment. All subsequent measurements are compared against this baseline.
Repeat the latency measurement at each location where URLLC devices will operate (machine stations, control panels, robot positions). Record SS-RSRP and SS-SINR at each point. The URLLC latency target (e.g., 10 ms P99 RTT) must be met at all deployment locations, not only at the best-coverage point. Locations that fail the latency target require gNB repositioning or additional small cells.
Industrial URLLC applications operate simultaneously with eMBB traffic (video surveillance, data uploads). Generate background eMBB load (uplink and downlink) while measuring URLLC latency. The URLLC slice must maintain its P99 RTT target when the eMBB slice is fully loaded. A significant RTT increase under eMBB load indicates slice scheduling prioritization is not correctly configured at the gNB.
Send 100 000 UDP packets at the application rate (e.g., 1 Mbps for control traffic) to the local server and measure the percentage received. The 3GPP TS 22.261 target for factory automation is 10-5 packet loss rate — 1 lost packet per 100 000 sent. Any loss rate above this threshold is a failing result that must be investigated before acceptance.
URLLC Acceptance Pass/Fail Criteria
- 5QI of URLLC PDU session is 80, 82, or 83 (confirmed in NAS decode)
- P99 RTT to UPF local server ≤ contractual latency target at all deployment locations
- Packet loss rate ≤ 10-5 under nominal load
- P99 RTT target maintained under full eMBB background load
- NSSAI isolation: non-URLLC devices cannot access the URLLC slice (cause #72 confirmed)
- 5QI 9 assigned to the URLLC PDU session (SMF misconfiguration)
- P99 RTT exceeds target at any required deployment location
- Packet loss rate exceeds 10-5 under nominal load
- RTT target degraded by more than 20% under eMBB background load
- Non-URLLC device successfully establishes session on URLLC slice (isolation failure)
HiCellTek for URLLC Testing
Decode QoS Rules IE from PDU Session Establishment Accept. Extract and display 5QI per QoS flow. Flag mismatches between the configured 5QI and the contracted URLLC target.
RTT measurement to configurable target server. P50/P95/P99 percentile reporting. Continuous time-series export for latency under load tests. Correlated with SS-RSRP and SS-SINR to isolate radio-related latency spikes.
Simultaneous SS-RSRP, SS-SINR, and CQI monitoring during latency measurements. Identifies correlated spikes: a latency outlier at the same timestamp as an SS-SINR drop points to radio interference rather than core network misconfiguration.
Excel export: per-location RTT statistics, packet loss rate, 5QI value, SS-RSRP/SINR. QMDL raw capture for archival. Generates the structured evidence required for URLLC acceptance sign-off in industrial 5G procurement contracts.
Frequently Asked Questions
URLLC (Ultra-Reliable Low Latency Communications) testing measures two independent dimensions: latency and reliability. Latency testing measures the round-trip time (RTT) of packets over the URLLC slice — the target for 5QI 80/82 is a packet delay budget of 10 ms. Reliability testing measures the packet loss rate and the percentage of packets delivered within the delay budget — 3GPP TS 22.261 specifies 10^-5 packet loss rate for factory automation URLLC services. Both must be measured simultaneously under load conditions, not in isolation.
The primary 5QI values for URLLC in private 5G are 5QI 80 (Non-GBR, 10 ms packet delay budget) and 5QI 82/83 (GBR, 10 ms packet delay budget). 5QI 80 is standardized for discrete automation and is the most common in industrial private 5G. 5QI 82 is used when guaranteed bit rate is required in addition to low latency (e.g., motion control). All 5QI values are defined in 3GPP TS 23.501 §5.7.4, Table 5.7.4-1. The 5QI assigned to the URLLC PDU session is visible in the QoS Rules IE of the PDU Session Establishment Accept.
Android ICMP ping (SOCK_DGRAM) can measure application-layer RTT but does not directly measure the 5G user plane latency at the Uu interface. For accurate URLLC latency measurement at the radio level, the round-trip time must be measured between the UE and a server on the UPF's N6 interface (within the private network), avoiding internet traversal. DIAG-level timing measurements (RLC/MAC timestamps) provide sub-millisecond precision for the radio segment but require modem-level access. Standard RTT measurement to a local server provides the operational latency that matters for industrial applications.
URLLC latency failures originate in the radio segment (Uu interface) or the 5G core forwarding chain. To isolate the radio segment: (1) measure RTT to the UPF's local N6 interface server (removes backhaul), (2) measure RTT to a server beyond the UPF (adds backhaul latency). The delta between the two measurements is the backhaul contribution. If the RTT to the local server already exceeds the 10 ms budget, the failure is in the radio or core path. DIAG-level RLC/MAC latency analysis can further isolate the radio segment within the Uu RTT.