(m,k)-Firm Elevation Policy in 5G-TSN

• The paper introduces a dynamic priority-driven fallback mechanism that elevates selected delayed frames to maintain weakly hard real-time guarantees under unpredictable 5G delays.
• It employs an (m,k)-firm model with a periodic μ-pattern to coordinate elevation eligibility, ensuring only designated frames are rescued and overall schedule integrity is preserved.
• The policy augments existing TAS/PSFP schedules, trading a small overhead in nominal conditions for robust performance during delay anomalies in converged 5G-TSN environments.

Searching arXiv for the specified paper to ground the article and confirm bibliographic details. The $(m,k)$-firm Elevation Policy is a fallback mechanism for time-driven TSN schedules deployed over converged 5G-TSN networks. It is proposed to address a specific robustness problem: schedules are synthesized under simplified or percentile-based delay assumptions, whereas actual 5G delays are probabilistic, variable, and occasionally exhibit abrupt outliers. In that setting, a nominally correct time-driven schedule can lose its real-time validity when an unforeseen delay outlier causes a frame to miss the transmission window assumed by the schedule. The policy augments an existing primary schedule with a dynamic priority-driven scheme that elevates the priority of selected delayed frames so as to preserve a meaningful minimum level of service under unstable conditions, while limiting interference to other traffic (Egger et al., 13 Aug 2025).

1. Problem setting in 5G-TSN time-driven scheduling

The policy is formulated for time-driven TSN schedules in which forwarding behavior is tightly coordinated in time, especially through the Time-Aware Shaper (TAS) and Per-Stream Filtering and Policing (PSFP). A centralized network controller (CNC) computes a schedule based on assumptions about frame release times and traversal delays. This model is effective in wired TSN, where delays are small and nearly deterministic, but it becomes fragile when a 5G system is integrated as a logical TSN bridge (Egger et al., 13 Aug 2025).

The underlying problem is a mismatch between the idealized or bounded delay models used during schedule synthesis and the actual 5G delay process, which is described as statistical, nonstationary, and prone to outliers. Representative assumptions identified for schedule synthesis are:

• (A1) every frame $f$ is available for transmission exactly at time $f.release$,
• (A2) wired per-link transmission delays can be represented by fixed slots,
• (A3) 5G delays are bounded by $[d_{\min}, d_{\max}]$ with probability $\alpha$.

These assumptions may be violated by unexpected compute delays, time synchronization errors, abrupt 5G delay anomalies such as line-of-sight blockage or handover, and longer-term changes in channel or load conditions. The consequence is not merely that some frames become late. Delay outliers can cause an affected frame to miss its own deadline, and they can also invalidate the synchronized schedule in ways that may harm other real-time streams if mishandled (Egger et al., 13 Aug 2025).

This issue is particularly acute for time-driven schedules because they are brittle. If a frame misses the time window expected by the schedule, it may be discarded by PSFP even though it might still have been useful to the application. The paper further argues that runtime reconfiguration is too slow for abrupt disturbances, since it requires recomputing delay confidence intervals, recomputing the TSN schedule, and deploying new GCL and PSFP configurations across the network. That process can take seconds and may cause downtime. The Elevation Policy is therefore positioned as a light-weight fallback mechanism that can be preconfigured and activated immediately during unstable conditions (Egger et al., 13 Aug 2025).

2. Weakly hard real-time semantics and the $(m,k)$-firm model

The policy is grounded in weakly hard real-time guarantees rather than a strict requirement that every frame satisfy its deadline. A stream $F$ has an $(m,k)$-firm latency requirement if at least $m$ out of any $k$ consecutive frames must arrive before their deadline (Egger et al., 13 Aug 2025).

For the $f$0-th frame $f$1, the release time is defined as

$f$2

and the latency requirement $f$3 is satisfied iff

$f$4

The $f$5-firm condition constrains the pattern of deadline satisfactions over every sliding window of $f$6 consecutive frames. This is stronger than a long-term percentage guarantee and weaker than a hard real-time guarantee for every frame (Egger et al., 13 Aug 2025).

Within this framework, hard real-time corresponds conceptually to the strongest case, effectively requiring every frame to meet its deadline; the paper notes that some traffic is modeled with $f$7, which corresponds to a per-frame hard requirement. Best effort lies at the opposite end: misses may occur without structural restriction. The $f$8-firm model occupies the intermediate regime by allowing some misses while bounding the local clustering of failures. The examples given are:

• $f$9-firm: in every pair of consecutive frames, at least one must succeed.
• $f.release$0-firm: among any three consecutive frames, at least one must succeed.
• If an application tolerates at most $f.release$1 consecutive faults, this can be expressed as $f.release$2-firm.

The paper argues that this is more aligned with industrial notions such as survival time than asymptotic reliability metrics like “99% of frames meet their deadline.” A percentage metric can still admit a burst of many consecutive losses, whereas an $f.release$3-firm requirement explicitly constrains such bursts (Egger et al., 13 Aug 2025). This suggests that the policy is intended not merely to improve average performance, but to preserve application-relevant temporal structure in failure patterns.

3. Policy architecture and operational mechanism

The policy is designed to complement, rather than replace, a primary time-driven schedule. Under normal conditions, the primary TAS/PSFP schedule operates as usual. Under abnormal conditions, a dynamic priority-driven fallback is used. The key intervention is selective: only certain delayed frames are “rescued” by elevating their priority, while others are discarded so that the rest of the schedule remains protected (Egger et al., 13 Aug 2025).

The primary schedule is written as

$f.release$4

where $f.release$5 denotes PSFP arrival windows and $f.release$6 denotes TAS gate control lists. The augmentation introduced by the policy adds new PSFP behavior that distinguishes between on-time, late-but-salvageable, and too-late frames, and it also adds new GCL timing that leaves room for interference from elevated late frames. The result is a fallback layer around a primary time-driven schedule rather than a resynthesis of the schedule from scratch (Egger et al., 13 Aug 2025).

Activation occurs when a frame arrives later than what the primary schedule expects, meaning outside the nominal arrival interval for ordinary forwarding, but still early enough that forwarding it with high priority could preserve useful timing. The paper highlights deployment especially at bridges following segments prone to unpredictable delay, such as after the talker when release jitter is possible, or at the NW-TT after 5G transport (Egger et al., 13 Aug 2025).

The runtime fallback mechanism is implemented through extended PSFP stream-gate states. Standard PSFP can forward or discard. The policy adds a third state:

• forward
• discard
• elevate

In the elevate state, PSFP overwrites the frame’s PCP to the highest priority,

$f.release$7

after which the frame retains that elevated priority on subsequent hops. TAS then prefers it over lower-priority traffic, which minimizes additional queuing delay. However, not every late frame is elevated. Elevation is restricted to late frames selected by the stream’s $f.release$8-firm configuration (Egger et al., 13 Aug 2025).

At each relevant bridge, the CNC preconfigures PSFP windows for each frame $f.release$9. Three cases are distinguished:

1. Normal forwarding window: if the frame arrives in the expected interval, it is forwarded with its original PCP.
2. Elevation window: if it arrives after the expected interval but before it becomes useless, it is elevated.
3. Late discard: if it arrives too late, it is discarded.

Formally, the normal forwarding interval for $[d_{\min}, d_{\max}]$0 at hop $[d_{\min}, d_{\max}]$1 is

$[d_{\min}, d_{\max}]$2

where $[d_{\min}, d_{\max}]$3 is the scheduled opening time of the transmission slot, $[d_{\min}, d_{\max}]$4 is the latest possible transmission start after accounting for elevated-traffic interference, and $[d_{\min}, d_{\max}]$5 and $[d_{\min}, d_{\max}]$6 are lower and upper bounds on transmission-plus-processing delay under stable conditions. If the frame is eligible for elevation, PSFP elevates it when it arrives in

$[d_{\min}, d_{\max}]$7

A frame is therefore elevated if it arrives later than expected by the primary schedule but still has a chance to reach the listener before its deadline; frames arriving later than that are discarded (Egger et al., 13 Aug 2025).

4. The $[d_{\min}, d_{\max}]$8-pattern and coordinated eligibility for elevation

A central feature of the policy is that elevation decisions are not made by a purely reactive local rule. The paper explicitly rejects the rule “elevate frame $[d_{\min}, d_{\max}]$9 whenever losing it would violate the $\alpha$0-firm requirement,” because local devices have only a restricted local view. If delays occur in different segments, different devices could make inconsistent decisions and inadvertently violate the intended guarantee (Egger et al., 13 Aug 2025).

