1. [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.

2. [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.

3. [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.

4. [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.

5. [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.

6. [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.

7. [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.

8. [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.

9. [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.

10. [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.

11. [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.

12. [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.

13. [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.

1) Technical Accuracy

1.1 Mischaracterisation of the normative scope and ownership

• The summary states: “IMS Data Channel applications defined in 3GPP TS 26.114.”
  Issue: TS 26.114 is an SA4 codec/media handling specification (IMS conversational multimedia), and while it may include aspects related to conversational services and media, the definition and service requirements for “IMS Data Channel applications” (and any “Data Channel” feature) typically span multiple specs and groups (SA1 requirements, SA2 architecture, CT protocols, SA4 media). Claiming that the applications are “defined” in TS 26.114 is at best imprecise and may be misleading.
  Suggestion: Use more accurate wording such as “specified/handled in TS 26.114 (media aspects)” and cite the primary spec(s) where the Data Channel feature is actually defined (service requirements and architecture).

1.2 Overstated regulatory conclusion (“expected to be subject to telecom regulation”)

• The summary asserts: “When IMS Data Channel is part of IMS telephony services … expected to be subject to local telecom regulation.”
  Issue: This is a strong statement and reads like a regulatory determination. In most jurisdictions, regulatory classification depends on the service offered to end users (e.g., ECS/ICS concepts in EU, “telecommunications service” vs “information service” in US, etc.), not on whether a feature is “part of IMS telephony” at a technical level. A Data Channel used within a telephony session does not automatically make the content itself regulated as telecom; it may be treated as an ancillary service, an application-layer feature, or content, depending on local law.
  Risk: The statement could be interpreted as 3GPP taking a legal position, which 3GPP generally avoids.

1.3 Ambiguity between “IMS telephony services” and “standalone Data Channel”

• The summary introduces “standalone Data Channel” as “other services.”
  Issue: The term “standalone” is not clearly defined here. Is it:
• a Data Channel established outside an IMS telephony session but still within IMS?
• a non-IMS service using similar technology?
• a WebRTC-like data channel?
  Without definition, the regulatory discussion is not technically anchored and may be internally inconsistent.

1.4 Technology/content conflation (HTML/JavaScript)

• The summary frames the question as “HTML and JavaScript content (typically not subject to telecom regulation).”
  Issue: Whether HTML/JS is regulated is not a technical property; it depends on the service context and jurisdiction. Also, “HTML/JS content” implies a browser-like execution environment on the UE, which raises security and platform questions that are not addressed (see completeness).

2) Completeness

2.1 Missing references to the exact question and original LS text

• The review text references “Question 6” but does not include:
• the exact wording of Question 6 from NG UPG, or
• the exact SA1 reply text.
  Impact: It is hard to verify whether SA1’s response is accurate, complete, or appropriately scoped. A reviewer cannot assess whether the response actually addresses the question.

2.2 Missing normative/spec references beyond TS 26.114

• If the topic is “IMS Data Channel,” the document should reference:
• the service requirements spec(s) (SA1),
• architecture spec(s) (SA2),
• protocol specs (CT), and
• security/privacy specs (SA3), as applicable.
  Gap: Only TS 26.114 is mentioned, which is insufficient and likely not the primary anchor for “application” behaviour.

2.3 No analysis of security, execution environment, and content handling

• Discussing HTML/JavaScript implies:
• code execution on UE,
• sandboxing,
• origin/authentication of content,
• integrity protection,
• update/refresh behaviour,
• interaction with the call UI and user consent.
  Gap: None of these are addressed, yet they are central to both feasibility and regulatory concerns (e.g., consumer protection, malware, lawful intercept boundaries, privacy).

2.4 No clarification of what 3GPP can/should standardize

• The response says it is “not within scope to determine which regulation(s) HTML/JS would be subject to.” That is reasonable, but incomplete without stating:
• what 3GPP can do (e.g., define technical hooks for compliance, transparency, user consent, logging, policy control),
• what is out of scope (legal classification).
  This would make the liaison more actionable.

3) Impact Assessment (on specs and implementations)

3.1 Potential downstream interpretation risk

• Even if the LS is non-normative, statements like “expected to be subject to telecom regulation” may be used by:
• regulators as “industry position,”
• operators to justify compliance burdens,
• vendors to implement restrictive behaviours.
  Impact: Could inadvertently influence implementation and deployment decisions without technical basis.

3.2 Interworking and product implications not assessed

• If “Data Channel applications” can carry active content (HTML/JS), implementations may need:
• a rendering engine,
• a secure runtime,
• content validation,
• policy enforcement.
  Impact: Major complexity and fragmentation risk across UE platforms and vendors. The document does not assess this.

3.3 No assessment of backward compatibility / feature negotiation

• If regulatory treatment differs by service context, implementations may need:
• explicit signalling of service type/context,
• policy control hooks,
• user consent flows.
  Gap: No mention of how existing IMS clients or networks would distinguish “telephony context” vs “other services.”

4) Feasibility

4.1 Practical implementability of “HTML/JavaScript content” in IMS context is unclear

• If the intent is to deliver executable web content over an IMS Data Channel, feasibility depends on:
• UE capability standardization (or explicit non-standardization),
• security model (sandbox, permissions),
• content provenance (signing, trusted sources),
• lifecycle management (caching, revocation).
  Assessment: Without these, the proposal is not implementable in a consistent, interoperable way.

4.2 Regulatory compliance cannot be “implemented” without technical hooks

• If the liaison implies telecom regulation may apply, then implementers will ask:
• How to support lawful intercept boundaries?
• How to ensure emergency services constraints (if applicable)?
• How to ensure accessibility/consumer transparency?
  Assessment: The LS provides no technical guidance, so it is not actionable for implementers.

5) Weaknesses in Argumentation / Methodology

5.1 Lacks a clear separation between legal classification and technical standardization

• The response appears to drift into legal conclusions (“expected to be subject…”) while also disclaiming scope. This is internally inconsistent.

5.2 No jurisdictional neutrality

• 3GPP typically avoids statements that assume a universal regulatory model. The summary’s framing (“telecom regulation” vs “not telecom regulation”) is too binary and not globally valid.

5.3 Undefined terms and missing context

• “IMS telephony services,” “standalone Data Channel,” and “applications” are not defined, making the response hard to interpret and easy to misapply.

6) Suggestions for Improvement

6.1 Tighten terminology and cite the correct specs

• Replace “defined in TS 26.114” with precise references:
• identify the primary spec(s) defining the Data Channel feature and its usage,
• clarify whether TS 26.114 is only referenced for media handling aspects.
• Define “IMS telephony service” in terms of 3GPP service definitions (or reference the relevant SA1 service requirement clauses).

6.2 Rephrase to avoid legal determinations

• Replace “expected to be subject to local telecom regulation” with neutral language, e.g.:
• “Regulatory treatment is jurisdiction-dependent and typically depends on the service offering and national definitions; 3GPP does not determine classification.”
• If SA1 wants to be helpful, it can add:
• “When used as part of a regulated telephony offering, operators may need to consider applicable obligations for the overall service.”

6.3 Make the liaison actionable by identifying technical considerations (without giving legal advice)

Add a short list of technical aspects that may be relevant for compliance and risk management, such as:
- content provenance and integrity (signing, authentication),
- UE execution environment constraints (sandboxing, permissions),
- user consent and transparency,
- policy control and operator configuration,
- logging/auditing hooks (where appropriate),
- security and privacy considerations (coordinate with SA3).

6.4 Clarify the “standalone Data Channel” scenario

• Explicitly describe the scenarios NG UPG is asking about:
• within an IMS telephony session,
• within other IMS sessions,
• outside IMS (if relevant).
• If “standalone” is not a 3GPP-defined service, say so and limit the response accordingly.

6.5 Include the exact Question 6 text and the exact SA1 reply text in the contribution (or as an attachment)

• This is essential for traceability and for SA plenary to consolidate responses correctly.

6.6 Engage the right groups for a coordinated response

• Recommend that SA consolidates inputs from:
• SA2 (architecture/service context),
• SA3 (security model for active content),
• CT (signalling/negotiation),
• SA4 (media/data channel handling),
• SA6 (application enablement, if applicable).
  This will prevent SA1’s response from being interpreted as the sole “3GPP position.”

Bottom line

As summarized, the liaison response is directionally cautious (“not within scope to determine regulations”) but undermined by imprecise spec referencing, undefined scenarios, and an over-strong statement implying regulatory classification. It should be rewritten to be jurisdiction-neutral, technically anchored (correct specs/definitions), and more actionable by highlighting relevant technical considerations without making legal assertions.

1) Technical Accuracy

1.1 Ambiguity / potential mischaracterization of “IMS specifications”

• The statement “Model handling in MF and enriching MF with inference capability are currently not supported by IMS specifications” is broadly true in the sense that IMS does not standardize AI/ML model lifecycle management or inference APIs.
• However, it is too absolute and risks being technically misleading because IMS does already support:
• Media manipulation and media-related functions via IMS media architecture (e.g., MRFC/MRFP concepts in IMS multimedia resource functions, and media anchoring/processing in IMS deployments).
• Application server-based service logic (e.g., SIP AS) that could host AI/ML logic without requiring new IMS core normative support.
• If SA2 intends to say “no normative IMS procedures exist for AI/ML model distribution, execution, or inference control,” it should be stated explicitly. As written, it could be read as “IMS cannot support AI/ML media processing at all,” which is not accurate.

1.2 “MF (Media Function)” terminology is underspecified

• “MF” is not a universally unambiguous IMS term across SA2/SA4 contexts. In IMS, media functions are often discussed as MRF (MRFC/MRFP), MGW, TrGW, IMS-AGW, etc., depending on the feature.
• If SA4 used “MF” in a specific SA4 media architecture sense, SA2 should align terminology or reference the exact definition. Otherwise, the LS risks confusion and incorrect scoping.

1.3 Reference to “TS 23.228 Annex AC” as baseline is questionable without context

• TS 23.228 is the IMS stage-2 spec; Annexes vary by release and may change. Citing “Annex AC” without:
• a short description of what Annex AC covers, and
• the exact release/version,
  makes the baseline reference fragile and potentially incorrect for recipients.
• Also, if the topic is “AI/ML for media,” TS 23.228 may not be the only or best baseline; depending on the intended function, other specs (e.g., IMS media resource function aspects, IMS RTC study outputs, or SA4 media specs) may be more relevant.

1.4 “Not in scope of the IMS RTC study for Rel-20” needs evidence

• This may be correct, but the LS provides no citation to the RTC study item scope, objectives, or agreed conclusions. Without referencing the relevant study report or WI description, it reads as an assertion rather than a verifiable statement.

2) Completeness

2.1 Missing summary of SA4’s ask and technical problem statement

• The response does not restate what SA4 requested (from S4aR250196 / S2-2509930). Without that, the LS is hard to evaluate and risks misalignment.
• A good LS response should include:
• the SA4 request in 2–3 bullets,
• SA2’s understanding of the intended use cases,
• and where SA2 sees gaps or overlaps.

2.2 Missing use cases and functional decomposition

• SA2 asks “what new functionalities are expected,” but does not propose a structured template. This is a missed opportunity. The LS should request:
• Use cases (e.g., noise suppression, super-resolution, avatar rendering, content moderation, QoE optimization, codec parameter tuning)
• Where inference runs (UE, network media function, AS, edge)
• Control plane triggers (SIP/SDP, HTTP APIs, policy control)
• Media plane implications (RTP/RTCP extensions, new payload types, transcoding, latency budgets)

2.3 Missing references to relevant 3GPP AI/ML work

• Even if IMS RTC study excludes it, 3GPP has broader AI/ML activities (SA1/SA2/SA5, and potentially CT aspects). The LS should at least acknowledge:
• whether any existing 3GPP AI/ML enablers could be reused,
• whether the proposal overlaps with non-IMS AI/ML management frameworks (if any exist in Rel-19/Rel-20 contexts).

2.4 Missing assessment dimensions

• The LS says SA2 will assess impacts after clarification, but does not list what dimensions SA2 will evaluate. It should request information needed for:
• security/privacy,
• interoperability,
• charging,
• lawful intercept,
• QoS/QoE and policy,
• roaming/interconnect implications.

3) Impact Assessment (on specs and implementations)

3.1 Potential spec impact areas are not identified

If AI/ML “model handling” or “inference capability” were to be standardized in IMS context, the likely impacted areas include:
- Stage 2 architecture (TS 23.228): new functional entities or enhancements to existing ones (MRF/MF, AS, UE capabilities).
- SIP/SDP procedures: negotiation of AI/ML-based media processing, capability exchange, and service invocation.
- Media plane specs: RTP/RTCP behavior, potential new RTP header extensions, payload considerations, or constraints on transcoding.
- OAM/management: model provisioning, versioning, rollback, telemetry.
- Security: model integrity, provenance, execution sandboxing, privacy of media features/embeddings.

None of these are mentioned, so SA4 cannot gauge the magnitude of the work or where to focus.

3.2 Risk of unintended “no” message

By stating “not supported” and “not in scope,” the LS may be interpreted as a rejection rather than a request for clarification. That can prematurely shut down useful exploration, especially if SA4’s ask is modest (e.g., capability signaling only).

3.3 Implementation impact not discussed

Even if no normative changes are made, vendors may implement proprietary AI/ML media processing in AS/MRF. Standardization could:
- improve interoperability but
- impose significant compliance burden (model lifecycle, certification, security).

The LS does not acknowledge this trade-off.

4) Feasibility (practical implementability)

4.1 Feasibility depends on where inference runs—LS does not constrain it

• UE-based inference: feasible with capability signaling and optional service invocation; minimal network impact but device diversity is high.
• Network MF/MRF inference: feasible but heavy; requires compute placement, scaling, latency control, and potentially new management interfaces.
• AS-based inference: feasible and aligns with IMS service model, but may still require standardized invocation and media anchoring.

The LS does not ask the key feasibility questions (latency budget, compute placement, model size, update frequency, fallback behavior).

4.2 Interoperability feasibility is not addressed

If “model handling” is in scope, interoperability becomes difficult unless 3GPP standardizes:
- model format constraints (or references external standards),
- version negotiation,
- minimum inference behavior,
- conformance testing approach.

The LS does not flag these challenges to SA4.

5) Weaknesses in argumentation / methodology

5.1 Overly high-level and reactive

The response is essentially “not supported; please clarify.” It lacks:
- SA2’s interpretation of SA4’s intent,
- a preliminary gap analysis,
- a list of candidate architectural options.

5.2 Single baseline reference is insufficient

Relying only on “TS 23.228 Annex AC” is weak. A robust methodology would cite:
- the RTC study scope text,
- relevant IMS media architecture clauses,
- any SA4 media function specs that define MF behavior.

5.3 No explicit decision request or timeline

The LS does not say what SA2 needs to decide next (e.g., whether to open a study item, whether to treat as out-of-scope for Rel-20, whether to capture as Rel-21 candidate). Without a timeline, the exchange may stall.

6) Suggestions for improvement (constructive)

6.1 Tighten terminology and references

• Replace “MF” with the exact standardized entity name(s) (e.g., MRF/MRFC/MRFP) or explicitly define MF in the LS.
• Cite exact spec versions (e.g., TS 23.228 v20.x.y) and briefly state what “Annex AC” contains and why it is the baseline.

6.2 Provide a structured clarification template to SA4

Ask SA4 to answer in a table, for each proposed AI/ML capability:
- Use case / service description
- Execution location (UE / AS / MRF / edge)
- Required signaling (SIP/SDP? HTTP? policy?)
- Media plane impact (RTP/RTCP changes? transcoding? new streams?)
- Model lifecycle needs (download, update, selection, rollback)
- Performance constraints (latency, bitrate overhead, compute)
- Security/privacy considerations (model integrity, data exposure)

6.3 Add a preliminary SA2 gap analysis (even if incomplete)

Include 5–10 bullets mapping “what IMS already supports” vs “what would be new,” e.g.:
- Existing: service invocation via SIP AS; media anchoring; conferencing resources.
- Potential new: capability negotiation for AI/ML processing; standardized control of AI/ML media enhancement; model version signaling; policy control hooks.

This helps SA4 respond concretely and reduces iteration cycles.

6.4 Clarify scope positioning and next-step options

Instead of only stating “not in scope,” propose options:
- Option A (minimal): standardize only capability signaling and service invocation hooks (low impact).
- Option B (medium): standardize network media function behavior for specific AI/ML media enhancements (moderate impact).
- Option C (high): standardize model handling lifecycle (high impact, likely cross-SA coordination).

6.5 Explicitly call out cross-group dependencies

If model handling is discussed, flag likely need for coordination with:
- SA3 (security),
- SA5 (management),
- CT (protocol impacts),
- and any 3GPP AI/ML framework activities.

6.6 Improve the LS tone to avoid premature rejection

Rephrase “not supported” to “not currently specified normatively” and “not in scope of current study” to “not covered by current Rel-20 RTC study objectives,” while leaving room for Rel-21 consideration if justified.

Overall assessment

The LS is technically plausible but too terse and underspecified to be effective. It risks confusion due to ambiguous terminology (“MF”), fragile referencing (“Annex AC”), and lack of a structured request for the information SA2 actually needs. Strengthening the clarification request with a template, adding minimal gap analysis, and clearly outlining feasible standardization options would materially improve the contribution’s quality and usefulness.

1) Technical Accuracy

