Skip to content
Independent reference on the Future Railway Mobile Communication System

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

Shared source register

Your progress is stored in this browser on this device.