Apex Standards 3GPP Meeting Tracker

---

updated as of Mon, Apr 17, 2023, 09:04 PM UTC (4 hours ago)
Mon, Apr 17, 02:04 PM California
Mon, Apr 17, 11:04 PM Berlin/Paris
Tue, Apr 18, 05:04 AM Beijing

3GPP-S4-123-e    Agenda Item 2.0 : Approval of the agenda and registration of documents

3GPP-S4-123-e    Agenda Item 4.0 : Approval of previous meeting report

3GPP-S4-123-e    Agenda Item 5.1 : SA4 SWG ad hoc meetings

• TDoc S4-230437: This TDoc discusses the extraction of information from Application Server to GTP, and the importance of not letting one application stay back because of lack of bandwidth. It also mentions the use of DTLS and SCTP as tunnels for the application layer.
- "UPF can extract this information from the Application Server and put it into the GTP, where radio extracts the information."
- "If, for example, two applications with low latency requirements are used simultaneously, it would be undesirable to let one application stay back because of lack of bandwidth, as it would introduce extra latency."
- "DTLS and SCTP just tunnels for the application layer."
• TDoc S4-230438: This TDoc highlights the proposed update to the Permanent Document for MP_RTT Structuring, and how the architecture, Stage 3 protocol, and Stage 3 signaling examples for the eiRTCW signaling protocol will be entered into the TR. It also mentions the conflict with the URL specified in SDP and the security issue with UE-provided URLs.
- "The proposed update to the Permanent Document for MP_RTT Structuring how the architecture, Stage 3 protocol, and Stage 3 signaling examples for the eiRTCW signaling protocol will be entered into the TR."
- "The URL in SDP has conflict with the solution specified in SA2 NGRTC stage2/3 and we need to align with SA2 work, the other is that the URL is provided by UE and it may introduce security issue."
• TDoc S4-230615: This TDoc discusses the selection of a concise set of requirements and methods for characterizing capture, documentation of all methods, and investigation of microphone location.
- "It will be most likely non-trivial selection which method is sufficient to characterize capture, don’t know how to arrive at that, will target a concise set of requirements and methods so that requirements not too costly."
- "Value documentation of all methods, properly documented but not reached level of mandatory, numbers are just in the Pdoc?"
- "Phone size is increasing, but it does not help, we should know the current average and what is the range, there are smaller phones that can be covered."
- "Also investigate on microphone location in chapter 5?"

[TDoc S4-230517]:
- Discussion on the relevance of DTX (Discontinuous Transmission) testing for EVS-used background noise types.
- No clear decision on whether to include or exclude other street signals such as birds or street musicians.
- Agreement to include second and third sentences of the first paragraph into 4.5.2 of IVAS-8a and to collect reasonable files and select out of them those to be used.
- New input contribution expected for the next call with updated proposal including exact wording on channel order.

[TDoc S4-230518]:
- Discussion on price of GAL (Generic Audio Library).
- Agreement on performing HL (Hearing Loss), CL (Cognitive Load), and MC (Mean Opinion Score) tasks on a voluntary basis without the need for a contract.
- Simplification of the process for selection of model parameters and sound material.
- Further input expected on specific items such as GAL and stereo material.

[TDoc S4-230519]:
- No contributions on eUET (enhanced Universal Encoding Tool) but two contributions available on ISAR (Improved Speech Acquisition and Recognition).
- Approval of agenda and registration of documents.
- Agreement on ISAR work item for input contribution to SA4#123e.

[TDoc S4-230520]:
- Discussion on the meaning of "tested" in an informal way in the bit rates part.
- Agreement to note the contribution and assume to receive an update.
- Interest indicated to team up and provide input.

[TDoc S4-230521]:
- Agreement on IVAS-7a as the updated version implementing agreed inputs from the last call.
- Addressing the need for headphone equalization and agreement on using the same headphones model.
- Updated table of experiments agreed for a more balanced distribution of languages.

Technical differences among the TDocs mentioned in the prompt are as follows:

1. TDoc S4-230444:
- Talks about a feasibility study on typical traffic characteristics for XR services and other media.
- No documents are currently available, but input is expected for an upcoming meeting.
- Thomas suggests using consistency from Video Characterization, with revisions expected for SA4#123.

2. TDoc S4aV230018:
- Proposed agenda for SA4 VIDEO SWG conference, including interoperability points for visual and audio.

3. TDoc S4aV230013:
- Revised version of TDoc S4aV230010.

4. TDoc S4-230446:
- Includes an IPR and anti-trust reminder.
- No reports or liaisons from other groups are available.
- Presenter is Richard Bradbury.

5. TDoc S4-230447:
- Proposed inline changes to TS 26.501, adding Service URL Handling as new sub-functionality of Media Session Handler.
- Comments are made on the necessity of including low level details about modem and UPF.

6. TDoc S4-230448:
- Talks about decision-making for compute distribution, but specifies that actual decision-making is outside the scope of the spec.
- Richard suggests that having more than one application is already possible.

Examples from the TDocs to support the above differences are:

- TDoc S4-230444: "Noted for now, but expect input for the upcoming meeting."
- TDoc S4aV230018: "Proposed agenda for SA4 VIDEO SWG conf. Interoperability Points for Visual and Audio."
- TDoc S4aV230013: "Revised S4aV230010."
- TDoc S4-230446: "Presenter: Richard Bradbury."
- TDoc S4-230447: "Thomas described considerations on decision-making for compute distribution but actual decision-making is outside the scope of the spec."
- TDoc S4-230448: "Richard : On the idea of being able to have more than one application, it is already possible."

3GPP-S4-123-e    Agenda Item 5.2 : Other 3GPP groups

TDoc S4-230454:
- CT3 switched to the usage of the UserServiceDescription data structure for the encoding of the MBS User Service Announcement.
- Previously used MBSUserServAnmt data type based encoding (defined by CT3).

TDoc S4-230455:
- CT4 analyzed the research paper enclosed in the LS and found that the OpenAPI constructs used in the API descriptions of the 3GPP 5G Core are in line with the recommendations expressed on the official OpenAPI 3.0.x documentation.
- OAuth/2.0 is mandatory to support by NF Service Consumers and Producers, but optional to deploy.

TDoc S4-230459:
- PSER definition as “the PSER defines an upper bound for a rate of non-congestion related PDU Set losses” suggested by RAN2.
- PDU set concept is applicable to both UL and DL.

TDoc S4-230460:
- Agreement on the principles of Option 3 and Option 4.
- QoE continuity is done in AS layer for HO between LTE/5GC and NR.
- RAN2 prefers APP layer handling for buffer level threshold-based triggering of RVQoE reporting.

TDoc S4-230461:
- RAN3 has agreed to introduce buffer level threshold-based triggering of RVQoE reporting in Rel-18.
- RAN2 prefers APP layer handling for triggering of RVQoE reporting based on buffer level.

TDoc S4-230462:
- W1-U interface (as specified in TS 37.470), which uses GTP-U, has not been captured in TS 29.281.
- RAN3 kindly asks CT and CT4 to take the above information into account and update the corresponding specification.

TDoc S4-230466:

- The TDoc is a response to a security architecture inquiry for 5G multicast/broadcast services
- SA3 is thanking SA2 for their response LS
- The work item is 5MBS
- The contact person is Longhua Guo

Example from TDoc S4-230466: "SA3 thanks SA2 for the reply LS on security architecture for 5G multicast/broadcast services."

TDoc S4-230467:

- The TDoc is a response to the impact of MSK update on MBS multicast session update procedure
- SA3 is thanking SA2 for their reply LS
- The work item is 5MBS
- The contact person is Longhua Guo

Example from TDoc S4-230467: "SA3 thanks SA2 for the Reply LS on the impact of MSK update on MBS multicast session update procedure."

TDoc S4-230469:

- The TDoc is a response to a clarification on the deployment of bundle EAS
- The release is 3GPP Rel-18
- The work item is eECM
- The source is 3GPP SA5
- The contact person is Shitao Li

Example from TDoc S4-230469: "3GPP SA5 thanks SA6 for collaborating on bundle EAS."

TDoc S4-230478:

- The TDoc references various 3GPP TS specifications related to quality of experience measurement collection
- 3GPP SA5 respectfully asks RAN2, RAN3, SA4, CT1, and CT4 to take the above information into account and update relevant specifications if needed
- The approved functions include Management Based QoE Measurement Collection (QMC) for NR and Signalling Based QoE Measurement Collection for NR

Example from TDoc S4-230478: "3GPP SA5 respectfully asks RAN2, RAN3, SA4, CT1 and CT4 to take the above information in account and if needed update relevant specification."

[TDoc S4-230464]: This TDoc discusses the Multicast/Broadcast Service Security Function (MBSSF) and its insertion into the user plane path between the AF and MB-UPF. The clause 7.1.1.2 of TS 23.247 defines procedures for the insertion of MBSF/MBSTF, but related procedures are lacking if MBSSF is not located in MBSF or MBSTF.

[TDoc S4-230465]: This TDoc requests SA4 to define the 3GPP specific RTP/SRTP header extensions for the identification of PDU Sets and provide how the parameters listed above can be derived from existing RTP/SRTP headers, header extensions and/or payloads. The feasibility of signaling the PDU set size in bytes is pending on the confirmation by SA4.

