Proposed General Updates to Terms of Reference for SA4 Working Group

Summary and Background

This document proposes general updates to the SA4 Working Group Terms of Reference (ToR) in preparation for 6G work. The proposal is separate from AI-related updates covered in S4-260xxx. The document is submitted for agreement at SA4 and subsequent approval at SA plenary in March 2026.

Main Technical Contributions

Scope of Responsibilities Updates

Codec Development Expansion

• Broadened codec scope: Updated language to include "codecs for speech, audio, video, graphics and other newly emerging media types" (previously more limited scope)
• Enhanced media handling: Added explicit mention of "transport and handling of such media including related session descriptions and storage formats"

Service Architecture Enhancements

• Cloud and edge computing: Explicit inclusion of "media-centric cloud and edge computing architectures" in the definition of streaming and real-time communication services
• Media APIs: Added "media APIs" and "media profiles" to the list of SA4 responsibilities
• Session descriptions: Formalized responsibility for session descriptions

Third-Party Services Support

• New responsibility area: Added explicit scope for supporting third-party media services and applications to benefit from 3GPP system functionalities
• Network and client interfaces: Defined responsibility for providing suitable network and client interfaces/APIs
• Traffic characteristics: Includes definition of traffic characteristics and QoE requirements for emerging services (particularly XR applications)

AI/ML Integration

• AI/ML for multimedia: Added explicit mention of "artificial intelligence (AI)/Machine Learning (ML) for multimedia" as part of SA4's service scope

Sub-Working Group Structure

The document formalizes the structure of four SA4 Sub-Working Groups with detailed Terms of Reference:

Multimedia Broadcast Streaming (MBS) SWG

• Core focus: Integration of codecs, system and delivery aspects for download, streaming, and messaging services
• Key responsibilities:
• Content formats and delivery protocols for unicast, multicast, and broadcast streaming
• Messaging services
• Cloud and edge computing architectures
• Media APIs
• QoE and energy efficiency metrics reporting
• Traffic characteristics definition

Real-Time Communication (RTC) SWG

• Core focus: Integration of codecs and system aspects for real-time communication services including multimedia telephony and XR communications
• Key responsibilities:
• Content formats and delivery protocols for services with real-time constraints
• Updates to cloud and edge computing architectures
• Media APIs
• QoE metrics reporting
• Traffic characteristics for real-time services

Video SWG

• Core focus: Specification of codecs for video, graphics, images, and other visual media types including immersive formats
• Key responsibilities:
• Visual quality evaluation and test methodology
• Characterization of visual formats
• QoE metrics definition
• AI/ML applications: Explicit inclusion of AI/ML applied to multimedia scenarios
• Neural network model formats
• Model optimization and compression aspects

Audio SWG

• Core focus: Development and maintenance of specifications for speech/audio codecs and quality evaluation
• Key responsibilities:
• Transport and media handling aspects
• Testing, verification, characterization, and selection criteria
• End-to-end performance including terminal characteristics
• Immersive audio formats for multimedia telephony and XR communications
• Capture and rendering aspects of audio media delivery
• Ultra-low bitrate coding: Explicitly added to support voice services via non-terrestrial networks (NTN)

Governance and Decision-Making

• Hierarchical structure: Formalized that SA4 SWGs operate under SA4 WG
• Decision confirmation: All SWG documents require confirmation at SA4 level

External Collaboration

The annex lists key external organizations for coordination: - ISO/IEC JTC 1/SC 29 - SVT, DASH-IF - 5G-MAG - Khronos - GSMA - IETF - ITU-T Study Groups 12 and 16

Key Changes Summary

The main updates reflect: 1. Preparation for 6G work 2. Formalization of cloud/edge computing architectures 3. Explicit AI/ML integration (with detailed AI proposal in separate document) 4. Enhanced support for third-party services 5. Formalization of four SWG structure with detailed ToRs 6. Addition of ultra-low bitrate coding for NTN support 7. Strengthened focus on emerging media types and XR services

Proposed Updates to Terms of Reference for SA4 Working Group Addressing AI Data

Summary and Background