Scenario 1 (Roaming S8HR/N9HR): “LI implies these interfaces should not be confidentiality protected”

• Questionable / likely incorrect framing. LI requirements do not generally imply that roaming interfaces (S8HR/N9HR) “should not be confidentiality protected.” 3GPP LI is typically realized via network-internal interception functions and handover interfaces (HI), not by mandating plaintext on service interfaces.
• If SA2 suggested “make traffic visible to VPLMN by removing encryption,” SA3 is right to flag it as problematic, but SA3’s wording risks implying that LI requires no confidentiality protection on those interfaces. That is not a safe or accurate generalization.
• Missing distinction between “interceptability” and “decryptability.” LI can be satisfied by delivering IRI/CC from an entity that legitimately terminates security (or has access to keys under lawful authorization), rather than forcing “no encryption” on the bearer.

“VPLMN could access DC content copy … using DTLS 1.2 with NULL cipher”

• Technically dubious as a practical proposal.
• DTLS 1.2 does define NULL cipher suites, but real-world stacks often disable them, and many security policies prohibit negotiating NULL. Even if “possible,” it is operationally unrealistic and would be non-compliant with common security baselines.
• More importantly: if the IMS Data Channel is end-to-end protected between UE and some home-network function, the VPLMN cannot simply “choose” NULL cipher unless it is a DTLS endpoint (i.e., terminating DTLS). If VPLMN is not the DTLS endpoint, cipher choice is irrelevant.
• DTLS 1.3 statement needs specification anchoring. It is broadly correct that DTLS 1.3 removes NULL cipher suites, but the document should cite the relevant IETF RFC(s) and the 3GPP normative references that mandate/recommend DTLS versions for IMS Data Channel (if any).

“DTLS 1.3 is recommended from Rel-19 onwards”

• Potentially inaccurate / at least unsupported in this summary. 3GPP does not “recommend DTLS1.3 from Rel-19 onwards” in a vacuum; it depends on the specific feature/spec. If SA3 is making a normative direction claim, it must be backed by:
• the exact 3GPP spec(s) and clause(s) where DTLS versioning is specified for IMS Data Channel, and
• whether it is a “shall”/“should”/informative recommendation.
• As written, it reads like a policy statement rather than a spec-grounded fact.

“Security downgrade must be applied to all HPLMN UEs to avoid LI detectability”

• Overstated and not rigorously justified.
• LI “undetectability” requirements exist in many jurisdictions, but the conclusion that all HPLMN UEs must be downgraded is not necessarily true. There are alternative approaches (e.g., lawful key access, network termination points, targeted duplication at trusted functions) that do not require global downgrade.
• If the argument is “targeted downgrade is detectable by the target,” that needs a threat model and evidence (what signals are observable to the UE? handshake parameters? cipher suite list? certificate chains?).

“Conflicts with regulatory requirements (e.g., EU Cyber Resilience Act)”

• Risk of being misleading.
• The EU CRA is not a simple “must encrypt data in transit by default” rule in the way stated here; it is broader product security regulation with essential requirements. The document should be careful not to assert a specific legal obligation without precise citation and interpretation.
• Also, 3GPP generally avoids making strong legal compliance claims without careful wording. This should be framed as “may create compliance challenges” rather than a definitive conflict, unless SA3 has legal analysis.

2) Completeness

Missing normative references and clause-level grounding

The summary lacks:
- Exact spec references for IMS Data Channel security architecture (e.g., where DTLS is specified, endpoints, cipher requirements).
- LI architecture references (TS 33.107/33.108, and any IMS-specific LI specs such as TS 33.108 annexes or relevant SA3-LI outputs). The document should explicitly map the scenarios to LI requirements: IRI, CC, and where interception points are expected.

Missing analysis of alternative LI-compliant architectures

Scenario 1 focuses on “NULL cipher / no confidentiality” as the implied solution and rejects it. What’s missing:
- Options such as anchoring/termination in a trusted network function (home or visited) that can lawfully provide CC.
- Key escrow / lawful key access models (even if controversial) should be mentioned as possibilities and then rejected with rationale if SA3 opposes them.
- Split interception (IRI in VPLMN, CC in HPLMN) and how that meets regulatory needs in roaming.

Missing threat model and detectability analysis

Claims about detectability and downgrade need:
- What the UE can observe (DTLS handshake, cipher suite negotiation, ALPN, certificate, fingerprinting).
- Whether “undetectability” is a requirement in the relevant LI requirements baseline for this feature.

Scenario 2: insufficient technical detail

• The “DC Application Proxy” applicability question is good, but incomplete:
• What is the exact TS 23.228 text being referenced?
• What is the call flow for UE-initiated P2P DC in each proxy mode?
• Where is MF located (home/visited), and what are the trust boundaries?

Scenario 3: acceptance of “no gaps” is weak

• SA3’s “will not explore further” is not robust. Even if SA2 sees no gaps, SA3 should at least:
• sanity-check LI coverage for interworking conversions (DC ↔ RTP video, DC ↔ SMS/HTTP) and whether CC remains meaningful (content transformation, loss of metadata, timing).
• confirm whether existing LI specs cover new identifiers (DC session IDs, MF anchoring identifiers, DTLS fingerprints, etc.).

3) Impact Assessment

On security posture and interoperability

• If any solution implies weakening DTLS (NULL cipher or forced downgrade), the impact is severe:
• breaks modern security baselines,
• likely breaks interoperability with implementations that disallow NULL,
• creates a long-term maintenance and compliance burden.

