SA#110 Brief Report on SA4 Topics

General Information

Meeting Details: - SA#110 took place 9-12 December 2025, hosted by ATIS in Baltimore, US - SA4 Chair: Gilles Teniou (Tencent/CCSA) - Report presented at SA4#135 in Goa, India (9-13 February 2026)

Overall Outcome Summary

The SA4 report to SA#110 was noted. Key approvals included: - All SA4 CRs (Rel-12, Rel-17, Rel-18, Rel-19) were approved - Draft TS 26.251 V2.0.0 (IVAS_Codec_Ph2) was approved - IVAS verification test lab reports were approved - SA4 chair input on WG Terms of Reference was sent back to SA4 for further discussion

Key Plenary Discussion Points

Workload Concerns: - Verizon raised concerns about SA4's capacity given the large number of proposed TRs, citing slow progress on FS_ULBC - SA4 Chair clarified that slow progress was due to dependencies and related issues, not workload - TSG SA Chair requested companies to prepare contributions on workload issues rather than raising them in the Chair report

ToR and AI Work: - MediaTek commented on the postponed SA4 ToR and emphasized the need to progress AI-related studies - TSG SA Chair indicated that SA4 ToR requires consensus within SA4 before TSG SA approval

6G Planning: - TSG SA Chair requested information on 6G planning for the next TSG SA meeting

IVAS Verification Reports

All test lab reports for IVAS Characterization Phase were approved: - MESAQIN.com Listening Lab Report (SP-251447) - FORCE Technology Listening Lab Report (SP-251448) - Global analysis lab report

New Release 20 Work Items

Work Item (WID)

Terminal Audio Quality Performance and Test Methods (SP-251352) - Status: Approved

Study Items (SIDs)

1. Study on Evaluation of QUIC-based Protocols for On-demand and Live Video Services (FS_QStream-MED) - SP-251353 - Status: Approved (revised to SP-251659) - Allocated TR numbers: TR 26.835 and TR 26.934

2. IMS Data Channel Enhancements (SP-251354) - Status: Approved (revised to SP-251660) - Allocated TR number: TR 26.814

3. QUIC-based Media Delivery for Real-time Communication (FS_Q4RTC-MED) - SP-251355 - Status: Approved (revised to SP-251661) - Allocated TR number: TR 26.836 - Clarification: Focused on 5G but will consider new aspects introduced by 6G

4. Study on Image Formats (SP-251356) - Status: Approved (revised to SP-251662) - Allocated TR number: TR 26.892

5. Study on Avatar Communication Phase 2 (SP-251357) - Status: Approved (revised to SP-251663) - Revision: Removed repeated supporting company

6. Study on Media Aspects for 6G System (SP-251620) - Status: Approved (revised to SP-251652) - Allocated TR number: TR 26.870 - Rapporteurs: - Primary: Thomas Stockhammer (Qualcomm) - coordination of the study - Secondary: Elmira Ramazanirend (Vodafone) - Draft TR edition - Key Revisions: - AN and Others impacts changed to "Don't Know" - SA5 included for charging and management impacts - SA1 included in objective 6 for service requirements - Additional supporting companies added - Non-3GPP member removed

Specifications for Approval

Draft TS 26.251 v2.0.0 - IVAS Codec Phase 2 (SP-251444) - Status: Approved (Rel-19) - Contains fixed-point C code of the IVAS codec as electronic attachment (IVAS Software Version 3.0) - Provides full and bit-exact EVS codec functionality for mono speech/audio signal input - Optimized for encoding/decoding of stereo and immersive audio formats including: - Multi-channel audio (5.1, 5.1.2, 5.1.4, 7.1, 7.1.4) - Scene-based audio (Ambisonics up to order 3) - Metadata-assisted spatial audio (MASA) - Object-based audio (ISM up to 4 ISMs) - Combined formats: OSBA and OMASA - Supports rendering including binaural rendering for headphones with head-tracking

Change Requests

EVS_Codec CRs (SP-251429) - 8 CRs to TS 26.445 (Rel-12) - Status: Approved - Note: Huawei commented that CRs to old frozen releases should be discouraged and only accepted for real FASMO corrections - These CRs corrected references to other clauses

All other SA4 CRs: - All Rel-17, Rel-18, and Rel-19 CRs submitted for approval were approved as is - Admin CRs on TS 26.512 were approved

Liaison Statements

LS on External Resource Handling in IMS Data Channel

Incoming LS from GSMA NG UPG (SP-251301) - Status: Noted - SA4 Response (SP-251622, revised to SP-251693): Approved - Issue: Ambiguity in handling external resource access in IMS Data Channel applications - SA4 Position: - Acknowledged gaps in current TS 26.114 specification - Originally assumed DCSF and DC AS would be exclusive hosts for all content - Did not anticipate scenarios involving external resources - Plans to study this issue and provide clarifications as part of DC Enhancements (FS_DCE_MED) study in Release 20

LS on Traffic Model Study in RAN WG1

Incoming LS from RAN WG1 (SP-251304) - Status: Noted (SA in CC) - SA4 recognizes importance of defining traffic models reflecting realistic traffic characteristics - SA4 will provide input as work progresses for AI/ML Services and immersive communication services

Work Item Summaries

1. IVAS_Codec_Ph2 (SP-251375) - Source: vivo Mobile Communication Co., Ltd. (Rapporteur) - Status: Endorsed

2. Video Operating Points - Harmonization and Stereo MV-HEVC (VOPS) - SP-251503 - Source: Apple Switzerland AG - Status: Endorsed

AI Traffic Characteristics Discussion

Key Issue: - Several contributions (SP-251553, SP-251499, SP-251540, SP-251576, SP-251452) attempted to structure work on identifying AI/ML data traffic characteristics, proposing SA4 as lead WG - Concerns raised by some companies that SA4 should not be the exclusive WG for AI traffic characteristics - Tentative way forward proposed in SP-251625 but no consensus reached - Document was noted with no action to SA4

SA4 Chair Position: - Work in other WGs should not interfere with SA4's planned work on AI traffic characteristics in the context of media services - SA4 should proceed with its work, report progress to SA (and potentially RAN WGs), and let them decide applicability to other cases beyond media applications

Other Business

Study on 3GPP AI/ML Consistency Alignment (FS_AIML_CAL)

• Study completed
• Draft TR 22.850 approved (SP-251698)
• LS to be sent to WGs for information

Study on Modernization of Specification Format and Procedures for 6G

• Draft TR 21.802 presented for information
• Status: Noted (SP-251617)

Release 21 Timeline Discussion

Key Points: - Release 21 is the release for submission to IMT-2030 (6G) - 3GPP normative work will be submitted to ITU-R before 2030 - ASN.1/OpenAPI freeze date is no earlier than March 2029 - Previous decision: Rel-21 timeline to be decided no later than June 2026 - Some groups (SA1, RAN Plenary) will finish Rel-20 work before June 2026

Timeline Planning: - Joint session organized at TSG#111 (March 2026) for companies to share views on Rel-21 timeline - TSG Chairs will provide joint input paper outlining proposed Rel-21 timeline - Some Rel-21 dates (e.g., Stage-1 freeze) may be tentatively agreed at TSG#111 - Final approval of Rel-21 timeline targeted for TSG#112 (June 2026) - First Rel-21 SID proposed at SA#110 (from SA1)

