[Technical] The proposed immersive gaming data rates “100, 300, 500 Mbps” and frame rates “90/120 fps” are introduced without any linkage to codec assumptions, resolution/FOV, compression efficiency, or split between video vs. pose/control traffic, making it impossible for SA4 to validate whether these are realistic or internally consistent with TR 38.838’s XR service assumptions.

[Technical] The packet size mean formula (M = R \times 10^6 / F / 8) implicitly assumes one packet per frame and that all traffic is frame-synchronous, which is generally not true for immersive gaming (multiple slices/tiles, audio, metadata, pose updates); this risks producing a misleading packetization model compared to TR 38.838’s intent.

[Technical] Changing the truncated Gaussian parameters to STD=25% and Min/Max=25%/300% for immersive gaming is a major behavioral change, but no evidence is provided that packet sizes for gaming are Gaussian-like or that the tails (up to 3× mean) are representative; this could significantly distort scheduler/buffer evaluations and should be justified or replaced with an empirically grounded distribution.

[Technical] The PDB values for immersive gaming (baseline 15 ms, optional 10/30 ms) are asserted without clarifying whether they apply one-way, E2E, or radio-interface budget, and without mapping to SA4 latency definitions; this ambiguity can lead to inconsistent interpretation across RAN1/SA4.

[Technical] For “UL-heavy video uploading,” the model proposes lowering packet generation rate to 15/30 Hz while increasing data rate up to 100 Mbps, which implies very large packets per “frame” (hundreds of kB) and may exceed typical MTU/segmentation behavior; the model should specify segmentation/packetization rules or else results will be non-comparable.

[Technical] Presenting two mutually exclusive candidates for UL packet size variability (baseline 10.5/50/150% vs. 25/25/300%) without selection criteria or scenario mapping leaves the model under-specified and undermines reproducibility of evaluations.

[Technical] The UL model references “Jitter: Optional, follows clause 5.1.1.2” but does not state whether jitter is applied to inter-arrival times, frame times, or both, nor how it interacts with the reduced 15/30 Hz generation; this can materially change burstiness and should be explicitly defined.

[Technical] Model-2 (“with haptics”) is largely FFS: packet size, silent periods, multi-channel generation, and co-generation mechanism are all open, meaning the model cannot yet be implemented consistently; at minimum, a baseline deterministic haptics model (rate, size, silence model) is needed before SA4 can meaningfully comment.

[Technical] The haptics PDB values “12 ms or 30 ms” are given without rationale and without stating whether haptics is more stringent than XR video/pose traffic; SA4 will need a clear service-level justification and relationship to immersive communication QoS targets.

[Technical] The statement “haptics traffic defined as XR traffic packet generation with co-generated haptics packets” is unclear: co-generated could mean same timestamp, same bearer, or correlated arrivals; the correlation model must be specified because it affects multiplexing gains and peak load.

[Editorial] The contribution cites “Table 5.4.1-1”, “Table 5.1.1.1-1”, and “Table 5.5.2.1-1” and “clause 5.1.1.2” but does not explicitly identify the source document/version (presumably TR 38.838); SA4 cannot verify the deltas without exact references.

[Editorial] Several baseline values appear inconsistent/unclear (e.g., “baseline: 30, 8 Mbps” for gaming data rate) and should be corrected to a single baseline per scenario or explicitly indicate multiple baselines; as written it is ambiguous and risks misinterpretation.

[Editorial] Terminology is inconsistent (“immersive communication,” “eXR,” “XR,” “AR UL Model 1,” “CG Traffic Model”) without definitions or mapping to TR 38.838 scenario names; aligning names and adding a short mapping table would improve clarity and reduce cross-WG confusion.