On existing IMS/DC implementations

• If the proposal (or SA2’s implied approach) requires VPLMN access to plaintext, it may require:
• architectural changes (visited network termination of DTLS, new trust relationships, new keying models),
• updates to MF/DC AS behavior,
• potential changes in UE behavior (cipher suite support, negotiation constraints).

On LI specifications and handover interfaces

• Any new interception point (MF/DC AS) may require:
• new or updated IRI/CC definitions,
• correlation identifiers for DC sessions,
• clarification of where CC is produced (visited vs home) in roaming.

4) Feasibility

DTLS NULL cipher approach

• Low feasibility:
• often disabled in libraries,
• unacceptable to security certification regimes,
• incompatible with DTLS 1.3 direction,
• operationally fragile (middleboxes, policy enforcement, audits).

“Apply downgrade to all HPLMN UEs”

• Not feasible operationally:
• massive blast radius,
• unacceptable user/security impact,
• likely to be rejected by operators and regulators focused on cybersecurity.

Proxy-mode anchoring for LI (Scenario 2)

• Feasible in principle, but needs:
• clear normative permission in architecture specs (TS 23.228 and related),
• clear definition of when MF may anchor UE-initiated P2P,
• performance/latency considerations and scaling impact.

5) Weaknesses

• Over-reliance on a strawman solution (NULL cipher / no confidentiality) without systematically evaluating other LI mechanisms.
• Insufficient specification grounding: multiple claims (“DTLS1.3 recommended from Rel-19”, “TS 23.228 says…”) are not backed by clause references.
• Legal/regulatory assertions are too strong and not properly cited; risks undermining credibility in 3GPP.
• Scenario 3 is prematurely dismissed; SA3 should independently validate LI completeness for interworking and content transformation.
• No clear recommendation: SA3 flags concerns but does not propose a concrete path forward for SA2/SA3-LI.

6) Suggestions for Improvement

A) Add precise references and tighten wording

• Cite:
• the exact clauses in TS 23.228 regarding DC Application Proxy applicability and session initiation conditions,
• the IMS Data Channel security spec(s) that define DTLS usage and versioning,
• LI baseline specs (TS 33.107/33.108) and any IMS/DC-specific LI requirements.
• Replace “LI implies interfaces should not be confidentiality protected” with a more accurate statement, e.g.:
• “Some LI deployment models may seek access to plaintext in the visited network; this conflicts with end-to-end protection assumptions.”

B) Provide an explicit options analysis for Scenario 1

Include at least 3–4 candidate approaches with pros/cons:
1. Home-network interception only (CC produced in HPLMN; VPLMN provides IRI and routing info).
2. Visited-network anchoring/termination (MF in VPLMN terminates DTLS under defined trust model).
3. Lawful key access (if considered at all—likely controversial; document why it is/ isn’t acceptable).
4. Service restriction in roaming (if LI cannot be met without weakening security, consider policy-based disablement of DC in certain roaming cases—again, controversial but should be analyzed).

C) Clarify the threat model and “undetectability” requirement

• State whether LI undetectability is a requirement for this feature in 3GPP scope or jurisdictional.
• If claiming detectability, explain what the UE can observe and why targeted changes are detectable.

D) Strengthen Scenario 2 with concrete call flows

• Provide call flows for:
• UE-initiated P2P DC in HTTP Proxy / DC App Proxy / UDP Proxy modes,
• where DTLS terminates,
• where CC can be generated.
• If SA3 believes TS 23.228 restricts DC App Proxy to network-initiated sessions, propose:
• a spec change request (CR) to extend applicability, or
• a clear statement that LI cannot be met for UE-initiated P2P under that mode.

E) Do not dismiss Scenario 3 without validation

• At minimum, add a checklist:
• identifiers available for correlation,
• whether CC content is preserved after interworking,
• whether MF/DC AS becomes an interception point requiring new LI definitions.

F) Reframe regulatory discussion

• Replace definitive legal conflict statements with:
• “may create compliance challenges with emerging cybersecurity regulations and operator security policies,”
• and cite sources carefully (or move to informative annex / liaison note with cautious language).

Bottom line

The document correctly flags that “weakening encryption to satisfy LI” is problematic, but it is not sufficiently rigorous or complete: it lacks normative references, overstates some claims (DTLS versioning, “interfaces should not be protected,” “must downgrade all UEs”), and does not provide a structured set of feasible alternatives. Strengthening the contribution requires clause-level grounding, explicit architectural options, and concrete call flows—especially for roaming and UE-initiated P2P cases.

1) Technical Accuracy

1.1 Incorrect/unclear document identifiers and scope

• Title mismatch: The contribution is labeled S4-260025 but the content is a “Summary of S3-254551”. If this is intended as an S4 document, the relationship between S4-260025 and S3-254551 should be explicit (e.g., “S4-260025 contains S3-254551 for information” or “S4-260025 summarizes S3-254551”). As written, it is confusing and risks mis-tracking in the meeting records.
• LS references appear inconsistent: You cite “SA2’s LS (S3-254015/S2-2509593)”. An LS from SA2 would normally be tracked in SA2 (S2-…) and received/registered in SA3 (S3-…). That’s plausible, but the pairing should be explained (e.g., “received in SA3 as S3-254015, originating from SA2 as S2-2509593”). Right now it reads like two unrelated numbers.

1.2 Questionable claim: “fully specified” / “completion of Rel-19 security requirements”

• The statement that “security aspects … have been fully specified in normative Annex R of TS 33.328” is too strong unless you explicitly delimit what “security aspects” means (e.g., authentication, key management, media protection, identity, authorization, privacy, interop, lawful intercept considerations, etc.).
• TS 33.328 is typically a security specification for a particular service domain; claiming that Annex R alone “completes Rel-19 security requirements” for “IMS avatar communication” may be incomplete if other specs are involved (e.g., IMS security baseline in TS 33.203, SIP/IMS security procedures, media security, identity/privacy, certificate handling, etc.). At minimum, the claim should be scoped to “the security normative work item deliverables under NG_RTC_SEC_Ph2 for IMS Avatar as captured in TS 33.328 Annex R”.

1.3 Potential inconsistency: “normative Annex R” and CR status

• You state “Final CR (CR084) … agreed at SA3#124” and “Expected approval: SA#110 plenary”.
• If the CR is “Final” and “agreed” at SA3, it still needs TSG SA approval; that part is fine. However, the document should clarify whether it is for approval at SA#110 or merely planned (and whether any remaining dependencies exist).
• Also, “Final CR” terminology can be ambiguous: in 3GPP practice, “Final” is a CR category, but it does not automatically mean the work is complete—only that the CR is in a final state for approval. The text conflates “Final CR agreed” with “work completed”.

1.4 Work item naming and traceability

• “NG_RTC_SEC_Ph2” is plausible, but the document provides no WI identifier (e.g., SP-xxxx) or a link to the SA work plan. Without that, the claim is hard to verify and weak from a process/traceability standpoint.

2) Completeness

2.1 Missing technical substance for SA2 consumption

As a reply LS summary, it may be acceptable to be short, but it is missing key information SA2 needs to act:
- What exactly is covered in Annex R (high-level bullets): threat model assumptions, security objectives, procedures, interfaces, and whether it covers both control plane and media plane aspects.
- Dependencies on SA2 architecture: Are there any assumptions about IMS avatar signaling, media transport, identity binding, or network functions that SA2 must ensure?
- Any open issues / residual risks: Even if normative work is “complete”, there may be known limitations, deferred items, or implementation notes.

2.2 Missing references and cross-spec alignment

• Only TS 33.328 Annex R is referenced. If IMS avatar communication relies on other security specs (likely), the LS should point to:
• TS 33.203 (IMS security) and any relevant clauses impacted/assumed.
• Any relevant key management / media security specs (depending on whether SRTP/DTLS-SRTP, MIKEY, or other mechanisms are used in the avatar context).
• Any privacy/identity specs if avatars involve user representation, metadata, or biometric-like data.
• If SA2 asked specific questions in S3-254015/S2-2509593, the reply should explicitly map question → answer. The current text does not demonstrate that SA3 addressed SA2’s concerns; it only states completion.

2.3 Missing CR details

• “CR084” is mentioned without:
• CR title
• affected version/release
• summary of changes
• whether it introduces new requirements on UE/IMS core
  This makes it hard for SA2 to understand impact.

3) Impact Assessment

3.1 Impact on specifications

• If Annex R introduces new normative security procedures, it may affect:
• IMS procedures (SIP signaling security, authentication, authorization)
• Media security (if avatar streams are treated as media)
• Interworking with existing IMS services and NG RTC features
• The document does not assess whether SA2 specs need updates (e.g., new parameters, new SDP attributes, new SIP headers, new policy control hooks, new identifiers).

3.2 Impact on implementations

• “Security work completed” can imply implementers should now implement Annex R. But the LS does not indicate:
• Whether the solution is backward compatible
• Whether it requires new credentials, new key derivations, new certificate validation, or new trust anchors
• Whether it impacts performance (e.g., additional handshakes, crypto overhead) or latency (important for real-time avatar use)
• Without this, SA2 and implementers cannot gauge rollout complexity.

3.3 Interoperability and deployment impact

• If the security solution introduces optional features, profiles, or negotiation, SA2 needs to know mandatory-to-implement vs optional to avoid fragmentation. The LS does not mention any profile/optionality.

4) Feasibility

4.1 Practical implementability not demonstrated

• The document provides no evidence that Annex R procedures are implementable within typical IMS/UE constraints:
• Key management feasibility (UE capabilities, SIM/USIM involvement, certificate storage)
• Compatibility with existing IMS security associations
• Handling of roaming, interconnect, and multi-operator trust
• If the avatar communication involves new media types or metadata, feasibility depends on how they are protected and negotiated; none of this is summarized.

4.2 Process feasibility: timing and approvals

• “Agreed at SA3#124” and “expected approval at SA#110” suggests the work is near completion, but the LS should state:
• Whether any parallel CRs exist in other specs
• Whether any late objections or pending alignment with SA2 remain
  Otherwise, SA2 may proceed assuming stability when changes could still occur.

5) Weaknesses

5.1 Over-reliance on a single statement of completion

• The core argument is essentially: “Annex R exists; therefore security is done.” This is weak because it does not:
• Demonstrate coverage of SA2’s concerns
• Provide a checklist of security aspects addressed
• Identify assumptions and constraints

5.2 Lack of traceability and verifiability

• No clause numbers, no CR title, no WI/SP reference, no version of TS 33.328, no link to the SA3 decision record. This makes the contribution hard to audit.

5.3 No explicit request to SA2 beyond “take into account”

• “Take the completion status into account” is vague. SA2 typically needs actionable guidance:
• “No further action needed”
• or “Please align architecture/spec X with security assumptions Y”
• or “Please reference TS 33.328 Annex R clause Z in your spec”
  The current wording risks being ignored or misinterpreted.

6) Suggestions for Improvement

6.1 Fix identifiers and improve clarity

• Explicitly state the relationship between S4-260025 and S3-254551 (attach, summarize, or forward).
• Clarify LS numbering: “Originating LS: S2-2509593; registered in SA3 as S3-254015”.

6.2 Provide a minimal technical summary of Annex R

Add 5–10 bullets summarizing what Annex R normatively specifies, for example:
- Security objectives and threat assumptions for IMS avatar communication
- Authentication/authorization model (reuse of IMS AKA? additional authorization?)
- Key establishment and media protection approach
- Integrity/confidentiality requirements for avatar-related signaling and media
- Privacy considerations (avatar metadata, user identifiers)
- Interop/negotiation and fallback behavior

