Load-Adaptive Priority Migration Mechanism for Deterministic Switched Ethernet

1.1. Problem Statement and Motivation

The Deterministic Networking (DetNet) architecture [RFC8655] and its data plane framework [RFC8938] provide the foundation for delivering bounded-latency, zero-congestion-loss data flows over IP networks. [RFC9320] further establishes a methodology that uses queuing models and arrival curve analysis to compute end-to-end latency upper bounds.¶

However, existing DetNet queuing mechanisms — including Time-Aware Shaping (TAS), Credit-Based Shaping (CBS), Cyclic Queuing and Forwarding (CQF), and Guaranteed Service (GS) — collectively rely on a core assumption: scheduling parameters are pre-computed based on flow specifications established at flow setup time, and existing standards do not define mechanisms for adaptive parameter adjustment based on runtime load measurements [RFC9320]. While this assumption simplifies analysis and configuration, it introduces two practical limitations:¶

(1) Lack of runtime load visibility. The forwarding plane lacks the ability to measure per-hop utilization without injecting explicit probe traffic. Probe traffic itself consumes bandwidth and introduces measurement bias, undermining the objectivity of measurement results.¶

(2) Lack of dynamic priority adaptation. When actual traffic load exceeds the reserved envelope, low-criticality traffic cannot be gracefully degraded to protect high-criticality flows. The network falls into an "all-or-nothing" binary state — either operating normally or breaching all guarantees, with no smooth degradation gradient. This problem is logically equivalent to the rigid boundary dilemma of network slicing: resource allocation between slices is fixed at establishment time and cannot adaptively adjust as real-time load drifts.¶

The DetNet architecture (RFC 8655) allocates link bandwidth and buffer space for each flow through offline resource reservation, but reallocation of reserved resources is not permitted — unused reserved bandwidth can only be released to best-effort traffic (RFC 8578 Section 11.1.9), and cannot be transferred to other DetNet flows that also require deterministic guarantees. The 5G preemption mechanism (TS 38.213 PI/CI) reallocates resource blocks between URLLC and eMBB via control-plane signaling, with response times on the order of seconds. Together, these mechanisms reveal an architectural gap: at the L2 data plane, there exists no mechanism for real-time load-based adaptive priority migration capable of completing resource reallocation between deterministic flows within hundreds of milliseconds.¶

The above limitations affect a broad class of deterministic network deployment scenarios: automotive Ethernet backbones carrying mixed-criticality traffic (control, sensing, media), and industrial automation networks with dynamically changing production schedules.¶

This document addresses both limitations simultaneously through a load-adaptive approach: (a) using an M/D/1 inverse formula to derive per-hop utilization from measured forwarding delay, completely eliminating probe traffic requirements; (b) designing a load level classification scheme that triggers PCP remapping when utilization crosses configurable thresholds. The method has been validated through simulation experiments on a 5-node Ethernet topology representing an automotive zone gateway architecture, but its applicability extends to any switched Ethernet topology with periodic token path traversal capability.¶

1.2. Main Contributions

This document makes the following contributions:¶

• M/D/1 Inverse Formula: A closed-form expression to derive per-hop utilization rho from measured queuing delay Tq, requiring no iteration. The formula supports reverse configuration based on delay requirements in different network environments, with clear physical meaning.¶

• Three-Region Load Characterization: Three operationally distinct regions are identified in the M/D/1 inverse space (normal, transitional, saturated), where the underlying queuing distribution in the transitional region has undergone a qualitative change, yet the EWMA-smoothed utilization value remains nearly identical to the normal region.¶

• Load Classification with Hysteresis: A four-level scheme (Green/Yellow/Orange/Red) is designed, where downgrade requires confirmation over 8 consecutive samples to prevent level oscillation, while maintaining fast response to load spikes.¶

• Cross-Domain Maximum Aggregation: Load level decisions across multiple traffic domains are coordinated via a shared global variable, achieving consistent PCP migration policy enforcement.¶

• Experimental Validation: Comprehensive four-phase load testing on a 5-node Gigabit Ethernet network, covering injection periods from 50 ms to 10 ms across 8 priority levels.¶

1.3. Scope