This document proposes updates to the SA4 Working Group Terms of Reference (ToR) to address AI-related media services and data characteristics, particularly in the context of 6G development. The proposal has been under discussion since SA4#134 and SA#110, with multiple related papers submitted addressing the scope and responsibilities for AI traffic characteristics across different 3GPP working groups.

Context from Previous Meetings

SA4#134 and SA#110 Discussions: - Initial ToR update version discussed but no consensus reached at SA4#134 - SA#110 received multiple papers (SP-251499, SP-251540, SP-251576) discussing AI traffic characteristics responsibilities - Key debate centered on whether SA4's mandate should be restricted to media-related AI or generalized to any AI/ML model - Discussion included clarification of responsibilities between SA1, SA2, and SA4 regarding AI traffic characteristics - SA#110 postponed the ToR update without providing clear guidance to SA4

Key Observations from Related Papers: - AI traffic will be one of the most important data types in 6G networks with dedicated characteristics - SA4 holds expertise in detailed traffic analysis (demonstrated in XR work in Releases 18-19) - SA2 also scoped work items for AI traffic system impacts and QoS framework requirements - Need for clear delineation of responsibilities to avoid duplication and ensure efficient collaboration

Triggering Event: The approved FS_6G_MED study includes objectives to "collect and study AI representation formats and traffic characteristics used in AI-related media services" based on use cases including agents, multi-modal large language models, and diffusion models.

Main Technical Contributions

1. Overview Section Updates

Expanded Scope for AI-Based Media Services: - Added explicit mention of "AI-based media services" alongside existing services (XR, gaming) - Included "use of artificial intelligence (AI) and machine learning models for multimedia" - Added "[media-related] the relevant AI representation formats and data types for these services including but not limited to those making use of multi-modal large language and diffusion models" - Note: The text shows "[media-related]" in brackets, suggesting optional qualifier that was debated

Current Responsibilities Acknowledgment: Updated to reflect SA4's current work on XR-based services, Next Generation Video for 5G, Media Distribution, Media Cloud and Edge Processing, Glass-based AR, VR conferencing, and Immersive Voice and Audio Services.

2. Scope of Responsibilities Updates

Codec Specifications (First Bullet): - Expanded from just codecs to include "transport and handling of such media including related session descriptions and storage formats"

Media Services and Architectures (Second Bullet): - Added "media APIs" and "media profiles" to the list of responsibilities - Clarified "media-centric cloud and edge computing architectures"

Guidance to Other 3GPP Groups (Third Bullet): - Maintained responsibility for providing guidance on QoS parameters, traffic characteristics, and system implications

Quality Evaluation (Fourth Bullet): - Expanded to include "multimedia and AI data representation quality evaluation" - Added "new evaluation methods" to the scope

Third-Party Media Services Support (Fifth Bullet - Key Addition): - Major expansion: Added comprehensive responsibility for supporting third-party media services and applications - Explicitly includes "definition of traffic characteristics and QoE requirements for different services and data types" - Critical addition: "including in particular also emerging including AI-based media applications and services" - This bullet establishes SA4's role in providing traffic characteristics for AI-based applications to other WGs

End-to-End Performance (Sixth Bullet): - Expanded to include "multimedia services" alongside speech, audio, and video

Interoperability (Seventh Bullet): - Clarified scope as "from codec and media transport point of view"

3. Service Scope Clarification

Updated Services List: The responsibilities now explicitly cover services including but not limited to: - Multimedia telephony - Mission critical services - Multimedia unicast and multicast/broadcast streaming - Content delivery - Online gaming - Extended realities (XR) - New: Services based on cloud and edge computing architectures - New: Services based on artificial intelligence (AI)/Machine Learning (ML) for multimedia

4. Sub Working Group Terms of Reference

Multimedia Broadcast Streaming (MBS) SWG: - Responsibilities include integration of codecs, system and delivery aspects - Covers download, streaming, and messaging services - Includes QoE, energy efficiency metrics, and traffic characteristics definition

Real-Time Communication (RTC) SWG: - Focuses on real-time communication services including multimedia telephony and XR communications - Covers services with real-time constraints - Includes cloud/edge computing architectures updates and traffic characteristics