6.3 Add traceability details

Include:
- TS 33.328 version and release
- CR084 title, affected clauses, and a 2–3 line change summary
- WI identifier (SP number) for NG_RTC_SEC_Ph2

6.4 Be precise about “completion”

Replace “fully specified” with scoped language, e.g.:
- “SA3 has completed the normative security specification deliverables for IMS Avatar communication under NG_RTC_SEC_Ph2, captured in TS 33.328 Annex R (CR084 agreed in SA3#124, pending SA#110 approval).”
Also state whether any non-normative guidance, test specs, or remaining study items exist.

6.5 Provide explicit actions for SA2

Depending on the intent, propose concrete actions such as:
- “SA2 to reference TS 33.328 Annex R clause R.x in the IMS Avatar stage-2 spec”
- “SA2 to ensure architecture supports [specific security assumption], e.g., binding of avatar stream to authenticated IMS identity”
- “SA2 to confirm no additional security requirements beyond Annex R are needed”

6.6 Add an impact note

Even a short paragraph would help:
- Backward compatibility expectations
- Any new network/UE capabilities required
- Any expected deployment constraints (roaming, interconnect, certificate/trust)

Bottom line

As a process/status reply, the document is directionally fine, but it is too thin and over-claims completion without scoping, traceability, or actionable guidance. Strengthening the LS with a concise technical summary, explicit mapping to SA2 questions, and clear references (CR title/clause/version/WI) would materially improve its usefulness and reduce the risk of misalignment between SA2 architecture and SA3 security specifications.

1) Technical Accuracy

1.1 Mischaracterization / ambiguity of CAPIF scope vs. IMS use case

• The document suggests CAPIF (TS 23.222) “could potentially serve as a reference” for interworking between IMS sessions and external (non-IMS) content sources. This is plausible at a high level (API exposure and security), but the contribution does not acknowledge key scope differences:
• CAPIF is primarily an API exposure framework (onboarding, discovery, authorization, logging) for API invokers and API providers. It does not define IMS session-level interworking procedures (e.g., SIP dialog correlation, media plane integration, MSRP/data channel binding, etc.).
• The GSMA question is about “interworking between the IMS session and external content sources” (e.g., “pulling information from a public API”). CAPIF can help with secure API access, but it does not inherently solve session coupling (how the API result is injected into an ongoing IMS communication, how identity/consent is mapped, how policy is enforced per session).
• As written, the reply risks being interpreted as “CAPIF covers it” or “CAPIF is the intended solution,” which would be technically misleading without explicit caveats.

1.2 “Third-party API providers in non-3GPP systems” phrasing is questionable

• The statement “CAPIF architecture and procedures for third-party API providers in non-3GPP systems…” is imprecise. CAPIF is a 3GPP framework intended to support exposure and consumption of APIs; “non-3GPP systems” is not a CAPIF-defined category in a clean way. CAPIF can expose APIs implemented by various domains, but the document should be careful not to imply CAPIF standardizes “non-3GPP systems” procedures beyond the CAPIF interfaces and roles.

1.3 Security claim lacks specificity

• The reply states CAPIF can “securely expose capabilities” and “enable secure utilization.” While CAPIF indeed addresses security aspects, the reply does not specify which security properties are relevant to the GSMA question (e.g., mutual authentication, authorization, token-based access, auditing). Without that, the “secure manner” part of the question is not substantively answered.

2) Completeness

2.1 The reply does not actually answer the “plan to define procedures and architecture” question

• The question asks whether SA2/SA6 plans to define procedures/architecture. The response says SA6 has not yet studied it and will keep GSMA informed. This is not a clear “yes/no/under what conditions” answer.
• If SA6 has no plan, it should say so explicitly. If it might be addressed under an existing WI (FS_MMTel_Ph2_APP) or a future WI, that linkage is missing.

2.2 Missing references to IMS-specific enablers and relevant specs

• If the topic is “external data channel content access” in an IMS context, the reply should at least reference the IMS service architecture and any relevant IMS enablers (even if only to say “out of scope”):
• IMS architecture baseline (e.g., TS 23.228) and service capability interaction concepts.
• Any SA6 application enablers relevant to data channels / content insertion (depending on the exact feature context of FS_MMTel_Ph2_APP).
• Without these, the reply feels disconnected from the IMS session aspect of the GSMA question.

2.3 Missing analysis of what “interworking” means in this context

The reply does not clarify whether “interworking” refers to:
- Network-side retrieval of external content and injection into an IMS session (e.g., via an application server), or
- UE-side retrieval (UE calls public API directly) with IMS only carrying the resulting content, or
- Hybrid (network provides authorization/attestation; UE fetches content).
These are materially different architectures with different standardization needs.

2.4 Missing discussion of trust domain and “public API” realities

• GSMA explicitly mentions “public API.” CAPIF typically assumes a controlled onboarding and trust relationship. The reply does not address how CAPIF would apply when the API provider is truly public/untrusted/outside PLMN control, or what additional mechanisms would be needed (e.g., federation, external IdP, consent, API gateway policies).

3) Impact Assessment

3.1 Minimal immediate spec impact (as written)

• Since SA6 states it has not studied and does not propose normative changes, the immediate impact on existing specifications is minimal.

3.2 Risk of misdirection / scope creep

• Referencing CAPIF without clarifying boundaries could steer discussions toward adopting CAPIF for IMS session interworking without a clear gap analysis. This can create:
• Misalignment between SA6 (IMS application layer) and SA2 (system architecture) responsibilities.
• Potential duplication or conflict with existing API exposure frameworks (e.g., 5GC NEF exposure patterns) if not carefully positioned.

3.3 Potential implementation impact if CAPIF is later mandated

• If future work were to mandate CAPIF-like onboarding/security for IMS-related external content access, it could impose:
• New network functions (CAPIF core functions) or integration with existing API gateways.
• New UE/client behaviors (token handling, discovery) depending on where the API invoker resides.
• None of these impacts are acknowledged, so stakeholders cannot gauge complexity.

4) Feasibility

4.1 Feasibility depends on architecture choice (not provided)

• Using CAPIF as a “reference” is feasible only if the intended solution is API exposure/consumption within a managed trust framework. If the requirement is to securely access arbitrary “public APIs” during an IMS session, CAPIF alone may be insufficient without:
• Federation/roaming trust models
• External identity and consent handling
• Policy enforcement tied to IMS session context

4.2 Practical coupling to IMS session is non-trivial

• The key feasibility challenge is binding API access to an IMS session (identity, authorization, charging, policy, and user consent). The reply does not acknowledge this, which understates complexity.

5) Weaknesses

5.1 Non-committal and lacks actionable guidance

• “Not yet studied” + “keep informed” provides little value to GSMA. It does not indicate whether SA6 considers it in-scope, who should lead (SA2 vs SA6), or what timeline/WI vehicle might exist.

5.2 No gap analysis

• The reply does not identify what is missing today in 3GPP specs for the described use case:
• Is the gap security? session correlation? API discovery? authorization? data channel semantics?
• Without a gap analysis, CAPIF is mentioned as a generic “maybe,” which weakens the technical credibility.

5.3 Conflation risk: “external content access” vs “API exposure”

• The GSMA question is about interworking between IMS session and external content sources. CAPIF is about API exposure and consumption. The reply does not articulate how API consumption translates into “content access” within an IMS data channel context.

6) Suggestions (Constructive)

6.1 Provide a clearer, direct answer on “plans”

• Explicitly state one of the following (with rationale):
• SA6 has no plan (and why; e.g., out of scope, better handled by SA2/CT).
• SA6 plans to study under FS_MMTel_Ph2_APP (or propose a new study item), with a tentative timeline.
• SA6 believes SA2 should lead architecture; SA6 can support application aspects.

6.2 Add a short gap analysis and scope statement

Include 3–5 bullets clarifying:
- What “interworking” is assumed to mean (network-side vs UE-side vs hybrid).
- What aspects are potentially standardizable (security, authorization, discovery, session binding).
- What is likely out of scope (e.g., standardizing arbitrary public API schemas/content).

6.3 Clarify CAPIF applicability and limitations

If CAPIF is mentioned, add precise positioning:
- CAPIF can be a reference for secure API onboarding/discovery/authorization.
- CAPIF does not define IMS SIP/media procedures; additional work would be required for session coupling.
- Identify what additional specs/functions would be needed (e.g., an IMS AS acting as API invoker; mapping of IMS identity to API authorization context).

6.4 Add concrete references and alignment points

• Cite relevant IMS architecture/service enablers (at least TS 23.228) and any SA6 specs relevant to the “external data channel” feature context (if applicable).
• If the intent is to leverage 5GC exposure concepts, mention alignment with NEF/API exposure principles (without over-claiming).

6.5 Propose next steps for SA coordination

• Recommend SA2/SA6 joint discussion to determine:
• Whether the architecture belongs in SA2 (system architecture) and procedures in SA6 (IMS service/application).
• Whether a new study item is needed, with a clear problem statement and success criteria.

Bottom line

The reply is technically not wrong in pointing to CAPIF as a potentially relevant security/API framework, but it is too vague, does not answer the “plan” question, and lacks the necessary scope clarification and gap analysis to be useful. Adding explicit boundaries, references, and a concrete next-step proposal would significantly improve the contribution’s value and reduce the risk of misinterpretation.

1) Technical Accuracy

Ambiguity / potential mischaracterization of “regulatory scope” (SA1 feedback)

• The statement “When IMS Data Channel is used as part of IMS telephony services, the applications (including HTML and JavaScript content) are expected to be subject to local telecom regulation” is overly broad and potentially inaccurate as written.
• In many jurisdictions, regulatory obligations attach to the provider and the service classification (e.g., ECS/ICS, PATS, OTT, etc.), not automatically to any application-layer content delivered during an IMS session.
• “HTML/JavaScript content” could be user-generated, third-party hosted, or operator-provided; regulatory treatment differs materially. The LS summary risks implying a blanket rule.
• The follow-on statement “Standalone Data Channel… could also include local telecom regulations” is similarly vague and could be read as implying telecom regulation is likely even for non-telephony use, which is not generally defensible without jurisdiction-specific analysis.

Security scope (SA3 feedback) is technically plausible but incomplete in framing

• The claim that SA3 has “no plans to standardize security architecture and measures for content/source validation and trust computation” may be accurate as a status update, but it conflicts with the practical reality that external content access introduces:
• origin authentication / integrity requirements,
• policy enforcement,
• sandboxing and privilege separation,
• and potentially lawful intercept / audit considerations depending on service classification.
• If the LS implies that these are “out of scope,” it risks leaving a security vacuum while SA4 simultaneously acknowledges specification ambiguity. That combination is technically risky.

SA4 “original design assumption” about exclusive hosting by DCSF/DC AS

• The statement that SA4 assumed DCSF/DC AS would be “exclusive hosts for all content” is questionable unless the relevant normative text in TS 26.114 explicitly constrains content sourcing that way.
• If TS 26.114 already allows URIs or references that could resolve externally (directly or indirectly), then the “assumption” is not a safe basis for dismissing external mashups.
• If TS 26.114 is silent, then the assumption is not a technical constraint—only an interpretation—so implementers may already have diverged.

SA6 CAPIF reference (TS 23.222) may be conceptually misapplied