This document specifies the following:¶

• M/D/1 per-hop utilization inverse formula¶

• Three-level load classification scheme and hysteresis logic¶

• Cross-domain maximum aggregation mechanism¶

• Priority-aware PCP migration rules¶

• Dual-format tokenized measurement protocol¶

The mechanism targets IEEE 802.1Q switched Ethernet and has been validated in a discrete-event network simulation environment with a 5-node Ethernet topology (1 initiator + 4 forwarding nodes) across three VLAN domains.¶

3.1. Alive Heartbeat Broadcast Frame

The Alive frame is a broadcast heartbeat message used for node liveness detection and load level summary synchronization. It MUST be broadcast once every T_Alive (200 ms) on each VLAN domain.¶

Format (65 B total, 19 B payload):¶

Byte 0: Layer-1 node address (0x00-0xFF) Byte 1: Layer-2 node address (0x00-0xF, Bit 0: layer-1 node) Byte 2: Control byte (bit 7: Alive/Ring, bits 5~0: 0) Bytes 3~6: Network phase map (node info, one bit per node) Byte 7: Protocol Version Byte 8: VLAN domain ID Byte 9: TTL Byte 10: Reserved ¶

3.2. Ring Chained Token Frame (Dual Timestamp)

The Ring frame is a chained token frame, unicast hop-by-hop along the logical ring, used for per-hop delay measurement and load data collection. It MUST be sent by the initiator node once every T_Ring (200 ms), traversing all nodes along the ring before returning to the initiator.¶

• Predecessor node timestamps for the next hop to compute Tq¶

• Per-hop timestamp history array (hop_ts + fwd_ts)¶

• Per-node load rate data array¶

• Ring control information (TTL, sequence number, command flags)¶

Frame format conventions are as follows: - Transport layer encapsulation: Alive frames use UDP port 30490, Ring frames use UDP port 30491 - Network layer addressing: IPv6 ULA prefix fd00::/48 is used, with each VLAN domain assigned an independent multicast group FF01::(VLAN_ID):1 (e.g., VLAN100 corresponds to FF01::100:1); MAC address mapping follows RFC 2464 - Byte order: All multi-byte fields use network byte order (Big-Endian) - Hop count limit: The hop counter is 8-bit, initial value 0, incremented by 1 for each forward, with a maximum support of 8 hops; frames exceeding the limit shall be silently discarded - Frame timeout mechanism: The initiator maintains a Ring frame timeout timer T_RingMon (default equal to the transmission period of 200 ms). If a RING_COMPLETE frame is not received before timeout, the round is determined to have triggered a timeout retransmission — the initiator re-sends the Ring frame to start a new traversal round. After N consecutive rounds of timeout, the link is deemed to have a fault; each node autonomously degrades to independent operation mode via local TTL timeout, and each node independently executes PCP migration using the most recently locally preserved load level until the next successful Ring frame restores global synchronization. This timeout retransmission mechanism does not depend on any external protocol stack.¶

3.3. RING_COMPLETE Broadcast and Load Data Aggregation

When the Ring frame returns to the initiator (identified by destination address or a dedicated RING_COMPLETE control byte), the frame already carries the per-hop rho data written in-place by all nodes on the link during their respective forwarding phases. The initiator aggregates all per-hop rho values to determine the global load level for the current VLAN, then MUST broadcast the completed frame to all nodes on that VLAN. Upon receiving the broadcast, each node updates EWMA and synchronizes its local global load level. If a particular hop's load rate is significantly higher than the link average, this indicates a localized bottleneck at that hop. The possible causes of such a bottleneck are not necessarily overall network load being high — it could also be due to equipment failure, link quality degradation, or unreasonable link bandwidth allocation. In such cases, the response SHOULD NOT trigger global PCP migration (global degradation cannot resolve a local fault), but rather to adjust the forwarding path to bypass the anomalous link, or for the network operations layer to re-evaluate the bandwidth allocation strategy for that link. The path adjustment mechanism for local bottlenecks is outside the scope of this document; the PCP migration described herein targets only egress queue congestion scenarios caused by elevated global load.¶

4.1. Ring Topology and Node Roles