Guidance and Actions to SA4

No particular guidance was provided to SA4.

Action: SA4 will report progress and plans related to AI traffic characteristics at the next SA plenary.

Reply LS on RAN Simulation Assumptions for ULBC

Document Information

• Source: RAN1
• Target: SA4
• CC: RAN4, RAN2, SA2, CT1
• Meeting: RAN1 #122 (Bengaluru, India, Aug 25-29, 2025)
• Response to: S4-251584
• Release: Rel-20
• Work Item: FS_ULBC

Overall Description

RAN1 provides responses to SA4's liaison statement S4-251584 regarding evaluation assumptions for ULBC (Uplink Broadcast) simulations.

Response to Question 1: Evaluation Assumptions Confirmation

RAN1 generally agrees with SA4's proposed evaluation parameters with the following clarifications and comments:

Modulation Order

• Observation: MCS indices 0 and 1 use π/2 BPSK for single tone transmissions
• Action for SA4: SA4 to decide whether to evaluate π/2 BPSK with MCS indices 0 and 1

Downlink CNR Parameter Correction

• Issue identified: The relevant UE parameter for downlink is noise figure (and/or G/T), not transmit power
• Recommended correction: "DL CNR=-3.3dB, 0dBi UE antenna gain, 15kHz SCS, 12 tones, 1 UE receive antenna, noise figure of 7dB"

40ms Bundling Support

• RAN1 specifications may support 40ms bundling by assuming 15kHz SCS (single and multi-tone) in the uplink
• Decision point: SA4 to decide whether to include this case in evaluations

SPS Frame Structure

• Status: RAN1/2 have not yet started work on designing SPS
• Implication: RAN1 cannot currently confirm whether the example frame structure for SPS (related to Figure 5.2.2.3-2 and associated text) will be supported

BLER Target

• RAN1 precedent: Previous RAN1 evaluations for voice have considered 2% BLER as the target performance metric
• Decision point: SA4 to decide what values to use in their evaluations

Power Classes

• To be confirmed by RAN4

Frame Structure Supportability (Figure 5.2.2.3-1)

• General support: The example is supportable by RAN1 specifications in most scenarios
• Exception: May not be supportable when:
• Cell is very large (e.g., >3000km)
• UE does not support TA report
• Network does not support UE-specific K-offset
• Requirements: The example requires:
• UE configured with two HARQ processes
• HARQ feedback disabled

Response to Question 2: RX G/T Value for NB-IoT with GEO

G/T Calculation Method

The parameter G/T is calculated as follows (per TR 38.821):

Formula: G/T = G_rx - 10log₁₀(T₀ + T_a) - NF + G_rx

Where: - G_rx = receive antenna gain - NF = noise figure - T₀ = ambient temperature - T_a = antenna temperature

Value Derivation for -31.6 dB/K

The value is obtained with: - G_rx = 0 dBi - NF = 7 dB - T₀ + T_a = 290K

Alternative Values and Consensus

• Lower values: Values smaller than -31.6 dB/K can be derived based on assumptions in TR 36.763 (e.g., NF=9dB)
• RAN1 recommendation: The value of -31.6 dB/K may be used by SA4 in their evaluations
• Higher values: Some companies in RAN1 consider that values higher than -31.6 dB/K can be supported in commercial implementations
• Consensus status: RAN1 could not reach consensus on these higher values

Action to SA4

RAN1 respectfully requests SA4 to take the above information into account.

Next RAN1 Meetings

• RAN1 #122-bis: Oct 13-17, 2025, Prague, CZ
• RAN1 #123: Nov 17-21, 2025, Dallas, US

Reply LS on Issues Related to Support of IMS Voice over NB-IoT NTN Connected to EPC

Document Information

• Source: RAN1
• To: SA2
• CC: RAN2, SA4, CT1, SA3, SA1
• Release: Release 20
• Work Item: FS_5GSAT_Ph4_ARC
• Meeting: RAN1 Meeting #122bis (Prague, CZ, 13-17 October 2025)
• Document Number: R1-2508096
• Response to: R1-2506707

Overall Description

This LS provides RAN1's response to SA2's question regarding the probability of consecutive packet losses in IMS voice over NB-IoT NTN scenarios.

SA2 Question Addressed

Question 2 (To RAN1): Can RAN1 provide any data regarding the probability that such number of consecutive packets (e.g., 16 or 64) can be lost or erroneously decompressed? How often such event can occur?

RAN1 Response

Scenario 1: Line-of-Sight Guaranteed

Under the following conditions: - Line-of-sight maintained for the duration of the call - No change in large scale parameters (e.g., fixed shadowing) - Using NTN TDL-C channel model (previously used by RAN1 and SA4 evaluations)

Finding: The probability of having 16 or 64 packets consecutively lost is negligible under typical operating conditions (e.g., up to 10% packet error rate).

Scenario 2: Line-of-Sight Not Guaranteed

When line-of-sight cannot be guaranteed for the duration of the call: - Intermittent blockage may occur in practice (e.g., according to the land mobile satellite channel model in TR 38.811) - In this case, the probability of having 16 or 64 packets consecutively lost may not be negligible

Note: RAN1 has not reached consensus on whether to consider this case.

Actions

ACTION: RAN1 asks SA2 to take the above information into account.

LS on Traffic Model for Immersive Communication

Document Information

• Source: RAN WG1
• Target: SA WG4
• Meeting: RAN1 #123 (Dallas, USA, November 17-21, 2025)
• Release: Rel-20
• Work Item: FS_6G_Radio

Overall Description

RAN1 has developed traffic models for immersive communications services based on 6G radio evaluations. The work builds upon the existing XR traffic model defined in TR 38.838, with amendments to support immersive communication use cases.

Technical Contributions

Model-1: eXR Model without Haptics

This model extends the existing XR traffic model from TR 38.838 with specific parameters for immersive gaming and UL-heavy video uploading scenarios.

Immersive Gaming Parameters (CG Traffic Model)

Frame Generation and Data Rate Updates (Table 5.4.1-1 amendments): - Data rate (R): Added values of 100, 300, and 500 Mbps for immersive gaming (baseline: 30, 8 Mbps; optional: 45 Mbps) - Frame generation rate (F): Added values of 90 and 120 fps for immersive gaming (baseline: 60 fps) - PDB: 15 ms (baseline), with optional values of 10 or 30 ms

Packet Size Distribution Updates (Table 5.1.1.1-1 amendments):

For immersive gaming, using truncated Gaussian distribution: - Mean (M): R×1e6 / F / 8 bytes - STD: [25%] of M (compared to baseline 10.5% of M) - Max: 300% of M (compared to baseline 150% of M) - Min: 25% of M (compared to baseline 50% of M)

This represents significantly higher variability in packet sizes for immersive gaming compared to baseline XR.

UL-Heavy Video Uploading Parameters (AR UL Model 1)

Updates to Table 5.5.2.1-1: - Packet size: Two candidates proposed: - 1st candidate: Follows clause 5.1.1.1 with STD/Min/Max = 10.5/50/150% - 2nd candidate: Follows clause 5.1.1.1 with STD/Min/Max = [25]/25/300% - Packet generation rate (F): 15, 30 Hz (baseline: 60 Hz) - Data rate (R): 20, 60, 100 Mbps (baseline: 10 Mbps; optional: 20 Mbps) - PDB: 10, 15 ms (baseline: 30 ms; optional: 10, 15, or 60 ms) - Jitter: Optional, follows description in clause 5.1.1.2