• CAPIF is an API exposure framework (northbound API exposure, onboarding, authorization, logging, etc.). Using CAPIF as a reference for “IMS session interworking with external content sources” is not obviously aligned:
• External content retrieval (e.g., web resources referenced by HTML/JS) is not the same as API invocation under operator control.
• CAPIF does not directly solve browser-like content security issues (CORS, CSP, origin policy, script integrity, sandboxing), nor does it define how a UE renders/executes content in an IMS Data Channel context.
• The LS summary risks overstating CAPIF’s applicability unless the intent is specifically “external resources are only accessible via operator-controlled API exposure gateways,” which would be a major architectural constraint and should be stated explicitly.

2) Completeness

Missing normative references and pinpoint citations

• The document summary references TS 26.114 and TS 23.222, but does not cite:
• the exact clauses in TS 26.114 that are ambiguous (e.g., where external URIs/resources are referenced, how content is described, any security considerations),
• the exact CAPIF capabilities being mapped to the problem (onboarding, authorization, API invoker/provider roles, etc.).
• SA2’s “separate direct reply” is not included. For a consolidated LS response, omitting SA2 content creates a material gap—especially since SA2 typically owns IMS architecture and could be central to “external resource access” behavior.

Missing threat model and security requirements

• If the concern is “external data channel content access requirements,” the response should include at least a minimal threat model:
• external host impersonation, MITM, malicious script injection,
• data exfiltration from IMS context,
• privilege escalation via UE rendering engine,
• tracking/privacy leakage (3rd-party beacons),
• downgrade/redirect attacks.
• Without this, SA3’s “no plans” position is not justified, and SA4’s “study later” lacks prioritization rationale.

Missing definition of “external resource mashups”

• The term is used but not defined. It matters whether “external” means:
• outside the PLMN but still operator-trusted CDN,
• public Internet domains,
• enterprise domains,
• third-party AS reachable via IMS core,
• or resources embedded by reference (URI) vs. fetched by the DC AS and proxied.
• Different cases imply different security, policy, and charging implications.

Missing analysis of UE behavior and execution environment

• The key practical question is: who fetches external resources and who executes scripts?
• UE directly fetching external URLs vs. DC AS fetching/proxying vs. DCSF mediation.
• Whether the UE uses a webview/browser engine, and what sandboxing applies.
• The response does not address this, yet it is central to “content access requirements.”

Missing backward compatibility / deployment impact analysis

• No assessment of whether existing R18/R19 implementations already allow external references, and what clarifications would do to them.
• No discussion of whether clarifications would be normative “shall” requirements or informative guidance.

3) Impact Assessment (on specs and implementations)

Potentially significant impact if external access is constrained

• If SA4 clarifications in R20 end up requiring “all resources must be hosted by DCSF/DC AS” or “must be fetched via operator-controlled proxy,” that would:
• break existing implementations that allow direct external fetch,
• require new network functions (proxy, filtering, caching),
• introduce latency and scaling costs,
• create new compliance obligations (content moderation, logging).

Security and liability implications if left ambiguous

• If the specs remain ambiguous, vendors/operators may implement inconsistent policies:
• Some UEs may block external resources; others may allow them.
• Some may enforce TLS pinning/allowlists; others may not.
• This fragmentation can lead to:
• interoperability failures (content works on some devices only),
• increased attack surface and incident risk,
• inconsistent regulatory compliance posture.

CAPIF-based approach could imply architectural changes

• If CAPIF is used as a “reference,” it may push toward an operator-controlled exposure model:
• onboarding of third-party providers,
• token-based authorization,
• logging/auditing.
• That is a non-trivial addition for IMS Data Channel ecosystems and may not align with the original lightweight content model.

4) Feasibility (practical implementability)

“Study in R20” is feasible but timing risk is high

• Deferring to FS_DCE_MED in R20 is feasible procedurally, but it leaves:
• R18/R19 deployments without guidance,
• GSMA requirements unresolved for near-term product cycles.
• If devices already ship with permissive external access, later restrictions may be impractical to retrofit.

Implementing secure external content access is feasible but requires explicit choices

Feasible solutions exist, but the LS does not indicate which direction is preferred:
- Allowlist + TLS requirements (operator-provisioned trust anchors, domain allowlists).
- Proxy model (DC AS fetches external resources, sanitizes, rewrites URLs).
- Integrity mechanisms (e.g., subresource integrity-like hashes, signed manifests).
- Sandboxing model (no script execution, or restricted JS APIs, strict CSP).
Each has different feasibility and cost; without selecting a model, “clarifications” risk being non-actionable.

5) Weaknesses (argumentation / methodology)

• Non-actionable responses: Multiple WGs essentially say “not studied / no plans / will inform later.” As an LS response to explicit GSMA concerns, this reads as deflection rather than resolution.
• No prioritization: SA4 acknowledges gaps but does not state severity, affected scenarios, or interim guidance.
• No evidence: Claims like “original design assumption” are not backed by citations to normative text, prior agreements, or study conclusions.
• Scope fragmentation: Security (SA3), architecture (SA6/SA2), and media/application behavior (SA4) are tightly coupled here. Treating them independently risks inconsistent outcomes.
• CAPIF hand-waving: Referencing CAPIF without mapping concrete procedures (roles, onboarding, authorization flows) to the IMS Data Channel content problem weakens credibility.

6) Suggestions (constructive improvements)

A. Add precise spec references and problem statements

• Include clause-level references to TS 26.114 where:
• content is described/transported,
• any URI/resource referencing is defined,
• UE behavior is implied or left open.
• Define “external resource” and “mashup” with a taxonomy (operator domain, partner domain, public Internet; direct fetch vs. proxied).

B. Provide interim guidance (even if R20 study is planned)

• Recommend a baseline safe behavior for current deployments, e.g.:
• default deny external resources unless operator-authorized,
• require HTTPS with valid PKI and optionally operator allowlist,
• prohibit/limit active content (JS) unless integrity-protected and from trusted origins.
  Even informative guidance would reduce fragmentation.

C. Establish a minimal security requirements set (coordinate SA3/SA4/SA2)

• Propose a joint SA2/SA3/SA4 work item output (or at least a liaison back) covering:
• trust model (who vouches for external origins),
• authentication/integrity requirements,
• policy provisioning to UE,
• logging/audit hooks if needed.
• If SA3 truly will not standardize this, explicitly state which WG/spec will (or that it will be left to implementers—acknowledging the risk).

D. Clarify the execution environment and responsibilities

• Specify whether:
• UE is expected to execute HTML/JS (and under what sandbox),
• DC AS is expected to sanitize/transform content,
• DCSF has any mediation/policy role.
  This is essential for implementable requirements.

E. Be careful with CAPIF positioning

• If CAPIF is only a conceptual reference, say so and avoid implying it solves content security.
• If the intent is “external resources must be accessed via operator-controlled API exposure,” then:
• state that explicitly,
• outline the mapping (API provider onboarding, authorization, resource access),
• and assess impact on existing IMS Data Channel architecture.

F. Include SA2 content or summarize it

• Since SA2 is central to IMS architecture, the consolidated LS should either:
• include SA2’s response, or
• summarize its key conclusions and provide a reference to the separate reply.

G. Add an impact/backward compatibility section

• Identify whether clarifications will be:
• purely informative (no behavior change),
• normative restrictions (potentially breaking),
• or optional features with negotiation/capability exchange.
• Consider adding capability negotiation so UEs/AS can interoperate when external access is supported/blocked.

If you can share the actual LS text (not only the summary), I can pinpoint exact wording issues and propose concrete replacement text aligned with 3GPP LS conventions and the relevant TS clauses.

1. [Technical] The LS asks groups to “apply the standardized AI/ML terminology defined in the updated TR 21.905,” but TR 21.905 is a definitions/abbreviations repository and not a normative “vocabulary specification”; the LS should clarify that the intent is consistent use of defined terms/abbreviations rather than imposing normative requirements.

2. [Technical] The document provides no summary of what terminology was actually added/changed by “CR 0128 on TR 21.905” (e.g., specific new definitions, deprecated terms, scope notes), making it hard for recipient groups to assess impact or identify where their specs may now be inconsistent.

3. [Technical] Claiming “No further work is planned” is potentially premature for a cross-cutting terminology alignment topic; at minimum, the LS should indicate whether any follow-on normative work (e.g., TS-level alignment, guidance for model lifecycle, data governance, or performance metrics) was explicitly deemed out of scope or deferred.

4. [Technical] The LS does not identify which existing 3GPP AI/ML-related terms are expected to be replaced (e.g., “AI,” “ML,” “model,” “training,” “inference,” “dataset,” “feature,” “drift”), nor does it provide a mapping/transition note, risking inconsistent adoption and parallel terminology across groups.

5. [Technical] There is no guidance on how to handle conflicts with already-established terminology in RAN/CT/SA specifications (e.g., if a term is already defined differently in a TS/TR); the LS should state precedence rules or at least recommend reconciliation via CRs.

6. [Technical] The deliverable list references “TR 22.850 v1.0.0” but does not state whether it is purely informative or contains recommendations that should be carried into normative specs; recipients may miss required follow-up if recommendations exist.

7. [Technical] The LS does not specify the version/date of TR 21.905 that includes the approved CR 0128, which is necessary for groups to reference the correct baseline and avoid applying terminology inconsistently across releases/versions.

8. [Editorial] The document number “S4-260028” conflicts with the stated “Document Number: SP-251699”; clarify whether this is an S4 LS draft, an SP document, or a re-numbered item to avoid traceability issues in meeting records.

9. [Editorial] The meeting/date information is inconsistent: it says “TSG-SA Meeting #110 (Baltimore, US, December 2025)” while the attachments are labeled “SP-251xxx,” which suggests a different numbering/timeframe; ensure the identifiers align with SA#110 outputs.

10. [Editorial] The “Attachments” list references SP-251698 and SP-251666 but the LS itself is SP-251699; include explicit titles and versions for the attachments (and confirm they are the final approved versions) to improve clarity for recipients.

11. [Editorial] The phrase “updated TR 21.905” is ambiguous; use “TR 21.905 (with CR 0128 approved at SA#110)” or provide the resulting version number to remove ambiguity.

12. [Editorial] “Apply the standardized AI/ML terminology … in their respective work” is vague; consider rewording to “use the terms/definitions/abbreviations as defined in TR 21.905 and avoid introducing conflicting definitions” to make the requested action unambiguous.

1) Technical Accuracy

1.1 Mischaracterization of 3GPP specs and numbering

• TR 21.905 is not a TR: 3GPP 21.905 is a TS (Technical Specification) (“Vocabulary for 3GPP Specifications”), not a TR. The document repeatedly says “TR 21.905” and “CR … on TR 21.905”. This is technically incorrect and should be corrected everywhere (including the “Technical Contributions” and “Terminology Standardization” sections).
• CR numbering/context is underspecified: “CR 0128 on TR 21.905” is ambiguous without:
• the target release (Rel-19/Rel-18/etc.),
• the baseline version of TS 21.905,
• the CR title/scope (what terms were added/modified),
• the approval status (approved at SA#110 is claimed, but no meeting decision reference is provided).
• TR 22.850 v1.0.0: The claim “approved at SA#110” may be plausible, but the LS summary provides no technical content to validate that it indeed “documents the study findings” and what those findings are. As written, it reads as an administrative statement rather than a technical completion notice.

1.2 Questionable claim: “Consistency alignment” achieved via vocabulary only

• The LS implies that “AI/ML consistency alignment” is essentially solved by “terminology standardization” in TS 21.905. That is a questionable reduction of “consistency alignment” to vocabulary alignment only.
• In practice, cross-WG consistency issues for AI/ML in 3GPP typically include architecture alignment (SA2), management (SA5), data handling, model lifecycle, signaling impacts (CT/RAN), and normative requirements—not just definitions.
• If the study truly only produced terminology, the scope/title “Consistency Alignment” is potentially misleading; if it produced more, the LS fails to reflect it.

1.3 Potential inconsistency with existing AI/ML terminology work

• 3GPP already has AI/ML-related terminology and concepts scattered across multiple specs/TRs (e.g., NWDAF-related analytics, management aspects, RAN intelligence discussions). The LS does not state whether the new vocabulary:
• reuses existing terms,
• deprecates conflicting terms,
• or introduces new canonical definitions that override prior usage.
• Without an explicit mapping, there is a risk the CR introduces definitions that conflict with established terms used in existing normative specs.

2) Completeness