The reference topology consists of one initiator node and N forwarding nodes (N = 4 in the reference implementation). The nodes are organized as a logical ring over a physical switched Ethernet fabric. The initiator initiates each ring traversal by sending a token frame (Ring frame). Each forwarding node receives the token, appends its measurement data, returns the data to the previous node, and initiates a new measurement toward the next node. The last node broadcasts the completed frame back to the initiator as RING_COMPLETE, simultaneously broadcasting it to all nodes on that VLAN.¶

4.2. Traffic Class Separation

Three VLAN domains isolate traffic by criticality level:¶

• TC0 (VLAN100): Highest criticality, PCP = 2, PCP migration prohibited¶

• TC1 (VLAN200): Medium criticality, PCP = 0~7, PCP-1 when LoadLevel >= 2¶

• TC2 (VLAN250): Lowest criticality, PCP = 0~7, PCP-1 when LoadLevel = 1, PCP-2 when LoadLevel >= 2¶

The TC0/TC1/TC2 division is logically equivalent to the independent logical channels allocated for different service classes in a network slicing architecture — the highest-criticality flows receive deterministic latency guarantees (analogous to URLLC), medium flows are unaffected under normal load but moderately degraded under high load (analogous to eMBB), and the lowest-criticality flows yield resources first (analogous to mMTC).¶

4.3. Dual-Format Heartbeat Protocol

LAPM relies on two frame formats working together to support load awareness:¶

• Alive frame: A broadcast heartbeat frame sent every T_Alive (200 ms), used for node liveness detection and load level summary synchronization. Payload: 10 bytes. See Section 3.1 for byte-level format.¶

• Ring frame: A chained token frame carrying per-hop timestamps (hop_ts + fwd_ts) and load data arrays, traversing each node along the ring with each hop appending measurement data. Payload: 41 bytes. See Section 3.1 for byte-level format.¶

The core advantage of this dual-format separation is: the low overhead of the Alive frame (10 B) enables high-frequency domain-wide liveness broadcasting, while the larger payload of the Ring frame (41 B) accommodates cumulative collection of per-hop measurement data. The two formats have distinct responsibilities -- Alive handles "who is alive", Ring handles "what is the load" -- avoiding the bandwidth waste of a single large frame carrying both responsibilities simultaneously.¶

5.1. Per-Hop Delay Measurement

Each forwarding node records two timestamps upon receiving a Ring frame:¶

• hop_ts: Arrival timestamp recorded by the current node (10 microsecond granularity)¶

• fwd_ts: Transmission timestamp acquired by the previous node at send time¶

The per-hop queuing delay is:¶

Tq = hop_delay - T_fixed. The timestamp measurement precision depends on time synchronization quality; see [IEEE8021AS] for synchronization requirements.¶

where T_fixed is the calibrated baseline processing time (359 microseconds in the simulation reference implementation, dominated by discrete-event scheduling overhead). This dual-timestamp measurement method is structurally isomorphic to IETF TWAMP (RFC 5357): TWAMP computes RTT through four timestamps (T1~T4) between Session-Sender and Reflector; LAPM simplifies this to per-hop dual timestamps to extract the queuing delay component Tq.¶

5.2. M/D/1 Inverse Formula and Ts Fair-Share Calibration

For an M/D/1 queue [KLEINROCK] with deterministic service time Ts, the mean queuing delay is:¶

Wq = (Ts * rho) / (2 * (1 - rho))¶

Setting Wq = Tq, the closed-form inverse solution for queuing delay Tq vs. link utilization rho is derived:¶

rho = (2 * Tq) / (2 * Tq + Ts)¶

This closed-form solution requires no iteration, guarantees convergence, and maps Tq in [0, infinity) to rho in [0, 1). Ts is a calibratable service time parameter.¶

Fair-Share Calibration Method. Traditional calibration methods require experimentally determining rho_ref under known load conditions, which presents a circular reasoning problem — calibration itself requires knowledge of rho, yet the purpose of the inverse formula is precisely to compute rho. This document proposes the Fair-Share calibration method to eliminate this circularity:¶

In an 8-priority-channel Ethernet port, assuming the channels evenly share the port bandwidth, the "fair share" for each channel is:¶

