| TDoc Number | Title | Source | Summary | Proposals | Comments |
|---|---|---|---|---|---|
| (pdf) | SA4 Work and Study Items Status at the start of SA4#135 | SA WG4 Chair | No summary available | No proposals available | No comments |
| (pdf) | VIDEO SWG AH report since SA4#134 | VIDEO SWG Chair (Tencent) |
VIDEO SWG Ad-Hoc Report (Post SA4#134)Meeting OverviewThis report covers two VIDEO SWG ad-hoc sessions held between SA4#134 and SA4#135: - Session 1: December 16, 2025 (15:00-18:00 CET) - Session 2: January 27, 2026 (15:00-18:00 CET) The sessions were conducted online with 22 and 18 participants respectively. 1. Maintenance Work - VOPSS4aV250070: Annotation Schema for VOPS and FS_AVFOPS_MEDStatus: Agreed Key Contributions: - Proposed annotation schema (JSON format) and animation example for video signals used in conformance testing - Addresses the intersection of VOPS and Advanced Video Formats (AV) conformance activities - Proposes moving conformance activities into the study phase to align completion with normative work Technical Details: - Introduced annotation schema for documenting test bitstreams - Covers requirements for bitstream generation and references to existing testing specifications - Reference encoders are informative only, not normative - Big Buck Bunny identified as initial test sequence candidate - JSON files to be added to 3GPP Forge as baseline Discussion Points: - Clarified that encoder specifications remain outside normative scope - Focus on providing conformant bitstreams with documentation of generation methods - Encoder references needed for reproducibility but not as normative elements 2. FS_AVFOPS_MED (Study on Advanced Video Formats and Operation Points)2.1 S4aV250069: Video with Changeable BackgroundStatus: Endorsed Scenario Description: - Enables users to change recorded video backgrounds using auxiliary alpha channel - Uses MV-HEVC for alpha channel signaling Technical Aspects: - Reviews previous 3GPP work (none found in existing specs) - References external developments: - MV-HEVC for multi-view video coding - CICP draft for alpha channel signaling - ISO base format amendment for alpha maps Open Issues: - Alpha signal definition: Lack of clear, codec-independent specification for alpha channels - Alpha channel represents transparency levels, but conventions vary by system - CICP work ongoing but not yet providing complete definition - Action identified: Need precise, codec-agnostic definition of alpha signals and interpretation 2.2 S4aV250071: Refocusable VideoStatus: Endorsed Scenario Description: - Recording video with ability to change focus plane after capture - Uses three tracks: blurred video, sharp video, and depth map Technical Aspects: - References Android and Apple ecosystem implementations - Ongoing work in CICP for depth map code points - ISO file format amendments in progress Open Issues: - Signal mapping: Need clarity on mapping between signals in specifications and Android/Apple APIs - Depth interpretation: Complexity of depth normalization and application across scenarios - Interoperability: Need for clear definitions of how depth maps are defined and used - More documentation required on APIs and signal mapping 2.3 S4aV250072: Video with Semantic Segmentation MapStatus: Endorsed Scenario Description: - Combines video signal with semantic segmentation map - Segmentation map assigns class identifiers (e.g., face, hair, clothes) to pixel values - Applications: AR filtering, video indexing Technical Aspects: - JVET work extending MV-HEVC auxiliary layers to support segmentation planes - Codec-agnostic approach for broader applicability - Each segmentation model has its own category set - Application must know which model was used to interpret IDs correctly Key Technical Challenges: - Semantic vocabulary: Need defined vocabulary or model reference for segmentation map values - Coding artifacts: Robustness achieved by mapping value ranges to class IDs (number of classes typically much lower than possible sample values) - Model reference: Essential to specify which segmentation model was used for interoperability - Signal definition: Need to define signals and semantics independently of coding solutions, not relying on SEI messages or codec-specific mechanisms Discussion Outcomes: - Focus on defining signals independently of coding solutions - Further work needed on requirements, model references, and semantic definitions - Use case valuable despite implementation concerns 3. Avatar Phase 2 Work (Avatar_Ph2_MED)3.1 S4aV260005: Corrective CR for TS 26.813Status: Endorsed Details: - Content agreeable but needs revision for SA4#135 in Goa - Template from portal to be used - Corrections and clarifications to existing Avatar specification 3.2 S4aV260004: Work Plan for Avatar_Ph2_MEDStatus: Agreed Work Plan Structure: - Objectives organized by dependencies and complexity - Some evaluations can only be done after earlier steps complete - Prioritization based on interest and technical dependencies Process Agreements: - CR submission approach: Flexibility maintained for early CRs if solutions complete and group agrees - Parallel work: Normative work should not run in parallel with study (discouraged practice) - Early implementation: CRs can be issued early if consistent, but doesn't automatically start normative work - FFS items: Can be addressed early with intermediate CRs if appropriate - Corrections vs. features: Clarifications/corrections can be made anytime if justified; new features should wait for study completion Key Issues Clarification: - Listed "key issues" are actually objectives from the work item, not newly identified problems - Study planned to run until September 2026 - Possibility of starting normative work earlier if editors' notes addressed 3.3 S4aV260006: Consolidated CR for FS_avatar_ph2_MEDStatus: Endorsed as basis for further work Approach: - Base CR to track changes across study - Contributions as candidate text against new or existing sections - Consolidation at each meeting - CRs sent for approval when ready Editorial Requirements: - Cannot attach full draft TRs to CRs - Must use correct 3GPP styles - References must be up-to-date - Only modified clauses included in final CR - TR version not referenced in document - "Avatar Phase 1" terminology not used in TR - Change history of TR not used to integrate co-CRs Open Question: - Security and SA3 objective (possibly objective 7) listed in time plan but corresponding section not visible in CR document 4. Process and Administrative MattersDocument Handling Decisions
IPR and AntitrustStandard IPR and antitrust clauses read at opening of each session, with reminders about: - Obligation to inform Organizational Partners of Essential IPRs - Compliance with competition laws - Consensus-based decision making Summary of Agreed/Endorsed Documents| Document | Title | Status | Target | |----------|-------|--------|--------| | S4aV250070 | Annotation schema for VOPS/FS_AVFOPS_MED | Agreed | Baseline for conformance work | | S4aV250069 | Video with changeable background | Endorsed | CR to TR 26.966 | | S4aV250071 | Refocusable video | Endorsed | CR to TR 26.966 | | S4aV250072 | Video with semantic segmentation map | Endorsed | CR to TR 26.966 | | S4aV260004 | Avatar Phase 2 work plan | Agreed | Study organization | | S4aV260005 | Corrective CR for 26.813 | Endorsed | Revision for Goa | | S4aV260006 | Consolidated CR for Avatar Phase 2 | Endorsed | Basis for further work | Key Technical Gaps Identified
|
Technical ProposalsThis document does not contain any technical proposals in the formats specified (e.g., "Proposal X:", "Proposal:", etc.). The document is a meeting report/minutes from the 3GPP SA4 VIDEO SWG Ad-Hoc meetings held in December 2025 and January 2026. It contains decisions, agreements, endorsements, and notes on various technical documents (TDocs), but no formal proposals are explicitly marked as such in the text. |
No comments |
| (pdf) | SA4 AH report on FS_6G_MED | SA WG4 Chair |
SA4 AHG Call on FS_6G_MED - January 15th 2026Meeting OverviewThis report documents the SA4 Ad Hoc Group (AHG) call held on January 15, 2026 (16:00-17:30 CET) to discuss the newly approved FS_6G_MED study (Study on Media aspects for 6G system), which was approved at the December 2025 SA plenary in Baltimore. The call was chaired by Gilles Teniou (Tencent, SA4 Chair) with 51 participants attending. Study Leadership: - Prime Reporter: Thomas Stockhammer (Qualcomm) - coordination - Secondary Reporter: Elmira Ramazanirend (Vodafone) - draft TR production Work Plan (S4aP260002/S4aP260005)Key DiscussionsMeeting Schedule: - Initial dates proposed for AHG calls were adjusted based on participant availability - Changed to March 16th and 23rd (avoiding conflicts with DVB meeting on 18th and other constraints) - Discussion on establishing regular timeslots for 6G_MED calls in weeks without other SWG telcos - Suggestion for physical meeting in Amsterdam was noted, though online format preferred due to travel approval concerns - Proposal for half-day workshop potentially at IBC or MHV events Use Case Handling: - Question raised about use case templates and organization - Use cases primarily sourced from SA1 - Discussion on whether SA4 is limited to SA1-defined use cases or can expand - Consensus that inputs are welcome with discussion on integration approach - Suggestion to summarize SA1 use cases and extract SA4-specific requirements rather than exact wording Deadlines: - Request to set appropriate deadlines for contributions - Concern raised about bringing use cases and work tasks to Goa meeting Decision: Revised to S4aP260005 and agreed as basis for further work TR Skeleton (S4aP260004)Structure DiscussionsKey Issues vs. Key Questions: - Clarification requested on difference between "key issue" and "key questions" (confirmed as same) - Discussion on "context and external factors" (similar to SA2 aspects/challenges) Clause 6 Structure: - Preference expressed not to populate Clause 6 in first meeting - Proposal to aggregate discussions in annex with moderators determining structure under each work topic - Question on whether same structure applies to all work topics (confirmed yes) - Concern about consistency of structure across work topics - Recognition that content may vary depending on topic complexity Clause 4.2 - Use Cases: - Suggestion to rename for clarity or postpone structure agreement - "Requirements" terminology unclear - Discussion on whether SA1 use cases are sufficient or need expansion with examples - Debate on whether expanded use cases belong in Clause 4 or under work topics Clause 7: - Note should reference "considerations in clause 6" Annex Usage: - Unclear purpose of annex - Explained as replacement for PD (permanent document) for consolidating information - Decision on annex content migration to other clauses deferred Proposed Way Forward
Decision: Noted (to be revised and submitted to SA4#135 with comments incorporated) Ways of Working (S4aP260003/S4aP260006)Key DiscussionsStarting Point Assumptions: - Debate on whether assumptions about reusing existing 5G components vs. starting fresh are necessary at this stage - Concern that assumptions may be premature and should be decided over time - Question on whether 6G may have entirely new service requirements - Agreement that starting point is needed - Concern that text is unclear and difficult to understand what is being agreed Decision: Revised into S4aP260006 and noted. Thomas Stockhammer to start email thread for iterating over the text. Administrative MattersIPR and AntitrustStandard IPR and antitrust clauses were read at session opening, reminding delegates of: - Obligations to inform Organizational Partners of Essential IPRs - Compliance with antitrust and competition laws - Consensus-based decision making approach Other Business
Minute Taking
Document Status Summary| Document | Title | Status | |----------|-------|--------| | S4aP260001 | Proposed agenda | Approved | | S4aP260002 | Work Plan (Draft) | Revised to S4aP260005 | | S4aP260003 | Ways of working considerations | Revised to S4aP260006 | | S4aP260004 | TR skeleton | Noted | | S4aP260005 | Work Plan (Revised) | Agreed | | S4aP260006 | Ways of working (Revised) | Noted | | S4aP260007 | Meeting report | Noted | |
I have reviewed the document carefully, and I can confirm that there are no technical proposals in this document. This document is a meeting report/minutes from an SA4 Ad Hoc Group call on FS_6G_MED held on January 15, 2026. It contains discussions, decisions on document approvals (approved, noted, agreed, revised), and administrative matters, but does not contain any technical proposals in the formats you specified (e.g., "Proposal X:", "Proposal:", etc.). The document includes decisions such as documents being "approved," "agreed," "noted," or "revised," but these are procedural meeting outcomes rather than technical proposals. |
No comments |
| (pdf) | Report from Audio SWG AH on FS_ULBC (December 2, 2025) | SA4 Audio SWG chair (Ericsson LM) |
Report from Audio SWG AH on FS_ULBC (December 2, 2025)Executive SummaryThe Audio SWG met on December 2, 2025, with 35 participants to address FS_ULBC matters, prioritizing non-treated documents from SA4#134. Key discussions covered:
Opening and Administrative MattersThe Audio SWG Chairman, Tomas Toftgård (Ericsson), opened the call at 22:00 CET on December 2, 2025. Standard IPR, antitrust, and consensus principles reminders were provided. Notes were taken by Thomas Stockhammer with co-pilot assistance. FS_ULBC Technical DiscussionsCodec Selection Process (S4aA250128)Presenter: Jiayi Xu (China Mobile) Content: - Four selection approaches outlined: - Traditional "winner takes all" (3GPP style) - Open collaborative (outside 3GPP, e.g., IETF) - MPEG-style process (call for proposals with collaborative refinement) - Combined approach (selecting baseline(s) for optimization within 3GPP) - MPEG/JPEG AI processes described as potential models - Proposal for call for proposals after TR phase - Open questions: dataset definition/sharing, Release 20 timeline feasibility, existing vs new codec, backward compatibility Discussion: - Stefan B: Questioned motivation for deviating from typical 3GPP work item approach - Jiayi: Clarified intent to initiate discussion, not push specific direction; open to traditional 3GPP mechanism - Thomas: Emphasized timeline focus; noted MPEG process typically takes 3-4 years, incompatible with Release 20 - Zhe: Expressed support for collaborative approach - Lasse: Concerned about proper motivation needed before changing established 3GPP approach; cited successful EVS/IVAS collaborations Decision: S4aA250128 noted. Offline discussions encouraged. Bundling Periods and User Experience (S4aA250129)Presenter: Lasse Laaksonen (Nokia, Dolby) Content: - Impact of bundling periods (80, 160, 320ms) on user experience examined - Longer periods (320ms) significantly affect delay and packet loss - Clarification needed on target use cases (conversational vs push-to-talk) - No specific proposal; open for discussion Discussion: - Markus: Supported reconsidering 320ms period if 160ms works well for transport; concerns about laggy experience - Zhe Wang: Agreed on reconsidering 320ms relevance unless required by transport constraints Decision: S4aA250129 noted. Design Constraints (S4aA250130)Presenter: Stephane Ragot (Orange) Content: - Proposal to consolidate all design constraint proposals into single document - Reference EVS approach for handling multiple inputs - Starting point: EVS codec supporting multiple bandwidths - 8 kHz likely too low for quality; 48 kHz may be unnecessarily high - Possibility of single bandwidth to reduce deployment complexity - Support key sampling rates for interworking Discussion: - Huan-yu: Supported collecting proposals; suggested parallel development with radio simulations - Atti: Supported single sample rate to simplify SDP negotiations and remove bandwidth negotiation complications - Juan: Suggested separating sample rate and audio bandwidth discussions - Milan: Clarified unique sampling rate discussion essentially about maximum bandwidth - Jiayi: Asked about comparing codecs with different sample rates - Stephane: Referenced extensive EVS testing experience with multi-bandwidth comparisons Agreement: - Collect all design constraint proposals into PD with references and brackets - Collective editing at later stage for fairness and efficiency - Stephane volunteered to draft initial collection Decision: S4aA250130 noted. Codec Bitrate and Capacity (S4aA250131)Presenter: Huan-yu Su (vivo, Samsung, Spreadtrum, MediaTek) Content: - Analysis of codec bit rate impact on radio resources and user capacity - Higher bit rates significantly reduce supported users - Proposal: limit codec bit rate to maximum 3 kbps for network efficiency Discussion: - Liangping: - Analysis overly pessimistic; referenced Qualcomm contribution showing support for all bit rates with 80ms bundling - Simulation flawed: only one tone used for 15 kHz subcarrier spacing; more tones should be used for higher TBS - Using more tones would lower coding rate and improve performance - Table 5 shows high coding rate (.46) with one tone; three tones would bring below 1/3 - Even current simulation shows multiple users supported at 31 dBm - Resource allocation decisions should be left to network operators, not fixed by codec specification - Huan-yu: - Disagreed; 23 dBm devices are low-end with limitations - Designing for ideal scenarios inappropriate - Leaving decisions entirely to operators not advisable; should provide range but not extremes - Stefan Bruhn: - Scheduling in figure one not optimized; other schemes could allow better capacity - Questions on transport block size gaps and uplink/downlink resource balancing - Dong: Requested Liangping organize offline meeting as simulation coordinator Decision: S4aA250131 noted. Offline meeting to be organized by Liangping. Transport Path Updates (S4aA250132)Presenter: Huan-yu Su (vivo) Content: - Updates based on 3GPP TR 23.700-19 V1.1.0 - Recommendation: use user plane instead of control plane for GEO satellite communication - Proposed additions: editor's note, updated references, table entry changes Discussion: - Jiayi: Asked whether editor's note for Pdoc or TR; concerns about referencing SA1/SA2 Tdocs in TR - Tomas: Clarified proposal for Pdoc, not TR; referencing acceptable in Pdoc - Markus: Asked about other interim solutions besides user plane - Dong: Explained control plane/user plane decision finalized; only IP vs non-IP remains open - Atti: SA2 agreed IP-based user plane mandatory, non-IP optional Agreement: - Add editor's note regarding user plane solution for GEO satellite communication - Update table as needed - Keep IP vs non-IP open for future updates Decision: S4aA250132 noted. Tandem Conditions and Transcoding (S4aA250133)Presenter: Noboru Harada (NTT) Content: - Example scenarios for ULBC interworking: native ULBC and tandem with legacy systems - Table 1: target codecs for tandem conditions (updated) - Assumption: ULBC operates on single bandwidth; transcoder adjusts for legacy codecs - Transcoder modifies sampling rates using bandwidth extension - Proposal: design constraints for transcoding function separate from ULBC end-user terminals - Transcoder runs on more capable devices (e.g., PC) Proposals: 1. Reflect tandem condition scenarios in Pdoc 2. Maintain/update target codec list for future VR reference 3. Set specific design constraints for tandem conditions and transcoding Discussion: - Noboru: Clarified transcoder operates in separate node, not ULBC device; different complexity/memory constraints applicable - Tomas: Supported clarification - Zhe Wang: Asked if proposal requires two sets of technical solutions - Noboru: - Not requiring two solutions - Goal: ensure good quality after transcoding - Bandwidth extension/conversion not required in ULBC device; can be handled by transcoder - Provides design flexibility - Atti: Asked about expected transcoder performance - Noboru: Not yet at stage of specifying performance requirements; focus on scenarios and constraints - Stephane: Suggested including EVS Wideband 13.2 channel aware mode in target codec list Decision: S4aA250133 noted. Performance Requirements (S4aA250135)Presenter: Atti Venkatraman (Apple) Content: - Minimum performance requirements for TR 26.940 - At lowest operating bit rate (1 kbps): speech quality at least as good as ("NWT") AMR-WB at 12.65 kbps - At higher operating range (~3 kbps): match or exceed EVS super wideband at 13.2 kbps - Benchmarks using widely deployed codecs - Starting list of minimum reference codecs/operating points, expandable Discussion: - Huan-yu: Concerned about overspecifying bandwidth; setting targets too high (e.g., 24.4 kbps) unrealistic for GEO satellite - Atti: Clarified not setting 24.4 kbps as target - Milan: Suggested EVS at lowest bit rate (7.2/8 kbps) as state-of-the-art wideband reference instead of AMR-WB 8.85 kbps; questioned relevance of higher bit rates (23.85, 24.4 kbps) - Atti: Reference codec list not meant to exclude others; focus on minimum performance requirements similar to current IMS voice services - Stefan: Asked about feasibility at 3 kbps, especially with packet loss; questioned comparison conditions - Atti: - Broad framework similar to EVS SA1 approach - Detailed tables to be developed for operating points - Comparison at 3 kbps as general minimum requirement - Further granularity for clean speech, noisy speech, packet loss conditions - Minimum quality benchmarks reflecting current IMS experience - Erik: Questioned if "better than AMR-WB 12.65 kbps" at 1 kbps too challenging for emergency situations - Atti: Clarified proposal is "NWT" (not worse than), not "better than" - Lasse: Suggested including bit rates in brackets for flexibility Agreement: - Atti to revise proposal incorporating comments (brackets for bit rates, clarified references) - Updated version for next meeting Decision: S4aA250135 noted. Packet Loss Concealment with AI Codecs (S4aA250136)Presenter: Markus Schnell (Fraunhofer IIS) Content: - Experiment based on DAC codec - DAC IBM condition at 1.5 kbps with low packet loss rate - Other configurations from existing TR experiment - Results: higher bit rates with higher packet loss can outperform lower bit rates with lower packet loss for DAC - DAC IBM model (trained for low bit rates) outperformed all other conditions - Conclusions: - Optimal performance under error-prone conditions achieved by models trained for specific bit rates and block error rates - Bit rate scalability (as in DAC) comes with significant performance cost at lower bit rates - Specifically trained models for certain operation modes may be more efficient Agreement: - Add new experiment and two proposed observations/conclusions to TR - Keep existing statement about allowing design freedom regarding bit rate scalability Decision: S4aA250136 agreed. Updates Based on RAN1 LS (S4aA250137)Presenter: Liangping Ma (Qualcomm) Content: - Updates to PD incorporating round one LS revisions - Key changes: references, uplink/downlink parameter corrections, modulation types, number of tones for subcarrier spacing, bundling period support, revised notes reflecting LS - Text added to figures and notes aligning with LS exceptions and conditions Discussion: - Tomas: Pointed out uplink/downlink parameter mix-up; questioned correct number of tones and noise figures - Stefan: Noted downlink section incorrectly referenced UE maximum TX power - Erik: Disagreed with updating based on specific LS interpretation; meaning not clear; premature before further clarification through offline coordination - Liangping: - Clarified two separate issues: RAN1 LS interpretation vs decision on supporting special exception case - RAN1 LS clearly defines single exception case with three components - Intent to accurately interpret RAN1 LS - Supporting special case is separate discussion - Stefan: Emphasized need for stable assumptions all companies can agree on for consistent simulations; referenced Dallas disagreements; supported continued offline coordination Conclusions: - Concerns from Ericsson regarding agreement on proposed changes - Topic debated in several meetings with different views - Continue offline discussions between Ericsson, Qualcomm, and interested parties - Expand discussions beyond bilateral to include all relevant stakeholders - Thomas noted discussions are very RAN-centric Decision: S4aA250137 noted. Simulation Assumptions and Process (S4aA250138)Presenter: Liangping Ma (Qualcomm) Content: - pCR to PD adding two previously agreed Tdocs: 1. Simulation contribution process (detailing assumptions for alignment) 2. Link budget analysis (verified numbers from RAN1 specifications, real-world deployment scenarios) - Help companies understand possible deployment deviations (e.g., scenarios where certain losses negligible) Discussion: - Stefan: Concerned about need for stable simulation assumptions; referenced Dallas disagreements; questioned if addition helps achieve consensus - Liangping: Document agreed upon; provides details on possible deviations from 3GPP assumptions; helps justify simulation choices; conclusions confirmed by RAN1 Agreement: - Add proposed text and references to PD - Include note clarifying document provides analysis of possible deviations from 3GPP assumptions Decision: S4aA250138 agreed. LS Handling (S4aA250139)Presenter: Liangping Ma (Qualcomm) Content: Analysis and recommended handling of reply liaisons from other working groups to SA4 on ULBC Decision: S4aA250139 noted without presentation (priority given to non-treated SA4#134 documents; no time for further consideration). Revision provided as new document. Complexity Evaluation (S4aA250127)Presenter: Xuzhou Ye (Bytedance, vivo) Content: Complexity evaluation of ULBC audio codec Decision: S4aA250127 noted without presentation (already treated at SA4#134; no time for further consideration). Withdrawn Documents
ClosingThe chair thanked delegates for their contributions and discussions. The call closed at 23:29 CET. Annex A: Meeting AgendaMeeting focused on FS_ULBC (item 1.7) with documents prioritized from SA4#134. Annex B: Participants35 participants from organizations including: Apple, Bytedance, CMCC, Dolby, Ericsson, Fraunhofer IIS, Huawei, Lenovo, MediaTek, Motorola, Nokia, NTT, Orange, Panasonic, Philips, Qualcomm, Samsung, Spreadtrum, Vivo, VoiceAge, Vodafone, Xiaomi, and others. |
Extracted ProposalsThis document does not contain any explicitly marked proposals in the standard 3GPP format (e.g., "Proposal 1:", "Proposal:", etc.). The document contains discussions, decisions, agreements, and notes on various technical documents (S4aA250127 through S4aA250139), but none of these are formatted or labeled as formal "Proposals" in the text. |
No comments |
| (pdf) | Report from Audio SWG AH on FS_ULBC (Jan 15 & 19, 2026) | SA4 Audio SWG chair (Ericsson LM) |
Report from Audio SWG AH on FS_ULBC (Jan 15 & 19, 2026)Executive SummaryThe Audio SWG held two meetings dedicated to FS_ULBC (Study on Ultra Low Bitrate Speech Codec) on January 15 (38 participants) and January 19, 2026 (35 participants). Key discussions covered:
No proposals were agreed for inclusion in the TR at this stage. Several contributions require additional offline work and clarification. S4aA260004: RAN Simulation Offline Meeting ReportStatus: Agreed This document reported on the offline meeting held December 10, 2025, covering:
Discussion: No comments raised. Decision: Document agreed without modifications. S4aA260003: Feasible Bitrates for 10-Degree Elevation Angle Channel ModelStatus: Noted (not agreed) Technical ContentQualcomm and Xiaomi proposed new TBS values based on a 10-degree elevation angle NTN-TDL-C channel model, arguing it is more realistic than the initial 50-degree model from TR 38.811. Key differences from initial channel model: - Lower elevation angle (10 degrees vs. 50 degrees) - Higher K-factor (25 dB vs. 0 dB) - Claimed to be closer to field measurement data Proposed TBS values: - Without DMRS bundling: up to 932 bits feasible - With 10 ms scheduling/timing penalty (worst case): up to 680 bits feasible - Highest net bit rate: ~11 kbps (at 31 dBm transmit power) - BLER remains below 2% target for both uplink and downlink Proposal: Amend TBS value tables for different bundling periods (80ms, 160ms, 320ms) to include higher values, with last row changed to "net bit rate" to clarify these are thresholds, not operational rates. Discussion PointsConcerns about channel model applicability (Ruonan): - Questioned whether new TBS values apply only to 10-degree elevation or all angles - Noted simulation calibration was done for 50-degree elevation, not 10-degree - Lack of link budget details in the paper - Calculated different link budget with little difference in simulated TBS performance - Major concern: System capacity supports only one UE uplink and three UE downlink per beam - considered insufficient Liangping's responses: - New TBS values only for new channel model (stated in paper) - Field data shows 10-degree model closer to reality due to higher K-factor - Downlink can support more than one UE within 80 ms period - Uplink can use multiple tones - Total supported UEs per satellite much higher due to multiple beams - System capacity should be determined by network operator Timing and feature dependencies (Erik): - Questioned impact of DMRS bundling wording - Sought clarification on "no uncertainty" scenario regarding UE-specific Koffset and TA report - Questioned whether TA reports and UE-specific Koffset fully accounted for in link-level simulations - Expressed hesitation about the approach Liangping's clarifications: - TA report impact minimal for GEO satellites (only during connection setup) - Both scenarios (with and without these features) considered in analysis - Worst-case scenario (without features) still supports 680 bits TBS Power consumption concerns (Stefan B): - High transmit power (31 dBm) impact on overall power consumption and battery drain - Whether all UEs required to support high power classes - Whether 31 dBm is mandatory in Release 19 Liangping's responses: - Higher transmit power increases power consumption (radio efficiency ~50%) - For automotive use cases, power less of an issue - 31 dBm supported for handheld devices per specifications - 26 dBm and 31 dBm will be supported in Release 19 - Average power for handhelds (considering silence periods and half-duplex) comparable to 2G SAR situations Field measurements and codec relevance (WangDong): - Questioned whether 10-degree model and high bit rates (11 kbps) supported by field tests - Concern about necessity when existing codecs (EVS at 9.6 kbps) provide sufficient quality - Why new TBS values needed if existing codecs already effective at lower rates Liangping's responses: - New values consistent with new channel model based on field measurements - Field tests not conducted at 31 dBm due to lack of available devices - 11 kbps is theoretical maximum under specific conditions (31 dBm) - Lower transmit power results in lower bit rates - Radio perspective requires reporting maximum feasible bit rate, not prescribing codec operation Codec design perspective (Markus Schnell): - Questioned usefulness of very high bit rates (11 kbps) when EVS at 9.6 kbps already provides high quality - Some lower bit rates (e.g., 6.6 kbps) may lack suitable 3GPP codecs - Suggested focusing on identifying gaps in 3GPP codec coverage - Could help with system capacity concerns Liangping's response: - Simulation results provide upper limit and intermediate values - Designers don't have to use highest bit rates - Lower bit rates allow more simultaneous users - ML-based codecs could potentially offer better quality at same bit rate vs. EVS Multiple TBS values interpretation (Stefan, Thomas): - Question about intention behind listing many TBS values - Thomas clarified: table provides factual information from simulation studies, not codec design mandates - Not about standardizing codec for all bit rates - Provides net bit rate data for reference High bit rate concerns (Ryan Lee - Samsung): - Reluctance about including higher bit rates - Focus should remain on ultra low bit rate codecs - If higher bit rates included, should clearly state only applicable for 31 dBm scenarios - Should be deprioritized as only relevant for limited high-power cases Process concerns (Jiayi): - Field measurements should be verified/cross-checked by multiple companies - Multiple companies have proposed TBS values (documented as open issues) - Recommended reviewing all proposals together - Suggested separating topics of elevation angle and TBS value WangDong's process concern: - Not the right time to add new TBS value proposal to open issues list - Introduces dependencies and complexities related to elevation angles - Should be considered separately DecisionS4aA260003 noted - No consensus to adopt new TBS values or add to open issues table. Several participants indicated the proposal introduces new dependencies (elevation angle) and should not be added to open issues at this time. Tomas recommended further offline discussion with topic to be revisited in future meetings. S4aA260005: ULBC Complexity and RTF AnalysisStatus: Noted (requires pCR before TR inclusion) Technical ContentDolby, Nokia, and Novamint presented updated RTF (Real-Time Factor) analysis for DAC algorithm, resubmitting previous contribution (SA4134) with updates based on Vivo suggestions. Updates included: - More detailed information on models - Addition of graphs illustrating RTF numbers - Focus on RTF metrics for different model sizes Key findings: - RTF measurements for models ranging from 20 million to 70 million parameters - Performance tested on multiple devices with different thread configurations (1 thread vs. 4 threads) - Some anomalies observed (e.g., worse RTF with 4 threads vs. 1 thread on certain devices) Discussion PointsRTF anomalies (Jiayi): - Why RTF with 4 threads worse than 1 thread for certain devices - Whether issue occurs only with DAC or other algorithms - Requested clarification on RTF definition (RTF > 1 indicates real-time processing) Rishabh's responses: - No clear explanation for worse 4-thread performance (possibly model size limitations or noise) - Document presents observed numbers without drawing conclusions - Agreed to add clarifying sentence about RTF definition Processor details (Markus S): - Which processor/core type used in one-thread mode (high-performance vs. low-power) - What happens during first frame (cache loading vs. initialization/memory allocation) - Whether software optimized for this case Rishabh's responses: - Specific processor/core type currently unknown, will investigate - First frame performance mostly affected by cache loading - Cache flushing can cause steady-state numbers to resemble first-frame numbers Model size and quality (Huan-yu): - Whether optimization maintaining same subjective quality - Concern about comparing models of different sizes - Even 20 million parameters considered large - Asked if smaller models (e.g., 10 million parameters) tested Rishabh's responses: - Subjective quality not focus of document - Goal: assess real-time performance for different model sizes - Only models down to 20 million parameters tested so far - Hope to include smaller models (10 million) in future meetings Runtime environment details (WangDong): - Which dedicated core used for ONNX runtime execution - Speed (1 GHz or max GHz) - CPU capacity and memory usage during inference - Frame-by-frame simulation setup with non-causal model Rishabh's responses: - Only overall maximum CPU descriptions currently available - Need to gather detailed runtime information - Frame-by-frame setup presents 80 ms data at a time - Goal: measure real-time performance under constraints, not quality TR inclusion discussion: - Zhe questioned whether clause 6.4 appropriate place (not just "additional design considerations" if only observations) - Huan-yu concerned about including incomplete data, preferred waiting for complete information - Thomas suggested creating pCR to clarify where and how text should be included - pCR should be agreed before content added to TR DecisionS4aA260005 noted - Group agreed to proceed by: 1. Gathering more information (especially core usage details) 2. Preparing pCR for the contribution 3. Ensuring proper formatting and references before TR inclusion 4. Improving figure clarity for better readability S4aA260006: Device Capability DiversityStatus: Noted (requires coordination with RAN groups) Technical ContentDolby and Nokia presented discussion on diversity of UE capabilities and impact on system performance and scheduling. Key points: - Devices have varying transmit power classes and receive antenna configurations - Significant impact on link-level performance - Relying on single baseline capability limits system performance, especially for lower-capability devices - Allowing diverse UE capabilities enables better system capacity and performance Proposed strategies: - Dynamic scheduling: shorter periods for higher-capability devices, longer for lower-capability devices - Enable multi-tone transmission for higher transmit power devices - Service differentiation: baseline, intermediate, and enhanced services based on device capabilities or subscription levels Proposal: - Add new clause on UE capabilities in TR 26.940 - Update multi-user considerations - Remove assumption that all devices use same configuration - Start with three target bit rates for codec selection reflecting device capability range Example UE types discussed: - Type A (enhanced): higher transmit power (31 dBm), two receive antennas - Type C (baseline): lower transmit power (class 3), single receive antenna Discussion PointsApplicability concerns (Ruonan): - Whether enhanced UE types (e.g., Type A) exclusively for shorter bundling times (80 ms) - Would this exclude baseline UE types like Type C Stefan's response: - Example illustrative but based on analysis - Baseline UEs with limited transmit power struggle at short bundling times - Operators may need longer periods (160 ms) for such devices - Main point: allow diverse UE capabilities, not forbid them Coordination with RAN groups (Erik): - Supported idea of different UE capabilities - UE features typically specified by RAN1, handed to RAN2 for defining capabilities - Suggested coordination between groups on this matter - Need awareness and coordination regarding specification and definition SA4 remit concerns (Andrei): - Defining UE capabilities not within SA4's remit - Topic relevant for service and bit rate discussions - Asked how Stefan intends to continue given NB-IoT defines categories and 5G NR defines capabilities - Need to relate proposal to these frameworks and coordinate with RAN groups Stefan's response: - Contribution aims to open discussion and highlight various UE capability assumptions - Expertise on UE capabilities lies outside SA4 - Open to input from responsible working groups - Ensure clear language in TR without pushing/mandating specific features SPS scheduling concerns (WangDong): - UE capabilities should not be defined within SA4 - SPS scheduling mechanisms being studied in RAN2, should not be defined in SA4 Stefan's response: - SPS scheduling idea not new to this contribution - Previously discussed in group and TR - Need to be careful about what will be specified - Assuming SPS usage not unique to this contribution Technical details (Liangping): - Concerns about UE power references - suggested using text from NB-IoT NTN LS instead of NB-IoT reference - Gain from two receive antennas could vary (more or less than 3 dB) depending on orientation - MIMO as future consideration - Overall concepts good but need accurate details and terminology Interoperability (Markus Schnell): - Asked about interoperability between different device classes - Whether enhanced classes can always communicate with basic classes - Maximum transmit power for NB-IoT devices (referenced 20 dBm value) - Whether new power class considered in channel simulations Stefan's response: - Some form of capability exchange or system awareness assumed for interoperability - 20 dBm (Class 5) power class believed to be defined - No new requirements proposed 20 dBm power class discussion: - Tomas noted 20 dBm class not previously considered - Liangping: 20 dBm included due to specification copy-paste, but 23 dBm more common for smartphones - Stefan: 20 dBm listed to keep options open for wearables, could be removed if unnecessary Process suggestion (Andrei): - First collect assumptions from link-level simulations - Categorize achievable rates into three device capability categories - Share assumptions and results with RAN groups for feedback - Get confirmation on existing capabilities matching these categories Stefan's agreement: - Various companies perform simulations based on different UE capability assumptions - Support documenting assumptions transparently - Clarify these are current working assumptions needing confirmation from responsible groups DecisionS4aA260006 noted - Several comments and concerns raised, particularly about: - SA4's remit in defining UE capabilities and SPS scheduling - Need for coordination with RAN1 and RAN2 - Proposal not agreeable at this point - Participants encouraged to consider potential updates offline S4aA260007: Scheduling Timing UncertaintyStatus: Noted (requires further discussion) Technical ContentQualcomm and Ericsson presented collaborative analysis addressing interpretation of RAN1 LS 1654 regarding uplink timing uncertainty between UE and base station. Key points: - Timing uncertainty affects UE scheduling capacity - Analysis clarifies when two timing diagrams (Figures 3-2 and 3-3) are equivalent for UE scheduling capacity For 80 ms bundling period: - Equivalence achieved when maximum differential delay is 10 ms - Corresponds to cell size of 1500 km - Timing constraint: X+Y ≤ 68 ms For 160 ms bundling period: - Similar analysis with corresponding conditions Proposal: Remove previous text in permanent document and replace with clarified conditions. Discussion PointsWording and calculation concerns (Ruonan): - Confusion about maximum differential delay (10 ms) calculation - Questioned applicability to GEO satellite coverage - Whether restriction on X+Y necessary for different cell sizes and bundling times - Concern about taking assumption as baseline - Value may need evaluation by other groups (e.g., RAN1) Liangping's responses: - 10 ms refers to roundtrip maximum differential delay, not baseline - Calculation based on cell size and elevation angle - Document doesn't define maximum differential delay, provides equivalence conditions - Cell size for 10 ms roundtrip delay is 1500 km (calculated using speed of light and worst-case elevation angle) - Open to removing baseline assumption if problematic - Need baseline when running simulations Practical impact (Stefan): - Asked about practical impact of changing from 10.3 ms to 10 ms - Difference seemed minor regarding cell size and coverage - Wanted to understand point of contribution Liangping's response: - Difference in cell size very small (proportional to differential delay) - Main purpose: identify condition where two timing diagrams are equivalent - Affects available resource for uplink scheduling Further concerns (Ruonan): - Continued questioning necessity and clarity of wording - Possible misunderstanding - Offered to provide revised version based on their understanding Process discussion: - Tomas: group would wait for proposals and updates - Liangping: suggested starting with email discussion to resolve issues - Offline meeting only if necessary to avoid inconvenience DecisionS4aA260007 noted - Further discussion needed on wording and assumptions. Group to proceed with email discussion and potential offline work before reconsidering. Meeting AdministrationMeetings held: - January 15, 2026, 14:00-15:09 CET (38 participants) - January 19, 2026, 14:00-14:53 CET (35 participants) Chair: Tomas Toftgård (Ericsson) Notes: Thomas Stockhammer (with assistance of co-pilot) Acknowledgment: Thomas Stockhammer thanked for assistance with meeting notes. All participants reminded of IPR policies, antitrust/competition law compliance, and consensus principles. |
Extracted ProposalsThis document does not contain any explicit proposals. The document is a meeting report from the Audio SWG Ad-Hoc meetings on FS_ULBC held on January 15 & 19, 2026. While the document discusses several contributions (S4aA260003, S4aA260004, S4aA260005, S4aA260006, and S4aA260007) that contained proposals, the report itself only records the decisions on these documents (noted or agreed) and does not explicitly list the proposals in the standard format (e.g., "Proposal X:", "Proposal:", etc.). The proposals would be contained within the referenced source documents (S4aA260003, S4aA260005, S4aA260006, and S4aA260007), but they are not explicitly extracted and listed in this meeting report. |
No comments |
| (pdf) | RTC SWG report post SA4#134 | RTC SWG Chair (Nokia) |
RTC SWG Report Post SA4#134Executive SummaryThe RTC SWG held two adhoc calls post SA4#134 with 15 input contributions and 24 participants in the first adhoc, and 10 input contributions and 30 attendees in the second adhoc. Two tdocs were agreed. Key Outcomes by Work Item:
AIML_IMS_MED (Media Aspects for AI/ML in IMS Services)Scope Definition and ArchitectureS4aR250216 - Scope in Light of SA2 LS The group discussed the scope following the SA2 liaison response. Key decisions:
Call FlowsS4aR260004/S4aR260014 - Call Flow for Device Inferencing Joint contribution from Samsung and InterDigital. After extensive discussion:
Key discussion points: - Model sizes can be significant (e.g., 80 MB), requiring consideration of download time and network impact - Application metadata would indicate supported tasks; JavaScript in application can check UE capabilities - MF acts as HTTP proxy and can cache - Need for both UE-side and network-side caching solutions - Partial model updates and model compression need to be addressed S4aR250205 - Call Flow for Device Inferencing (Samsung) Initial proposal that was merged into S4aR260004. Noted for further work. S4aR260007 - Call Flow for Device Inferencing Update (InterDigital) Discussion focused on: - Clarification needed on whether this replaces normal BDC bootstrap procedures - Terminology should be moderated to clarify high-level stage 2 description - Protocol details need refinement S4aR250206 - Call Flow for Network Inferencing Noted. Needs update to reflect inferencing on DC AS instead of MF. Questions raised about model download source (DCAR vs DC AS). S4aR250207/S4aR260008 - Call Flow for Split Inferencing Noted. Similar to network inferencing but for split scenarios. Needs update to have split inferencing on DC AS rather than MF. Parameters in request/response messages need synchronization with other proposals. S4aR250218 - Update Call Flow for Local/Remote/Split AIML Inferencing (InterDigital) Noted. Needs update due to MF/DC AS changes. Proposed two data channels: one for configuration and one for data exchange. Terminology modifications needed for steps 1 and 3. Task and Model ManagementS4aR250208 - On AI Application Tasks and Subtasks Noted. Discussion on whether to use subtask concept or stay with application/task/model terminology. Clarity needed on subtask definition before adoption. S4aR250209/S4aR260006 - AI/ML Media Processing and Task Updating (Nokia) Noted. Addresses task reselection and task update scenarios: - Task update vs. new task may require different procedures - Distinction between updating a model vs. adding new capabilities (e.g., translation language) - In P2P case, may need application data channel - Clarification needed on whether "network functions" refers to MF or other entities S4aR250211 - Adaptive Model Delivery (Nokia) Noted. Proposes two cases: 1. Standard model delivery 2. Adaptive delivery with MF as proxy Discussion points: - Need clarification on model selection process (UE, user, or other entity) - Low precision and incremental model updates need more description - Make model update optional in second case Application Manifest and NegotiationS4aR250213/S4aR260011 - On Application Manifest for AIML Applications (Nokia) Noted. Proposes JSON format for application manifest with metadata. Needs alignment with other contributions. Email discussion to be triggered on this topic. S4aR260009/S4aR260012 - Negotiation Messages (InterDigital) Noted. Proposes metadata for negotiation messages. Questions raised: - Where will application info format be used? - Are we defining a new DC protocol? - Motivation is to identify what metadata needs to be considered S4aR260010 - Negotiation Messages for Split Inferencing Noted. Needs revision to sync with basic call flows. Codec and CompressionS4aR260005 - On NNC Decoding in Web Environment (Fraunhofer HHI, Nokia) Noted. Discussion on Neural Network Coding (NNC) decoder in web environment. No alternative decoder currently available. Comparison document to be shared on differences. Specification StrategyS4aR250215 - Discussion on TS Agreed to add an annex to TS 26.114 and prepare CR accordingly. Consensus for smaller scope with annex in 26.114 rather than separate specification. S4aR250217/S4aR250220 - Draft CR on AIML Processing in IMS Calls Noted. Will be developed as CR to TS 26.114 based on agreed scope. FS_DCTC_eQOS_MED (Study on Usage of Dynamically Changing Traffic Characteristics and Enhanced QoS Support)Technical ReportS4aR250212 - Draft TR 26.823 Noted. Presented for information. Issues identified: - No revision marks and incorrect version number - Missing agreed document numbers in change history - Style conformance issues - Skeleton was only agreed in closing plenary Expected revision for next adhoc with: - Change marks - ETSI style compliance - Agreed documents listed in annex - Correct version number Evaluation StrategyS4aR250219 - Evaluation Testing Strategy Proposal (InterDigital) Noted. Discussion points: - Network impairment testing vs. in-the-field testing needs more work - No need to limit to one evaluation platform - RTT measurement possible also for QUIC - Need details on "specific" platform and parameter sources - Which specific application for AI testing - Hard to set up OPs for OTT; need reference platform with control - Joint meeting with other evaluation/studies to develop common evaluation framework - Reference to 26.955 for joint discussion - QoE metrics handling needs resolution FS_Q4RTC_MED (Study on QUIC for RTC Media)Work PlanS4aR250210/S4aR250221 - Draft Work Plan for FS_Q4RTC_MED Agreed (S4aR250221). Discussion points: - Note on normative work to be triggered before end of study - Evaluation work needs alignment with other studies - Need clear item in timeplan on common evaluation framework - Coordination with QStream starting from Goa meeting - Careful on "common" aspects as different tools may be needed Protocol OverviewS4aR260001/S4aR260013 - Overview of QUIC-based Media Delivery Protocols (Nokia) Noted (S4aR260013). Good base document. Comments to be provided by email on requirements and other aspects. Technical Report SkeletonS4aR260003 - Draft TR 26.836 v0.0.1 (Skeleton) (NTT, Nokia) Noted. Issues identified: - Clause 4.2.3 number missing - Some existing content can be moved to annex - Pros and cons need clarification (for RTC or general?) - Introduction/title of 5.3: F→Functional - Consider including evaluation under each application scenario - Version number needs offline check with Andrijana Meeting DetailsFirst Adhoc Call: - Date: December 17, 2025, 14:00-16:21 CET - Host: Nokia - 15 input contributions, 24 participants Second Adhoc Call:
- Date: January 28, 2026, 15:00-17:15 CET Minutes taken by Gaëlle Martin-Cocher (first adhoc) and Bo Burman/Shane He (second adhoc). |
Technical Proposals Extracted from DocumentThis document does not contain any explicit technical proposals marked with the standard proposal formats ("Proposal X:", "Proposal X.", "Proposal:", "Proposal.", or "Proposal The document is a meeting report (RTC SWG report post SA4#134) that contains discussions, decisions, agreements, and notes on various technical contributions, but no formally marked proposals in the specified formats. |
No comments |
| (pdf) | Report of the SA4-e (AH) MBS SWG post 134 (Dec 18 and Jan 29) | MBS SWG Chair |
3GPP SA4 MBS SWG Post-134 Ad Hoc Meeting ReportMeeting OverviewTwo ad hoc sessions were held: - Session 1: December 18, 2025, 15:30-17:38 CET (28 participants) - Session 2: January 29, 2026, 15:30-17:35 CET (29 participants) The meetings focused primarily on the FS_Energy_Ph2_MED study (Media Energy Consumption Exposure and Evaluation Framework Phase 2), with additional discussions on Release 19 corrections, Advanced Media Delivery Phase 2, and a new QUIC-based streaming study. Release 19 and Earlier MattersMBSF Notification Event Corrections (S4aI260006)Contribution: BBC (Richard Bradbury) Technical Content: - Corrects discrepancies between SA4 stage 2 specification (TS 26.502) and CT3 stage 3 specification found during reference implementation - Adds two missing events to align with CT3: - "User data ingest session starting" (indicates start of active period) - "User data delivery has started" (confirms broadcast MBS session start) - Simplifies table by factoring out repetitive information - Corrects sequence diagram to ensure correct identifier is passed back - Editorial fixes for clarity Impact: Corrective changes only; aligns SA4 spec with CT3 with no impact on CT3 work. Similar corrections planned for Releases 18 and 19. Decision: Agreed FS_Energy_Ph2_MED (Study on Media Energy Consumption Exposure and Evaluation Framework Phase 2)Energy-Related Information for Media Application Services (S4aI250198)Contribution: BBC (Richard Bradbury) Technical Content: Key Gaps Identified: - Current EIF (Energy Information Function) from Release 19 only covers user plane network functions (gNB, UPF) - Does not cover energy consumed by Application Servers (AS) or User Equipment (UE) - AS are not network functions and do not provide energy information to EIF Proposed Abstract Data Model: - Hierarchical model for 5G media streaming allowing energy apportionment at multiple levels: - Application server instance - Content hosting configuration - Distribution configuration - Streaming session - Service data flow - Generic energy report structure with baseline parameters: - Timestamps - Energy consumed (joules) - CO2 emissions per joule - Data volumes (uplink/downlink) - Session IDs - Endpoints - Extensible for specific use cases Recommendations: 1. Update TR to clarify EIF scope (Proposal 1 & 2: Agreed) 2. Require candidate solutions to include procedures and parameters for collecting/aggregating energy data from AS, NFs, and UEs (Proposals 3, 4, 5: Endorsed in principle) - Not gating for existing solutions - Template/examples to be developed with Julien - CRs to be prepared for next meeting Discussion Highlights: - Franck questioned use of data volume vs. direct energy reporting; Richard explained flexibility for different architectural solutions - Prakash questioned value of AS energy exposure; Richard affirmed importance given gap in Release 19 - Rufael emphasized factual accuracy when referencing TS 23.501 and avoiding overlap with other groups - Thomas noted TR should not self-reference; context to be clarified in CR Decision: Agreed (with follow-up CRs expected) Solution for KI5: Media Application Server Energy Management (S4aI250199)Contribution: Orange, BBC (Julien Lemotheux, Richard Bradbury) Technical Content: - Candidate solution for 5GMS focusing on selection of media streaming service location driven by content steering server based on energy characteristics - Added new procedures for solution #5 in clause 7.6 - Missing steps for streaming session management now included and renumbered - Improved text and procedures based on feedback Minor Corrections Identified: - Remove "downlink" from Step 5 in diagram 7.6.3.2 to make procedure generic - Typo in 7.12.2 to be addressed Decision: Revised to S4aI250208; Endorsed (with minor corrections to be incorporated before merging into Mega CR) Solution for KI6: Client-Driven Management (S4aI250200)Contribution: Orange (Julien Lemotheux) Technical Content: - Candidate solution for Key Issue 6: client-driven management of media delivery service energy optimization - Title updated to "Client Driven Selection of Media Entry Point in the Generalized Media Delivery System Based on Energy Characteristics" - Replaced terms like "SIM variant" and "delivery pass" with "media entry point" - Allows client to reconfigure media handler during session to select different entry point based on energy characteristics - Playback resumes from previous position (similar to Netflix/Amazon session resumption) Discussion Highlights: - Richard noted switching entry points mid-session is disruptive (black screen/spinner) and needs better description - Shilin questioned step numbering discontinuity and why media entry points passed to media-aware application rather than directly to media stream handler - Julien explained application needs entry point information to make selection Decision: Revised to S4aI250210; Noted (further clarification needed) Updating Key Issue Description on Application Service Provider Provisioning (S4aI250202)Contribution: Samsung (Prakash Kolan) Technical Content: - Addresses three SA1 use cases related to energy provisioning: 1. Dynamic service adjustment based on network energy information 2. Service adjustments based on energy configuration 3. Tolerance to QoS degradation - Proposes adding table summarizing different way forward options for these use cases into TR - Provides reference points for candidate solutions to map to specific options Discussion Highlights: - Richard noted contradiction in requirement 5.3 "tolerance to QoS degradation" - content suggests optimizing without degrading QoS - Julien suggested simplifying/merging options (e.g., option 2 with option 1; options 3 and 4) - Prakash agreed to work on simplification Decision: Endorsed as basis for future work (with simplification to be addressed in revision) Greening of Streaming Collaboration (S4aI250203)Contribution: Qualcomm (Thomas Stockhammer) Technical Content: - Update on interactions with Green Streaming (GSS) organization - GSS focus: streaming app energy measurement and CDN (complementary to 3GPP telco aspects) - GSS ongoing projects: - Remote energy measurement platform - Yang data model for energy - White papers - Proposal: Joint online webinar (90-120 minutes) on energy awareness in mobile streaming - Involve 3GPP, GSS, and other organizations - Schedule before next 3GPP meeting - Goal: information exchange and awareness raising Discussion Highlights: - Julien noted timing challenge as study aims to finish in Goa - Rufael welcomed industry input for documentation in TR - Richard interested in Yang data model - Gaëlle noted first meeting useful for mutual understanding even if not immediately impacting TR Decision: Noted; Thomas to discuss with 5G-MAG and sync with rapporteur Solution for KI1 and KI4: Energy-Related Information Collection (S4aI250204, S4aI250207)Contribution: InterDigital (Franck Aumont) Status: Not presented due to time constraints Decision: Noted without presentation; to be resubmitted Solution for KI5: Media Application Server Energy Management (S4aI250206)Contribution: Nokia (Daniel Venmani) Technical Content: - Candidate solution for relocating media application servers based on energy consumption at different service locations - Procedure: 1. Launch media session 2. Collect QoE measurements from UE 3. Energy Information AF requests energy consumption reports from media AS for each service location 4. AF ranks service locations by energy consumption 5. AF informs UE to enable selection of most energy-efficient location - Main technical focus: enabling AS to report energy consumption per service location (current gap in SA4) Discussion Highlights: - Richard questioned necessity of steps 9, 18, and 23 in call flow; suggested removal - Richard noted expanding EIF to include AS information is outside SA4 remit (SA2 responsibility) - Rufael emphasized AS energy reporting should be handled by EIAF within SA4, not by expanding EIF scope - Prakash and Julien noted similarity to Julien's solution; suggested merging and highlighting differences - Main difference: use of QMC and source of information Decision: Revised to S4aI250209; Noted (not endorsed due to outstanding comments; further work needed) Update Summary of Energy Information Function (S4aI260009)Contribution: BBC, Orange (Richard Bradbury) Technical Content: - Expanded summary of EIF based on latest Release 19 developments from SA2 - Incorporated corrections from Rufael (Huawei): - Terminology aligned with TS 23.501 ("energy consumption information" not "energy related information") - EIF obtains energy data from OM and computes values per PDU session using SMS information - Describes what SA2 studied and specified in TS 23.501: - EIF role in collecting, calculating, and exposing energy consumption data at various granularities - Added stage 3 specification details (TS 29.566, TS 29.122): - Structure of energy notifications and reports - Timestamps and optional energy info data (joules consumed during reporting period) Discussion Highlights: - Rufael emphasized importance of consistency with SA2 outcomes - Franck raised concern about information granularity difference: - 5GC NF can request per QoS flow data - Media AF cannot get per QoS flow data (potential loss of granularity at data flow level) - Richard clarified text comes from baseline TR 26.942 Release 19; if discrepancy exists, separate CR needed Decision: Agreed (to be added to merged common CR) Principles for Documenting Candidate Solutions (S4aI260010)Contribution: BBC, Orange (Richard Bradbury, Julien Lemotheux - Rapporteur) Technical Content: - Guidelines for documenting candidate solutions as annex to TR - Standardizes structure inspired by previous studies (e.g., TR 26.804 for AMD) - Proposed skeleton includes: - Mapping to key issues - Functional description - Collaboration scenarios (referencing annexes in TS 26.501/26.506) - Architecture mapping - Energy-related information (baseline parameters) - Procedures (including sequence diagrams) - Gap analysis (deltas from current specs) - Proposed normative changes - Summary Clarifications: - Template applies to new candidate solutions added during phase 2, not existing solutions from phase 1 - Goal: help extract normative work and analysis for conclusion section - Not intended to modify existing solutions already in TR Discussion Highlights: - Thomas questioned purpose if not applied to existing solutions; concerned about methodology for evaluation - Julien explained template facilitates aggregation and analysis for new contributions - Richard noted both key issue-centric and solution-centric approaches valid; selection for normative work addressed later Decision: Agreed Media Application Service Model (S4aI260012)Contribution: BBC (Richard Bradbury) Technical Content: - Conceptual model to clarify what constitutes media application service - Hierarchical structure: - Media delivery session consists of service data flows - Service data flows consist of application data flows - Examples: segmented media delivery, RTC sessions - Accounts for deployment dynamics: - Peer-to-peer sessions - Multiple service location endpoints - Endpoints on different physical/virtual servers (including edge) - Network considerations: - Traffic routing depends on UE route selection policy - Multiple PDU sessions, network slices, access networks - UE mobility and edge computing - Energy implications: - Energy consumption changes dynamically due to these factors - EIF does not provide complete picture (lacks AS and UE energy visibility) - Mapping to 5GMS and RTC models detailed Discussion Highlights: - Thomas concerned about introducing many new capitalized terms and abstract definitions - Potential complexity and divergence from existing 5GMS architecture - Questioned if new concepts require updates to TS 26.501/26.506 - Nervous about implications for future normative work - Richard clarified: - Conceptual framework for informational purposes only - Not new data model or intended for normative work - Most terms already in existing specifications - Generic model, not specific to 5GMS or RTC - Iraj questioned if model covers entire 5GMS operation or just energy consumption - Richard: conceptual overview for user plane operations, arranging existing concepts - Prakash supported inclusion; most terminology already referenced in SA2/SA4 specs - Julien: model important for structuring report and clarifying granularity levels Resolution: - Thomas requested clear scoping to TR only, not basis for normative changes in existing specs - Introductory text explaining rationale and scope to be added - Richard agreed to add clarifying text Decision: Endorsed (with clarifications to be added in revision) Solution 5 Update (S4aI260016)Contribution: Orange, BBC (Julien Lemotheux, Richard Bradbury) Technical Content: - Updates to candidate solution 5 defining Energy Information Collector and Energy Information Application Function - Goal: establish baseline procedures for energy information reporting reusable by other candidate solutions - Key changes: - Clarified subscription and reporting process with EIF - Information requests now require subscription detailing needed data (service data notification, application ID) - Standardized process: after subscription, EIF exposes energy report to requesting component - Same principle applies to reports from Energy Information AF and Energy Information Collector - Initial reporting step introduced: - Configure and receive first report before media session starts - Ongoing reporting during media streaming session - Updates as more detailed information (e.g., IP 5-tuple) becomes available - Aligned with new template for candidate solutions: - Includes gap analysis section - Includes proposed normative changes section - Special numbering to avoid disrupting references in other TR parts Discussion Highlights: - Richard: Steps 18 and 19 should be inside loop - Richard: Step 7 should happen as result of media session, not provision (steps 7-9 need to move up) - Daniel questioned motivation for EIAF to choose client and for client to move between AS - Julien acknowledged missing information Decision: Revised to S4aI260027, then S4aI260028; Noted (further revision needed) Other Energy Phase 2 SolutionsMultiple additional candidate solutions were submitted but noted without presentation due to time constraints:
All to be resubmitted for SA4#135 in Goa. FS_AMD_Ph2 (Study on Advanced Media Delivery Phase 2)Network Assistance for Multi-Access Media Delivery (S4aI250201)Contribution: Samsung, Nokia (Prakash Kolan) Decision: Noted without presentation; to be resubmitted 5G System-Independent Media Streaming (S4aI250205)Contribution: Qualcomm (Thomas Stockhammer) Decision: Noted without presentation; to be resubmitted CMMF for Media Delivery over Multiple Access Networks (S4aI260020)Contribution: Dolby (Jason Cloud) Technical Content: - Discussion paper on using CMMF (Common Media Format) for multi-access media delivery within 5G system - Application-layer based approach - Implementation: - Multi-access capability in media player's access client - Multiple HTTP clients initialized, each bound to different network interface - Enables concurrent downloads from various access networks - Example: client connected to both Wi-Fi and 5G can toggle interfaces or handle network degradation - Integration with 5G system: - Mirrors multi-service location use case - Minimal architecture changes required - Mainly notes in call flows and potential client setup details in stage 3 Discussion Highlights: - Richard questioned feasibility on 3GPP UE (application awareness of ATSSS, interface abstraction) - Prakash clarified: - For ATSSS transparent mode, Richard's concern valid - Non-transparent mode: application aware of delivery - Application multipath supported in spec - Jason confirmed Android clients expose interfaces to application, allowing binding - Thomas expressed confusion: - Application would not see two HTTP clients or access networks as described - Functionality handled under the hood, outside 5G media streaming scope - Changes should be addressed in IETF protocols - Does not align with Release 20 multi-access discussions - Very different from ATSSS - Richard suggested issue might be implementation detail rather than specification concern Decision: Noted for now Other Release 20 MattersWork Plan for QUIC-Based Protocols Study (S4aI260024)Contribution: Xiaomi (Emmanouil Potetsianakis) Technical Content: - Work plan for FS_QStream_MED study - Focus: segmented media delivery for on-demand and live video services - Objectives: 1. Identify relevant applications, protocols, and technologies 2. Develop evaluation framework 3. Conduct evaluations 4. Integrate findings 5. Coordinate with other groups - Output documents: - TR 26.934: Test platform for media delivery technologies (joint with QUIC study of RTC) - TR 26.835: Evaluation of QUIC-based streaming protocols - Timeline: - Goa meeting: Finalize work plan and specification skeletons - Early phase: Application selection, metrics definition - Subsequent meetings: Test framework design, technology definition - Later stages: Simulation setup, platform development, communication with external groups, result analysis Discussion Highlights: - Thomas requested descriptions for each objective for easier reading - Thomas questioned why simulation setup/platform development not starting earlier (Goa) - Core issue should be coordinated with other study items - Should begin sooner than April - Emmanouil clarified: - Test platform TR and theoretical study of framework start in Goa - Actual implementations begin after Goa, aiming for tangible results by April - Coordination with RTC group expected for relevant objectives - Gaëlle asked for clarification on phases of objective 4 - Emmanouil explained: - Phase 1: Framework setup for segmented media - Phase 2: Define relevant network scenarios - Phase 3: Run experiments and evaluations - Split due to joint framework with RTC for different applications Decision: Agreed as baseline (comments to be incorporated for SA4#135 submission) Administrative MattersLiaison Statement ResponseSpecial powers granted to MBS SWG to send reply LS to S4-251660 were not exercised. Document System
Timeline ConcernsValerie (InterDigital) raised concerns about timeline for energy feasibility study: - Importance of structuring candidate solutions - Ensuring all proponents have fair chance for adoption in TR - Suggested further discussion with Julien offline Future SessionsJulien suggested organizing offline meeting approximately one week before next scheduled meeting to process and discuss contributions, given large number of documents. Meeting StatisticsSession 1 (Dec 18, 2025): - Duration: 2h 21m 45s - Participants: 28 - Average attendance: 1h 49m 9s Session 2 (Jan 29, 2026): - Duration: 2h 53m 54s - Participants: 29 - Average attendance: 1h 40m 14s Summary of DecisionsAgreed:
Endorsed:
Noted (requiring further work):
Noted without presentation:
|
Proposals Extracted from Document S4-260163Proposal 1: Agree to update clause 4.2.2.3 of TR 26.942 to reflect the latest status of Release 19 specifications regarding the Energy Information Function. Proposal 2: Agree to add a new clause 4.2.2.6 to TR 26.942 summarizing the energy consumption metric exposed by the Energy Information Function. Proposal 3: Agree that candidate solutions should describe the energy-related information transmitted between functions, including baseline parameters such as timestamps, energy consumed, CO2 emissions per joule, data volumes, session identifiers, and endpoints. Proposal 4: Agree that candidate solutions should specify what algorithms or calculations are applied to energy-related information at each function. Proposal 5: Agree that candidate solutions should describe how energy consumption is apportioned across different levels of the media application service hierarchy (e.g., application server instance, content hosting configuration, distribution configuration, streaming session, service data flow). |
No comments |
| (pdf) | Report from Audio SWG teleconference on DaCAS (9 December 2025) | SA4 Audio SWG Vice-Chair |
Report from Audio SWG Teleconference on DaCAS (9 December 2025)Meeting OverviewThe Audio SWG held a teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) with 19 participants for 1 hour. Three input documents were discussed, all focused on defining the evaluation approach, specification methodology, and deliverables for DaCAS example solutions. Main Technical ContributionsS4aA250140: Evaluation Approach for DaCAS Example Solutions (Nokia, Fraunhofer IIS)Key Proposals: - Self-evaluation approach for example solutions rather than cross-evaluation - High-level documentation guidelines for proponents - Informal assessment against requirements in TS 26.261 - Updated work plan with two timeline options depending on evaluation procedure chosen Timeline Proposals: - Table 1: Faster timeline with self-evaluation only - Table 2: Extended timeline including cross-evaluation - Key milestones: submission of example solutions in Montreal, specification work following Discussion Points: - Mixed support: some agreement on self-evaluation concept, but reservations about completely skipping cross-evaluation - Questions on deliverable package definition (executable vs source code) - Concerns about timeline dependencies on deliverable agreements - Clarification needed on what "informal evaluation" means in practice - Need to distinguish between demonstrating feasibility vs determining suitability of solutions Outcome: Document noted; offline discussions encouraged to provide potential revision S4aA250141: Specification of Suitable DaCAS Example Solutions (Nokia)Key Proposals: - Two-tier approach for example solutions: - All evaluations and documentation included in informative Annex of TS 26.533 - Example solutions additionally meeting requirements from TS 26.261 specified in TS 26.533 (status TBD) Documentation Requirements: - Algorithmic description with sufficient detail for implementation - Optional elements: - Adaptation considerations for commercial devices - Support for IVAS PI (Parametric Information) data - Integration with commercial processing pipelines - Device limitations and generalization capabilities Discussion Points: - Questions on required detail level: pseudocode vs source code - Clarification that last three bullets are optional/invitational - Relationship to ATIAS Phase 3 work - Distinction between two categories: 1. Feasible example solutions (demonstration via self-evaluation) 2. Endorsed solutions meeting TS 26.261 requirements (requiring testing) - Suggestion to share draft updates via SA4 reflector for broader input Outcome: Document noted; revision expected with broader consultation S4aA250142: Example Solution Deliverables (Bytedance, Xiaomi)Key Proposals for Deliverable Package: For Neural Network-based Solutions: - Code package including: - Training code - Inference code - Model checkpoints - Rationale: enable retraining for different devices beyond target device For DSP-based Solutions: - Algorithmic description allowing reimplementation General Requirements: - Legal framework submission (depending on solution specifics) - Sufficient details to convert raw microphone recordings to IVAS formats Discussion Points: - Strong concerns about mandating training code and checkpoints: - Risk of providing false impression of quality transferability - Training typically tailored to specific devices - Cannot guarantee similar quality on different devices - May be unnecessary if solution generalizes without retraining - Distinction between providing model (equivalent to DSP description) vs full training pipeline - Legal framework requirements too general and need clarification - Fundamental difference in reproducibility between DSP descriptions (anyone can reimplement) and NN solutions Outcome: Document noted; significant concerns raised about mandatory training code requirements Cross-Cutting Issues and Open QuestionsEvaluation Methodology
Deliverables Definition
Specification Approach
Timeline Dependencies
Next Steps
|
Technical ProposalsThis document does not contain any technical proposals. The document is a meeting report from an Audio SWG teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) held on December 9, 2025. The document discusses three input Tdocs (S4aA250140, S4aA250141, and S4aA250142) that were noted during the meeting, but none of these contain explicitly marked proposals in the format "Proposal X:" or "Proposal:" or similar variations. The document describes what was proposed in these inputs, but these are not formatted as formal proposals in the document itself. |
No comments |
| (pdf) | Report from Audio SWG teleconference on DaCAS (13 January 2026) | SA4 Audio SWG Vice-Chair |
Report from Audio SWG Teleconference on DaCAS (13 January 2026)Meeting OverviewThe Audio SWG teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) was held on 13 January 2026 with 20 participants for 1 hour. The meeting processed two input documents and produced two agreed output documents with revisions to be implemented in DaCAS-2 and DaCAS-3. DaCAS Example Solution Evaluation Procedures (S4aA260001 → S4aA260008)Contributors: Nokia, Fraunhofer IIS, Dolby Laboratories Main Technical ContributionsThis contribution established the framework for evaluating DaCAS example solutions through a combined approach: Evaluation Methodology
Key Discussion Points and ResolutionsCross-Evaluation Flexibility: - Cross-evaluation labs have freedom to conduct evaluation based on already provided signals or process evaluation signals with submitted solutions - The approach depends on available effort and resources at the cross-evaluation laboratory Dataset Requirements: - Mandatory minimum evaluation dataset to be defined - Cross-evaluation limited to datasets that solution proponents have provided - Proponents must process recordings from the evaluation database - Cross-evaluation labs may use mandatory dataset and potentially additional signals Clarifications Added: - Editor's note added to Clause 2.1 regarding cross-evaluation procedures - Clarification that recordings shared in the database should be used for processing with example solutions - Any company (proponent) can conduct cross-evaluation if desired Agreement StatusThe revised document (S4aA260008) was agreed with changes in brackets to be implemented in DaCAS-2. DaCAS Example Solution Deliverables (S4aA260002 → S4aA260009)Contributors: Bytedance, Beijing Xiaomi Mobile Software Main Technical ContributionsThis contribution defined the package and deliverables required for DaCAS example solutions. Deliverable Components1. Target Device Information: - List of supported target devices (revised from "target device to provide") - Device specifications and characteristics 2. Dataset Description: - Clarification that this refers to recordings used to develop example solutions - Discussion on whether to include external data used for development - Distinction between: - Common database for algorithmic development (transparent, shared data) - External data (e.g., for neural network training) - Geometric/analytical data (part of algorithmic description) 3. Algorithmic Description: - High-level description of solution development approach - Differentiation between signal processing and neural network solutions - For signal processing: description of methods (e.g., FEM method, upmix matrices) - For neural networks: indication of training data usage Key Discussion Points and ResolutionsExternal Data Usage: - Proponents allowed to use external data (e.g., for neural network development) - Current common database amount may be insufficient for neural network training - No prohibition on external data, but transparency required - Common database serves as baseline, not as closed/exclusive dataset Unified Deliverables: - Suggestion to combine deliverables for signal processing and neural network solutions - Recognition that solutions may combine both approaches - Need for unified set of deliverables across solution types Documentation Requirements: - Code package contents to be specified - Similar to table format used for dataset descriptions - High-level description of how solution was developed - Reference to potential datasets used Outstanding Items: - Bullet 2 (dataset description) placed in brackets for further discussion - Need to combine and unify deliverable descriptions - Editor notes inserted for future clarification Agreement StatusThe revised document (S4aA260009) was agreed with changes in brackets to be implemented in DaCAS-3. Administrative MattersIPR and ComplianceStandard 3GPP reminders provided regarding: - IPR disclosure obligations - Antitrust and competition law compliance - Consensus-based decision making Next Steps
Participation20 participants from organizations including: Bytedance, Dolby, Ericsson, Fraunhofer IIS, Nokia, NTT, Orange, Panasonic, Qualcomm, Philips, and Xiaomi. |
Technical ProposalsThis document does not contain any technical proposals. The document is a meeting report from an Audio SWG teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) held on 13 January 2026. While it discusses various technical aspects and documents that were agreed upon, there are no sections explicitly marked as "Proposal" in any of the standard formats. |
No comments |