2.1 Missing summary of what was standardized

The LS does not list:
- the actual terms added/changed in TS 21.905,
- the definitions,
- any scope notes (e.g., “AI model”, “ML model”, “training”, “inference”, “feature”, “dataset”, “federated learning”, “online learning”, “model drift”, etc.),
- or any non-goals (e.g., not standardizing algorithms).

For recipient WGs, “apply standardized terminology” is not actionable without at least a high-level list of the key terms and what changed.

2.2 Missing cross-spec impact analysis

A completion LS should ideally include:
- a list of impacted specifications (where terminology conflicts were found),
- whether any follow-up CRs are needed in those specs to align wording,
- guidance on transition (e.g., “replace term X with Y in future CRs; do not retroactively update legacy specs unless touched”).

None of that is present.

2.3 Missing references and traceability

• The LS references attachments (SP-251698, SP-251666) but provides no:
• linkable identifiers beyond SP numbers,
• change log summary,
• or decision references (e.g., “approved in SA#110, agenda item …, decision …”).
• For a broad audience (RAN/CT/SA WGs), the LS should include at least a one-paragraph executive technical summary of TR 22.850 conclusions.

3) Impact Assessment

3.1 Potential normative ripple effects

Even “just terminology” in TS 21.905 can have broad consequences:
- If definitions are normative (TS 21.905 is normative vocabulary), they can affect interpretation of requirements in other TS/TRs.
- If a term is redefined, it may create unintended reinterpretation of existing requirements where that term is used informally.

The LS does not assess:
- whether any existing specs become ambiguous under the new definitions,
- whether any existing usage becomes non-compliant with the vocabulary.

3.2 Implementation impact is likely low—but editorial burden may be high

• Implementations: likely minimal direct impact (terminology changes rarely change protocol behavior).
• Specifications and processes: potentially significant editorial workload across WGs to align language, especially if the new terms are intended to replace entrenched ones.

The LS should acknowledge this and propose a pragmatic approach (e.g., apply on touch, not mass retrofit).

3.3 Risk of fragmentation if not enforced consistently

Requesting all WGs to “apply” terminology without:
- a compliance mechanism,
- a checklist,
- or a mapping table,
may lead to partial adoption, increasing inconsistency rather than reducing it.

4) Feasibility

4.1 Feasible to update vocabulary; less feasible to ensure cross-WG adoption

• Updating TS 21.905 is straightforward and implementable.
• Ensuring consistent adoption across RAN/CT/SA is non-trivial without:
• explicit guidance,
• examples,
• and identification of “must-use” terms.

4.2 Closure statement may be premature

The LS says “No further work is planned” and the study is complete. That is feasible administratively, but technically it may be premature if:
- terminology changes require follow-up CRs in other specs,
- or if the study identified inconsistencies that were not resolved beyond vocabulary.

A study completion often triggers a WI (normative work) if alignment requires more than definitions.

5) Weaknesses

5.1 Overly administrative; lacks technical substance

The LS reads like a status note. For a topic titled “AI/ML Consistency Alignment,” it lacks:
- problem statement recap,
- key findings,
- what inconsistencies were found,
- what was decided (and why).

5.2 No evidence that terminology resolves the identified issues

There is no argumentation showing:
- what inconsistencies existed,
- how the new definitions fix them,
- and how WGs should apply them in practice.

5.3 Ambiguity about scope and intended usage

• Is the terminology intended for RAN AI/ML, core network analytics, management, OAM, data collection, model lifecycle, or all of these?
• Are the terms intended to be used in requirements, architecture, protocol, or only in informative text?

Without scope boundaries, recipients may interpret and apply inconsistently.

6) Suggestions for Improvement

6.1 Correct specification references and improve precision

• Replace all instances of “TR 21.905” with “TS 21.905”.
• Provide complete identifiers:
• TS/TR number, release, version, and CR number/title.
• Example: “CR 0128 (Rel-19) to TS 21.905 vXX.Y.Z: ‘Add AI/ML terminology for consistency alignment’”.

6.2 Add a concise technical summary of the deliverables

Include in the LS body (not only attachments):
- 5–10 bullet points of key terminology additions/changes (term + one-line definition or intent).
- A short summary of TR 22.850 conclusions:
- what inconsistencies were found,
- what principles were agreed (e.g., “AI vs ML usage”, “model lifecycle terms”, “training vs inference”, etc.).

6.3 Provide an adoption guide for WGs

Add an “Implementation guidance” section:
- “When drafting new specs/CRs, use terms X/Y/Z as defined in TS 21.905.”
- Provide a mapping table: “legacy term → preferred term”.
- Clarify whether existing specs should be updated:
- “Apply on touch” (recommended) vs “mass alignment CRs”.

6.4 Include impact/compatibility notes

• State explicitly whether any definitions:
• supersede prior informal definitions in other specs,
• or are designed to be compatible with existing usage.
• Identify any high-risk terms where redefinition could change interpretation, and propose mitigation (e.g., add scope notes in TS 21.905).

6.5 Consider whether a follow-on normative WI is needed

If TR 22.850 identified inconsistencies beyond vocabulary (likely), propose:
- a small normative WI or a coordinated set of CRs to align key specs (SA2/SA5/CT/RAN as applicable),
- or at least a plan for cross-WG editorial alignment.

6.6 Improve traceability

• Add meeting decision references (agenda item / decision number) for approvals.
• Ensure attachments are clearly described (title, version, release).

Bottom line

As an LS, the document is directionally fine (informing completion and requesting adoption), but it contains a clear technical error (TS vs TR 21.905) and is insufficiently detailed to enable consistent cross-WG adoption. Without a term list, mapping guidance, and impact notes, the request to “apply standardized terminology” is not practically actionable and risks inconsistent uptake.

1. [Technical] The LS asserts that “neither approach is currently achievable” for IMS Data Channel LI, but it provides no concrete analysis of where the current keying/encryption (e.g., DTLS-SRTP, E2E vs hop-by-hop, key ownership/termination points) prevents delivery of CC or decryption parameters, making the conclusion unverifiable and hard for SA2/SA4 to act on.

2. [Technical] The “required (if preferred not feasible)” framing (access to encryption parameters) is potentially incompatible with LI security principles unless tightly scoped (who provides keys, under what authorization, how protected, auditability); the LS should reference the exact TS 33.126 clauses and clarify whether it expects IRI/CC delivery of session keys, key escrow, or network-terminated encryption.

3. [Technical] Roaming cases “S8HR/N9HR model” are cited, but those are EPC/5GC roaming models and not directly an IMS/IMS Data Channel architectural term; the LS needs to map the roaming scenario to IMS entities (P-CSCF/S-CSCF/IBCF/TrGW) and identify which operator is expected to perform LI and where encryption terminates.

4. [Technical] The interoperability gap scenario (one CSP supports IMS Data Channel, the other does not, target on the non-Data-Channel CSP) is underspecified: it’s unclear whether the session is negotiated as MSRP/SIP MESSAGE fallback, rejected, or transcoded/translated at an interconnect function, and without that call flow it’s not possible to conclude LI is impossible.

5. [Technical] “Direct communications between two users” is ambiguous in IMS context (still network-routed SIP with media/data path via IP, or true P2P/E2E); LI feasibility depends critically on whether the data channel is end-to-end encrypted at the application layer versus protected only on access legs.

6. [Technical] Mid-session interception is mentioned, but the LS does not specify which mid-session events break LI (e.g., re-keying, ICE restart, DTLS renegotiation, path change, handover, inter-PSAP transfer), nor what LI function fails (CC duplication, correlation, key update delivery).

7. [Technical] The LS references TS 26.114 Figure 6.2.10.1-1 for “Data Channel Workflow,” but does not identify which nodes in that figure would need LI mediation/duplication or key access; without pinpointing the interception points, SA4/SA2 cannot derive normative architectural changes.

8. [Technical] The request “Develop a solution and architecture for secured IMS Data Channel that enables CSPs to meet LI requirements” is too open-ended; it should propose candidate solution directions (e.g., network-terminated DTLS at SBC/TrGW, LI-friendly key management hooks, standardized key export to MDF under warrant) to avoid divergent interpretations across groups.

9. [Technical] The LS does not address whether the LI requirement applies to both CC and IRI for IMS Data Channel, and how correlation identifiers (SIP dialog identifiers, data channel identifiers, 5-tuple changes) would be maintained—this is often the practical blocker in multi-leg/interconnect scenarios.

10. [Editorial] The document cites TS 33.126 requirements by IDs (R6.4-160/170/180/190) but does not quote or summarize them; readers outside SA3-LI may not know what each requirement mandates, weakening the clarity and actionability of the LS.

11. [Editorial] Terminology is inconsistent/unclear: “CSP” is used without definition (operator, service provider, or IMS network provider), and “IMS without IMS Data Channel feature” should be aligned to the exact feature name and spec references in SA4/CT (e.g., IMS Data Channel per TS 26.114/related stage 2/3).

12. [Editorial] The LS claims “major complications for CSPs to respect their national regulations” but does not separate regulatory obligation from 3GPP requirement compliance; it would be better to state the specific 3GPP compliance risk (non-fulfilment of TS 33.126 LI requirements) and the impacted deployment scenarios.

1) Technical Accuracy

1.1 “Current encryption architecture prevents meeting TS 33.126 R6.4-160/170/180/190”

• Questionable claim without evidence. The LS asserts non-compliance with specific TS 33.126 requirements but does not:
• quote the exact requirement text,
• map each requirement to IMS Data Channel procedures in TS 26.114 / related specs,
• identify which LI interface deliverables (IRI/CC) fail and at which interception point(s).
• Risk of mis-scoping: TS 33.126 is an architecture and requirements spec for LI; compliance depends on the overall system (network functions, mediation, handover), not only “IMS Data Channel encryption architecture”. The LS reads as if encryption design alone determines compliance, which is not technically rigorous.

1.2 “Two acceptable approaches for LI: plaintext copy preferred; otherwise provide encryption parameters”

• Potentially misleading framing.
• In 3GPP LI, the expectation is typically that the operator can provide CC in a form usable by LEA, but the exact mechanism (plaintext vs keys vs operator-side decryption) is constrained by national law and 3GPP security principles.
• Stating “preferred plaintext copy without confidentiality protection” is normatively loaded and may conflict with end-to-end security expectations and privacy/security requirements in other 3GPP specs. If the IMS Data Channel is designed to be E2E-protected, “plaintext copy” at the operator may be impossible by design.
• “Access to encryption parameters that enable decryption” is also underspecified: does it mean session keys, key derivation material, or something else? If keys are endpoint-derived (e.g., E2EE), the network may not possess them.