Video SWG: - Specification of codecs for video, graphics, and visual media including immersive formats - Key addition: "Artificial Intelligence (AI)/Machine Learning (ML) applied to multimedia scenarios, including neural network model formats and related optimization and compression aspects"

Audio SWG: - Development and maintenance of speech/audio codecs and quality evaluation - Covers immersive audio formats for multimedia telephony and XR communications - Includes both capture and rendering aspects

5. Governance Structure

SWG Operating Model: - SA4 SWGs operate under SA4 WG - All document decisions must be confirmed at SA4 level

6. External Collaboration (Annex)

SA4 maintains regular communication with: - Other 3GPP WGs - ISO/IEC JTC 1/SC 29 - DASH-IF - IETF - ITU-T Study Groups 12 and 16

Key Technical Implications

Clarification of SA4's Role in AI Traffic Characteristics

The proposed updates establish SA4 as the primary 3GPP WG responsible for: 1. Identifying data types and traffic characteristics for AI/ML media services 2. Providing traffic models and characteristics to other WGs (particularly RAN1, SA2) that request such information 3. Defining AI representation formats relevant to media services 4. Evaluating quality aspects of AI-based media data

Scope Boundaries

The use of bracketed "[media-related]" in the text suggests ongoing debate about whether SA4's AI responsibilities should be: - Option 1: Limited to media-related AI only (more restrictive) - Option 2: Extended to broader AI representation formats and data types (more expansive)

This ambiguity reflects the unresolved discussions from SA#110 regarding the division of responsibilities between SA2, SA4, and other WGs.

Proposal for Approval

The document proposes agreement on these ToR updates and submission for approval to SA plenary in March 2026 (noting this is a revision of SP-241362).

Summary of S4-260051: Promotional Activities for 3GPP SA4

Document Overview

This information document from Qualcomm provides an update on promotional activities related to 3GPP SA4 work, covering past presentations, upcoming scheduled events, and future opportunities for promoting SA4 standardization efforts.

Past Presentation Activities

• Limited promotional activity during the reporting period due to Christmas break and MPEG scheduling conflicts
• One presentation delivered to DTG Next Generation Media Group on January 27, 2026
• Presentation slides attached to the document for information

Upcoming Scheduled Events

DVB World (March 17-18, 2026)

• Event location: Amsterdam
• Dedicated session on "Assessing the future role of 5G Broadcast"
• Event website: https://dvbworld.org/programme/

Workshop on Media Energy Consumption Measurement and Exposure (March 19, 2026)

Event Details: - Date: March 19, 2026 at 15:00 CET - Format: Online via Zoom - Registration: Free attendance via https://eveeno.com/media-energy-workshop - Co-organized by: 3GPP SA4, Greening of Streaming, and 5G-MAG

Workshop Objectives: - Explore practical integration of energy measurement, reporting, and optimization within media streaming architectures - Focus on 5G and upcoming 6G systems - Designed as open technical exchange with expected tangible outcomes - Clarify technical feasibility, identify new interface requirements, and explore collaborative experiments