[TDoc S4-230468]: This TDoc discusses the QoE reports collected by the UE and their usefulness for the OAM. There is no time limit after which the QoE reports are no longer useful for the consumer, but a default behavior should be to prioritize new data.

[TDoc S4-230470]: This TDoc highlights Energy Saving (ES) and Digital Sobriety (DS) in the 5G network. It describes use cases/scenarios and related requirements to achieve energy savings and specifies solutions to support these use cases. It also proposes that digital sobriety includes how 3GPP may help save energy in the 5G network by designing sober, eco-friendly solutions.

Example snippets from the original TDoc to support the difference highlighting:

- TDoc S4-230464: "...related procedures are lacking if the MBSSF is not located in MBSF or MBSTF" (highlighting the lack of procedures in a specific scenario)
- TDoc S4-230465: "The feasibility of signaling the PDU Set Size in bytes is pending on the confirmation by SA4" (highlighting a specific parameter that is under consideration)
- TDoc S4-230468: "There is no time limit after which the QoE reports are no longer useful for the consumer" (highlighting the absence of a time limit)
- TDoc S4-230470: "It describes use cases/scenarios and related requirements to achieve energy savings" (highlighting the focus on achieving energy savings)

TDoc S4-230477:

- General requirements for Application Service Providers (ASP) to retrieve/pull and send/push collected data on-demand from/to UE Application without setting up session.
- SA6 wants feedback from SA4 on whether existing data collection from UE Application supports these requirements.
- Discussions related to reuse of procedures for data collection from UE Application defined in TS 23.288, TS 26.512.

TDoc S4-230480:

- Proposed draft Recommendation for requirements and framework of disaster mitigation and personnel rescue for sudden natural disasters.
- Scope includes network capabilities for disaster mitigation and personnel security, framework and interface for identification and location of trapped persons, etc.
- Aims to build a disaster mitigation and personnel rescue system for emergency scenes of sudden natural disasters globally.

TDoc S4-230481:

- TSG SA acknowledges that the EVEX framework in TS 26.531 and TS 26.532 defines detailed procedures and APIs for generic UE data collection and reporting functionality.
- SA4 is asked if they are willing to maintain and enhance the technical specifications that comprise the EVEX framework, or if another WG will take over.
- Rel.18 conclusions of FS_AIMLsys will not be modified.

TDoc S4-230573:

- Signaling of "End of Data burst information" is still under discussion.
- SA2 is asked about the agreed mechanism regarding how PDU set information from the new RTP header extension will be used by UPF.
- SA4 will add a response based on SA4#123-e progress.

The TDoc snippets highlight technical differences among various topics, such as disaster mitigation and personnel rescue, UE data collection and reporting, and signaling of "End of Data burst information." SA4 is also tasked with maintaining and enhancing the EVEX framework or transferring it to another WG if they are unwilling to make changes. Additionally, SA2 is asked about the mechanism for using PDU set information from the new RTP header extension in UPF.

3GPP-S4-123-e    Agenda Item 5.3 : Other groups

3GPP-S4-123-e    Agenda Item 6.3 : Other immediate issues

3GPP-S4-123-e    Agenda Item 7.0 : Audio SWG

3GPP-S4-123-e    Agenda Item 7.5 : IVAS_Codec (EVS Codec Extension for Immersive Voice and Audio Services)

• TD S4-230453 proposes a listening test experiment to evaluate potential reference conditions for the parametric metadata-assisted spatial audio (MASA) format with degradation anchors spanning both signal and spatial quality dimensions. However, the prolonged test time from asking three questions may result in listener fatigue and puts limitations on the test size.

• TD S4-230560 proposes two experiments, P800-1 and P800-2, to test clean speech and noisy speech respectively. The specific room characteristic and resulting reverb characteristic will be defined by the choice of the specific Spatial Room Impulse Responses used in the convolution process with the raw mono sentences. Each experiment is conducted twice, each time by a different LL.

• TD S4-230561 proposes experiments BS1534-1a and BS1534-1b for Stereo input format, and suggests that experiment 1a covers the mid bitrate range namely 48 and 64kbps and experiment 1b the higher range, i.e., 96 and 128 kbps. Experiments BS1534-3a and BS1534-3b are proposed for Multi-Channel 7.1.4 input format.

• TD S4-230562 proposes experiments BS1534-3a and BS1534-3b for Multi-Channel 7.1.4 input format, and suggests that the two tests allocated for this input format should cover the mid-bitrates and the higher bitrates.

• The listening experiments proposed in TD S4-230453 and the speech experiments proposed in TD S4-230560 involve different test designs and test materials.

• The experiments proposed in TD S4-230561 and TD S4-230562 differ in terms of the input format, bitrate range, and reference conditions used.

• TD S4-230561 proposes the use of BS.1534 MUSHRA tests, while TD S4-230562 proposes the use of BS.1543 MUSHRA tests. Both tests have different requirements for source material and input format.

Example snippets from TD S4-230453:
- "The prolonged test time from asking three questions may result in listener fatigue and puts limitations on the test size."
- "The material collection entity (MC) shall control that the unprocessed raw material (both artificially created and real recorded) meets the requirements defined by SA4, collect a pool of model parameters and sound materials and choose the model parameters and sound materials to be used in the experiments in a randomized blind process."

Example snippets from TD S4-230560:
- "The specific room characteristic and resulting reverb characteristic will be defined by the choice of the specific Spatial Room Impulse Responses used in the convolution process with the raw mono sentences."
- "Each experiment is conducted twice, each time by a different LL."

Example snippets from TD S4-230561:
- "The source finds that the performance for 48kbps with generic audio is also critical and therefore, it is suggested that experiment 1a covers the mid bitrate range namely 48 and 64kbps and experiment 1b the higher range, i.e., 96 and 128 kbps."
- "Experiments BS1534-1a and BS1534-1b give an overview of the experiments for Stereo input as can be seen in the respective rows from Table 5 below."

Example snippets from TD S4-230562:
- "The source finds that the two tests allocated for this input format should cover the mid-bitrates and the higher bitrates."
- "Multi-Channel 7.1.4 input format"

Technical Differences:
1. Public Collaboration: The updated IVAS standardization process includes public collaboration as a key component, which was not present in the previous plan.
- Example snippet: "As a consequence of Public Collaboration, no qualification phase is likely needed with the great benefit of shortening the timeline to arrive at the IVAS codec standard."

2. Number of Candidates: The original plan had 13 candidates, but the updated plan assumes only one single joint candidate resulting from public collaboration.
- Example snippet: "Altogether 13 companies indicated interest to submit a candidate in the IVAS project originally. Also, the working assumption was declared that there will be one single joint candidate (resulting from public collaboration)."

3. Funding Agreement: In the updated plan, proponents of a candidate codec must sign a funding agreement to support the selection and characterization tests financially, which was not mentioned in the original plan.
- Example snippet: "Following the working assumption included in IVAS-6, there will be required to sign a Funding Agreement to be a proponent of a candidate codec. This FA commits the proponent to support the selection and characterization tests financially."

4. Shaded Print: Older activities were put in shaded print in the updated plan, indicating that they are no longer relevant or have been replaced.
- Example snippet: "At the occasion of the recent update, older activities were put in shaded print."

5. Collection of Material: The background material used in selection for EVS was the same as in qualification, whereas for IVAS additional considerations relevant to the codec's performance may be clarified.
- Example snippet: "The duration of each noise file was required to be exactly 5 minutes, the resulting file size is 28.8 MB. The main issue is to define the SNR definition in the stereo and ambisonics case, and to verify that in the mono (downmix) case one would get similar SNR levels as for EVS. Additional considerations relevant for IVAS may be clarified, e.g., microphone placement for car noise recording (see also Annex D of P.1110 for user scenarios), room size and reverberation level for office noise."

6. Recording Car Noise: Car noise is intended to test the performance of the codec under steady-state background noise and should be recorded in a moving car, which is emphasized in the IVAS selection processing plan.
- Example snippet: "Car noise is intended to test the performance of the codec under steady state background noise and should be recorded in a moving car. This aspect could be properly covered in the IVAS selection processing plan (EVS-7a)."

- TDoc S4-230596 proposes an initial test plan for the mixed and music stereo P.800 experiment, P800-3, which assumes pre-mixed content and excludes mono compatible requirements. The experiment evaluates the performances of the IVAS candidate algorithm under FB mixed content and music for clean and impaired channel conditions.
- TDoc S4-230602 suggests testing only against not worse than multi-mono at 4*7.2 kbps audio bandwidth for the clean speech experiment with DTX off due to test plan economics. IVAS operation is required for WB, SWB, and FB audio input-output, and the source believes that environments without and with reverberance should be covered in the tests.
- TDoc S4-230605 highlights the preference for codec references based on multi-EVS coding of Ambisonics inputs over those based on unquantized metadata towards the lower bitrates in P800-8/9. In IVAS Codec selection, there are planned MUSHRA tests with 5.1 input format and Objects using Generic Audio. In P800-8 and P800-9, the DTX and FER conditions are selected to cover a broad range of bitrates.
- TDoc S4-230607 provides more detailed processing descriptions for "Codec reference conditions" based on the use of IVAS MASA C Reference Software tools. The performance requirements for MASA inputs have two types of "Codec reference conditions" that should be tested according to a separate input by the source.

Examples from the original TDoc supporting these differences include:

- TDoc S4-230596: "This contribution suggests an initial test plan for the mixed and music stereo P.800 experiment, P800-3. Proposal It is proposed to integrate the following draft test plan for the P800-3 test (clause X.3) into IVAS-8a."
- TDoc S4-230602: "For the clean speech experiment with DTX off, test plan economics not allow testing both requirementt therefore suggested to test only against not worse than multi-mono at 4*7.2 kbps Audio bandwidth IVAS operation is required for WB, SWB and FB audio input-output."
- TDoc S4-230605: "In IVAS Codec selection, there are planned two MUSHRA tests with 5.1 input format highlighted in the table below: experiments BS1534-2a and BS1534-2b using Generic Audio. In IVAS Codec selection, there are furthermore planned two MUSHRA tests with Objects highlighted in the table below: BS1534-6a and BS1534-6b using Generic Audio."
- TDoc S4-230607: "Figure 3 introduces use of the IVAS MASA C Reference Software for 'Parameter analysis and audio downmix' to derive the MASA format from the decoded FOA for rendering using the common renderer. Figure 2 and Figure 3 present the detailed processing of the MASA 'Codec reference conditions' according to use of the IVAS MASA C Reference Software tools. The performance requirements for MASA inputs have two types of 'Codec reference conditions'."

Technical differences between TDoc S4-230555 and TDoc S4-230557:

Azimuth variations:
- TDoc S4-230555: Azimuth varies continuously for the sentence pair to cover the whole circle starting at a negative sense (clockwise) for adult talker walking around a table and in positive sense (counter clockwise) for the artificially created spatial samples. Different starting azimuths are used for each sentence pair.
- TDoc S4-230557: The azimuth varies continually for two talkers walking around a table in opposite directions, and the same azimuth is used for both talkers for two standing talkers. The absolute azimuths and the difference of the azimuths of both talkers vary for each sentence pair.

Elevation variations:
- TDoc S4-230555: Elevation varies continuously for the sentence pair to cover the interval of -90° to 90°.
- TDoc S4-230557: Standing talkers have an elevation of 35°, and walking talkers have an elevation of 30°.

Database:
- TDoc S4-230555: The listening database consists of artificially created spatial audio samples following scene descriptions. The purpose of the experiment is to evaluate the performances of the IVAS candidate for encoding, decoding, and rendering of a single object with metadata.
- TDoc S4-230557: The listening database consists of artificially created spatial audio samples of conversation-like scenarios between 1 female and 1 male talker. The purpose of the experiment is to evaluate the performances of the IVAS candidate for encoding, decoding, and rendering of two simultaneous objects with metadata.

Example snippets from TDoc S4-230555:
- "Azimuth varies continuously for the sentence pair to cover the whole circle starting at..."
- "Elevation displacement: Elevation varies continuously for the sentence pair to cover the interval of -90° to 90°."
- "The metadata determines the position of the object around the listener in a 3-dimensional space as described in the Scene description section below."
- "The purpose of this experiment is to evaluate the performances of the IVAS candidate for encoding, decoding, and rendering of a single object with metadata."

Example snippets from TDoc S4-230557:
- "To increase positional variation, both the absolute azimuths and the difference of the azimuths of both talkers vary for each sentence pair"
- "The azimuth is the same for both talkers and varies continually"
- "The listening database consists in artificially created spatial audio samples from monophonic clean speech recordings where always 1 female and 1 male talker are combined in conversation-like scenarios"
- "The purpose of this experiment is to evaluate the performances of the IVAS candidate for encoding, decoding, and rendering of two simultaneous objects with metadata."

3GPP-S4-123-e    Agenda Item 7.6 : ATIAS (Terminal Audio quality performance and Test methods for Immersive Audio Services)

3GPP-S4-123-e    Agenda Item 7.7 : eUET (Enhancements to UE Testing)

3GPP-S4-123-e    Agenda Item 7.8 : FS_DaCED (Feasibility Study on Diverse audio Capturing system for End-user Devices)

3GPP-S4-123-e    Agenda Item 7.9 : ISAR (Immersive Audio for Split Rendering Scenarios)

3GPP-S4-123-e    Agenda Item 8.1 : New Work / New Work Items and Study Items

3GPP-S4-123-e    Agenda Item 8.11 : Others including TEI

3GPP-S4-123-e    Agenda Item 8.3 : Reports/Liaisons from other groups/meetings

#1:
- The APP layer triggering of buffer level threshold-based RAN Visible QoE reporting is preferable and will be supported in Rel-18.
- AS layer-based handling of the buffer level threshold-based triggering may be a bit late.
- SA4 asks RAN2 to take the information into account and provide feedback if any.
- Next SA WG 4 meetings: SA4#124 on May 22-26, 2023 in Berlin, Germany and SA4#125 on Aug 21-25, 2023 in Goteborg, SE.

Example snippet: "Hence, SA4 would like to confirm the APP layer triggering of buffer level threshold-based RAN Visible QoE reporting is preferable and will support this feature in Rel-18..."

#2:
- The current API definition on TS 29.581 does not satisfy the requirement for the MBSF to unambiguously indicate the two distinct subcases of pull-based object acquisition to the MBSTF at reference point Nmb2.
- The ObjAcquisitionMethod enumeration may need to be redefined to satisfy the stage2 requirement in TS 26.502.
- SA4 asks CT3 to take the information into account and advise of any resulting change to TS 29.581 by LS reply.

Example snippet: "SA4 notes that the current API definition on TS 29.581 does not satisfy the requirement for the MBSF (acting on behalf of the MBS Application Provider) to be able to unambiguously indicate the two distinct subcases of pull-based object acquisition highlighted above to the MBSTF at reference point Nmb2."

Technical Differences between TDoc S4-230486 and TDoc S4-230495:

1. TDoc S4-230486 discusses the scalability issues related to maintaining EVEX framework extensions across 3GPP releases, while TDoc S4-230495 discusses the preference for the application layer to handle RVQoE reporting based on buffer level.

2. TDoc S4-230486 highlights the issues of logical ownership, common vs. separate frameworks, and workload related to extending and maintaining the data collection, reporting, and exposure framework. In contrast, TDoc S4-230495 focuses on the feasibility of application vs. AS layer handling of RVQoE reporting based on buffer level.

3. TDoc S4-230486 emphasizes SA4's focus on producing media-centric technical specifications, including codecs, content formats, APIs, media handling, and delivery protocols, while TDoc S4-230495 focuses on RAN2's consideration of RVQoE reporting based on buffer level and the preference for application layer handling.

Examples from TDoc S4-230486:

- "Questions the suitability from the scalability perspective for SA4, over time across 3GPP releases, to maintain EVEX framework extensions"
- "Potentially heavy workload imposed on SA4 should it decide to take on the role of extending and maintaining the data collection, reporting and exposure framework going forward"
- "The focus of SA4 should be on investigating the needs of and producing corresponding media-centric technical specifications"

Examples from TDoc S4-230495:

- "The same mechanisms can be used by the application layer to do RVQoE reporting based on buffer level"
- "RAN2 is considering whether triggering of RVQoE reporting based on buffer level should be handled by application layer or AS layer"
- "There is a preference for application handling considering the information is readily available in the application"

Technical Differences:

1. Scope of the EVEX framework:
- SA4 recommends that extensions to the scope of the EVEX framework, such as supporting data analytics to UE Applications, should be handled by other groups.

Example snippet from TDoc S4-230482:
"SA4 recommends that extensions to the scope of the EVEX framework, for example to support the exposure of data analytics to UE Applications (as envisaged by Key Issue #2 in the SA2 FS_AIMLsys Release 18 feasibility study), are handled by other groups."

2. Ndcaf_DataReportingProvisioning service:
- This service is used for provisioning UE data collection, reporting, and event exposure in the Data Collection AF, as specified by SA4 in TS 26.532.
- The northbound exposure of this service is specified by CT3 in clause 5.24 of TS 29.522.

Example snippet from TDoc S4-230482:
"The Ndcaf_DataReportingProvisioning service for provisioning of UE data collection, reporting and event exposure in the Data Collection AF, as specified by SA4 in TS 26.532, as well as northbound exposure of this service by the NEF specified by CT3 in clause 5.24 of TS 29.522."

3. Use of the Naf_EventExposure service:
- This service is defined by SA2 in clause 5.2.19.2 of TS 23.502.
- It is used to expose events to authorized Event Consumer AF instances, as required by SA4 in TS 26.531.
- The southbound exposure of this service is specified by CT3 in clauses 4.2 and 5.1 of TS 29.591.

Example snippet from TDoc S4-230482:
"Use of the Naf_EventExposure service as defined by SA2 in clause 5.2.19.2 of TS 23.502, and as specified by CT3 in TS 29.517, to expose events to authorised Event Consumer AF instances, as required by SA4 in TS 26.531, as well as southbound exposure of this service by the NEF specified by CT3 in clauses 4.2 and 5.1 of TS 29.591."

4. Data collection from the UE Application capability:
- SA4 evaluates whether the existing data collection from the UE Application capability supports the requirements listed by SA6.
- Clause 4.5.2 of TS 26.531 defines a data exposure restriction model for the EVEX framework that satisfies these requirements.