Model-2: eXR Model with Haptics

This model introduces haptics traffic co-generated with XR traffic packets.

Key Characteristics: - Haptics traffic defined as XR traffic packet generation with co-generated haptics packets - PDB for haptics packets: Either 12 ms or 30 ms (selectable as traffic model parameter)

Open Issues (FFS): - Generation methodology for multi-channel haptics packets - Handling of silent periods in haptics transmission - Haptics packet size determination - Co-generation mechanism between haptics packets and XR traffic packets

Action Requested

RAN1 requests SA4 to provide inputs on the proposed traffic models, particularly: - Validation of the proposed parameter values for immersive gaming and UL video uploading - Guidance on the FFS items for the haptics traffic model - Any additional considerations from the service and application perspective

Next RAN1 Meetings

• RAN1 #124: February 9-13, 2026, Gothenburg, Sweden
• RAN1 #124bis: April 13-17, 2026, Malta

Reply LS on Issues Related to Support of IMS Voice over NB-IoT NTN Connected to EPC

Document Information

• Source: RAN2
• Target: SA2 (CC: SA4, CT1, SA3, SA1, RAN1)
• Meeting: RAN2 Meeting #131bis (Prague, Czech Republic, October 13-17, 2025)
• Release: Release 20
• Work Item: IoT_NTN_Ph4-Core
• Document Number: R2-2508784
• Response to: R2-2506747/S2-2507636

Overall Description

This is a reply LS from RAN2 to SA2 addressing multiple technical questions related to the support of IMS voice over NB-IoT NTN (Non-Terrestrial Network) connected to EPC. RAN2 provides responses to specific questions raised by SA2 regarding RoHC, scheduling methods, DRB support, and SRB configurations.

RAN2 Responses to SA2 Questions

Question 1: RoHC State Fallback Trigger

SA2 Question: Does RAN2 have any observation on how many consecutive packets lost or erroneously decompressed will trigger the RoHC state fall back at the compressor when using RoHC?

RAN2 Response: - RAN2 is not able to make any observation on this matter - The implementation of ROHC functions (e.g., compression and decompression) falls outside of RAN2 scope

Question 3: Scheduling Methods for Dynamic Voice Packet Sizes

SA2 Question: Can RAN2 confirm whether scheduling methods for support of IMS voice over NB-IoT NTN can handle the voice packets of different sizes changing dynamically?

RAN2 Response: - Scheduling methods may handle voice packets of different sizes through: - Semi-persistent scheduling - Dynamic scheduling - Over-provisioning of resources in UL - RAN2 will further study and discuss the details of the scheduling mechanism to avoid potential issues

Question 6: Support for More Than 2 DRBs

SA2 Question: Is it feasible to support more than 2 DRBs for a UE accessing NB-IoT in Rel-20?

RAN2 Response: - RAN2 understands that it is technically feasible to support more than 2 DRBs for a UE accessing NB-IoT in Rel-20

Questions 9 & 10: New SRB for Voice Media with RLC UM

SA2 Question 9: Can RAN2 provide feedback on whether it is possible to define a new SRB that will be used to carry voice media?

SA2 Question 10: If the answer to the above question is yes, can RAN2 confirm whether such SRB(s) are defined, whether it is technically feasible to support and configure RLC UM for such SRB(s) for example: in NB-IoT deployments over GEO satellite, when SRBs are used to carry voice media?

RAN2 Response: - RAN2 understands it is technically feasible to introduce SRB with RLC UM for voice packet

RAN2 Position on CP vs UP Solution

RAN2 discussed both Control Plane (CP) and User Plane (UP) solutions for supporting IMS voice over NB-IoT NTN:

• Majority preference: UP over CP solution
• Rationale: The CP solution has higher impacts on RAN2 specifications
• Note: RAN2 understands that the final decision will be taken at the checkpoint in December plenary

Actions

RAN2 respectfully asks SA2 to take the replies and information provided into consideration.

Summary of 3GPP Technical Document

Document Information

• Meeting: RAN2 #131bis (October 2025)
• Document Number: R2-2507790 / S4-260015
• Type: Reply LS (Liaison Statement)
• Subject: RAN simulation assumptions, bundling period and SPS for ULBC
• Release: Release 20
• Work Item: FS_ULBC (Feasibility Study on Uplink Broadcast)

Overview

This is a Reply LS from RAN2 to SA4 addressing questions related to protocol overhead, MAC header sizing, and SPS operation for voice transmission in NB-IoT NTN context.

Main Technical Contributions

1. Protocol Overhead for Voice Packet Transmission

User Plane (UP) Solution

RAN2 specifies the expected protocol overhead for UP-based voice transmission: - PDCP: 1 byte - RLC UM: 1 byte - MAC header: Variable size (addressed separately)

Control Plane (CP) Solution

RAN2 provides two scenarios for CP-based voice transmission:

Current Specification: - RRC: 2 bytes - RLC AM: 2 bytes (currently the only specified mode for SRB) - MAC header: Variable size

Potential Future Enhancement: - RRC: 2 bytes - RLC UM: 1 byte (if introduced for SRB in case CP solution is selected) - MAC header: Variable size

Note: RAN2 indicates that further feedback on expected average RoHC header size may be provided later.

2. MAC Header Size Clarification

RAN2 provides detailed guidance on MAC header sizing: - Range: 1 to 3 bytes possible - Most common scenario: 3 bytes total MAC header size is likely - This clarifies SA4's question about whether 1 byte MAC header is realistic

3. SPS Operation with Non-Standard Bundling Periods

RAN2 addresses the feasibility of 120ms and 240ms bundling periods for SPS operation in NB-IoT NTN:

Key Issue Identified: - SPS periodicities of 120ms and 240ms do not divide 10240 - This creates specification challenges

RAN2 Position: - Work on SPS for voice has not yet started in RAN2 - Supporting these non-standard periodicities would require additional specification work to resolve the identified issues - Implies potential complexity and effort required if these periodicities are to be supported

Actions Requested

RAN2 requests SA4 to take the provided responses into account in their ongoing work on ULBC.

3GPP Technical Document Summary

Document Information

• Document Number: S4-260016 / R3-255896
• Meeting: SA4 #135 (February 2026) / RAN3 #129 (August 2025)
• Title: Reply LS on MBS Communication Service Type
• Release: Release 18
• Work Item: NR_QoE_enh-Core
• Response to: S4-251096/R3-255028

Overall Context

This is a Reply Liaison Statement from RAN3 to SA4 regarding the MBS (Multicast/Broadcast Service) Communication Service Type specification. RAN3 is responding to SA4's previous LS and raising several follow-up questions concerning the implementation of the @communicationServiceType attribute in TS 26.247, specifically related to QoE (Quality of Experience) measurement collection and reporting.

Technical Issues and Questions Raised

Question A: Cardinality of Communication Service Types

Issue: SA4's CR to TS 26.247 (S4-251095) states that the @communicationServiceType attribute "shall contain one or more of the following values."

RAN3 Position: - For a QMC (QoE Measurement Collection) configuration, only one communication service type is possible at a time - The phrase "or more" should be deleted from the Description field