The paper illustrates this with a $\alpha$1-firm stream having elevation points at a bridge $\alpha$2 after release-time uncertainty and at a bridge $\alpha$3 after 5G delay uncertainty. If $\alpha$4 is acceptable at $\alpha$5 but later lost at $\alpha$6 because of an unexpected 5G delay, and $\alpha$7 is delayed at release and considered at $\alpha$8, then $\alpha$9 may incorrectly discard $(m,k)$0 if it does not know that $(m,k)$1 was already lost later. Both consecutive frames may then be lost, violating the $(m,k)$2-firm guarantee (Egger et al., 13 Aug 2025).

To avoid such inconsistency, the policy uses a predetermined $(m,k)$3-pattern. For an $(m,k)$4-firm latency requirement, the paper defines a $(m,k)$5-bit word

$(m,k)$6

with

$(m,k)$7

The interpretation is position-based and periodic:

• $(m,k)$8: the frame whose index falls in position $(m,k)$9 is eligible for elevation if delayed.
• $F$0: delayed frames at that position are not protected and may be discarded.

The formal rule is that when the $F$1-th frame $F$2 is delayed, its priority may be elevated iff

$F$3

Because the $F$4-pattern contains at least $F$5 ones in each $F$6-periodic block, at least those $F$7 positions in every block of length $F$8 are designated for protection or elevation. Operationally, if one of these protected frames becomes late, it is elevated instead of dropped; if an unprotected frame becomes late, it is discarded to protect the rest of the schedule (Egger et al., 13 Aug 2025).

The running example for a $F$9-firm requirement chooses $(m,k)$0, so every second frame position is eligible for elevation. The paper also uses $(m,k)$1-firm examples with

$(m,k)$2

and recommends choosing patterns that spread elevated traffic evenly. The runtime logic is not presented as an adaptive counter-based state machine. Instead, it is encoded statically in the periodic $(m,k)$3-pattern, PSFP stream-gate intervals, and TAS slot augmentation. The effective automaton is thus a periodic gate schedule whose intervals are labeled forward, elevate, or discard (Egger et al., 13 Aug 2025).

5. Formal model and schedule augmentation

The network is modeled as a directed graph

$(m,k)$4

where $(m,k)$5 are network devices visible to the CNC and $(m,k)$6 are full-duplex Ethernet or 5G links. Each time-triggered stream $(m,k)$7 specifies a route $(m,k)$8, PCP priority $(m,k)$9, period $m$0, phase $m$1, and size $m$2. The hypercycle is

$m$3

and the deadline condition remains Equation (1) above (Egger et al., 13 Aug 2025).

For a stream $m$4, the paper defines $m$5 to count the number of frames that can be elevated in the interval $m$6. Using $m$7,

$m$8

with

$m$9

where $k$0 and $k$1 determine the lowest and highest frame indices that can be elevated during the interval. The semantics of the function are described as counting eligible frame indices in the interval (Egger et al., 13 Aug 2025).

To upper-bound elevated traffic on a link $k$2, the policy introduces a token bucket $k$3 for the set of streams $k$4 traversing that link. The bucket size is

$k$5

and the token rate is

$k$6

These quantify worst-case burstiness and sustainable arrival rate of elevated traffic, with the range $k$7 needed to capture overflow across consecutive hypercycles (Egger et al., 13 Aug 2025).

Given a port $k$8, the initial schedule specifies a sequence of scheduled transmissions

$k$9

ordered by

$f$00

The augmented intervals are denoted $f$01. A frame $f$02 may be delayed directly by elevated traffic arriving when its gate opens, with worst-case delay

$f$03

A second case arises when the previous frame $f$04 is prolonged and token bucket refill during its transmission causes additional delay:

$f$05

The actual prolongation is

$f$06

and the transmission completion time is updated as

$f$07

If $f$08 has higher priority than $f$09, prolongation could let $f$10 overtake $f$11. To preserve the original transmission order, the deferment rule is

$f$12

and

$f$13

This preserves the initial schedule ordering while creating space for elevated traffic. At each step, the augmented GCL opens the gate associated with $f$14 during $f$15, and the PSFP forwarding and elevation intervals are then derived by Equations (2) and (3) (Egger et al., 13 Aug 2025).

Appendix B generalizes this augmentation with a Transmission Graph $f$16, inspired by disjunctive graph models from job-shop scheduling. It includes operation vertices $f$17, source and sink vertices, conjunctive edges for route and order dependencies, disjunctive edges for link contention, and FIFO edges for queue order. The generalized algorithm maintains a critical cost $f$18 and a per-link prolongation delay $f$19, and updates these using bucket burst, rate, deferment, and overlap handling (Egger et al., 13 Aug 2025). A plausible implication is that the policy is intended to remain analyzable under multi-hop contention rather than being confined to single-hop intuition.