Example snippet from TDoc S4-230483:
"SA4 is pleased to provide the following evaluation of whether the existing data collection from the UE Application capability supports the requirements listed by SA6. Clause 4.5.2 of TS 26.531 defines a data exposure restriction model for the EVEX framework that satisfies these requirements."

5. Reporting UE data directly to an ASP:
- There is nothing to prevent a UE Application from reporting UE data directly to an ASP using application-specific means outside the scope of 3GPP standardization (i.e., at reference point R8 which is defined in TS 26.531 but not further specified and therefore left to implementation).

Example snippet from TDoc S4-230483:
"Notwithstanding the abovementioned design limitations, SA4 observes that there is nothing to prevent a UE Application from reporting UE data directly to an ASP using application-specific means outside the scope of 3GPP standardisation (i.e., at reference point R8 which is defined in TS 26.531 but not further specified and therefore left to implementation)."

Overall, the technical differences among the TDocs relate to the scope of the EVEX framework, the Ndcaf_DataReportingProvisioning service, the use of the Naf_EventExposure service, the capability for data collection from the UE Application, and the possibility of reporting UE data directly to an ASP. These differences are supported by specific examples from the original TDocs.

3GPP-S4-123-e    Agenda Item 8.5 : CRs to features in Release 17 and earlier

TDoc S4-230474:
- Reference point Nmb2 is used by the MBSF to configure and control MBS User Services distribution methods in the MBSTF by invoking the Nmbstf service defined in clause 7.3.
- Reference point Nmb10 is used by the AF/AS to provision MBS User Services in the MBSF by invoking the Nmbsf service defined in clause 7.2.
- Reference point Nmb8 is used by the MBSTF to ingest content from the AF/AS.
- The Object Distribution Method has operating modes for pull-based or push-based object ingest method.

TDoc S4-230475:
- The Media Session Handler issues a request for a URL after successfully retrieving the Service Access Information from the 5GMS AF.
- A 5GMS-Aware Application can pass a complete set of Service Access Information to the Media Session Handler.
- The 5G System operator is responsible for supporting resolution of a well-known host name to the correct IP address(es) in the Trusted DN.
- The Media Session Handler forms the M5 request URL based on the information supplied in the 5GMS Service URL.

TDoc S4-230476:
- The 3GPP Service Handler is invoked in the background by the mobile Operating System via its registered intent filter to handle the URL.
- A name for 3GPP service is proposed to be registered as part of 3GPP specifications and can be referenced under a controlled URL.
- A concrete URL format for 3GPP services 3gpp.org will be specified and ensure that this can be used in the context of 3GPP-based services.
- A suitable website redirection mechanism is proposed in case the URL is not on the device.

TDoc S4-230505:
- Figure C.3.1-1 and C.3.2-1 show DASH content distribution with pull-based and push-based ingest using separate MBS Distribution Sessions.
- The Object ingest base URL is ignored in the pull-based ingest case, and remains empty in the push-based ingest case.
- A location-dependent MBS Serivce allows regional content variants to be distributed to different MBS Service Areas within the scope of a common MBS Session.

TDoc S4-230506: Call flow for MBS User Service provisioning by MBS Application Provider

- The MBS Application Provider can pre-allocate a TMGI for some or all of the MBS Distribution Sessions.
- The MBSF informs the MBS Application Provider of the successful establishment of content ingest for the MBS Distribution Session.
- The MBS User Data Ingest Session comprises the details of one or more MBS Distribution Session(s).

TDoc S4-230507: MBS Object Repair Parameters metadata unit

- An Object Repair Parameters document for the object repair procedures may be delivered to MBS Clients.
- The Object Repair Parameters document is identified using a URI.
- The most recently delivered Object Repair Parameters document takes priority.
- The MBS Client may use the Object Repair service to fetch missing portions of an object.

TDoc S4-230548: Object Distribution Method

- Object carousel operating mode refers to the case in which one or multiple objects are distributed via the Object Distribution Method in a repeated fashion.
- Object collection operating mode refers to the case in which multiple objects are distributed via the Object Distribution Method.
- MBS Distribution Session should be provisioned to accommodate the bit rate of the aggregated object flow.
- The FDT Instance should describe all objects that are currently available in the FLUTE Session.

TDoc S4-230575: 3GPP Service Handler

- 3GPP Service Handler is installed and invoked in the background by the mobile Operating System via its registered intent filter to handle the URL.
- 3GPP service can be established in the background and potentially connects to the network.
- 3GPP service can be registered under a controlled URL and a concrete URL format is specified.
- A website/redirection mechanism is specified in case the URL is not on the device.
- Handling non-3GPP URLs in common devices is not broadly supported by commonly available high-level UE Operating Systems and HTTP-based URL handling is preferred.

Table 7.6.3.1-1 specifies the data model for the ContentHostingConfiguration resource.

Table 11.2.3.1-1 specifies the data model for the ServiceAccessInformation resource, which has different properties depending on the type of Provisioning Session.

The Applicability column in Table 11.2.3.1-1 specifies which properties are present in the ServiceAccessInformation resource based on the type of Provisioning Session.

TDoc S4-230503 references documents that contain provisions for the infoBinding element, which includes child elements for serviceArea, mbsFSAId, and radiofrequency.

The serviceArea element in the infoBinding element declares one or more service areas where the MBS Session is currently available.

The userServiceDescription element may include an availabilityInfo child element that provides additional information about the availability of the MBS Distribution Session within the 5G Network.

The radioFrequency element indicates one or more radio frequencies in the NG-RAN downlink that transmit the MBS Session in the service area(s) identified by the serviceArea element.

The mbsFSAId element in the infoBinding element identifies a preconfigured area where the cell(s) announce the MBS FSA ID and its associated frequency for a broadcast MBS Session.

The M1_ContentHostingProvisioning API is specified in C.3.5.

The M5_ServiceAccessInformation API is specified in C.4.1.

1. TDoc S4-230456 defines a generic provisioning envelope for data collection and reporting, while TDoc S4-230457 defines a generic reference architecture for data collection and reporting.
- Example from TDoc S4-230456: "A generic data collection and reporting configuration envelope is defined in clause 4.6.3 of the present document, but details of the configuration are specific to individual reporting domains and are specified elsewhere."
- Example from TDoc S4-230457: "This clause defines a generic reference architecture for data collection and reporting that satisfies those procedures, including the logical functions involved and the logical reference points between them."

2. TDoc S4-230456 describes interactions between the Direct Data Collection Client and the Data Collection AF, while TDoc S4-230457 describes the set of UE data to be collected and exposed by the Data Collection AF.
- Example from TDoc S4-230456: "Used by a Direct Data Collection Client instance to obtain its data collection and reporting configuration from the corresponding Data Collection AF instance by means of the Ndcaf_DataReporting service defined in clause 4.4 of the present document."
- Example from TDoc S4-230457: "The set of UE data to be collected and exposed by the Data Collection AF is determined by the intersection between its provisioning state provided at R1 and the current set of subscriptions."

3. TDoc S4-230456 specifies details of the data collection and reporting configuration, while TDoc S4-230457 focuses on the logical functions involved in data collection and reporting.
- Example from TDoc S4-230456: "Each data report provides the external application identifier associated with the UE Application and also includes a non-empty list of data reporting records containing the parameters collected by the data collection client."
- Example from TDoc S4-230457: "The reference architecture may be instantiated separately in different slices of a network."

4. TDoc S4-230456 emphasizes individual reporting domains, while TDoc S4-230457 emphasizes the needs of different features of the 5G System.
- Example from TDoc S4-230456: "This is expected to be extended by individual reporting domains."
- Example from TDoc S4-230457: "It is intended that this reference architecture be instantiated in domain-specific ways to suit the needs of different features of the 5G System."

5. TDoc S4-230456 focuses on the Direct Data Collection Client, while TDoc S4-230457 focuses on the Data Collection AF.
- Example from TDoc S4-230456: "Subsequently used by the Direct Data Collection Client to send reports to its Data Collection AF instance by means of the Ndcaf_DataReporting service defined in clause 4.4 of the present document."
- Example from TDoc S4-230457: "The Data Collection AF is responsible for ensuring that access to UE data is controlled according to the rules indicated in its provisioning state."

3GPP-S4-123-e    Agenda Item 8.6 : SR_MSE (Split Rendering Media Service Enabler)

3GPP-S4-123-e    Agenda Item 8.7 : 5GMS_Ph2 (5G Media Streaming Architecture Phase2)

Technical Differences and Example Snippets from TDocs:

1. Service Access Information vs. Object Schedule Information

Service Access Information pertains to the set of parameters and addresses that are required by a 5GMS Client to activate the reception of a downlink media streaming session or the transmission on an uplink media streaming session, perform dynamic policy invocation, consumption reporting and/or metrics reporting, and request AF-based network assistance. On the other hand, Object Schedule Information is defined in terms of schedule description that may be delivered to the MBS Client prior to the MBS Distribution Session as part of the MBS User Service Announcement, within an MBS Distribution Session, or via an MBS Distribution Session dedicated to the transport of Schedule Description instance documents.

Example Snippets from TDocs:
- "The Provisioning Session, including eligibility criteria that indicate the circumstances in which edge computing is to be used for Media Streaming sessions associated with this Provisioning Session and parameters indicating the tolerance of the application for relocation of the Edge AS" (TDoc S4-230534)
- "The metadata itself describes details of services" (TDoc S4-230535)