rho_ref = 1/8 = 12.5%¶

At this reference point, the actual load on the P7 channel precisely touches the fair-share boundary. Measuring Tq at this point and substituting into the inverse formula:¶

Ts = (2 * Tq * (1 - 0.125)) / 0.125 = 14 * Tq¶

rho_ref = 12.5% is a design assumption — in the initial deployment phase where per-domain traffic characteristics are unknown, assuming N channels evenly share the port bandwidth is the minimal-assumption starting point. The IEEE 802.1Q standard does not define the "fair share" concept; this document introduces this term as a design convention for the calibration method.¶

Under the load condition of rho_ref = 12.5%, a calibration experiment is conducted. Referencing the TSN maximum delay of 2ms, Tq is approximately 2000 microseconds, and substituting into the inverse formula:¶

Ts = (2 * 2000 * (1 - 0.125)) / 0.125 = 28000 us¶

Hence, the simulation environment calibration value is T_s,calib = 28000 microseconds (28 ms). Note: Ts = 14*Tq is an algebraic relationship; the value of Tq is determined by experimental measurement rather than prescribed by a formula; T_s,calib is directly obtained from experimental calibration.¶

Substituting T_s,calib = 28000 microseconds, the actual inverse formula used is:¶

rho = (2 * Tq) / (2 * Tq + 28000) (Tq in us)¶

where Tq is in microseconds. This formula maps Tq = 0 microseconds (idle) to rho = 0%, Tq of approximately 1354 microseconds (40 ms load) to rho of approximately 8.8% (Green region), and Tq of approximately 34376 microseconds (10 ms saturation load) to rho of approximately 71% (Red region).¶

Fair-Share Calibration Results. Under the same four load groups (50/40/20/10 ms SOME/IP injection periods), fair-share calibration (Ts=28ms, with Mean(5) pre-filtering + EWMA alpha=0.1) yields the following load rate results:¶

All three low-load scenarios (50/40/20ms) are correctly classified as Green (0.3->6.0->9.0% gradient), and the 10ms high-load scenario as Red (67.6%). The four groups are perfectly dichotomized with only the 12.5% single threshold.¶

Migration from Simulation to Real Networks. The Ts fair-share calibration method itself is platform-independent. The structure of the inverse formula rho = 2Tq/(2Tq + T_s,calib) remains unchanged across platforms; only the calibrated T_s,calib value varies with deployment environment (Section 5.2 describes calibration).¶

5.3. mean5 Moving Average and EWMA Smoothing

Before being fed to EWMA, raw rho_raw first passes through a moving average filter of width 5 frames (mean5) for preprocessing:¶

rho_mean = (rho_raw_n + ...) / 5¶

Physical basis for window length selection. Calculated with the chassis domain Ring period T_round = 200 ms, a 5-frame sliding window covers 5 x 200 ms = 1 s of time span. One second is precisely the maximum common transmission period for automotive network periodic messages — message periods are distributed as 10/20/50/100/500/1000 ms, and a 1 s window ensures that at least one complete transmission cycle of all periodic messages is covered. Within this window:¶

• Single-frame glitch rejection: Event-type burst traffic (diagnostic flashing, service discovery, etc.) appears at most once within 1 s, and after 5-frame averaging is diluted to 1/5 of the original amplitude, preventing single-frame Tq spikes from directly impacting EWMA;¶

• Steady-state baseline convergence: Short-period messages at 10/20/40/50 ms appear multiple times within the window, and their contribution to queuing delay converges to a steady-state baseline value after averaging;¶

• Sustained trend tracking: When network load undergoes a genuine sustained migration (e.g., switching from 50 ms injection to 20 ms injection), the samples in the window refresh frame by frame, and rho_mean completes the transition within 3 frames (600 ms) — cutting glitches without cutting trends.¶

After moving average, rho_mean is further smoothed by exponentially weighted moving average:¶

rho_hat_n = alpha * rho_mean[n] + (1 - alpha) * rho_hat_{n-1}¶

