1) Technical Accuracy

1.1 Packet size parameterization is inconsistent (bytes vs bits)

• In the Downlink Haptics Traffic Model / Statistical Parameters table, Packet size is labeled “byte”, but the Pareto range is given as [504, 1736] bits.


• This is a clear unit inconsistency. If the range is truly in bits, the unit should be bits; if it is bytes, the numeric range is implausibly large for haptics.


• The Pareto CDF is written as (F(x)=1-(x_{\min}/x)^\alpha), but the table also states a range ([504,1736]) bits. A standard Pareto is unbounded above; if you intend a bounded/truncated Pareto, the CDF must be adjusted accordingly. As written, the “range” conflicts with the distribution definition.

1.2 Inter-arrival model conflicts with “silent periods do not need to be modeled”

• Principle (2) says silent periods do not need to be modeled, but the proposed exponential inter-arrival time inherently produces variable gaps, including long gaps (i.e., “silence”) unless explicitly truncated/conditioned.


• If the intent is “only model active periods,” then the model should be a two-state model (active/silent) or explicitly condition the exponential on an “active” state. Otherwise, the model does implicitly model silence.

1.3 Quantization to multiples of M is underspecified and may distort the distribution

• “Quantized to multiples of M using rounding function (e.g., M=32 ms)” is ambiguous:


• Is it round, floor, or ceil? Each changes mean/variance and tail behavior.


• If M=32 ms, this is very coarse for haptics-like traffic (often associated with higher update rates). Quantization at 32 ms can materially change burstiness and scheduler interaction.


• Also, “min=M” plus quantization implies the minimum IAT is M, but the exponential CDF shown is for a continuous distribution starting at 0. If there is a minimum, the correct model is shifted exponential: (T = M + X), (X\sim Exp(\lambda)), and the CDF should reflect that.

1.4 Parameter plausibility: λ=0.015 (per ms) implies ~66.7 ms mean IAT (before min/quantization)

• If (\lambda=0.015\ \text{ms}^{-1}), mean is (1/\lambda \approx 66.7) ms (plus any minimum). With M=32 ms and rounding, the effective mean could be even larger.


• This seems potentially inconsistent with typical “haptics” expectations (often tens to hundreds of Hz in some use cases). If this is a specific downlink haptic feedback stream, it needs justification and context (application, codec, sampling rate, event-driven vs periodic).

1.5 “Jitter follows TR 38.838 clause 5.1.1.2” is likely misapplied/unclear

• TR 38.838 is a RAN study TR; clause numbering and content may not map cleanly to “jitter” as a traffic model parameter for haptics. The document should specify:


• What jitter definition is used (packet delay variation? generation-time jitter? arrival jitter?).


• How it is applied in simulation (added to IAT? to latency budget?).


• As written, it is not technically actionable and risks misinterpretation.

1.6 PDB and Packet Success Rate are stated without defining the reliability metric

• “PDB 30 ms” and “Packet Success Rate 90%” are given, but:


• Is “packet success” defined as delivered within PDB (i.e., “survival” within deadline) or simply PHY/MAC delivery regardless of latency?


• 90% reliability is very low for many tactile/haptic control assumptions; if this is intentional (e.g., perceptual tolerance with concealment), it needs justification and reference.

1.7 Aggregation principle may be invalid depending on channel semantics

• Principle (1): “Simultaneous haptics packets over multiple channels can be modeled as one aggregated packet.”


• This can be wrong if channels have different QoS, different periodicities, different priorities, or different mapping to logical channels/flows (e.g., force feedback vs vibrotactile vs control).


• Aggregation changes packetization, header overhead, multiplexing behavior, and scheduler dynamics. It may be acceptable for load estimation but not for latency/reliability studies unless carefully bounded.

2) Completeness

2.1 Missing definition of the use case and trace conditions

• The model is said to be “based on haptics traces (provided in attachment),” but the contribution summary lacks essential metadata:


• Use case (teleoperation? gaming? XR interaction?),


• Downlink vs uplink semantics (what is “downlink haptics” exactly—feedback? commands?),


• Sampling rate / device characteristics,


• Codec/packetization rules,


• Network conditions during trace capture (if any).


• Without this, RAN1 cannot judge representativeness or applicability.

2.2 No goodness-of-fit or validation results

• The proposal asserts Pareto for size and exponential for IAT but provides no:


• Fit methodology (MLE? KS test? AIC/BIC?),


• Confidence intervals for α and λ,


• Comparison against alternative distributions (lognormal, Weibull, mixture models),


• Validation on hold-out traces.


• This is a major gap for a “statistical parametric model.”

2.3 Missing correlation model details

• Principle (3) says haptics and XR packets can be independent or correlated, but:


• No correlation structure is defined (cross-correlation function, conditional triggering, shared state machine, etc.).


• No parameters are provided to enable correlated generation in simulations.

2.4 Missing burst/active-silent modeling despite stating silence can be ignored

• If silent periods are excluded, you need:


• A definition of “active period,”


• How to model session-level activity (on/off durations),


• Or at least guidance on offered load scaling to account for omitted silence.

2.5 Uplink model reuse is too hand-wavy

• “Reuse uplink control or pose traffic model in section 5.2 of TR 38.838” lacks:


• Mapping justification (why pose/control is representative of haptic sensor data),


• Any parameter alignment (packet sizes, rates, deadlines),