2. Consumption Reporting Configuration vs. Application Service Entry Point Document

Consumption Reporting Configuration pertains to the parameters for reporting consumption of a downlink streaming session when the dynamic policy invocation feature is activated. These parameters are present in addition to the Service Access Information. Meanwhile, Application Service Entry Point Document is referenced in the MBS User Service Description and requires the presence of at least one MBS Distribution Session Description of type Object Distribution Method as well as a mapping between the Application Service Entry Point document and the associated MBS Distribution Session.

Example Snippets from TDocs:
- "When the dynamic policy invocation feature is activated for a downlink streaming session the parameters from Table 4.2.33 below are additionally present" (TDoc S4-230534)
- "If the MBS User Service Description contains a reference to an Application Service Entry Point document, then: 1) At least one MBS Distribution Session Description of type Object Distribution Method shall be present...2) When multiple MBS Distribution Session Descriptions of type Object Distribution Method are present, the appServiceDescription element shall define a mapping between the Application Service Entry Point document and the associated MBS Distribution Session" (TDoc S4-230535)

Overall, these technical differences highlight the varying parameters and requirements for different aspects of 5GMS, such as service access information, consumption reporting configuration, and object schedule information. These differences may affect the implementation and functionality of 5GMS components and should be carefully considered for efficient and effective use of the technology.

Technical Differences and TDoc Examples:

1. Metrics Measurement and Logging Client vs. Consumption Reporting Configuration
- The Metrics Measurement and Logging Client measures and logs QoE metrics while the Consumption Reporting Configuration measures and logs content consumption-related information.
- TDoc S4-230472: "Performs the measurement and logging of content consumption-related information in accordance with the Consumption Reporting Configuration part of provisioning data"
- TDoc S4-230531: "Performs the measurement and logging of QoE metrics in accordance with the Metrics Reporting Configuration part of provisioning data"

2. DRM Client (optional) vs. No Mention of DRM Client
- The DRM Client, when present, compresses the media data.
- TDoc S4-230472: "DRM Client (optional): When present, the DRM client might or might not be a part of the Media Player. Compresses the media data."
- TDoc S4-230531: No mention of the DRM Client.

3. Network Assistance vs. No Mention of Network Assistance
- Network Assistance provides uplink streaming delivery assisting functions such as bit rate recommendation and delivery boost.
- TDoc S4-230472: "Network Assistance: uplink streaming delivery assisting functions provided by the network to the 5GMSu Client and Media Streamer in the form of bit rate recommendation (or throughput estimation) and/or delivery boost."
- TDoc S4-230531: No mention of Network Assistance.

4. AS Instances vs. No Mention of AS Instances
- AS Instances refer to instances of Application Server.
- TDoc S4-230531: "5GMSd Application Provider queries the capabilities and authorized features. AS instances."
- TDoc S4-230533: No mention of AS Instances.

5. Modification of Media Player Entry vs. Media Content Announcement
- Modification of Media Player Entry happens under the direction of the 5GMSd AF to indicate content availability while Media Content Announcement happens when media content is announced to the 5GMSd-Aware application.
- TDoc S4-230533: "The 5GMSd AS modifies the Media Player Entry (typically a media presentation manifest) under the direction of the 5GMSd AF to indicate that content is available either on a the MBS Client's local Media Server or on 5GMSd AS."
- TDoc S4-230533: "The media content is announced to the 5GMSd-Aware Application and the application request the entry points for the service."

6. Figure 5.X.2-1 vs. Prerequisites
- Figure 5.X.2-1 shows the high-level procedure for DASH content delivery via MBS while Prerequisites outline the necessary steps before the procedure can be done.
- TDoc S4-230533: "Figure 5.X.2-1: High-level procedure for DASH content delivery via MBS"
- TDoc S4-230533: "Prerequisites (step 0): - The 5GMSd Application Provider has provisioned the 5G Media Streaming System, including content ingest and the authorization to distribute 5GMS content via MBS."

3GPP-S4-123-e    Agenda Item 8.8 : FS_SmarTAR (Feasibility Study on Smartly Tethering AR Glasses)

3GPP-S4-123-e    Agenda Item 8.9 : FS_MS_NS_Ph2 (Study on Media Streaming aspects of Network Slicing Phase 2)

3GPP-S4-123-e    Agenda Item 9.5 : MeCAR (Media Capabilities for Augmented Reality)

TDoc S4-230527:
- Proposes to add gaze point and gaze distance to interaction metadata
- Examples of processes include split rendering function rendering objects near gaze point with higher quality, providing depth of field effect for objects farther or closer than gaze distance, and delivering gaze point and distance for foveated processing
- Supports differentiation of processes based on whether object is focused or not

TDoc S4-230540:
- Outlines version numbering system for document modifications
- Scope and references sections provided
- Definitions of terms, symbols, and abbreviations section provided
- Defines terms from 3GPP TR 21.905 and other relevant documents
- Notes that contents of document are subject to change following TSG approval

TDoc S4-230541:
- Figure 5.2.3-1 shows typical latencies in networked AR services with OPs
- Processes in rendering loop must ensure end-to-end latency requirements for pose-to-render-to-photon latency are met
- Other types of latencies impact user experience, especially with cloud gaming, interactive scenes, or real-time network-based processing of sensor data
- References Microsoft Coordinate Systems and 3GPP TR 26.998

TDoc S4-230549:
- Split Rendering Client that complies with Pixel Streaming profile must support simultaneous decoding of two bitstreams and may support three
- Split Rendering Server that complies with Pixel Streaming Profile must support rendering for projection and cubemap composition layer configurations
- Split Rendering Client must support decoding and extraction of auxiliary pictures and alpha channel and depth representation information SEI messages

TDoc S4-230571:
- XR Baseline Client is composed of XR application, XR Runtime, and Media Access Function
- XR Runtime performs commonly required operations and interfaces with platform
- Media Access Function enables access to media and XR-related data
- Instantiation of XR Baseline Client left for Work Items and Study Items to define
- Provides functionality of RTC-5 interface as defined by TS26.506.

- A V3C video operation point and a rendering metadata operation point should be defined when defining V3C support. The Reconstruction profile component describes conformance point B, specifying the pre-reconstruction, reconstruction, post-reconstruction, and adaptation tools supported or recommended to achieve conformance in terms of 3D reconstruction.
- The upstream RGBD transmission may include split rendering, where any application offloads (part of) the rendering process to a processor connected to -but not located on- the AR UE.
- On-demand content can be prepared in advance for consumption from an AR device, in such cases, the complexity of generating the content is not very important, compared to the asset size (to conserve bandwidth) and complexity of displaying the content (to conserve AR device battery).
- A MeCAR device may support additional functionalities of XR Runtime or other APIs beyond the minimum set supported, 3D rendering capabilities that allow to render point clouds, meshes, depth, etc. present in the scenes, additional audio and video encoding and decoding capabilities, decoding of streaming formats encapsulated in CMAF, and capabilities to be exchanged with the network in order to support cloud/edge rendering.
- The specification introduces three methods for storing V3C-coded content in ISOBMFF, where each mode defines a number of sample entries that impose certain constraints on the track(s) supported by that mode and a specific sample format for these tracks in addition to other mode-specific tools. In the case of MPEG-DASH, the standard defines how to signal V3C content in the Media Presentation Description (MPD) for both the single-track and multi-track encapsulation modes, including defining V3C-specific DASH descriptors, and defines restrictions on the DASH segments generated for the content.

Example snippets:

- "The Reconstruction profile component describes conformance point B, specifying the pre-reconstruction, reconstruction, post-reconstruction, and adaptation tools supported or recommended to achieve conformance in terms of 3D reconstruction." (from TDoc S4-230576)
- "The upstream RGBD transmission may include split rendering, where any application offloads (part of) the rendering process to a processor connected to -but not located on- the AR UE." (from TDoc S4-230621)
- "On-demand content can be prepared in advance for consumption from an AR device, in such cases, the complexity of generating the content is not very important, compared to the asset size (to conserve bandwidth) and complexity of displaying the content (to conserve AR device battery)." (from TDoc S4-230621)
- "A MeCAR device may support additional functionalities of XR Runtime or other APIs beyond the minimum set supported, 3D rendering capabilities that allow to render point clouds, meshes, depth, etc. present in the scenes, additional audio and video encoding and decoding capabilities, decoding of streaming formats encapsulated in CMAF, and capabilities to be exchanged with the network in order to support cloud/edge rendering." (from TDoc S4-230622)
- "The specification introduces three methods for storing V3C-coded content in ISOBMFF, where each mode defines a number of sample entries that impose certain constraints on the track(s) supported by that mode and a specific sample format for these tracks in addition to other mode-specific tools." (from TDoc S4-230623)

[TDoc S4-230577]: Potential implementations
- UE needs to signal type and dimensions of visualization space
- Server can downscale 3D scene to fit rendering volume
- Complex and precise space can be defined with LiDAR sensors
- Available rendering space can be calculated by device or server
- Server can clip scene and only send virtual objects fully present in rendering volume
- AR experience may be unreal due to perceived collision between virtual objects and real environment
- Server can ensure virtual objects fit into available rendering space