To determine the optimal smoothing coefficient alpha, 1000 candidate parameters were selected within the theoretical range (0, 1) with a step size of 0.001, and comparative analysis was performed under four typical load periods (50 ms, 40 ms, 20 ms, 10 ms) at TC1 (VLAN200) forwarding node 1, truncating the first 100 frames. The experimental pipeline is:¶

TqUs -> rho_raw = 2T_q/(2T_q + T_s,calib) -> mean(5) -> EWMA(alpha)¶

where T_s,calib = 28000 microseconds (Section 5.2 fair-share calibration value).¶

Comparison of final rho values for each alpha under four load groups (based on fair-share calibration Ts=28ms, median5 pre-filtering):¶

Key observation: Under fair-share calibration, alpha=0.10 produces the optimal four-level load gradient — the three safe-region scenarios (50/40/20ms at 0.3~9.0%) and the 10ms danger-region scenario (67.6%) have a 7.5x discrimination gap, and the three low-load levels themselves maintain a 30x gradient (0.3->9.0%), ensuring stable level determination.¶

Per-level recommendations (based on four-group load data):¶

Cold-start handling bypasses EWMA for the first valid sample to avoid initialization bias.¶

mean(5) Preprocessing Effectiveness Verification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^¶

To quantify the impact of mean(5) moving average on EWMA output, two pipelines — with and without mean(5) — were run under four load conditions, using the same 7 focus alpha values (0.01, 0.05, 0.10, 0.20, 0.30, 0.50, 1.00):¶

The cost is merely 2 frames of latency (approximately 400 ms at a 200ms period), in exchange for significant suppression of single-frame glitches (e.g., Tq jumping from 2000 microseconds to 50000 microseconds). mean(5) serves as a pre-filter, diluting single-frame spike energy to 1/5 before EWMA smoothing, so that EWMA's exponential decay weights are not severely biased by single-frame outliers.¶

Experimental results indicate that in discrete-event simulation environments such as CANoe, occasional Tq jitter is an inherent noise source; in real automotive ECU environments, such jitter is significantly reduced but does not disappear entirely. Therefore, mean(5) preprocessing has cross-platform universality and is recommended as a standard pre-stage retained before EWMA.¶

Adaptive Sliding Window Experiment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^¶

An intuitive improvement approach is to dynamically select the sliding window size based on the current load level — using a narrower window under low load to ensure response speed, and a wider window under high load to enhance smoothing. The experiment compared two approaches:¶

• Fixed approach: Global mean(5)¶

• Adaptive approach: Level 0~1 (rho < 25%) -> mean(5); Level 2+ (rho >= 25%) -> mean(10)¶

EWMA (alpha=0.10) was run on the outputs of both approaches, with comparison under three load groups (40ms, 20ms, 10ms) based on Ts=28ms calibration:¶

Conclusion: Under Ts=28ms calibration with alpha=0.10 configuration, neither the 40ms nor the 20ms scenario triggers the Level 2 threshold (25%), so adaptive and fixed approaches show no difference. The 10ms scenario remains entirely in Level 2+, but the adaptive wider window produces only a 1.6pp final value difference, far from sufficient to improve level determination. Considering that adaptive window switching introduces additional state-dependent logic, and provides no substantive improvement for any load scenario, maintaining fixed mean(5) is the preferred approach. If enhanced high-load smoothing is desired, a more efficient design is to apply the adaptive logic to EWMA's alpha coefficient (rather than the sliding window size).¶

5.4. Three-Region Nonlinear Characteristics

Experimental validation reveals three operationally distinct regions (based on fair-share calibration Ts=28ms, alpha=0.10):¶

Key observation: Under fair-share calibration, the three-level thresholds (12.5/25/37.5%) naturally isolate the rho fluctuation ranges of the three regions. The normal region's rho never touches the 12.5% line; the saturated region's rho fluctuation lower bound (~60%) is far above the three-level threshold cap of 37.5% — high-load region instability is safely isolated above the threshold ceiling, and rho will never oscillate between Green<->Red.¶

5.5. Queuing Delay Clamping

To prevent unbounded values from destabilizing EWMA, Tq is clamped:¶

T_q <- min(T_q, T_max)¶