• Any note on whether haptic sensors produce different temporal characteristics (often higher rate, lower payload, tighter jitter constraints).

2.6 Missing explicit reference to the “eXR model with Haptics”

• The document mentions “eXR model with Haptics” but does not cite:


• Which SA4 spec/TR defines it (if any),


• Whether it is aligned with existing XR traffic models used in RAN1 (e.g., TR 38.838 XR traffic models).

3) Impact Assessment (on specs and implementations)

3.1 Potential misalignment with existing XR traffic models in TR 38.838

• Introducing a new downlink haptics model with Pareto/exponential assumptions may conflict with existing XR traffic modeling approaches in TR 38.838 (which often use structured frame/GoP-like models and periodic control).


• If RAN1 adopts this model, simulation outcomes (scheduler performance, HARQ/URLLC configuration conclusions) could change materially due to:


• Heavy-tailed packet sizes (Pareto),


• Memoryless IAT (exponential),


• Coarse quantization (M=32 ms).

3.2 Aggregation assumption can under/over-estimate scheduler stress

• Aggregating multiple channels into one packet:


• Reduces multiplexing overhead and may reduce perceived contention,


• Changes packet deadline handling (one big packet vs several small ones),


• Can bias results for grant sizing, segmentation, and retransmission behavior.

3.3 Reliability/PDB values could steer RAN conclusions incorrectly

• A 30 ms PDB with 90% success could lead to relaxed design targets compared to typical URLLC-like assumptions. If this is not representative, it risks underestimating required robustness.

4) Feasibility (practical implementability)

4.1 Implementable but underspecified

• Pareto and exponential generation are easy to implement, but the current description is not simulation-ready due to:


• Unit ambiguity (bits/bytes),


• Truncation/quantization ambiguity,


• Missing “min=M” formal definition,


• Undefined jitter application.

4.2 Correlation option is not implementable as stated

• “Independently or with correlation” is not a model. Without a defined mechanism, implementers will create inconsistent interpretations, harming comparability across companies.

4.3 Reusing TR 38.838 uplink model is feasible, but may be invalid

• It is feasible to reuse an existing model, but the technical validity depends on whether “pose/control” matches “haptic sensor information.” This needs evidence.

5) Weaknesses (argumentation and methodology)

1. No evidence for distribution choices (Pareto/exponential) beyond assertion.


2. Internal inconsistencies (Pareto “range” vs unbounded CDF; bytes vs bits; exponential CDF vs min/quantization).


3. Key principles are not reconciled with the parametric model (ignoring silence vs exponential gaps).


4. No sensitivity analysis (how results change with α, λ, M, truncation).


5. No mapping to QoS flows (are there multiple 5QIs? different PDBs? different priorities?).


6. No clarity on whether this is application-layer traffic, PDCP SDU, or MAC PDU modeling—critical for RAN1.

6) Suggestions for Improvement

6.1 Fix the formal model definitions (must-do)

• Correct units: decide bits or bytes and use consistently.


• If packet size is bounded, specify truncated Pareto explicitly:


• Provide (x_{\min}), (x_{\max}), and the correct truncated CDF/PDF.


• For IAT:


• Specify whether it is shifted exponential (T=M+X) or truncated (T=\max(M, X)).


• Specify quantization operator: ceil/floor/round, and whether quantization happens before/after applying the minimum.

6.2 Provide trace context and reproducibility hooks

• Add a short “Trace description” section:


• application scenario, device, sampling, packetization, duration, number of sessions, and whether traces are from real network or local capture.


• Provide summary statistics from traces: mean/median/percentiles for size and IAT, burstiness metrics.

6.3 Add goodness-of-fit and alternative models

• Include at least KS-test (or similar) and Q-Q plots summary, plus parameter confidence intervals.


• Compare against plausible alternatives:


• lognormal for size,


• gamma/Weibull or mixture models for IAT,


• on/off (Markov-modulated) models if silence exists.

6.4 Define “silence” handling properly

• Either:


• Model silence explicitly with an on/off process (recommended), or


• Clearly state that the model is conditioned on active interaction and provide a separate activity factor (duty cycle) to scale offered load.

6.5 Make correlation actionable

• If correlation with XR is important, define one concrete option, e.g.:


• haptics packets triggered with probability (p) within Δt of XR frame events,


• or a shared state machine (interaction events) that generates both streams.


• Provide parameter values derived from traces.

6.6 Clarify QoS interpretation of PDB and success rate

• Define whether “Packet Success Rate” means:


• delivered within PDB, or


• delivered eventually (no deadline), or


• BLER/packet error at a given layer.


• If 90% is intentional, justify with perceptual studies or SA4 requirements; otherwise consider aligning with more typical reliability targets or provide multiple operating points.

6.7 Uplink model mapping justification

• If reusing TR 38.838 §5.2, explicitly map:


• packet size distribution,


• periodicity,


• latency/jitter constraints,


• and explain why haptic sensor traffic matches pose/control.

Bottom line

The contribution is directionally useful as a liaison response, but the proposed downlink haptics model contains unit errors, distribution-definition inconsistencies, and insufficient specification detail to be safely adopted by RAN1 for comparative studies. Strengthening the statistical justification, clarifying silence/correlation handling, and making the model fully reproducible would materially improve its technical value and reduce the risk of divergent interpretations in RAN1 evaluations.