6. System model, deployment assumptions, and operational tradeoffs

The traffic model consists of a fixed set of time-triggered streams $f$20, each with a fixed route, period, phase, frame size, latency requirement, and PCP. The focus is on time-triggered traffic, which the paper treats as especially relevant for industrial settings with stringent timing requirements (Egger et al., 13 Aug 2025).

The scheduling model combines PSFP on ingress and TAS/GCL on egress. Under nominal operation, periodic traffic is admitted only when it arrives within its expected interval. For 5G integration, the architecture assumes a 3GPP-style arrangement in which the 5G system behaves as a logical 5G-TSN bridge. Devices visible to the CNC include wired TSN bridges, DS-TTs, NW-TTs, and TSN end devices. The architectural assumption is that 5G hides internal resource allocation and session details from TSN control while exposing bridge-like TSN behavior through translators (Egger et al., 13 Aug 2025).

The unstable network conditions of interest are epochs during which the delay assumptions used by the primary schedule do not hold for every frame. Examples include release-time anomalies, abrupt 5G delay outliers due to blockage or handover, and changing load that makes prior percentile models outdated. The paper explicitly states that the policy is not designed for arbitrary infinite delays; if the outlier already exceeds the frame deadline $f$21, then no real-time guarantee is possible (Egger et al., 13 Aug 2025).

Enforcement is split between centralized synthesis and distributed runtime behavior. The CNC computes the $f$22-patterns, PSFP forward/elevate/discard windows, and GCL augmentation, while each TSN bridge enforces those rules locally. This design is therefore centralized synthesis/configuration combined with distributed runtime enforcement (Egger et al., 13 Aug 2025).

The policy is deliberately complementary to the primary schedule. During normal operation, if frames arrive in their expected windows, the primary schedule forwards them normally and no priority elevation occurs. Quality of service remains close to that of the original schedule. However, because the schedule must reserve room for possible elevated traffic, the augmented schedule can introduce a small overhead even in stable conditions through prolonged slots, deferred later slots, and slightly increased latency or jitter for nominal traffic. During degraded conditions, selected delayed frames are elevated to PCP 7, unselected delayed frames are discarded, and the schedule remains valid because it was augmented in advance to tolerate the modeled elevated-traffic interference (Egger et al., 13 Aug 2025).

The principal tradeoff is explicit: the policy exchanges a little extra overhead under nominal conditions for substantial robustness under unstable conditions, and it protects selected weakly hard guarantees by intentionally dropping some delayed frames to shield other traffic. This suggests a design philosophy in which controlled sacrifice of some traffic is preferable to uncontrolled disruption of the schedule as a whole.

7. Evaluation context and significance

The paper reports three evaluation parts and lists performance metrics including schedulability: number of feasible schedules, maximum latency of sporadic streams, maximum jitter of isochronous streams, end-to-end latency under 5G delay outliers, and, in control experiments, median and maximum absolute pole-angle error $f$23 (Egger et al., 13 Aug 2025).

One evaluation component is a physical TSN testbed controlling an inverted pendulum over a network. The setup includes a talker and listener implemented as Linux machines with Intel I210 NICs, two Kontron TSN bridges, LinuxPTP synchronization, and ETF qdisc for precise transmission timing. The first link emulates 5G delays using histograms measured in prior work. The paper distinguishes stable epochs, in which 5G delays are upper-bounded by $f$24 (90th percentile), from unstable epochs; the supplied data truncates before the complete description of the unstable-epoch parameterization, but it explicitly states that the evaluations demonstrate two main findings: weakly hard real-time guarantees are essential to uphold the quality of control within a networked control system, and only a small overhead is imposed when the primary schedule can provide stronger quality of service guarantees (Egger et al., 13 Aug 2025).

Within that framing, the $f$25-firm Elevation Policy is significant because it offers a preconfigured fallback for environments where 5G-induced delay uncertainty cannot be fully captured by the assumptions used during schedule synthesis. It does not attempt to guarantee strict hard real-time behavior under all disturbances. Instead, it seeks to preserve a structured minimum guarantee that remains meaningful for control and cyber-physical applications when nominal timing assumptions break down (Egger et al., 13 Aug 2025). A common misconception would be to view the policy as a general-purpose reactive priority boost for any late frame; the paper’s formulation is narrower and more disciplined, since elevation eligibility is predetermined, analytically bounded, and coordinated across bridges through the $f$26-pattern.