1.3 Roaming references: “S8HR/N9HR model”

• Terminology mismatch / unclear applicability.
• S8HR/N9HR are EPC/5GC roaming models primarily discussed in the context of user plane anchoring and home routing. IMS roaming for VoLTE/VoNR has its own models (e.g., LBO vs home-routed IMS, visited/home IMS interconnect).
• The LS does not explain how S8HR/N9HR specifically impacts IMS Data Channel keying, media anchoring, or LI interception points. As written, it appears to conflate roaming models across domains without a clear technical chain.

1.4 “Interoperability case: one CSP uses IMS Data Channel, other does not; target on CSP without Data Channel; cannot intercept content”

• Not demonstrated and may be incorrect depending on architecture.
• If the far-end CSP does not support IMS Data Channel, the session may:
  • fall back to MSRP/SIP MESSAGE/other IMS media, or
  • fail to establish the data channel.
• If it falls back, LI may be possible via existing IMS LI mechanisms. If it fails, there is no content to intercept.
• If interworking exists via gateways, interception feasibility depends on where media terminates/anchors. The LS provides no call flow or interworking assumptions.

1.5 “Direct communications between two users (when at least one is an LI target)”

• Ambiguous. “Direct communications” could mean:
• IMS peer-to-peer media (still via network), or
• device-to-device / sidelink / local breakout, or
• E2EE application-layer channel over IMS signaling.

Each has different LI implications. The LS does not define the scenario.

2) Completeness

2.1 Missing normative references and scope definition

• The LS references TS 26.114 Figure 6.2.10.1-1 only. That is insufficient to support LI compliance claims.
• Missing references likely needed:
• TS 33.126 (exact clauses for R6.4-160/170/180/190)
• IMS security/key management specs relevant to IMS Data Channel (if any exist in SA3/SA4 scope)
• IMS media transport specs (e.g., SRTP/DTLS-SRTP/MSRP/TLS, depending on what “Data Channel” uses)
• LI handover/interface specs (e.g., TS 33.108/33.128 family, depending on the LI architecture used)
• Any SA4 specs defining IMS Data Channel security procedures (if in TS 26.114 or related).

2.2 No problem decomposition by interception type

• LI requirements typically distinguish:
• IRI (signaling-related information),
• CC (content),
• interception points and mediation.
• The LS does not state whether the gap is:
• inability to obtain CC at all,
• inability to associate CC with IRI,
• inability to perform mid-session activation,
• inability to deliver CC in required format,
• inability to intercept in roaming/interconnect due to anchoring.

2.3 No call flows / keying flows / trust model

• For an encryption-related LI gap, the LS should include at least one of:
• call flow showing where encryption is applied/terminated,
• key establishment flow (who has keys),
• whether encryption is hop-by-hop (operator-terminating) or end-to-end (UE-to-UE),
• where LI interception function would sit.

2.4 “Mid-session interception” not analyzed

• The LS mentions mid-session interception but provides no analysis of:
• whether keys rotate,
• whether re-keying is possible,
• whether LI activation triggers any re-negotiation,
• whether buffering/duplication is feasible.

2.5 No explicit requirements to SA2/SA4

• “Develop a solution and architecture” is too broad.
• Missing: concrete asks such as:
• define an interception point for IMS Data Channel media,
• define a key escrow / network-terminated security option,
• define interworking behavior when one side lacks feature support,
• define roaming anchoring requirements for LI.

3) Impact Assessment

3.1 Potential cross-spec impact is high but not acknowledged

If SA2/SA4 were to “enable LI” for an encrypted data channel, possible impacts include:
- Architecture changes (SA2): anchoring, media path requirements, interconnect assumptions, roaming models.
- Codec/media framework changes (SA4): security profiles, key management, transport selection, fallback behavior.
- Security architecture changes (SA3): if network access to plaintext or keys is introduced, it may:
- weaken confidentiality guarantees,
- create new attack surfaces,
- require new trust assumptions and compliance controls.

The LS does not discuss these trade-offs.

3.2 Backward compatibility and deployment impact not addressed

• If new LI-enabling mechanisms require:
• new SIP/SDP attributes,
• new key management procedures,
• new network functions (media relays/anchors),
• new UE behavior,
  then existing deployments may break or require upgrades. The LS does not assess this.

3.3 Inter-operator implications

• Interoperability across CSPs implies interconnect agreements and possibly standardized interconnect security profiles.
• If LI requires media anchoring in a particular domain, that can conflict with interconnect models and commercial arrangements. Not discussed.

4) Feasibility

4.1 Feasibility depends entirely on whether encryption is E2EE or hop-by-hop

• If IMS Data Channel is end-to-end encrypted with keys only at UEs, then:
• “provide plaintext copy” is infeasible without redesigning security goals.
• “provide encryption parameters” is infeasible unless keys are escrowed or derivable by the network—both are major security/policy changes.
• If it is hop-by-hop (e.g., UE–P-CSCF/AS/media relay), then LI may be feasible by intercepting at the termination point, but the LS does not clarify.

4.2 Mid-session LI feasibility requires explicit re-key / duplication strategy

• Practical LI activation mid-session typically requires:
• ability to start duplicating media at an anchor,
• or ability to obtain keys for the current session epoch,
• or forcing re-negotiation.
  None is described.

4.3 Roaming feasibility requires clear anchoring model

• In roaming, LI responsibilities can be home/visited dependent. Without specifying whether IMS Data Channel media is home-routed, visited-routed, or direct, feasibility cannot be assessed.

5) Weaknesses

5.1 Assertions without substantiation

• The LS makes strong compliance claims (“critical gaps”, “neither approach achievable”) without:
• evidence,
• flows,
• spec citations beyond a figure reference.

5.2 Conflation of regulatory requirement with technical mechanism

• The LS implicitly assumes LI must be satisfied by plaintext or key access. 3GPP typically specifies capabilities and interfaces; national regulation determines what is required. The LS should be careful not to mandate a particular “preferred” approach without grounding in 3GPP normative text.

5.3 Unclear scope and terminology

• “IMS Data Channel” is not defined in the LS (transport, security, termination points).
• “Direct communications” and the roaming models are ambiguous.

5.4 No threat/security impact discussion

• Any LI-enabling change to encryption/key handling has significant security implications. The LS does not acknowledge or propose mitigations (audit, access control, key protection, lawful authorization handling, etc.).

6) Suggestions for Improvement

6.1 Add a structured gap analysis table

For each cited TS 33.126 requirement (R6.4-160/170/180/190):
- quote the requirement text (or summarize precisely with clause reference),
- state the IMS Data Channel feature behavior (with TS 26.114 clause references),
- identify the failing point (e.g., no interception point, no key access, no association to IRI),
- specify whether the gap is for IRI, CC, or both,
- indicate whether the gap is specific to roaming/interconnect/mid-session.

6.2 Provide at least two concrete call flows

Include message/media/keying flows for:
1) Roaming (clearly specify: IMS home-routed vs LBO; and how data channel media is routed)
2) Inter-CSP interconnect (both sides support vs one side does not)
Mark:
- where encryption is applied/terminated,
- where an operator could realistically duplicate content,
- where LI mediation would obtain CC/IRI.

6.3 Clarify the security model of IMS Data Channel

Explicitly state:
- transport protocol (e.g., RTP/RTCP, SCTP/DTLS, MSRP, QUIC, etc.),
- security protocol (DTLS-SRTP, TLS, etc.),
- key establishment (SDP offer/answer, certificates, identity binding),
- whether keys are UE-only or network-terminated.

Without this, SA2/SA4 cannot act.

6.4 Narrow and make the “Action Requested” implementable

Instead of “develop a solution”, propose specific study items/questions, e.g.:
- Define an operator-controlled media anchoring option for IMS Data Channel to enable LI (with clear interoperability rules).
- Define fallback/interworking behavior when the peer network does not support IMS Data Channel (and LI expectations in fallback).
- Define mid-session LI activation handling (e.g., re-key triggers, duplication start, buffering).
- Define roaming/interconnect responsibilities (home vs visited interception, where CC is obtained).

6.5 Address security/privacy trade-offs explicitly

Add a section assessing:
- impact on confidentiality and threat model,
- key protection requirements if any key material is exposed to network functions,
- audit and authorization controls aligned with LI principles.

6.6 Identify impacted specs and propose ownership

List candidate specs likely impacted and which group should lead:
- SA2: architecture/roaming/interconnect anchoring
- SA4: media transport/security profiles and interworking
- SA3: security requirements and LI alignment (and ensure no contradiction with security objectives)

6.7 Validate the roaming terminology

If S8HR/N9HR is truly relevant, explain the mapping to IMS Data Channel routing and LI points. Otherwise, replace with correct IMS roaming models and references.

Bottom line

The LS raises a plausible concern (LI vs encrypted IMS Data Channel), but in its current form it is too assertion-based and underspecified to drive actionable work in SA2/SA4. Strengthening it with precise requirement mapping, concrete flows, and a clear security/termination model is necessary before meaningful specification impact or feasibility can be evaluated.

1. [Technical] The conclusion that SA4 studies “support the 20–100 Mbit range” is over-generalized: TR 26.956 Clause 9 results were at 25–30 fps, so using them to justify the same range for 90–120 fps immersive traffic (as RAN1 is modeling) is not technically substantiated without scaling assumptions or additional data.

2. [Technical] The statement that uplink “expected to require higher bit-rates within the range due to encoder constraints” is internally inconsistent: weaker encoders typically reduce achievable quality at a given bitrate (or require more bitrate for same quality), but uplink is also power/complexity constrained and often uses more aggressive compression—this needs a clearer, evidence-based direction (higher vs lower bitrate) and conditions.

3. [Technical] The document does not map the cited codec-study “rate points” (20–100 Mbit) to a traffic model definition needed by RAN1 (e.g., average vs peak, packetization, burstiness, frame/GoP structure, latency constraints), so it is not directly actionable for PHY/MAC evaluation.

4. [Technical] The “no values above 100 Mbit reported” argument from TR 26.955 is not a valid upper bound for future immersive/6G traffic; it reflects tested points and selected sequences, not a limit—this risks incorrectly constraining RAN1 modeling.

5. [Technical] The GeForce Now “~50 Mbit+” reference is a downlink cloud-gaming service and not representative of immersive uplink capture/telepresence; using it as supporting evidence for uplink or “transparent quality” immersive communications is misleading.

6. [Technical] The uplink discussion assumes “temporary frame rate drops and/or quality switches” yet still claims “comparable bit-rates”; adaptive drops typically reduce instantaneous/average bitrate—if the intent is that peak bitrate remains high, the text should explicitly distinguish peak vs average and adaptation behavior.

7. [Technical] The contribution mentions “4K + HDR at 120 fps” but does not specify whether this is mono/stereo, FoV, chroma format, bit depth, or codec configuration; without these, the bitrate numbers are not comparable across studies or usable for a traffic model.

8. [Technical] The note that Gaussian splat imaging “could result in (much) larger bit-rates” is too vague for RAN1; at minimum it should indicate expected order-of-magnitude ranges, whether uplink/downlink, and whether the traffic is video-like (CBR/VBR) or geometry/texture-stream-like.

9. [Technical] The document does not clarify whether the 20–100 Mbit range refers to single-stream user traffic or aggregate (e.g., multiple cameras/views/sensors), which is critical for immersive communication where multi-sensor uplink is common.