where T_max is configurable. The reference implementation uses T_max = 50000 microseconds to capture the full queuing delay range under saturation conditions (observed raw values exceeding 40000 microseconds under 10 ms injection).¶

6.1. Level Thresholds

The smoothed utilization rho_hat is mapped to a load level according to the following LevelFromRho rule:¶

function LevelFromRho(rho): if rho >= 0.375: return 3 // Red if rho >= 0.25: return 2 // Orange if rho >= 0.125: return 1 // Yellow return 0 // Green ¶

Fair-share-based threshold selection. The thresholds 12.5% / 25% / 37.5% respectively correspond to 1/8, 2/8, 3/8 fair shares — for each additional 1/8 exceeded, the protection level escalates by one grade. This set of thresholds is derived from the inherent properties of the physical port's 8 channels, requiring no experimental calibration. However, due to the EWMA filtering effect, the overall load will be slightly lower than the defined 12.5%. Referring to actual test results, under low load after EWMA filtering, the overall load jitter fluctuates within 2%, so selecting 10.5% / 23% / 35.5% would yield better results.¶

Four-group load experiments (Section 8.3) verify the effectiveness of these thresholds: under 50ms period, EWMA rho = 0.3% (Green); under 40ms period, EWMA rho = 6.0% (Green); under 20ms period, EWMA rho = 9.0% (Green, near the 12.5% natural early-warning boundary); under 10ms period, EWMA rho = 67.6% (Red). All three low-load groups are correctly classified as Green, and the high-load group as Red — no missed detections, no false alarms.¶

Ceiling isolation effect of three-level thresholds. Under the 10ms high-load scenario, rho rises sharply in the Red region, but the three-level threshold cap is only 37.5% — the lower bound of high-load region rho fluctuation is far above this ceiling. This means that once the Red region is entered, rho will never fall back below 37.5%, and the risk of erroneously returning to Green/Yellow/Orange is zero. High-load instability is safely isolated above the threshold, not affecting level determination.¶

• Simulation platform constraint note: This experiment was run on a commercial discrete-event network simulator. Upon migration to a real ECU environment, the latency stability of physical ASIC switches is far superior to the simulation platform; T_fixed and Ts should be re-calibrated using measured Tq data from the target platform, but the fair-share thresholds (integer multiples of 1/8) themselves do not change with the platform.¶

6.2. Hysteresis Mechanism

To prevent level oscillation, downgrading from a non-zero level back to Green (Level 0) requires 8 consecutive low-load samples (rho_hat < 0.125). During this transition period, the level is held at Yellow (Level 1) as a conservative intermediate state. At a 200 ms ring interval (Section 8.1), the 8 x 200 ms = 1.6 s downgrade window provides sufficient oscillation-resistant persistence. Upward transitions (to higher levels) take effect immediately, ensuring fast response to load spikes.¶

6.3. Cross-Domain Maximum Aggregation

Each VLAN domain independently computes its local load level, and the globally shared level takes the maximum across all domains:¶

gCurrentLoadLevel = max(level100, level200, level250) ¶

This value is written to the global system variable NM::LoadLevel, accessible to all nodes for PCP migration decisions.¶

Physical motivation for taking the maximum. Taking max rather than weighted average follows the worst-case protection principle: among the three VLAN domains sharing a physical switch port, a bottleneck in any single domain implies global egress queue stress — "wherever the bottleneck appears, the warning covers there." A weighted average would mask localized congestion in individual domains — for example, if V250 (TC2) load surges but TC0/TC1 remain normal, the average could still fall within the Green region, causing the V250 critical flows that need protection to be missed.¶

6.4. Priority-Aware PCP Migration

Data frames carry PCP values in VLAN tags. When the shared load level reaches defined thresholds, PCP values are decremented to lower scheduling priority:¶

• TC0 (highest criticality): PCP migration prohibited — high-criticality traffic is never downgraded.¶

• TC1 (medium criticality): PCP-1 when LoadLevel >= 1. PCP = 0 is never further reduced.¶

• TC2 (lowest criticality): PCP-1 when LoadLevel = 1; PCP-2 when LoadLevel >= 2.¶