[TDoc S4-230581]: Action and timestamp information
- Action identifiers handled by scene manager and rendered in associated media frame
- sceneUpdateTime: time when scene manager processes interaction task and updates scene
- startRenderTime: time when renderer in Split Rendering Server starts rendering media frame
- renderedFrameTxTime: time when Split Rendering Server sends rendered media frame to device
- Raw user action acquired from XR runtime by XR source management
- acceptable delay may differ according to use case and type of interaction

[TDoc S4-230582]: Pose estimation and split rendering loop
- Split render function in server may refer to pose-to-render-to-photon delay for estimation of new pose
- If multiple pairs of pose and metadata for same target display time received from device, split render function may select pose closest to display time
- Previous render-to-photon delay from most recent frame information can help server make selection
- Pose and timestamp information includes location and direction information when pose estimation was made
- targetdisplaytime is estimated target display time for rendered media frame

[TDoc S4-230591]: XR Baseline Client functionalities
- XR application: software application that integrates audio-visual content into user's real-world environment
- XR Runtime: set of functions that interface with platform to perform commonly required operations
- Media Access Function: set of functions that enables access to media and other XR-related data
- XR Source Management: management of data sources provided through XR runtime such as microphones, cameras, trackers, etc.

3GPP-S4-123-e    Agenda Item 9.6 : FS_XRTraffic (Feasibility Study on Typical Traffic Characteristics for XR Services and other Media)

3GPP-S4-123-e    Agenda Item 9.7 : FS_AI4Media (Feasibility Study on Artificial Intelligence (AI) and Machine Learning (ML) for Media)

Technical Differences among TDocs:

1. TDoc S4-230584: [FS_AI4Media] Frameworks for evaluation:
- The framework should provide a set of HW acceleration APIs to access GPU, TPU, etc.
- Supported models can be converted from/to ONNX format.
- TensorFlow/Keras is widely used by the community while PyTorch is popular in the research community.

2. TDoc S4-230585: [FS_AI4Media] Models for evaluation:
- The selected models should be compatible with a list of selected library/framework(s) for running the models.
- Pre-trained models are not available from the frameworks but from external sources like GitHub.
- The focus is on the most popular models like the ResNet model family for object detection tasks.

3. TDoc S4-230587: [FS_AI4Media] Intermediate data testbed architecture:
- A testbed architecture is proposed for the evaluation of intermediate data as a baseline for the implementation of one or several Intermediate data testbeds.
- The evaluation can consider different protocols to be used in the uplink and downlink, as well as real-world emulation constraints.
- Different means for delivery and access of intermediate data can be selected.

4. TDoc S4-230588:
- Split points model configuration contains the list of candidates split point.
- Remote inference is made by decode_predictions().
- The local inference is made by the remote inference node.
- Different means for delivery and access of intermediate data may be selected.
- The VGG16 model is imported with pre-trained weights.

Example snippets supporting the differences:

1. TDoc S4-230584:
- "The framework shall provide a set of HW acceleration APIs to access GPU, TPU, etc …"
- "Supported models. NNEF tools can convert trained models from/to ONNX format [14]"
- "TensorFlow/Keras is widely used by a large community which has generated a strong documentation while PyTorch is most popular in the research community."
- "Both most popular frameworks support ONNX, and tools for porting PyTorch model into TensorFlow or vice-versa."

2. TDoc S4-230585:
- "The selected models should be compatible with a list of the selected library/framework(s) for running the models."
- "Pre-trained model not available from the frameworks but from an external source, for instance GitHub."
- "We suggest focusing primarily on the most popular AI/ML models, for example the ResNet model family for object detection tasks."

3. TDoc S4-230587:
- "An architecture for evaluation of intermediate data is represented in the figure above."
- "This may include selection of different means for delivery and access of intermediate data."
- "The evaluation can consider different protocols to be used in the uplink and downlink, as well as real-world emulation constraints."

4. TDoc S4-230588:
- "Split points model configuration contains the list of candidates split point."
- "Remote inference is made by: decode_predictions() is a tool that return the class names and probabilities, fort example of the first top 3 best predictions."
- "The local inference is made by: Remote inference node."
- "Different means for delivery and access of intermediate data may include selection of different protocols to be used in the uplink and downlink."
- "The VGG16 model is imported with following code: “base_model” is the full model VGG16 with pre-trained weights."

[TDoc S4-230510]:
- The appropriate split points for AI/ML models used for AR Glass processing are identified before selecting a suitable split point for the service instance.
- A split inference configuration is negotiated at the start of the application service.
- Streaming protocols such as TCP/UDP and packetization methods such as RTP are related to split inference configuration.

[TDoc S4-230553]:
- Relevant metrics for evaluating solutions for the scenario are provided.
- Scenarios should be prioritized based on their feasibility within a reasonable time frame.
- DNN models and data sets used for evaluation are specified.
- Latency, bitrate, and recall are factors to consider for evaluating feasibility and accuracy.

[TDoc S4-230592]:
- Tensors are used to represent input data and parameters of the machine learning model.
- Variables represent the parameters of the machine learning model and are updated during training to improve performance.
- Variables used in the computational graph need to be initialized before running.

[TDoc S4-230593]:
- ONNX allows for models to be trained in PyTorch and exported to be executed in other frameworks.
- TensorFlow uses a static computational graph, while PyTorch uses a dynamic computational graph.
- TensorFlow is more commonly used in industry for production-level applications, while PyTorch is more popular in the research community.
- TensorFlow provides comprehensive visualization tools, while PyTorch allows for more flexibility in building and modifying the graph during runtime.

Examples supporting these differences:
- TDoc S4-230510: "streaming protocols such as TCP / UDP" and "packetization methods such as RTP" are related to split inference configuration.
- TDoc S4-230553: "DNN models that will serve for building anchors for this scenario" and "data sets that will be used for the evaluation of this scenario" are specified for the evaluation of the scenario.
- TDoc S4-230592: "variables used in the graph need to be initialized" and "tensors are used to represent the input data and the parameters of the machine learning model".
- TDoc S4-230593: "TensorFlow uses a static computational graph" and "PyTorch supports dynamic computation graphs".

- TDoc S4-230508 focuses on identifying media service architectures, service flows, operation configurations, data formats, and traffic characteristics for AI/ML in media-related services, as well as studying key performance indicators for these scenarios.
- Example from TDoc S4-230508: "List and describe the use cases for media-based AI/ML scenarios, based on those defined in TR 22.874."
- TDoc S4-230509 discusses interoperability considerations for delivering AI models and corresponding data, including compression or optimization constraints and performance metrics.
- Examples from TDoc S4-230509: "Model size and comparison ratio of the test split model to be delivered (compared to reference model)" and "Compression ratio of the compressed model compared to the original reference model."
- TDoc S4-230511 outlines the process for calculating inference latencies for split AI/ML services, establishing delivery pipelines, and negotiating split points between the UE and network.
- Example from TDoc S4-230511: "The 5GAI client request the AI data to be delivered from the 5GAI AS."
- TDoc S4-230589 describes scenarios for local image and video capture and inference, as well as evaluating the impact of intermediate data optimization and compression techniques.
- Example from TDoc S4-230589: "Privacy preserving of AI service from an image captured by the local device when inference starts from local node."

3GPP-S4-123-e    Agenda Item 9.8 : FS_ARMRQoE (Feasibility Study on AR and MR QoE Metrics)

3GPP-S4-123-e    Agenda Item 9.9 : New Work / New Work Items and Study Items

3GPP-S4-123-e    Agenda Item 10.1 : FS_eiRTCW (Feasibility Study on the enhancements for immersive Real-time Communication for WebRTC)

3GPP-S4-123-e    Agenda Item 10.11 : Others including TEI

3GPP-S4-123-e    Agenda Item 10.4 : CRs to features in Release 17 and earlier

3GPP-S4-123-e    Agenda Item 10.5 : iRTCW (immersive Real-time Communication for WebRTC)

TDoc S4-230450 highlights the technical differences among different functionalities that may be offered by a WebRTC application server, including:

- Content server functionality that serves content to the WebRTC application through a data channel
- Media processing functionality that can be used by the WebRTC application as a relay to perform transcoding, recording, 3D reconstruction, etc.
- Scene composition functionality that allows the server to compose a 3D scene and distribute it to multiple WebRTC sessions
- MCU functionality that offers multi-party conferencing functionality to merge several point-to-point WebRTC sessions
- SFU functionality that offers the selection, copy, and forwarding of IP streams produced by multiple WebRTC endpoints

TDoc S4-230526 focuses on requirements for bidirectional conversational dynamic 3D representation, including:

- Call setup and control, which includes signaling to set up a call or conference and relaying information to the support function
- Activation that integrates audio, video, and interactive information in a data channel to animate a 3D avatar
- Use of volumetric-types to represent generic people, which can be generated in the media server due to non-real-time requirements
- Use of video pre-processors and encoders to fetch expression information and compress input from an RGBD camera during the session

Finally, TDoc S4-230574 highlights ongoing work on defining V3C as a possible encoding format for volumetric content for different device types in MeCAR. This includes:

- Use of V3C for compressing point clouds and animating avatars
- Required pipelines for V3C delivery
- Use of volumetric-types to represent generic 3D objects or arbitrary people

Example snippets from the original TDocs supporting these differences include:

- TDoc S4-230450: "the server may offer multi-party conferencing functionality to merge a number of point-to-point WebRTC sessions"
- TDoc S4-230526: "Activation needs to integrate audio, video and interactive information in data channel to animate a 3D avatar"
- TDoc S4-230574: "There are standards, such as V3C, that can be used for compressing point clouds [21]."

