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.