PCP migration is executed at the strict-priority queue output stage: frames are deposited into the slot corresponding to their (possibly migrated) PCP value, and the currently highest-priority pending frame is immediately output. From a network slicing perspective, the essence of PCP migration is runtime resource reallocation between data-plane slices — unlike 5G slicing which adjusts slice resource allocation via control-plane signaling (seconds-level response), PCP migration completes within hundreds of milliseconds without control-plane involvement.¶

8.1. Migration from Simulation to Real ECUs

The experimental validation in this document was conducted on a commercial discrete-event network simulator. In a real automotive ECU environment, network switching is performed by dedicated ASICs, where switching delay controllability far exceeds that of the simulation platform. However, T_fixed (physical baseline delay) and T_s,calib (calibrated service time) must be re-calibrated for the target platform. The Ts inverse calibration method established in this document — substituting Tq measurements under several known load conditions into Ts = 2Tq(1-rho)/rho to back-calculate — is itself independent of the simulation platform and can be directly migrated to a real environment.¶

8.2. Transitional Region Detection Enhancement

The experiment revealed a critical issue (Section 5.4): in the transitional region (20 ms injection), the EWMA-smoothed rho has risen relative to the normal region (9.0% vs 6.0%), but still resides within the Green level, while the statistical characteristics of the raw Tq distribution (such as clamp ceiling hit rate) have already changed. This indicates that relying solely on EWMA-rho for level determination is insufficient to capture early signs of congestion. Future work may consider parallel monitoring of rho_raw variance or the Tq clamp ceiling hit rate, establishing a multi-dimensional transitional region early-warning mechanism.¶

8.3. SPQ Hardware Implementation and Frame Preemption Synergy

In the current simulation environment, SPQ is implemented as software queues, introducing approximately 1 ms of minimum scheduling delay and not supporting 802.3br frame-level preemption. When deployed on real ASIC hardware SPQ, scheduling delay can be reduced to the microsecond level and can work in concert with 802.1Qbu frame preemption. Since this work's PCP migration mechanism directly manipulates the VLAN Tag priority field, migration from software SPQ to hardware SPQ is transparent.¶

8.4. Feedback Control of Adaptive Network Slicing

The LAPM adaptive closed loop established in this document can be formalized as a data-plane feedback control system: the sensor is the M/D/1 inverse (measuring rho), the controller is the LevelFromRho mapping + PCP migration, and the actuator is the egress strict-priority queue. This framework can be further generalized — replacing the alpha coefficient with an adaptive gain (e.g., Kalman filter), replacing four discrete levels with a continuous PCP mapping function, and extending a single-domain closed loop to multi-domain cooperative control (leveraging the coupling term of cross-domain maximum aggregation). This direction elevates L2 priority migration from a heuristic policy to a class of data-plane feedback control problems, providing a theoretical foundation for adaptive resource management in deterministic networks.¶

8.5. Response Delay Analysis

LAPM exhibits asymmetric upstream/downstream response characteristics:¶

• Upstream response (load increase -> PCP migration): approximately 200 ms (one Ring traversal period, Section 8.1). Load detection is triggered after the Ring frame returns to the initiator, and level transition takes effect immediately.¶

• Downstream recovery (load decrease -> PCP restoration): approximately 1.6 s (8 x 200 ms hysteresis). Section 6.2 mandates 8 consecutive low-load samples for downgrade, providing approximately 1.6 s of anti-oscillation window.¶

The asymmetric design — fast up (hundreds of milliseconds for safety response) and slow down (seconds-level for oscillation prevention) — matches the practical requirements of automotive networks: load spikes need rapid suppression (safety first), while load recovery can be conservative (stability first).¶

10.1. References