Technical differences among the TDoc snippets:

1. TDoc S4-230451:
- Proposal to proceed with Rel-18 WI iRTCW with specific deliverables
- Includes a four-step process for each track: Review, Progress, Draft, Agree
- A permanent document is created after each track with key contents, tentatively agreed texts, and open issues
- Specifies TS 26.113 Enabler for Immersive Real-time Communication V2.0.0 and attached files
- Focuses on solutions and updates for TS 26.113

Example snippets from TDoc S4-230451:
- "It is proposed to proceed Rel-18 WI iRTCW with the following deliverables: TS 26.113 Enabler for Immersive Real-time Communication V2.0.0 (If any) files to be attached to TS 26.113"
- "Each track follows a four-step process: Review, Progress, Draft, Agree"
- "A permanent document including key contents, tentatively agreed texts, and open issues that may necessitate further works in RTC or other SA4 SWGs, 3GPP WGs, or other organizations."

2. TDoc S4-230626:
- Plans to identify minimum information/elements for establishing media sessions with appropriate QoS for WebRTC-based applications
- Coordination with other WGs, such as SA2, RAN1, and RAN2, for interworking of iRTC clients with 5G systems
- Request for feedback on iRTCW signaling protocol and coordination with CT groups
- Focuses on the development of iRTCW signaling

Example snippets from TDoc S4-230626:
- "In particular, it is planned to identify the minimum information / elements in the control/user (C/U)-Plane signal to establish media sessions with appropriate QoS for WebRTC-based applications; coordination with other WGs, e.g., SA2, RAN1, and RAN2, is identified for the interworking of iRTC clients with 5G systems."
- "SA4 would kindly ask to provide feedback on the iRTCW signaling protocol under investigation in SA4 and how such iRTCW signalling should be developed in coordination with CT groups."

1. The 5G-RTC AF can use either Npcf_PolicyAuthorization API over N5 or Nnef_AFSessionWithQoS over N33 interface to request dynamic policy allocation with the PCF.

- "The API defines a set of data models, resources, and related procedures for the creation and management of the dynamic policy request."

2. The Dynamic Policies API is accessible through the following URL base path: {apiRoot}/3gpp-rtc5/{apiVersion}/dynamic-policies/

- "The table below specifies the operations and the corresponding HTTP methods that are supported by this API."

3. The Dynamic Policy resource contains a serviceDataFlowDescription property that contains the service data flow template according to TS 23.503.

- "The PDUSetMarking object is defined in the following table."

4. The policyTemplateId is used to identify the Policy Template to which the Dynamic Policy Instance is associated.

- "The requested QoS parameters shall be within the limits of the provisioning QoS Policy Template."

5. The type of the application message should be a URN that uniquely identifies the application message type.

- "Application-specific message may be defined by the application and exchanged between the endpoints of a WebRTC session."

6. A key derivation mechanism is used to provide integrity and confidentiality protection.

- "For encryption, the derived key is used to encrypt the message payload."

7. The XR application consists of several components, including a Presentation Engine and a Media Access Function.

- "In the case of iRTCW, the UE will typically contain a WebRTC stack and a WebRTC signaling function client that will set up the WebRTC session."

8. The WebRTC API is considered part of the Media APIs that allow the XR Application to communicate with the WebRTC Stack.

- "For example, in the case of a pure 2D application, the XR Runtime may not be present."

9. MeCAR has developed a client architecture for XR services and applications that consists of several main components.

- "Some blocks of this reference architecture may be optional."

Overall, the technical differences among the TDocs relate to the specific APIs, data models, procedures, and components used in different aspects of 5G-RTC AF, dynamic policy allocation, URN identification for application messages, key derivation for integrity and confidentiality protection, and the XR application and client architecture.

TDoc S4-230449:

- iRTC client in terminal flow proposed to illustrate media, data, and signal flow
- Media pre/post-processors present but not within scope of standards
- Sensor output input to media post-processors or sent
- Device information input to media pre-processors
- Paths from media encoder to data channel and from data channel to media decoder
- Notable differences from MTSI functional components

Example: "Media pre/post-processors are present but are not within the scope of standards" is supported by the editor's note explaining that codec and protocol issues should be referred to TS 26.119 and 26.522.

TDoc S4-230452:

- 5 functional components: General, Audio, Video, Sensor, Transport protocols
- Description of sensors supporting operation of generic iRTC client in terminal
- Integration of WebRTC into 5G system
- Inter-working an iRTC client in terminal with another client connected to 3GPP

Example: "Description of sensors supporting operation of generic iRTC client in terminal" is supported by the functional component titled "Sensor" and its editor's note.

3GPP-S4-123-e    Agenda Item 10.6 : IBACS (IMS-based AR Conversational Services)

3GPP-S4-123-e    Agenda Item 10.7 : GA4RTAR (Generic architecture for Real-Time and AR/MR media)

- The STUN or TURN server in ICE function can extract the 5-Tuple information for each media session and convey the information to the Network Support AF in 5G-RTC AF.
- The Network Support AF uses the N5 interface to request QoS allocation and may have a provisioning session created by the AP with the MNO.
- In the client-driven approach, the WebRTC Application is aware of the support of edge processing in the network and uses EDGE-5 APIs to discover and locate a suitable 5G-RTC AS instance in the Edge DN.
- In the Application Function driven approach, the 5G-RTC Application Provider requests the deployment of edge resources as part of the Provisioning Session.
- If the Network support function feature is supported in the 5G-RTC AF, then the Network Support Function AF shall offer the bitrate recommendation request API based on existing policy templates.
- The WebRTC Application may connect to the selected TURN server and/or Media Function in the “5G-RTC AS” through the RTC-4m interface and real-time streaming starts.

Example snippets from the original TDoc:

- "The STUN or TURN server in ICE function, upon reception of the allocation request by the application (or WebRTC framework) may extract the 5-Tuple information for each of the media sessions and convey the information to the Network Support AF in 5G-RTC AF." (TDoc S4-230499)
- "The Network Support AF uses the N5 interface to request QoS allocation. A provisioning session may have been created by the AP with the MNO." (TDoc S4-230499)
- "In the client-driven approach, the WebRTC Application aware of the support of edge processing in the network and takes steps, such as using the EDGE-5 APIs, to discover and locate a suitable 5G-RTC AS instance in the Edge DN." (TDoc S4-230567)
- "In the Application Function driven approach, the 5G-RTC Application Provider requests the deployment of edge resources as part of the Provisioning Session." (TDoc S4-230567)
- "If the Network support function feature is supported in the 5G-RTC AF, then the Network Support Function AF (NS-AF) shall offer the bitrate recommendation request API based on existing policy templates." (TDoc S4-230609)
- "The WebRTC Application may connect to the selected TURN server and/or Media Function in the '5G-RTC AS' through the RTC-4m interface and real-time streaming starts." (TDoc S4-230609)

3GPP-S4-123-e    Agenda Item 10.8 : 5G_RTP (5G Real-time Transport Protocols)

Technical Differences among TDoc S4-230487, S4-230501, and S4-230512:

TDoc S4-230487: RTP Header Extension for PDU Set Information

- The RTP HE carries PDU Set Sequence Number (PSSN), End bit (E), and PDU Sequence Number within a PDU Set (PSN).
- The RTP header extension for PDU set information can be negotiated between an Application Server, MRF or MCU and UE for a downlink stream using the URN urn:3gpp:pdu-set-info in the SDP extmap attribute.

Example: "An RTP header extension (HE) for PDU set information may be negotiated between an Application Server, MRF or MCU and UE for a downlink stream using the URN urn:3gpp:pdu-set-info in the SDP extmap attribute."

TDoc S4-230501: Video Frame Identification Based on RTP Header Fields

- The Indication of End PDU of a PDU Set and PDU SN within a PDU Set/frame can be derived using the "M" bit and the sequence number in the RTP header.
- The start/end of the PDU Set can be identified based on the NAL unit type and the FU header, as well as the PACI header and PACI payload NAL unit.

Example: "According to RFC 6184 [4], within the RTP packet, the NAL unit type in the NAL unit header can indicate the content of NAL unit, e.g. coded slice of an I frame, coded slice of a P frame, and also the possible structures of the RTP payload, e.g. single NAL unit packet, aggregation packet and fragmentation unit (FU)."

TDoc S4-230512: Syntax and Semantics of Grouping Parameters

- The 3gpp-group-id attribute can be used to assign a group-identification-tag when using IETF defined groups with the a=group SDP attribute.
- The group-identification-tag shall be unique in the SDP and is used for identifying the group.
- Only group-type defined by the 5G_RTP specification shall be used.

Example: "When using IETF defined groups with the a=group SDP attribute, a group-identification-tag may still be assigned using the attribute 3gpp-group-id with the following syntax: 3gpp-group-id = 'a=group-id:' group-identification-tag."

Technical Differences and Example Snippets:

1. Paced Sending:
- The pacer sets the sending time of the next packet/group of packets in paced sending.
- Idle time is determined by the pacer, taking into account the other constraints such as frame rate.
- "In the case of paced sending, the pacer sets the sending time of next packet/group of packets, meaning that the idle time is determined by the pacer, taking into account also the other constraints such as frame rate." (TDoc S4-230546)