Request: RAN3 asks SA4 to confirm this interpretation and update the specification accordingly.

Question B: Support for "all" Value

Issue: SA4 previously indicated that the value "all" for @communicationServiceType refers to all communication service types (broadcast, multicast, and unicast) - Option 1 interpretation.

RAN3 Position: - A given QoE Reference can only point to a single communication service type in RAN3 specifications - Combination of two or more communication service types in a single QMC configuration is not supported in RAN3 specifications - Therefore, the value "all" should be deleted from the @communicationServiceType attribute

Request: RAN3 asks SA4 to confirm this and remove the "all" value.

Question C: Default Value for Optional Attribute

Issue: SA4 revised the attribute from "OD" (Optional with Default) to "O" (Optional) in TS 26.247. However, the CR (S4-251095) still states: "When absent, quality metrics collection is requested for all communication service types."

RAN3 Questions: 1. Can the @communicationServiceType have a default value even though the Use is "O"? 2. If no: RAN3 asks SA4 to remove the sentence about default behavior from the Description field 3. If yes: RAN3 asks SA4 to confirm whether the default value can be "unicast" (since RAN3 specifications do not support combinations of multiple communication service types in a single QMC configuration)

Additional Observation

RAN3 Assumption: Release 17 UEs can perform QoE measurement collection and reporting only for unicast communication service.

Actions Requested

RAN3 requests SA4 to: 1. Take the above issues into account 2. Provide answers to Questions A, B, and C 3. Update SA4 specifications accordingly if feasible

Key Technical Implications

The core technical disagreement centers on: - Multiplicity constraint: RAN3 specifications support only single communication service type per QMC configuration, while SA4's text suggests multiple types are possible - Default behavior: Misalignment between attribute cardinality (Optional) and presence of default value semantics - Backward compatibility: Ensuring Release 17 UE capabilities (unicast-only) are properly considered in Release 18 specifications

3GPP Technical Document Summary

Document Information

• Document Number: R4-2511782 (Response to S4-260017)
• Meeting: RAN4 #116, Bengaluru, India, August 25-29, 2025
• Type: Response LS (Liaison Statement)
• Release: Release 20
• Work Item: FS_ULBC (Feasibility Study on UL Broadcast)

Purpose

This document provides RAN4's response to SA4's LS (R4-2509024/S4-251584) regarding RAN simulation assumptions for ULBC, specifically addressing questions about supported power classes for NB-IoT NTN UE and HPUE.

Main Technical Contributions

Power Class Support for NB-IoT NTN

Current Release Support (Rel-18 onwards)

• Power Classes: PC3 (23dBm) and PC5 (20dBm)
• Supported Bands: 256, 255, 254, and 253
• Extension in Rel-19: Band 252 added for PC3/PC5 support

Release 19 Enhancements

• New Power Classes Introduced:
• PC1 (31dBm)
• PC2 (26dBm)
• Applicable Bands: 256 and 255
• Target Device Types: Both hand-held and non-handheld devices

Release 20 Future Work

• Objective: Study and potentially specify UE transmit power higher than PC1
• Target Power Level: Up to 37 dBm for NB-IoT NTN
• Status:
• Work item approved by RAN plenary (RP-251867)
• Feasibility and specific power levels under study
• Work has not yet commenced
• No designated bands identified yet for higher than PC1 operation

Actions

RAN4 requests SA4 to consider the provided information in their future work on ULBC and related activities.

LS Reply on IMS Voice over NB-IoT NTN Connected to EPC

Document Information

• Source: SA1
• To: SA2
• CC: RAN2, SA4, CT1, SA3, RAN1
• Response to: S2-2507636
• Meeting: SA1 #112 (17-21 Nov 2025, Dallas, USA)
• Document Number: S1-254508

Overall Description

This is a reply LS from SA1 responding to SA2's inquiry regarding requirements for IMS voice over NB-IoT NTN connected to EPC.

SA2's Question

SA2 asked SA1 to confirm whether the following are required for IMS voice over NB-IoT NTN: 1. Support for more than one IMS voice call 2. Support for DTMF (Dual-Tone Multi-Frequency)

SA1's Response

SA1 provides the following clarifications:

Multiple Simultaneous IMS Voice Calls

• Not required in this Release
• Support for more than one simultaneous IMS voice call is explicitly excluded from the requirements

DTMF Support

• Required for IMS voice over NB-IoT NTN
• Dual-Tone Multi-Frequency (DTMF) support must be included

Technical Contribution

The technical contribution consists of: - A clarification CR to TS 22.261 (CR 0852) that captures these requirements - The CR is attached to formalize these decisions in the specifications

Action to SA2

SA2 is requested to take the above clarifications into account in their work on IMS voice over NB-IoT NTN connected to EPC.

Summary of 3GPP Technical Document S4-260019 / S1-254509

Document Overview

This is a Reply Liaison Statement (LS) from SA1 to SA, responding to GSMA NG UPG's inquiry regarding external data channel content access requirements. The document addresses regulatory considerations for IMS Data Channel applications, particularly concerning HTML and JavaScript content.

Main Technical Contribution

Regulatory Framework for IMS Data Channel Applications

SA1 provides a response to Question 6 from NG UPG, which concerns the regulatory treatment of IMS Data Channel applications defined in 3GPP TS 26.114, specifically addressing the regulatory distinction between: - IMS telephony services (subject to telecom regulation) - HTML and JavaScript content (typically not subject to telecom regulation)

SA1 Position on Regulatory Applicability

SA1 clarifies the regulatory framework as follows:

When IMS Data Channel is part of IMS telephony services: - IMS Data Channel applications, including their HTML and JavaScript content, are expected to be subject to local telecom regulation

When used for other services (e.g., standalone Data Channel): - Subject to applicable regulations, which could also include local telecom regulations

Regarding regulatory exceptions: - The existence of any exceptions is contingent upon the applicable regulations - SA1 explicitly states it is not within their scope to determine which specific regulation(s) HTML and JavaScript content would be subject to

Actions

SA1 requests SA to: - Consolidate SA1's reply with responses from other working groups - Provide a consolidated response to GSMA NG UPG

Administrative Details

• Release: Rel-20
• Source: SA1
• Recipients: SA (To), SA2, SA3, SA4, SA6, CT (Cc)
• Related Document: S1-254137/UPG14_109r3

Reply LS on RAN Simulation Assumptions for ULBC

Document Information

• Meeting: SA2 #170 (Gothenburg, Sweden, 25-29 August 2025)
• Document Number: S2-2507578
• Response to: S4-251584/S2-2506169
• Release: Release 20
• Work Item: FS_ULBC

Overall Description

This document is SA2's reply to SA4's liaison statement requesting clarification on RAN simulation assumptions for Ultra-Low Bandwidth Communication (ULBC), specifically regarding protocol overhead considerations for IMS voice over NB-IoT NTN via GEO satellite.

Technical Contributions

Protocol Overhead Options

SA4 requested SA2 and RAN2 to comment on different protocol stack options and their respective packet overhead, including: - User Plane (UP) vs Control Plane (CP) options - IP vs Non-IP PDN types - Overall packet overhead including RTP/UDP/IP with RoHC, PDCP, RLC, and MAC headers - Potential AS layer optimizations