``` [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, October 2019.¶

[RFC8938] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, November 2020.¶

[RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, "Deterministic Networking (DetNet) Bounded Latency", RFC 9320, October 2022.¶

[IEEE8021Q-2018] IEEE, "IEEE Standard for Local and Metropolitan Area Networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2018, July 2018.¶

[Floyd-1993] Floyd, S. and Jacobson, V., "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, Vol. 1, No. 4, pp. 397-413, August 1993.¶

[Frangoudis-2013] Frangoudis, P.A., Ksentini, A., Hadjadj-Aoul, Y., and G. Boime, "PTPv2-Based Network Load Estimation", Proceedings of IEEE ISPCS 2013, pp. 101-106, September 2013.¶

[Yue-2005] Yue Peng, Liu Zengji, "A Novel Data Estimation Technique -- dEWMA and Its Application in RED", Journal of Electronics and Information Technology, Vol. 27, No. 8, pp. 1320-1323, 2005.¶

[Kong-2024] Kong, X., Li, C., Liang, G., Zhou, S., and C. Gao, "Research on Application of Time Sensitive Ethernet Technologies", Journal of Automotive Engineering, 2024.¶

[Hyndman] Hyndman, R.J. and Athanasopoulos, G., "Forecasting: Principles and Practice", 3rd ed., OTexts, 2021. ```¶

10.2. Appendix A: Complete M/D/1 Inverse Formula Derivation

For an M/D/1 queue with Poisson arrivals (rate lambda) and deterministic service time Ts:¶

Utilization: rho = lambda * Ts, 0 <= rho < 1¶

Mean queuing delay (Pollaczek-Khinchine formula, deterministic service C_s^2 = 0):¶

W_q = \fraclambda * T_s^22(1 - rho) = \fracrho * T_s2(1 - rho)¶

Setting Wq = Tq (measured queuing delay), solving for rho:¶

T_q = \fracrho * T_s2(1 - rho)¶

2T_q(1 - rho) = rho * T_s¶

2T_q - 2T_qrho = rho * T_s¶

2T_q = rho(2T_q + T_s)¶

rho = (2 * Tq) / (2 * Tq + Ts)¶

Ts is a calibratable service time parameter whose physical value is the frame transmission time, but which incorporates platform scheduling overhead in simulation or real environments. Ts can be determined through inverse derivation: rewriting the above formula to express Ts in terms of rho and Tq —¶

Ts = (2 * Tq * (1 - rho)) / rho¶

Under a reference condition with known load (rho_ref determined by the fair-share calibration method), measuring Tq under that condition and substituting into the above formula yields T_s,calib for that environment. The structure of the inverse formula rho = 2Tq/(2Tq + T_s,calib) remains unchanged. The calibration process and the derivation of T_s,calib = 28000 microseconds for the experimental environment in this document are detailed in Section 5.2.¶

10.3. Appendix B: Simulation Experiment Detailed Data

10.4. Appendix C: Experimental Data File Index

Raw experimental data is stored in the following files:¶

RC1 V200 EWMA multi-alpha analysis charts (first 100 frames, Ts=28000 microseconds, rho recomputed by 2Tq/(2Tq+Ts), English annotations):¶

Measurement scripts: rc1_someip_mon.py (Python COM automation), ewma_rc1_v200.py (RC1 V200 multi-alpha analysis), ewma_no_median.py (median5 comparison analysis), ewma_adaptive_median.py (adaptive window analysis)¶

11.1. Normative References

[IEEE8021AS]

"IEEE 802.1AS-2020 - Timing and Synchronization for Time-Sensitive Applications", n.d., <https://standards.ieee.org/standard/802_1AS-2020.html>.

[IEEE8021Q-2018]

"IEEE 802.1Q-2018 - Bridges and Bridged Networks", n.d., <https://standards.ieee.org/standard/802_1Q-2018.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8655]

Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/rfc/rfc8655>.

[RFC8938]

Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/rfc/rfc8938>.

[RFC9320]

Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, "Deterministic Networking (DetNet) Bounded Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022, <https://www.rfc-editor.org/rfc/rfc9320>.

11.2. Informative References

[Floyd-1993]

Floyd, S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", 1993.

[Frangoudis-2013]

Frangoudis, P. A., "PTPv2-Based Network Load Estimation", 2013.

[Hyndman]

Hyndman, R. J. and G. Athanasopoulos, "Forecasting: Principles and Practice", 2018.

[KLEINROCK]

Kleinrock, L., "Queueing Systems, Volume 1: Theory", 1975.

[Kong-2024]

Kong, W., "TSN Protocol Validation in Zonal Architecture", 2024.

[Yue-2005]

Yue, P., "Dual EWMA for Network Congestion Detection", 2005.