Design · 3.7
Performance, load and delay budgets
Time: about 11–14 minutes including the task; estimate
Guiding question: How does a timing requirement become measurable without mixing different quantities?
Learning objective: You assess load, delay budgets and percentiles using appropriate measurement boundaries.
Prerequisites: Previous lessons through 3.6, particularly the case file developed there.
First define the start and end
Talbahn wants to know how long a particular data block takes from the vehicle application to the receiving application. This differs from call setup time or the time from pressing the talk button to floor permission. Comparable figures need the same starting and ending events.
A delay budget allocates an allowable total time among contributions along a path. It supports planning and assignment of responsibility. Initially, the allocation is a design, not a measurement result.
A calculation with headroom
For this specific teaching measurement, Talbahn sets 150 ms as an internal planning target. It is not a normative FRMCS limit.
| Contribution | Planned allocation |
|---|---|
| Sending application and device | 15 ms |
| Radio access and transport | 55 ms |
| Service processing | 25 ms |
| Receiving device and application | 20 ms |
| Unallocated headroom | 35 ms |
| Total | 150 ms |
The calculation is 15 + 55 + 25 + 20 + 35 = 150 ms. If the planned service contribution rises to 40 ms, an additional 15 ms is committed. Remaining headroom is 20 ms, provided all other allocations stay unchanged.
This headroom is not the radio margin from 3.6: that lesson considered power differences in dB, while here we consider time allocations in ms. A term such as “margin” therefore always needs its reference quantity.
Measured times vary
A percentile describes a threshold within a distribution of observations. In simplified terms, the 95th delay percentile is the value not exceeded by 95 per cent of the delays analysed. It does not say how large the remaining values are.
The 95th percentiles of individual segments cannot simply be added to obtain an end-to-end 95th percentile. The slowest events may occur in different transmissions, and delays may be dependent. To obtain the actual overall distribution, Talbahn needs suitable end-to-end measurements or a justified model of dependencies.
An average alone conceals rare long delays. Conversely, even a good percentile can mislead if lost transmissions disappear from the analysis. Talbahn therefore explicitly records losses, outages and timeouts.
Measurement conditions belong with the result
Jitter describes variation in packet transit time. Such variation can affect speech playback even when the average looks good.
The case file records measurement boundaries, direction, load, location range, number of trials, time base and treatment of losses. When timing at two devices, clocks must be sufficiently aligned or their offsets accounted for. Otherwise a measurement may show an error caused only by the clocks. [S20]
URLLC stands for Ultra-Reliable Low-Latency Communication. It describes a mobile-communication concept for particularly reliable communication with low delay. The name replaces neither the selected measurement boundary nor end-to-end evidence.
Check your understanding
A report adds five 95th percentiles to obtain 140 ms and declares the 150 ms target passed. It also deleted failed transmissions. What must be corrected?
Model answer
Added segment percentiles do not demonstrate an end-to-end percentile. Appropriate overall measurements and a predefined assessment criterion are needed. Failed transmissions must be reported as loss or failure. Measurement boundaries and conditions must also be compared with the target. The existing analysis does not support a passing result.
What to remember
A quality figure is informative only together with its measurement boundary, distribution and treatment of failures.
Your Talbahn case file
Record start and end events, time budget, load and treatment of losses. Mark 150 ms as a fictional planning target.
Sources
S20 · IETF RFC 7679: A One-Way Delay Metric
IETF RFC 7679: A One-Way Delay Metric
Version: January 2016 · Checked: 2026-10-11
Scope: Measurement boundaries, timing and treatment of observed delay.
Limitations: 150 ms in this course is a fictional budget, not a limit derived from this RFC.
Used in: 1.8, 3.7
Your progress is stored in this browser on this device.