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.