SA2 Response: - SA2 has documented multiple alternative solutions in TR 23.700-19 for "Key Issue #1: Support of IMS voice call over NB-IoT NTN via GEO satellite connecting to EPC" - These solutions cover various options for: - CIoT EPS Optimisation (User Plane or Control Plane) - PDN type selection (IP or non-IP) - No conclusion has been reached yet on the solutions for Key Issue #1 - Final protocol overhead depends on the selected solutions - Conclusions and estimated overhead will be provided later - Expected completion: December 2025 (SA#110) per FS_5GSAT_Ph4_ARC SID

MAC Header Overhead Assumption

SA4 specifically questioned whether a 1-byte MAC header overhead assumption is realistic.

SA2 Response: - SA2 defers this question to RAN2 for proper assessment - SA2 requests RAN2 to provide feedback on expected overhead for: - PDCP - RLC - MAC

Actions

SA2 requests SA4 to take the provided answers into account for their ongoing work on ULBC RAN simulation assumptions.

Key Takeaways

• SA2's work on protocol stack options for IMS voice over NB-IoT NTN is still in progress
• Multiple solutions are under consideration with different overhead implications
• Final overhead estimates cannot be provided until solution selection is complete
• Lower layer (PDCP/RLC/MAC) overhead questions are redirected to RAN2 for expert input
• Timeline for conclusions: December 2025

LS on Issues Related to Support of IMS Voice over NB-IoT NTN Connected to EPC

Overall Context

SA2 is studying support for IMS voice over NB-IoT NTN connected to EPC under study item FS_5GSAT_Ph4_ARC (TR 23.700-019). The study is investigating solutions using both IP and non-IP PDN connection types for voice traffic. SA2 requires input from multiple working groups to evaluate alternative solutions and achieve target KPIs.

RoHC-Related Issues (Questions to RAN2 and RAN1)

RoHC State Transitions and Packet Loss

When IP PDN connections are used, Robust Header Compression (RoHC) is expected to be required to meet KPIs. RoHC is supported: - Between UE and eNB for "user plane" DRBs - Between UE and MME for "control plane CIoT" using SRBs

Key Technical Issue: During voice calls, consecutive packet losses or erroneous decompression can trigger RoHC state fallbacks: - SO (Second Order) → FO (First Order) state: ~16 consecutive lost packets (e.g., UO-0 header with 4-bit SN) - FO → IR (Initialization and Refresh) state: ~64 consecutive lost packets (e.g., UOR-2 header with 6-bit SN)

These state transitions cause gaps in voice packet transmission.

Question 1 (RAN2): Observations on number of consecutive packets lost/erroneously decompressed triggering RoHC state fallback?

Question 2 (RAN1): Probability data for 16 or 64 consecutive packet losses/erroneous decompression? Frequency of such events?

Variable Packet Sizes

Voice packets exhibit different sizes due to: - Talk/silence transitions - RoHC state changes - Other dynamic factors

Question 3 (RAN2): Can scheduling methods for IMS voice over NB-IoT NTN handle dynamically changing voice packet sizes?

Non-IP Solution and RTP Header Optimization (Questions to SA4)

For non-IP voice media traffic, there is no header compression. Understanding essential RTP header fields is necessary to reduce overhead.

Question 4 (SA4): What are the essential RTP header fields (sequence number, timestamp, SSRC, Payload Type) for minimum information needed in RTP header for IMS voice over NB-IoT NTN?

Question 5 (SA4): Views on reducing RTP header overhead for IMS voice over NB-IoT NTN?

DRB Limitations (Question to RAN2)

Current limitation: NB-IoT UE supports maximum 2 DRBs. Supporting more DRBs would enable simultaneous voice and other services during calls.

Question 6 (RAN2): Is it feasible to support more than 2 DRBs for UE accessing NB-IoT in Rel-20?

Control Plane Solutions and NAS Overhead Reduction (Questions to SA3 and CT1)

Several solutions under Key Issue #1 use control-plane mechanisms with Control Plane CIoT EPS optimization and SRBs for SIP signaling and/or voice media.

Current NAS Overhead

Rel-19 NORDAT_CP WI specified new NAS message with reduced overhead: - NAS layer overhead: 2 bytes - Security overhead: 4 bytes (MAC for integrity protection) - Sequence number: 1 byte - Total: 7 bytes

Question 7 (SA3): For dedicated SRB (via dedicated EPS bearer for Data over NAS) carrying only voice media packets, is there concern to eliminate the 5 bytes of NAS layer security overhead?

Question 8 (CT1): Beyond security considerations, any further possibility to reduce NAS overhead beyond Rel-19 NORDAT_CP for transporting voice packets over NB-IoT NTN?

RLC Mode for SRBs (Questions to RAN2)

Currently, SRBs only support RLC Acknowledged Mode (AM) per TS 36.331. For control-plane solutions carrying voice media, RLC Unacknowledged Mode (UM) may be beneficial.

Question 9 (RAN2): Feedback on possibility to define new SRB for carrying voice media?

Question 10 (RAN2): If yes to Question 9, is it technically feasible to support and configure RLC UM for such SRB(s) in NB-IoT deployments over GEO satellite when SRBs carry voice media?

Service Requirements (Question to SA1)

Multiple Calls and DTMF Support

Per TS 22.228: UE can support multiple IMS voice calls (e.g., using communication HOLD service).

Per TS 23.014 and TS 26.114 Annex G: Dual Tone Multi-Frequency (DTMF) signaling requires DTMF events as telephone events within same RTP media stream as speech ("inband"), using same IP address and UDP port but different RTP Payload Type number.

These requirements affect overall protocol stack overhead for non-IP based solutions.

Question 11 (SA1): Can SA1 confirm whether support for multiple IMS voice calls and DTMF is required for IMS voice over NB-IoT NTN?

Actions

SA2 requests respective WGs to answer questions addressed to them and provide any other necessary feedback.

LS on AI/ML for Media

Document Information

• Meeting: SA WG2 Meeting #172 (17-21 November 2025, Dallas, USA)
• Document Number: S2-2510954 (revision of S2-2510915)
• Response to: S4aR250196 = S2-2509930
• Release: Rel-20
• Work Item: AIML_IMS-MED
• Direction: SA2 → SA4

Main Technical Content

SA2 Response on AI/ML for Media

SA2 acknowledges SA4's LS and provides the following response regarding AI/ML capabilities for media handling:

Current Specification Status

• Model handling in MF (Media Function) and enriching MF with inference capability are:
• Currently not supported by IMS specifications
• Not in scope of the IMS RTC study for Rel-20

Request for Clarification

SA2 requires additional information from SA4 to provide a more comprehensive assessment:

Question to SA4: What new functionalities are expected to be supported by: - UE - IMS entities (e.g., MF, DC AS - Data Channel Application Server)

Baseline for comparison: TS 23.228 Annex AC

Next Steps

SA2 indicates that once SA4 provides clarification on the expected new functionalities, SA2 will be able to: - Make a more accurate evaluation - Assess potential impacts to SA2 specifications

Action Item

ACTION: SA2 requests SA4 to: - Take the above information into account - Answer the clarification question regarding expected new functionalities for UE and IMS entities

3GPP Technical Document Summary: Reply LS on IMS Voice over NB-IoT NTN Security

Document Identification