2. End of Data Burst:
- SMF should request UPF to detect the last PDU of the data burst and mark the End of Data burst in the GTP-U header of the last PDU in downlink.
- The End of Data burst may vary from burst to burst depending on the variations in frame rate and when a PDU set is made available by the encoder.
- "Session Management Function (SMF) should request the UPF to detect the last PDU of the data burst and mark the End of Data burst in the GTP-U header of the last PDU in downlink, according to the PCC rule and/or the local operator policies. However, it may vary from burst to burst depending on the variations in frame rate and when a PDU set (slice or frame) is made available by the encoder, which may depend on the scene complexity." (TDoc S4-230546)

3. CDRX:
- CDRX allows UEs to temporarily stop monitoring the wireless channel when there is no downlink traffic during the Connected state (RRC_CONNECTED).
- "The central concept of CDRX is to allow UEs to temporarily stop monitoring the wireless channel when there is no downlink traffic during the Connected state (RRC_CONNECTED)." (TDoc S4-230546)

4. Media Component QoS:
- The dynamic policy information that is configured by the MSH for the session contains the MediaComponentQoS object, which includes the mapping of the Media Sub-components.
- The QoS policy template is extended to include a name for each sub-component of the session.
- "The dynamic policy information that is configured by the MSH for the session contains the following information: The MediaComponentQoS object contains the following information: Mapping of the Media Sub-components The QoS policy template is extended to include a name for each sub-component of the session." (TDoc S4-230558)

5. Signaling Usage of PDU Set and End of Burst Marking:
- The marking of XR traffic is a mechanism that helps the network to identify XR traffic and optimize its delivery.
- An intermediate server, such as a trusted WebRTC signaling server or a P-CSCF, is able to inspect the SDP offer/answer and extract the information related to the PDU Set and End of Burst marking.
- "The marking of XR traffic is a mechanism that helps the network to identify XR traffic and optimize its delivery. An intermediate server, namely a trusted WebRTC signaling server or a P-CSCF, is able to inspect the SDP offer/answer and extract the information related to the PDU Set and End of Burst marking." (TDoc S4-230558)

6. Usage of End of Burst Indication:
- The UPF indicates the usage of End of Burst Indication (EOBI) by inserting it in the GTP-U header in the last PDU of the last PDU set based on implementation-specific mechanisms to detect the end of the data burst or based on explicit indications from the AS.
- Each codec has various profile and layer configurations, so the RTP packetization would need to extract high-level syntax parameters to signal the end of PDUs/PDU set.
- "The usage of EOB is indicated by UPF such as: 'inserting the EOBI (End of Burst indication) in the GTP-U header in the last PDU of the last PDU set based on implementation-specific mechanisms to detect the end of the data burst, or based on explicit indications from the AS. For example, an AP includes 2 NAL units, the first NAL unit is the end PDU in a PDU set but belongs to the same RTP packet which also includes the beginning of another PDU set. Each codec has various profile and layer configurations, it would be required for the RTP packetization to extract high-level syntax parameters to signal the end of PDUs/PDU set." (TDoc S4-230601)

7. UPF Configuration for PDU Set Information Identification:
- The AF may configure PDU set information RTP HE usage in an RTP session in PCF for a given QoS flow, e.g., through the NEF.
- The AF and AS negotiate the usage of RTP HE for transmitting the PDU set information between them during a media session and inform the network about the support for PDU set information.
- "For a given QoS flow, the AF may configure PDU set information RTP HE usage in an RTP session in PCF, e.g., through the NEF. In step 1a, the AS and AF negotiates the usage of RTP HE for transmitting the PDU set information between AS and UPF during a media session and informs the network about the support for PDU set information." (TDoc S4-230618)

- TDoc S4-230556: EDB field is 2-bits in length with semantics for PSI field indicating importance of PDU Set compared to others in the same RTP stream.
- TDoc S4-230556: RTP header extension fields include E flag set to 1 for last PDU in PDU Set, PSSN for PDU Set sequence number, PSN for current PDU sequence number, and PSSize for total size of all PDUs in PDU Set.
- TDoc S4-230572: PSSN field is 10 bits indicating PDU Set sequence number starting from 0, L field is 4 bits indicating length of header extension element, PSSB field length depends on L value and indicates PDU Set size in bytes, and E field is set to 1 for last PDU in a region.
- TDoc S4-230612: PDU sets with specific payload Type field values in NAL Unit header of RTP packet are set with higher priority, and PDU sets with TID value 1 are set with higher priority.
- TDoc S4-230613: PDU sets with specific Type field values in NAL Unit header of RTP packet are discardable, and PDU sets with highest TID field value are discardable.
- TDoc S4-230613: NAL unit type octet in H.264 contains the NRI field.
Example snippets from TDoc S4-230556 to support difference highlighting:
- "The EOB field is 2-bits in length with the following semantics: PSI (4 bits): the PDU Set Importance field indicates the importance of this PDU Set compared to other PDU Sets within the same RTP stream."
- "E (1 bit): this flag shall be set to one for the last PDU of the PDU Set."
- "PSSN (10 bits): the sequence number of the PDU Set to which the current PDU belongs."
Example snippets from TDoc S4-230572 to support difference highlighting:
- "PSSN: PDU Set Sequence Number (10 bits) – starting from 0 to cover the maximum number of PDU sets typically in a picture."
- "L: Length (4 bits) – the number, minus one, of data bytes of this header extension element following the one-byte header."
- "End of Region (1bit) – E is set to 1 for the last PDU in a region."
Example snippets from TDoc S4-230612 to support difference highlighting:
- "Therefore, PDU sets with a payload Type field value equal to 7, 8, 13 or 15 (refer to Table 7.1 in AVC specification [1]) in the NAL Unit header of the RTP packet are set with higher priority."
- "When the Type field value in the NAL Unit header of RTP packet is in the range 16 to 23 (inclusive), then the corresponding PDUs in that PDU set are set with higher priority value for example with 0x01."
Example snippets from TDoc S4-230613 to support difference highlighting:
- "PDU sets with Type field value equal to 8 or 9 (refer to Table 7.1 in HEVC specification [3]) in the NAL Unit header of RTP packet are RASL pictures and they are discardable."
- "PDU sets with any other TID field value in the NAL Unit header of RTP packet are not discardable."
- "The NAL unit type octet contains the NRI (nal_ref_idc) field highlighted in Figure 4."

1. Pose-to-render-to-photon delay: The TDoc S4-230529 introduces the concept of pose-to-render-to-photon delay, which allows the MeCAR device to know the amount of processing time as well as the connection delay required for a loop of split rendering. This delay is the gap between the actual-target-display-time (T2.actual) and the pose estimate time (T1).
Example snippet from TDoc S4-230529: "The gap between the actual-target-display-time (T2.actual) and the pose estimate time (T1) is the pose-to-render-to-photon delay, which allows the MeCAR device to know the amount of processing time as well as the connection delay required for a loop of split rendering."

2. RTP Header Extension for Rendered Pose: The proposed Change 1 introduces a new RTP header extension for rendered pose. The split rendering server streams the rendered frame using one or more video streams, depending on the view and projection configuration that is selected by the UE. Estimated-target-display-time (T2.estimated) is the estimated target display time for the media frame which is rendered, or will be rendered, using to this pose. The two-byte header format of the header extension is used for signaling the rendered pose. Pose includes location and direction information.
Example snippet from TDoc S4-230529: "The split rendering server streams the rendered frame using one or more video streams, depending on the view and projection configuration that is selected by the UE. The two-byte header format of the header extension is used for signaling the rendered pose. Pose includes location and direction information."

3. Reusing RTP header extensions: TDoc S4-230547 proposes the reuse of RTP header extensions to avoid sending the same/related header extension data multiple times in different streams. The HE for rendered pose has a size of 36+2*n bytes, where n is the number of action identifiers in the header extension.
Example snippet from TDoc S4-230547: "According to the 5G_RTP PD, the HE for rendered pose has a size of 36+2*n bytes, where n is the number of action identifiers in the header extension. This may lead to sending the same/related header extension data multiple times in different streams. Reusing RTP header extensions."

4. End-of-burst indication: TDoc S4-230611 proposes to signal the end-of-burst indication in the PDU Set information header extension. This is useful for identifying the end of a burst in a media stream. The end of a burst can be identified by setting the RTP HE EOB field to 0x01 for the last PDU of an Intra Random Access Pictures (IRAP) picture.
Example snippet from TDoc S4-230611: "The end-of-burst indication can be signalled in the PDU Set information header extension. the PDU is part of the last PDU set of the data burst."

5. Support for traditional and immersive real-time services: TDoc S4-230620 aims to specify functionalities of RTP to improve support for traditional and immersive real-time services and enablers. This includes support for IMS-based conversational XR services, WebRTC-based conversational XR services, WebRTC-based conversational services using traditional media, and XR split-rendering, i.e., real-time transport of media between the UE and edge.
Example snippet from TDoc S4-230620: "The objective of this work item is to specify functionalities of RTP to improve support for traditional and immersive real-time services and enablers. To support XR split rendering as described in clause 8.6 of TR 26.998, RTP is also needed to transport immersive media and metadata information between the edge and device."

3GPP-S4-123-e    Agenda Item 10.9 : MP_RTT (Multiparty Real-Time Text)