Confirmed Presentations: - 3GPP SA4: Presentation on ongoing Work Item "Study on Media Energy Consumption Exposure and Evaluation Framework phase 2" (WI #1080050), led by Julien Lemotheux (Orange) - Greening of Streaming: Hands-on experimentation with live, end-to-end energy measurement across devices, networks, and streaming workflows - 5G-MAG: Reference implementations of media delivery architectures, user equipment data collection and reporting, APIs - MPEG: Topic to be confirmed

Target Audience: - Engineers, architects, researchers, and standards contributors interested in sustainable media delivery implementation

5G-MAGazine Publication

Planned Content for First Issue: - AMD Rel.19 topics: - CMCD (Thomas) - CMMF (Fred) - 3GPP PDU set handling Rel-19 Enhancements (Saba) - Split Rendering with IMS Data Channel (Saba) - Developer Corner: - OpenMobileNetworkToolkit (Peter Hasse) - DVB-NIP Analyzer Tool (Yannick Poirier)

Future Opportunities

MWS 2026

• Event website: https://www.fokus.fraunhofer.de/en/fame/events/mws26.html
• Potential opportunity to organize activities around 6G

IBC 2026

• Technical Paper Conference: https://show.ibc.org/submit-technical-paper-2026
• Joint submissions encouraged

Future Media Townhall Edition 2

• Organizations with relevant content encouraged to contact the author

Proposal

The document proposes that SA4 take this information into account for promotional planning purposes.

Generic Network Interface Emulator for Media Delivery Evaluation

Introduction

This contribution proposes a generic network interface emulator for evaluating media delivery protocols under realistic 3GPP network conditions. The emulator supports evaluation objectives across three related study items: - FS_QStream_MED: QUIC-based streaming protocols - FS_Q4RTC_MED: Real-time communication - FS_6G_MED: 6G media aspects

The emulator provides configurable network profiles based on custom and 5QI characteristics, supporting advanced netem controls for realistic traffic shaping to enable consistent and reproducible evaluation.

Background and Motivation

The contribution addresses requirements from SP-251659 (FS_QStream_MED) and SP-251661 (FS_Q4RTC_MED) for evaluation frameworks under realistic UE-observed network conditions. A reusable emulator with standardized profiles improves repeatability and comparability across implementations.

Key Capabilities

• One-way delay, jitter, loss, and bandwidth shaping
• Advanced netem controls: correlation, distributions, loss models, reordering, duplication, corruption, and queue limits
• HTB (Hierarchical Token Bucket) rate limiting combined with netem impairments
• YAML-based profile configuration

Standard Profiles

• ideal_6g: 1 ms delay (baseline reference)
• 5g_urban: 20 ms delay, 0.1% loss, 100 Mbit/s
• wifi_good: Home/office WiFi conditions
• cell_edge: 120 ms delay, 1% loss, 5 Mbit/s
• satellite: 600 ms delay, 0.5% loss, 10 Mbit/s
• congested: 200 ms delay, 3% loss, 1 Mbit/s
• 5QI-derived profiles: Mapped from PDB/PER values

Network Emulator Architecture

The emulator is built on Linux Traffic Control (tc) with netem qdisc, providing precise control over network characteristics. It implements a layered approach where network conditions are applied at the interface level, enabling transparent emulation for any media delivery protocol without requiring client or server modifications.

5QI-based Network Profiles

Pre-defined profiles derived from 3GPP 5QI specifications (TS 23.501 Table 5.7.4-1):

• 5QI 1: Conversational Voice (PDB 100ms → delay, PER 10^-2 → 1% loss)
• 5QI 2: Conversational Video/Live Streaming (PDB 150ms, PER 10^-3 → 0.1% loss)
• 5QI 7: Voice, Video, Interactive Gaming (PDB 100ms, PER 10^-3 → 0.1% loss)
• 5QI 80: Low-latency eMBB/AR (PDB 10ms, PER 10^-6 → 0.0001% loss)

Advanced Netem Controls

The emulator supports sophisticated network modeling beyond basic delay and loss:

• Delay distribution models: normal, pareto, paretonormal
• Delay correlation: Controls smoothness of delay variations
• Loss correlation: Enables bursty loss patterns
• Gilbert-Elliott loss models: Two-state Markov model for realistic loss simulation
• Bandwidth shaping: HTB with configurable rate limits
• Packet buffer limits: Configurable queue sizes
• Additional impairments: Reordering, duplication, corruption

YAML Configuration Structure

The contribution provides comprehensive YAML profile examples with detailed parameter mappings to tc/netem commands:

• Delay parameters: delay_ms, jitter_ms, delay_distribution, delay_correlation_pct
• Loss parameters: loss_pct, loss_correlation_pct, loss_model (Gilbert-Elliott)
• Bandwidth parameters: rate_mbit, limit_packets
• Additional impairments: reorder_pct, duplicate_pct, corrupt_pct

Each profile includes inline documentation explaining the parameter purpose and mapping to Linux tc commands.

Deployment Scenarios

Multiple deployment configurations are supported:

1. Standalone deployment: Single host for client-side testing
2. Docker deployment: Containerized execution with NET_ADMIN capabilities for cross-platform consistency
3. Network bridge deployment: Positioned between client and server for transparent traffic shaping
4. Integration with simulation frameworks: Compatible with ns-3 and similar tools

Example Usage

```python from netemu import NetworkEmulator

emulator = NetworkEmulator( interface="eth0", profiles_path="profiles.yaml" )

Apply profiles for uplink and downlink

emulator.apply_profile("poor_cellular", ingress_profile="5g_urban")

... run tests ...

emulator.clear() ```

Proposals

The contribution proposes that SA4 agrees on the following:

1. The network emulator based on Linux tc with netem qdisc provides an appropriate baseline for media delivery protocol evaluation under realistic 3GPP network conditions.

2. The 5QI-derived network profiles may be used as reference conditions for comparing media delivery technologies across the related study items.

3. Additional network profiles (satellite, congested, edge scenarios) complement the 5QI profiles for comprehensive evaluation coverage.

4. Document the emulator architecture and profiles in TR 26.934 (Test platform for media delivery technologies) to ensure consistent evaluation methodology.

References

• [1] SP-251652: New SID on Media Aspects for 6G System (FS_6G_MED)
• [2] SP-251659: New SID on evaluation of QUIC-based protocols for on-demand and live video services (FS_QStream_MED)
• [3] SP-251661: New SID on QUIC-based media delivery for Real-time Communication (FS_Q4RTC_MED)
• [4] 3GPP TS 23.501: System architecture for the 5G System (5GS)

Summary of S4-260179: Considerations for SA4 Terms of Reference

1. Introduction and Background

This contribution provides considerations for updating the SA4 Terms of Reference (ToR), following discussions at SA4#134 in Dallas where no agreement was reached on S4-252136. The document presents Huawei/HiSilicon's views on the ToR update with a revised version of the previous contribution.

2. AI/ML Related Traffic Characteristics

Main Position

The document argues that traffic characteristics input is the most urgent topic as it affects progress in other working groups.

Key Technical Points

• Related work on general AI traffic characteristics has already been addressed in SA1 and SA2 in Release 18 (e.g., TS 23.501 includes 5QI 88 for AI/ML traffic)
• SA4 should focus specifically on media service-related AI traffic characteristics to complement SA1/SA2 work
• Real-time media-related AI traffic is of particular interest to 3GPP working groups
• This includes representations and formats for AI-related media, such as multi-modal AI

Supporting Contribution

The source references companion contribution S4-260096 on AI-related formats used in state-of-the-art AI/ML systems with media components, indicating that TR 26.927 and the 6G study need updates.

3. AI/ML Quality Evaluation

Main Position

The document argues against including general AI/ML quality evaluation in SA4 ToR.

Rationale

• Quality evaluation of AI is highly task-dependent
• Many AI services are not under SA4 control
• Different tasks have different evaluation criteria
• Developing generic AI quality evaluation mechanisms is not trivial
• Could introduce numerous quality evaluation problems SA4 cannot address

Recommended Scope

SA4 should only address quality evaluation when: - Very constrained to specific media-related use cases - Valuable in the SA4 context (e.g., AI codec or other specific media-related AI use cases)

4. General Considerations

Scope Boundaries

• Most AI traffic (text/application data) is outside SA4 scope: MCP/A2A and agent protocols use text training data and application access, which have never been in SA4's domain
• Timed text differs from general unstructured web text and was traditionally in multimedia scope due to synchronization requirements

Media-Related AI Traffic

• For AI-related media traffic, multimodal AI requires attention
• Different representations are popular compared to previous considerations
• State-of-the-art updates needed in TR 26.927 or 6G study

AI Codec vs. AI Model Distinction

• AI codec/representation format evaluation differs from evaluating the AI model itself
• Different codecs/formats can compress/represent neural networks and AI models
• Codec development work is appropriate for SA4
• Work beyond codecs should be limited to well-defined media-related use cases

6G Considerations

• 6G AI/ML use cases should be considered for AI traffic characteristics
• Embodied AI identified as having the most stringent real-time requirements relevant to the network
• Current mobile networks meet most requirements of today's AI services (chatbots), making them less useful as anchors for 6G targeting 2030
• Previous ToR mentioned 5G; may be necessary to refer to 6G-specific aspects and use cases

General AI Usage in 3GPP

• General usage of AI in 3GPP (e.g., for network operation) should not be linked to codec working group SA4
• Such applications are outside SA4's expertise

5. Proposal

The document proposes incorporating these suggestions into any revision of the SA4 Terms of Reference, with suggested updates provided in an attachment to the paper.

Improvement to Working Methods

1. Introduction

This contribution addresses the incoming liaison S4-251685 from the previous SA4 meeting by identifying a "pain point" in the current working methods and proposing a test run approach using TR 21.905 to modernize the format and contribution process for TRs and TSs.

2. Problem Statement

Current Process Inefficiencies

• Inefficient Term/Acronym Management: Rapporteurs and specification editors are requested to include terms and acronyms not present in TR 21.905, but this mechanism is not efficient
• Infrequent Updates: The process to add new terms/acronyms to TR 21.905 is not triggered often by SA4, even for terms extensively used across SA4 specifications and other groups (e.g., XR)

Identified Discrepancies

The contribution references an existing tool developed by IoTconsultancy.nl (available at https://3gpp.guru/) that enables lookup of acronyms and definitions across all 3GPP TS/TR documents. This tool highlights several discrepancies in 3GPP specifications:

Example 1: "XR" Acronym

• Not defined in TR 21.905
• Used across multiple specifications with varying definitions
• The tool can point to exact locations where acronyms are defined in different TRs/TSs

Example 2: "IMS" Acronym

• Long list of specifications using the acronym as defined in TR 21.905
• Also a long list of specifications using IMS with different meanings, variations, or typos

Current Disclaimer Limitation

Most specifications include the disclaimer: "For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1]."

While strict alignment of abbreviations is not required, minimizing divergences would be desirable.

3. Proposal

Develop an Equivalent Tool Within 3GPP

The contribution proposes evaluating whether an equivalent tool could be developed within 3GPP with the following capabilities:

1. Online TR 21.905: Have an online version of TR 21.905 as the entry point
2. Online Development: Continue to develop TR 21.905 via online mechanism
3. Request Mechanism: Define a mechanism for WGs to provide requests for adding new acronyms or terms to the online version of TR 21.905
4. Search and Cross-Reference: Allow searching for acronyms and terms with pointers across specifications

Additional Benefits

• Harmonize acronyms and terms across specifications
• Identify typos that could be corrected more easily

Rationale for Using TR 21.905 as Test Case

• Universal Relevance: TR 21.905 is relevant to all WGs and to all TRs and TSs of 3GPP
• Engagement Opportunity: Allows engaging all WGs in evaluating online tools on one common specification
• Identify Common Needs: May highlight common needs and differences between WGs before attempting to use/define tools for development of more substantial TR/TS
• Uncertainty Management: It is not yet clear that if the TR/TS development process changes, all WGs would have the same needs

TR Series Classification for Advanced Image Formats Study

Introduction

This contribution addresses a procedural issue with the approved Study Item Description (SID) for Advanced Image Formats (FS_AIF_MED). A modification was made during SA plenary approval that fundamentally changes the nature and accessibility of the deliverable without proper notification to the study proponents.

Background and Original Intent

The FS_AIF_MED study was agreed in SA4 with the intention of creating a normal Technical Report (TR) that would:

• Investigate advanced image format technologies
• Identify potential normative work opportunities
• Be publicly available as a reference for the industry
• Serve as a foundation for future study and specification development

Issue Description

The Problem

During SA plenary, the SID was modified to designate the deliverable as an internal TR (800-series) rather than a standard TR. The source believes this change may have originated from:

• A typo in the SA4-agreed SID that noted the TR placeholder number as 26.8xx
• The placeholder number was not intended to carry significance to fundamentally change the deliverable nature
• The SA4-agreed SID designation and clear study objectives indicated a normal TR
• An internal TR was never discussed at SA4 level

Mismatch with Internal TR Definition

According to 3GPP specifications [1], internal TRs (800-series) are defined as:

• "Not intended for publication"
• "3GPP internal"
• "Interim results of feasibility studies"

None of these definitions match the intended deliverables of this study.

Assessment

The proponents believe this was most likely an administrative oversight, as there was no technical discussion about limiting the scope or accessibility of this work.

Proposal

The proponents request that SA Plenary:

Agrees to correct the SID to designate the deliverable as a standard (public) TR rather than an internal TR, to align with the study's objective of identifying potential normative work and ensuring industry-wide accessibility of the findings.

References

[1] "Numbering Technical Reports (two classes):" https://www.3gpp.org/specifications-technologies/specifications-by-series

Analysis of 26 Series Specifications in Preparation of 6G Specs Modernization

1. Introduction

This document provides SA4 with an initial assessment of SA4-controlled specifications (26 series) in the context of the 6G Specs Modernization (6GSM) activity. The 6GSM initiative is exploring modernization of specification development workflows, including review of current spec formats and working practices, with progress captured in TR 21.802. This contribution focuses specifically on the current state of 26 series specifications and their alignment with 6GSM findings.

2. Potential Outcomes of 6GSM Work

The definitive target format for Rel-20 specifications remains unclear. Options under consideration include:

• Maintaining current DOCX format (potentially with restrictions)
• Moving to streamlined formats: Markdown, ASCIIDoc, LaTeX, or OpenDocument

A key open question is whether new formats and working methods will apply only to newly developed specifications or also to existing specifications continuing in Rel-20 and beyond. This assessment aims to provide SA4 with visibility on technical debt present in current specifications.

3. Issues Observed in the 26 Series

An initial assessment was conducted on latest SA4 specifications from Rel-19 using Python scripting to extract structural insights and identify improvement areas.

3.1 DOC vs. DOCX

Finding: All specifications are now in DOCX format except TS 26.445, which has been split into subparts with only recently updated parts migrated to DOCX.

Recommendation: Convert all TS 26.445 subparts to DOCX for consistency. Consider consolidating subparts into a single DOCX file, as handling speed issues are less problematic than when the series was originally created.

3.2 Tables

Finding: Tables can slow down word processor performance. TS 26.114, TS 26.253, and TR 26.930 include numerous tables, but their size and quantity remain well below "mega tables" seen in other 3GPP specifications.

Assessment: Performance impacts are limited and not a significant issue in the 26 series.

3.3 Embedded Images

Finding: Embedded images cause MS Word lag, particularly in Print view. Key observations:

• TS 26.447 contains >1,000 embedded images
• Other specifications contain several hundred images
• Some images included at higher resolution than necessary
• Large file sizes noted: TR 26.998, TS 26.506, and TR 26.804 each exceed 50MB

Recommendation: Review specifications to identify images that could be replaced with lower-resolution versions. All specifications could benefit from such optimization.

3.4 Embedded Objects

Finding: 26 series specifications feature broad range of embedded objects with the following distribution:

• vsdx: 357
• bin: 235
• sldx: 46
• vsd: 41
• docx: 19
• vsdm: 10
• doc: 1

Most objects are embedded as OLE objects, presenting challenges when working across formats other than DOCX.

Recommendation: - Streamline range of embedded formats with preference for interoperable standards - Move away from Visio (not all delegates have access) - Adopt "Diagrams as Code" approach - Use widely supported formats like SVG and PNG to enhance accessibility and future-proof specifications

3.5 Relationships / Template

Finding: Templates with 3GPP styles (e.g., 3GPP_70.dot) are typically referenced as local files.

Recommendation: Switch to online version to eliminate editing warnings about missing templates and make contribution process smoother. Templates do not contain macros and are therefore safe to use online.

3.6 Equations

Finding: - Some equations remain in legacy Equation Editor format (deprecated due to unresolvable security vulnerabilities) - Some equations exist only as images and cannot be edited directly in MS Word

Recommendation: - Migrate legacy equations to modern OMML format used in DOCX files - Identify and convert image-based equations to editable formats to improve maintainability and alignment with 3GPP document best practice

4. Summary and Recommendations

The review has identified several areas where technical debt has accumulated in SA4 specifications. These issues should ideally be addressed as part of Rel-19. While MCC may handle some aspects, spec rapporteurs are encouraged to examine their own specifications and consider required updates or clean-up actions.

The source is also assessing feasibility of converting 3GPP specifications from DOCX to Markdown format, with updates to be shared as progress is made.