• Document Number: S3-253797
• Meeting: SA3#124, Wuhan, China (13-17 October 2025)
• Release: Rel-20
• Work Item: FS_5GSAT_Ph4_SEC
• Type: Reply Liaison Statement

Context

This document is SA3's response to a Liaison Statement from SA2 (S3-253118/S2-2507636) regarding security considerations for IMS voice over NB-IoT NTN (Non-Terrestrial Network) connected to EPC.

Main Technical Contribution

Security Overhead for Voice Media Packets over NAS

Question from SA2 (Question 7):

SA2 asked whether SA3 would accept eliminating the 5 bytes of NAS layer security overhead for voice media packets in the context of: - Alternative solutions documented in TR 23.700-19 - Support of IMS voice over NB-IoT NTN connected to EPC - Use of a specific SRB via dedicated EPS bearer for Data over NAS - Transfer limited to voice media packets only

SA3 Decision:

SA3 rejected the proposal to eliminate the NAS layer security overhead with the following rationale:

• The majority of companies in SA3 opposed allowing non-integrity protected voice packets to be sent over NAS to the MME
• No consensus was reached in SA3 to eliminate the 5 bytes of NAS layer security overhead
• This maintains the integrity protection requirement for voice packets transmitted over NAS

Implications

The decision preserves the existing NAS layer security mechanisms for voice traffic, prioritizing security over the potential bandwidth savings that would result from removing the 5-byte overhead. This is particularly relevant for NB-IoT NTN scenarios where bandwidth efficiency is typically a concern, but SA3 determined that security requirements take precedence.

Action to SA2

SA3 requests SA2 to take this security position into account when finalizing the solutions for IMS voice over NB-IoT NTN connected to EPC.

3GPP Technical Document Summary: LS Reply on LI Requirements on IMS Data Channel

Document Information

• Source: SA3
• Target Groups: SA2, SA3-LI (CC: SA4, CT1)
• Meeting: SA3#124 (Wuhan, China, October 2025)
• Document Number: S3-253806
• Release: Rel-18
• Work Item: NG_RTC_SEC

Overall Context

This document is an LS reply from SA3 to SA2 regarding Lawful Intercept (LI) requirements for IMS Data Channel. SA3 provides feedback on three specific scenarios identified by SA2 concerning LI implementation challenges.

Technical Contributions by Scenario

Scenario 1: Roaming Cases with S8HR/N9HR Model

Issue Raised by SA2: How can VPLMN decrypt Data Channel content when UE is in roaming state?

SA3 Position: SA3 identifies significant security concerns with the proposed approach:

• Current Constraint: S8HR/N9HR are direct interfaces between roaming UE and HPLMN, and LI requirements imply these interfaces should not be confidentiality protected
• Technical Possibility: VPLMN could access DC content copy without confidentiality protection by using DTLS1.2 with NULL cipher
• Strong Recommendation Against NULL Cipher:
• NULL cipher not possible in DTLS1.3 and not recommended in DTLS1.2
• DTLS1.3 is recommended from Rel-19 onwards
• Security downgrade must be applied to all HPLMN UEs to avoid LI detectability
• Conflicts with regulatory requirements (e.g., EU Cyber Resilience Act) mandating state-of-the-art encryption for data in transit and storage by default

Scenario 2: Interoperability Between CSPs and P2P Direct Communications

SA2 Analysis: - HTTP Proxy Mode: P2A and P2A2P Data Channels terminated in MF, which can provide decrypted DC content copy for LI - DC Application Proxy Mode: Serving IMS network can anchor P2P Data Channel of target UE in MF for LI support - UDP Proxy Mode: LI requirements cannot be fulfilled

SA3 Feedback: - Clarification Request: According to TS 23.228, "DC Application Proxy" is only applicable when network initiates P2P session - Open Question: SA3 requests clarification whether SA2 considers "DC Application Proxy" applicable for UE-initiated P2P sessions for LI purposes

Scenario 3: Interoperability Between CSP with and Without IMS Data Channel

SA2 Analysis: - When target UE uses IMS without Data Channel feature, interworking between DCMTSI UE and MTSI UE occurs - IMS DC content from DCMTSI UE terminated in MF or DC AS - MF/DC AS supports interworking with MTSI UE via IMS video flow or other mechanisms (SMS, HTTP via Internet DN) - Existing LI specifications assumed sufficient for these interworking scenarios - No gaps identified by SA2

SA3 Position: Since SA2 identified no gaps, SA3 will not explore these scenarios further.

Actions Requested

SA3 requests: 1. To SA2 and SA3-LI: Consider the security concerns raised for Scenario 1 2. To SA2: Provide clarification on the question regarding Scenario 2 (applicability of DC Application Proxy for UE-initiated P2P sessions)

Key Technical Implications

• Security vs. LI Trade-off: The document highlights fundamental tension between LI requirements and modern security best practices
• DTLS Version Migration: Transition from DTLS1.2 to DTLS1.3 eliminates NULL cipher option, creating architectural challenges for LI
• Regulatory Compliance: EU CRA requirements conflict with LI approaches requiring weakened encryption
• Proxy Architecture Limitations: Different MF proxy modes have varying LI capabilities, with UDP Proxy mode unable to support LI requirements

Summary of S3-254551: Reply LS on IMS Avatar Security Aspects

Document Overview

This is a Reply Liaison Statement (LS) from SA3 to SA2 regarding the status of security aspects for IMS Avatar communication. The document responds to SA2's LS (S3-254015/S2-2509593) on Avatar Security Aspects and provides a status update on the completion of related security work.

Main Technical Contributions

Completion of Rel-19 Security Work for IMS Avatar Communication

SA3 reports the completion of normative security work for IMS avatar communication under the following parameters:

• Work Item: NG_RTC_SEC_Ph2 (Next Generation Real-Time Communication Security Phase 2)
• Specification: TS 33.328, Annex R
• Status: Final CR (CR084) for TS 33.328 Annex R was agreed at SA3#124 (October 17-21, 2025)
• Expected Approval: SA#110 plenary meeting

Key Milestone

The security aspects for IMS avatar communication have been fully specified in the normative Annex R of TS 33.328, completing the Rel-19 security requirements for this feature.

Actions

SA3 requests SA2 to: - Take the completion status of the IMS Avatar security work into account - Note that the normative security specifications are now available in TS 33.328, Annex R

Meeting Schedule

• SA3#126: February 9-13, 2026 - Goa, India
• SA3#127: April 13-17, 2026 - Malta

LS Reply on External Data Channel Content Access

Document Information

• Source: 3GPP TSG SA WG6
• To: SA (cc: SA1, SA2, SA3, SA4, CT)
• Response to: S6-254010//UPG14_109r3 (LS from GSMA NG UPG about external data channel content access requirements)
• Release: Rel-20
• Work Item: FS_MMTel_Ph2_APP

Overall Description

SA6 provides a response to GSMA NG UPG's liaison statement regarding external data channel access, specifically addressing Question 4 directed to SA2 and SA6.

Question Addressed

Question 4: Does 3GPP SA2/SA6 plan to define procedures and architecture for interworking between the IMS session and external (non-IMS) content sources allowing for example pulling information from a public API in a secure manner?

SA6 Response

Current Status: - SA6 has not yet studied the procedures and architecture for interworking between the IMS domain and external (non-IMS) content sources