10. [Editorial] Several claims cite TR clauses/tables (e.g., “Table 6.6.3.7-1”) without enough context to verify relevance (what codec, what content, what operating points); adding the exact metric (e.g., “target bitrate points for highest quality anchors”) would improve traceability.

11. [Editorial] Terminology is inconsistent/vague (“transparent quality”, “highest quality sequences”, “higher range of 20–100 Mbit”); these should be aligned to 3GPP wording (e.g., “visually lossless/transparent” with defined test methodology) or clearly qualified as informal.

12. [Editorial] The document mixes “RAN1” and “RAN WG1” and “SA WG4 to be” in a way that is confusing for an LS; tighten the addressee/source naming and ensure the organizational references match current 3GPP structure for Rel-20 FS_6G_MED.

1. [Technical] The statement “all currently defined LI requirements in TS 33.126 remain applicable for 6G” is too strong without scoping, because TS 33.126 is written against specific 3GPP system assumptions (e.g., LI architecture, identifiers, service types) that may not map 1:1 to 6G features; at minimum it should qualify applicability “where relevant” and identify expected gaps.

2. [Technical] The proposed normative “shall” text in TR 23.801-01 is problematic because TRs are typically informative/study documents; adding normative requirements in a TR risks process inconsistency and unclear compliance expectations (the text should be informative guidance or moved to a TS/requirements spec).

3. [Technical] The proposed clause 4.2 insertion is vague (“all WTs and corresponding key issues”) and does not define what “taken into account” means (e.g., mandatory LI impact assessment, LI assumptions, or explicit LI-related outputs), so it is unlikely to drive actionable architecture work.

4. [Technical] Referencing only TS 33.126 may be incomplete for 6G architecture studies, since LI requirements and related security/privacy constraints often span multiple specs (e.g., LI architecture, security architecture, identifiers); the LS should at least confirm whether additional normative references are expected or explicitly state TS 33.126 is the sole LI requirements anchor.

5. [Technical] The LS asks groups to “inform SA3-LI of any issues … that may prevent compliance with TS 33.126” but provides no criteria or mechanism (e.g., trigger conditions, template, timeline aligned to architecture milestones), which risks late discovery—the opposite of the stated goal.

6. [Technical] The request to add the same text to “other 6G TRs/TSs under development” is over-broad and may be inappropriate for TSs where LI is out of scope (e.g., radio/codec specs); it should identify specific target documents or at least limit to architecture/service requirements specs.

7. [Technical] The LS does not identify any concrete 6G architectural topics likely to impact LI (e.g., new identifiers, distributed core functions, AI-native functions, new access types, slicing evolution), so recipient groups lack guidance on what to look for when “identifying potential topics.”

8. [Editorial] The document mixes “6G systems” and “6G architecture development” without defining the scope (e.g., whether it refers to a specific 3GPP 6G study item/TR set), which makes the requested actions ambiguous across groups.

9. [Editorial] The proposed text says “For more details on LI requirements, see TS 33.126” but does not specify version/release alignment; for early 6G studies, a stable reference (release-independent wording or explicit versioning) would avoid ambiguity as TS 33.126 evolves.

10. [Editorial] The action list repeats “request clarification from SA3-LI” but does not provide a contact point, expected response handling, or whether clarifications should be captured as LS replies vs. change requests, reducing procedural clarity.

1) Technical Accuracy

1.1 Claim: “All currently defined LI requirements in TS 33.126 remain applicable for 6G”

• Questionable as stated / over-broad. TS 33.126 is written for the 3GPP system context of existing generations (notably EPS/5GS concepts, LI architecture assumptions, and interfaces). Declaring all requirements “remain applicable” to “6G” is not technically substantiated in the LS summary.
• Potential mismatch with future architecture: If 6G introduces new service-based paradigms, new trust models, new identifiers, new mobility anchoring, new slicing constructs, new exposure models, or new end-to-end security models, some TS 33.126 requirements may need:
• reinterpretation (mapping to new functions),
• scoping (which parts apply),
• or explicit exceptions/updates.
• Missing nuance: At minimum, the statement should be qualified as “remain applicable in principle” or “remain applicable subject to architectural mapping and gap analysis”.

1.2 Proposed normative text in TR 23.801-01 clause 4.2

• Normative “shall” in a TR is problematic. TRs are typically informative (study items). Introducing “shall” language in a TR is at least stylistically inconsistent and can be challenged procedurally. If the intent is to create a binding requirement, it should be:
• placed in a TS (normative specification), or
• rephrased in TR as “should be taken into account” / “is to be considered”.
• Reference correctness: “For more details on LI requirements, see TS 33.126.” is fine as a reference pointer, but it implicitly assumes TS 33.126 is the correct anchor for “6G LI requirements”. That may be premature if Rel-20/6G will require a new or revised LI requirements spec (e.g., a new TS/TR or a new versioned scope).

1.3 Scope ambiguity: “6G systems”

• 3GPP has not historically used “6G” as a formal system name in normative specs. If “6G” is being used as shorthand for “Rel-20 and beyond system”, the LS should align terminology with the official project naming used in SA2/SA3 (e.g., “next generation system”, “Rel-20 system”, etc.). Otherwise, the statement is technically ambiguous.

2) Completeness

2.1 Missing gap analysis / mapping

The LS asserts applicability but does not provide:
- a mapping of TS 33.126 requirements to candidate 6G architectural elements (new NFs, new interfaces, new identifiers),
- a list of known deltas where 6G directions may break assumptions (e.g., decentralization, new privacy features, new encryption defaults, new routing/anchoring changes),
- any risk register of LI-sensitive architectural choices.

Without this, the request is largely procedural (“please consider LI”) rather than technically actionable.

2.2 Missing references beyond TS 33.126

LI in 3GPP is not only TS 33.126. Depending on the topic, other relevant specs often include:
- TS 33.127 (handover interface aspects),
- TS 33.128 (retained data / related LI aspects, depending on scope),
- TS 33.108 (general security architecture; impacts LI feasibility),
- TS 23.501/23.502 (5GS architecture; for mapping precedent),
- ETSI LI handover standards (where applicable) for HI alignment.
If the intent is “requirements continuity”, the LS should at least acknowledge the broader LI spec set or explicitly justify why TS 33.126 alone is sufficient.

2.3 Missing discussion of jurisdictional/legal variability

The LS mentions “different jurisdictions and legal frameworks” but provides no concrete mechanism for handling:
- conflicting national requirements,
- privacy-by-design constraints,
- end-to-end encryption and lawful access boundaries,
- roaming and cross-border interception constraints.
A study-phase note is fine, but the LS could be strengthened by identifying which requirement categories are most sensitive.

3) Impact Assessment

3.1 On SA2 architecture work (TR 23.801-01 and other 6G studies)

• Low direct spec impact if kept as informative guidance, but high process impact: it forces SA2 to treat LI as a first-class constraint early.
• If implemented as normative “shall” text, it may create:
• procedural disputes (normative language in TR),
• unclear compliance criteria (“taken into account” is not testable),
• potential blocking comments in SA2 if LI requirements are perceived to constrain architectural innovation.

3.2 On SA4/SA6 (media, codecs, application enablers)

• The LS is broad and may cause scope creep: SA4/SA6 may not know what “take into account” means for media pipelines, E2EE media, conferencing, XR, etc.
• Potentially significant impact if 6G introduces more pervasive application-layer encryption or new media transport models; LI feasibility may become contentious.

3.3 On existing implementations

• If interpreted strictly (“all TS 33.126 requirements remain applicable”), vendors may be forced into backward-compatibility constraints that are not yet defined for 6G, potentially increasing complexity and cost.
• Risk of late-stage rework if LI is not properly mapped early—this is a valid concern, but the LS does not quantify or prioritize.

4) Feasibility

4.1 Feasibility of the requested action (adding text)

• Adding a reference sentence is feasible, but:
• normative phrasing in a TR is likely to be challenged,
• “for all WTs and corresponding key issues” is vague—SA2 may not be able to demonstrate compliance.

4.2 Feasibility of “TS 33.126 applies to 6G”

• Feasible only if SA3-LI commits to:
• producing a Rel-20 LI gap analysis against the emerging 6G architecture,
• updating TS 33.126 (or creating a new spec) with explicit mappings and any new requirements.
  Without that, feasibility is uncertain because “applicability” cannot be validated.

5) Weaknesses

5.1 Overly generic and non-testable requirement

• “shall be taken into account” is not measurable and can devolve into a checkbox statement with no engineering value.

5.2 No concrete technical issues identified

• The LS asks other groups to identify topics needing SA3-LI input, but SA3-LI does not provide an initial list of known LI-sensitive areas. This weakens the coordination request because it shifts all burden to recipients.

5.3 Potential procedural/specification-style issue

• Proposing normative text for a TR is a common point of contention. This weakens the likelihood of smooth acceptance in SA2/SA4/SA6.

5.4 Single-spec anchoring

• Anchoring solely on TS 33.126 risks missing other LI-related requirements/specs and creates an impression that LI is “solved” by a single document, which is rarely true in practice.

6) Suggestions for Improvement

6.1 Rephrase the proposed TR text to be appropriate for a study item

Replace normative “shall” with informative study wording, e.g.:
- “Lawful interception requirements should be considered for all WTs and corresponding key issues in this study. LI requirements are specified in TS 33.126 (and related LI specifications).”
Or:
- “This study is expected to assess implications on LI requirements (TS 33.126) and identify gaps.”

6.2 Provide an initial LI gap/risk checklist for 6G architecture

Include (even as an annex or companion note) a short list of architectural areas that typically impact LI, for example:
- identifiers and identity privacy (new SUPI-like concepts, pseudonyms),
- routing/anchoring changes (distributed UPF equivalents),
- service-based interfaces and exposure (APIs, eventing),
- slicing/tenant separation and lawful intercept per slice/tenant,
- E2EE and application-layer encryption defaults,
- edge computing and local breakout,
- non-3GPP access integration changes,
- roaming/inter-PLMN interception support.

This makes the LS actionable and reduces ambiguity for SA2/SA4/SA6.

6.3 Clarify what “applicable” means

Add a statement such as:
- “TS 33.126 requirements remain applicable as baseline principles, subject to mapping to the 6G architecture and identification of any necessary enhancements or exceptions.”
This avoids an absolute claim that may be technically incorrect later.

6.4 Expand references or explicitly scope them

Either:
- reference the broader LI spec set (33.126/33.127/33.128 as appropriate), or
- explicitly state: “TS 33.126 is the primary requirements baseline; additional LI specs may apply depending on architecture.”

6.5 Define a concrete coordination mechanism

Instead of “send LSs if needed”, propose:
- a standing agenda item / joint workshop between SA2 and SA3-LI at key milestones,
- a timeline aligned with TR 23.801-01 deliverables,
- a commitment from SA3-LI to deliver a Rel-20 LI gap analysis report by a specific stage.

6.6 Avoid “6G” terminology if not formally adopted

Align with the official naming used in the target TRs/TSs (e.g., “Rel-20 system”, “next generation system”) to prevent editorial and procedural pushback.

Bottom line

The intent (early LI consideration) is reasonable, but the LS as summarized is too absolute, too generic, and procedurally fragile (normative “shall” in a TR). It would be significantly strengthened by (i) rewording to study-appropriate language, (ii) providing an initial LI-sensitive topic list and gap-analysis plan, and (iii) clarifying the meaning and limits of “TS 33.126 applicability” for a future 6G/Rel-20 architecture.

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.