Potential Reference Framework: - SA6 references the CAPIF (Common API Framework) defined in 3GPP TS 23.222 - CAPIF introduces third-party API providers that can: - Securely expose their capabilities to other services under PLMN control - Enable secure utilization of third-party API provider resources by other services - The CAPIF architecture and procedures for third-party API providers in non-3GPP systems could potentially serve as a reference for procedures enabling interworking between IMS sessions and external (non-IMS) content sources

Future Plans: - SA6 commits to keeping GSMA NG UPG informed of progress in this area

Actions

To SA: - SA6 requests SA to consolidate SA6's reply with replies from other working groups and respond to GSMA NG UPG

3GPP LS Response on External Data Channel Content Access Requirements

Document Overview

This is a Liaison Statement (LS) response from 3GPP TSG SA to GSMA NG UPG addressing concerns about external data channel content access requirements. The document consolidates feedback from multiple SA Working Groups (SA1, SA3, SA4, and SA6) regarding the handling of external resources in IMS Data Channel applications.

Main Technical Contributions

SA1 Feedback: Regulatory Scope

SA1 clarifies the regulatory framework for IMS Data Channel applications:

• IMS Telephony Context: When IMS Data Channel is used as part of IMS telephony services, the applications (including HTML and JavaScript content) are expected to be subject to local telecom regulation
• Standalone Data Channel: When used for other services, they are subject to applicable regulations which could also include local telecom regulations
• Regulatory Determination: SA1 explicitly states it is not within their scope to decide which specific regulation(s) HTML and JavaScript content would be subject to

SA2 Feedback

SA2 has provided a separate, direct reply to GSMA NG UPG (not included in this consolidated response).

SA3 Feedback: Security Architecture

SA3 addresses security concerns for external content:

• Current Status: SA3 does not currently have plans to standardize security architecture and measures for:
• Content and source validation
• Methods to compute trust towards external hosts and content
• Future Updates: SA3 commits to keeping GSMA NG UPG informed of any future developments in this area

SA4 Feedback: Specification Gaps and Study Plans

SA4 provides the most detailed technical response:

• Acknowledgment of Issue: SA4 acknowledges the gaps identified by GSMA NG UPG regarding ambiguity in handling external resource access in IMS Data Channel applications
• Current Specification Limitations: TS 26.114 does not explicitly address scenarios involving external resource mashups clearly enough
• Original Design Assumption: SA4 originally assumed that the Data Channel Signalling Function (DCSF) and Data Channel Application Server (DC AS) would be the exclusive hosts for all content, and did not anticipate scenarios involving external resources
• Planned Action: SA4 commits to studying this issue and providing necessary clarifications as part of the DC Enhancements (FS_DCE_MED) study in Release 20

SA6 Feedback: Interworking Architecture and CAPIF Reference

SA6 provides architectural context and potential solutions:

• Current Status: SA6 has not yet studied procedures and architecture for interworking between the IMS domain and external (non-IMS) content sources
• CAPIF Framework Reference: SA6 highlights the CAPIF framework (3GPP TS 23.222) as a potential reference:
• Introduces third-party API providers
• Enables third-party API providers to securely expose their capabilities to other services under PLMN control
• Resources of third-party API providers can be securely utilized by other services
• The architecture and procedures for third-party API providers in non-3GPP systems could serve as a reference for IMS session interworking with external (non-IMS) content sources
• Future Updates: SA6 commits to keeping GSMA NG UPG informed of their progress

Actions

The LS requests GSMA NG UPG to take the consolidated feedback from all SA Working Groups into account.

LS on Completion of Study on AI/ML Consistency Alignment

Document Information

• Meeting: TSG-SA Meeting #110 (Baltimore, US, December 2025)
• Document Number: SP-251699
• Release: Rel-19
• Work Item: FS_AIML_CAL (Study on AI/ML Consistency Alignment)
• Source: TSG SA
• Contact: Johannes Achter (johannes.achter@magenta.at)

Main Purpose

This Liaison Statement informs all 3GPP working groups about the completion of the Study on AI/ML consistency alignment.

Technical Contributions

Study Completion

TSG SA has completed the Study on AI/ML consistency alignment, with the following deliverables:

1. TR 22.850 v1.0.0 - The technical report documenting the study findings was approved at SA#110
2. CR 0128 on TR 21.905 - A change request to TR 21.905 was approved to establish consistent AI/ML terminology

Terminology Standardization

The key technical contribution is the definition of consistent AI/ML terminology to be used across all 3GPP working groups. This terminology has been captured in the approved CR to TR 21.905, which serves as the 3GPP vocabulary specification.

Work Item Closure

• No further work is planned on this study activity
• The study item FS_AIML_CAL is considered complete

Actions Requested

TSG SA requests all recipient groups (TSG RAN, TSG CT, and all SA, RAN, and CT working groups) to: - Take note of the completed study - Apply the standardized AI/ML terminology defined in the updated TR 21.905 in their respective work

Attachments

• SP-251698: TR 22.850 v1.0.0
• SP-251666: CR 0128 on TR 21.905

LS on LI Requirements on IMS Data Channel

Document Information

• Meeting: SA3-LI#97 (29 April – 02 May 2025, Washington DC)
• Document Number: S3i250185
• Release: Rel-19
• Work Item: LI19
• Source: SA3-LI
• To: SA4, SA2
• Cc: CT1, SA3

Overall Description

Problem Statement

SA3-LI has identified critical gaps in the current IMS Data Channel encryption architecture that prevent CSPs from meeting lawful interception (LI) requirements specified in TS 33.126, particularly requirements R6.4-160, R6.4-170, R6.4-180, and R6.4-190, including mid-session interception scenarios.

Key Issues Identified

1. Encryption Architecture Limitations

The current encryption and architecture design for IMS Data Channel fails to meet LI requirements in the following scenarios:

• Roaming cases with S8HR/N9HR model
• Interoperability cases between two CSPs
• Direct communications between two users (when at least one is an LI target)

2. LI Access Requirements Not Met

SA3-LI specifies two acceptable approaches for LI:

1. Preferred: Access to a copy of communication content without confidentiality protection
2. Required (if preferred not feasible): Access to encryption parameters that enable decryption of encrypted content

Neither approach is currently achievable with the existing IMS Data Channel implementation.

3. Interoperability Gap

When two CSPs interoperate where: - One CSP uses IMS Data Channel - The other CSP uses IMS without IMS Data Channel feature - The LI target is on the CSP without Data Channel

The CSP cannot intercept and provide the content exchanged between the two users, creating a compliance gap.

Reference Architecture

The document references Figure 6.2.10.1-1 from TS 26.114 showing the Data Channel Workflow, indicating the architectural context of the identified issues.

Impact

These limitations create major complications for CSPs to respect their national regulations regarding lawful interception obligations.

Action Requested

SA3-LI requests SA4 and SA2 to:

Develop a solution and architecture for secured IMS Data Channel that enables CSPs to meet the LI requirements as described in TS 33.126.

Next SA3-LI Meetings

• SA3LI Meeting #98: 15th – 18th July 2025, Florence, Italy
• SA3LI Meeting #99: 4th – 7th November 2025, TBD, USA

LS on Traffic Model for Immersive Communication

Document Information

• Source: Huawei Hisilicon (SA WG4 to be)
• To: RAN WG1
• Response to: R1-2509596/S4-260013
• Release: Rel-20
• Work Item: FS_6G_MED

Overall Description

SA4 provides a response to RAN1's LS regarding traffic models for immersive communications, drawing on previous study work and ongoing investigations.

Main Technical Contributions

Historical Context from 5G Studies

TR 26.955 - 5G Video Codec Study

• Immersive Gaming Scenarios (Clause 7.3.3):
• Evaluated rate points between 20 Mbit to 100 Mbit for highest quality sequences
• Target scenario: 4K + HDR at 120 fps

• No values above 100 Mbit reported in the study

• Frame Rate Considerations (Table 6.6.3.7-1):

• Frame rates of 90 fps and 120 fps considered for online gaming

• Aligns with proposed model updates from RAN1

• Industry Deployment Reference:

• Current gaming services (e.g., GeForce Now) require approximately 50 Mbit+

• 5G Uplink Limitations:

• High quality uplink scenario (4K + HDR) was not considered due to limited uplink bandwidth
• SA4 developed coding profiles for downlink applications (5G media streaming, immersive gaming)

Uplink Scenario Considerations

Real-Time Uplink Characteristics

• Encoder Constraints:
• Uplink encoders (sender side) typically less powerful than downlink

• Expected values in the higher range of 20-100 Mbit for transparent quality

• Adaptive Mechanisms:

• Temporary frame rate drops and/or quality switches may compensate for encoder limitations

• Could still result in comparable bit-rates

• Traffic Variability:

• Frame rate changes more likely compared to traditional downlink cases
• Bit-rates in 20-100 Mbit range assumed for transparent quality

3D and Immersive Formats

TR 26.956 - Emerging 3D Formats

• Clause 9 Results:

• Explored formats beyond traditional 2D video:

  • Video-based point cloud
  • Multi-view stereo with depth
  • Immersive video

• Bit-rate Range:

• Transparent quality results roughly in 20-100 Mbit range

• Matches RAN WG1 assumptions

• Frame Rate Limitation:

• Only lower frame rates tested: 25-30 fps

Ongoing Studies

• Gaussian Splat-Based Imaging:
• Currently under study in SA4
• Could result in:
  • Different frame rates
  • Potentially (much) larger bit-rates

Future Work in FS_6G_MED

• Study just started in SA4
• Uplink video scenario not yet studied
• Expected investigation areas:
• High quality uplink cases based on SA WG1 use cases
• Derivation of corresponding requirements for uplink video
• Building on earlier 5G downlink results

Actions

To RAN WG1:

SA4 respectfully requests RAN WG1 to take this information into account.

Key Technical Takeaways

1. Bit-rate Range Alignment: SA4's previous studies support the 20-100 Mbit range proposed by RAN1 for immersive communications
2. Uplink-Downlink Asymmetry: Uplink scenarios expected to require higher bit-rates within the range due to encoder constraints
3. Format Evolution: Emerging 3D formats (point clouds, Gaussian splats) may require significantly higher bit-rates than traditional 2D video
4. Frame Rate Considerations: High frame rates (90-120 fps) already considered in 5G studies, with adaptive mechanisms expected in uplink scenarios

3GPP Technical Document Summary

Document Information

• Source: SA3-LI
• Document Number: S4-260134 / s3i260049
• Meeting: SA4 #135 (February 2026) / SA3LI #100 (January 2026)
• Title: LS on LI requirements
• Release: Rel-20
• Work Item: LI20

Overall Purpose

This is a Liaison Statement (LS) from SA3-LI to SA2, SA3, SA4, and SA6 regarding Lawful Interception (LI) requirements for 6G systems.

Main Technical Contributions

LI Requirements Continuity for 6G

SA3-LI has determined that: - All currently defined LI requirements in TS 33.126 remain applicable for 6G - These requirements may be expanded to accommodate 6G-related changes being developed in SA2 - LI considerations must be integrated early in the 6G architecture development to avoid post-development issues that could prevent compliance with LI requirements across different jurisdictions and legal frameworks

Proactive Coordination Request

SA3-LI requests that SA2, SA3, SA4, and SA6: 1. Identify potential topics within their respective work areas that may require SA3-LI input before the 6G architecture is finalized 2. Send LSs to SA3-LI on these topics 3. Take existing TS 33.126 requirements and future 6G LI expansions into account during architecture definition

Proposed Text Addition

SA3-LI requests the addition of the following normative text to clause 4.2 of TR 23.801-01 and other 6G TRs/TSs under development:

"Lawful interception requirements shall be taken into account for all WTs and corresponding key issues in this study. For more details on LI requirements, see TS 33.126."

Actions Requested

To SA2:

• Add reference to LI requirements in clause 4.2 of TR 23.801-01 with the proposed text
• Request clarification from SA3-LI on any aspects of TS 33.126 if needed
• Inform SA3-LI of any issues in TR 23.801-01 solutions that may prevent compliance with TS 33.126

To SA3, SA4, and SA6:

• Add reference to LI requirements in their respective 6G studies with the proposed text
• Request clarification from SA3-LI on any aspects of TS 33.126 if needed
• Inform SA3-LI of any issues in their 6G solutions that may prevent compliance with TS 33.126

Reply LS on Traffic Model for Immersive Communication

Document Information

• Source: SA WG4
• To: RAN WG1
• Response to: R1-2509596
• Release: Release 20
• Work Item: FS_6G_Radio

Overall Description

SA4 has discussed RAN1 LS R1-2509596 and provides information on the eXR model with Haptics.

Key Modeling Principles

SA4 establishes the following principles for haptics traffic modeling:

1. Simultaneous haptics packets over multiple channels can be modeled as one aggregated packet
2. Silent periods of haptics do not need to be modeled
3. Haptics packets and XR traffic packets can be generated either independently or with correlation

Downlink Haptics Traffic Model

SA4 provides a statistical parametric model for downlink haptics traffic based on haptics traces (provided in attachment).

Statistical Parameters

| Parameter | Unit | Value/Distribution | |-----------|------|-------------------| | Packet size | byte | Pareto distribution with α=7, range = [504, 1736] bits
CDF: F(x) = 1 - (x_min/x)^α, where x_min is the minimum value | | Packet inter-arrival time (T) | ms | Exponential distribution with λ=0.015, min=M
Quantized to multiples of M using rounding function (e.g., M=32ms)
CDF: F(t) = 1 - e^(-λt) | | Jitter | ms | Follows description in clause 5.1.1.2 in TR 38.838 | | PDB | ms | 30 | | Packet Success Rate | % | 90 |

Key Characteristics

• Packet sizes follow a Pareto distribution (heavy-tailed distribution) with shape parameter α=7
• Inter-arrival times follow an exponential distribution with rate parameter λ=0.015, subsequently quantized to multiples of M (e.g., 32ms)
• 30ms PDB requirement with 90% packet success rate

Uplink Haptics Traffic Model

For uplink haptics traffic, SA4 recommends reusing existing models:

• Uplink haptics mainly involves transmission of haptic sensor information
• The uplink control or pose traffic model defined in section 5.2 of TR 38.838 can be reused

Action Requested

SA4 respectfully requests RAN1 to take the above information into account for traffic modeling in immersive communication studies.