According to clause 6.43 of TS 22.261, synchronization between different media components is crucial for immersive multi-modal VR applications. This becomes particularly important when the synchronization threshold between two or more modalities is lower than the latency Key Performance Indicator (KPI) for the application, emphasizing the significance of minimizing delay differences. Otherwise, the arrived flows need to wait for other highly related flows that do not arrived yet. The SA2 provides the 5GS Packet Delay Variation monitoring to expose the variation of packet delay measured between UE and PSA UPF, which is only the single flow delay jitter. SA2 also defines the PDU Set Delay Budget (PSDB), which is the maximum delay that a PDU Set may experience for the transfer between the UE and the N6 termination point at the UPF. Application enabling layer could help to provide the end-to-end measurement of the delay difference among those associated flows. Another example is the duration of the burst. When the duration of the burst is long or the burst are too frequent, those indicators can suggest that the burst traffic may exceed the transmission capacity, leading to the viewer to detect frame dropping. Therefore, the duration of the burst, or, the frequency of burst may become an indicator that VAL may be interested in when providing XR services. The enabling layer can monitor the traffic to get the predicted duration of the burst based on the statistic, which can be used to do the traffic shaping. To sum up, there are multiple indicators that may impact the performance of XR services, therefore this key issue will study:

• Identify what KPI the application enabling layer could provide that impact the QoS of the XR services.
• How the KPI could be measured at the application enabling layer, and the enhancement of the SEALDD services.

Many XR use cases will require E2E multi-modal communication flows between application clients and application servers. SA1 has defined requirements for tactile and multi-modal communication service in clause 6.43 of TS 22.261, including the support to provide policy(ies) for E2E multi-modal communication flows associated with applications. Using information provided by application clients and servers (e.g., policies), the application enablement layer, in coordination with the 5G CN, can support functionality to assist in managing E2E multi-modal communication flows between application clients and application servers. This key issue will study:

• Whether and how to support the E2E multi-modal communication flows between application clients and application servers within the application enablement layer?
• Whether and how to support the interaction between the application enablement layer and 5G CN to manage E2E multi-modal communication flows between application clients and application servers?
• Whether and how SEALDD may be enhanced to assist in managing E2E multi-modal communication flows between application clients and application servers involved in the same application service (e.g., support for multi-modal aware SEALDD flow management and policies)?

In clause 7.6.1 of TS 22.261, the gaming or training service data can be exchanged between two 5G connected AR/VR devices. Communication over a direct link between the UEs can improve performance and service experience. Communication over 5G network and direct wireless connection can be used in parallel between AR/VR devices for redundancy or for different kinds of multi-modal call flows. Based on user consent, operator policy and trusted 3rd party request, the 5G network shall support a means to authorize specific UEs to transmit data (e.g. AR/VR service data) via direct device connection in a certain location and time or when direct device connection cannot fulfil the required QoS, communication over 5G network can provide redundant connection. It is required to study the following:

• How the application enablement layer can be enhanced to support usage of direct communication between 5G connected AR/VR devices.
• Whether and how the application enablement layer can be enhanced to make coordination (e.g., the connection redundancy) between network based communication and direct communication between AR/VR devices for AR/VR services communication.

The XRApp aims to help XR service providers in delivering immersive experience which is enabled by communicating and synchronizing data streams such that multiple participants have a consistent immersive impression. From SA6 perspective, in addition to the SEALDD, which could provide the data delivery services, more application enablement layer capabilities could be utilized. Taking Online AR Gaming as an example, this gaming involves two types of users. Player UEs receive streams of the live game from the game server and send control signals back to the server, and spectators who can join the live game, receive the stream from various perspectives, and potentially interact with players through cheering or game reward mechanisms. To support online AR gaming, the following capabilities could be leveraged (with potential enhancements):

• Data delivery for guaranteed multi-modal flow transmission.
• Network Slice Capability Enablement function for Provisioning differentiated network slices for players and spectators;
• Location management function to facilitate geofencing for the designated game arena in AR gaming.
• AI/ML may be required for Image & Object Recognition.

Currently, the XRApp is identified to be deployed as functionality component of the SEALDD, but there is a gap between the current architecture and the above requirements. So it is proposed to study the following open issues:

• Whether and how the identified application enablement capabilities could be utilized to jointly support the XR service.
• Whether and how the application enablement architecture could support the XR service taking advantage of the identified application enablement capabilities.

Different from other types of AR UE, the end-to-end path for the tethered UE includes one more wireless/wireline tethering link between AR Glasses and the tethering 5G Phone. In order to fulfill the end-to-end QoS requirements for the AR glass session, the consumer needs to acquire the tethering link status via measurement and analysis, and takes it into account when determining the QoS for the 5G system link. With the tethering link status, the application enablement layer may communicate with AF for dynamic QoS policy adjustment accordingly. The 5G WireLess Tethered AR UE is introduced in TR 26.998, and is further studied in TR 26.806. they provides the Segment-by-segment delay measurement solution based on the ICMP, and End-to-end delay measurement based on RTP. The End-to-end delay measurement relies on tethered device to do the RTP based measurement. While it successfully identifies non-5G delays, distinguishing delays from the tethered link and those after N6 remains challenging. The Segment-by-segment delay measurement utilizes the UPF and tethered device for ICMP based measurement, however how UPF retrieves the RTT between the UPF and the application server and further exposes the latency results to the AF are not supported in SA2 in current release. And all the measurement results are sent to the AF, indicating that SA4 does not play a role in optimizing latency based on the measurements. The above study provides good foundation for this KI. This KI can further study how to identify tethered links and optimize transmission. It is proposed to study the open issues:

• Whether and how could the application enabling layer identify traffic flows from the tethered devices behind the UE.
• Whether and how could the application enabling layer support the acquisition of tethering link status via measurement and analytic and provide a transporting optimization, considering different type of the tethered UE (standalong tethered device, or wire/wireless tethered device).
• Whether and how the PINAPP could be utilized to support the tethered UE.

As for XR service, current XR application server selection mechanism using EDGEAPP may not be able to satisfy the strict latency requirement. And considering that XR application server may involve multi-model communication flow, to support multi-model communication flow synchronization, it is better to improve service experience to provide ensure the operation on the multi-model synchronization. However, due to one DNAI may be mapped to multiple UPFs in different EDNs, thus only using DNAI to and application server may not be enough. Consider the following case (as showed in Figure 4.6-1): The UE is in the overlapping area of EDN#1 and EDN#2, when performing service provisioning, the UE may anchor to UPF#2 however the UE may connect to the EES#1 for EAS information. Then the UE may connect to EAS#1 discovered from EES#1. The issue may happen that the user plane path is not optimal, which may not be able to satisfy the XR application requirement.

This key issue includes the following aspects:

• Whether and how enablement layer can support XR application server to further reduce service latency?
• Whether and how enablement layer can support XR application server selection?

In real-time XR service, E2E KPI (e.g. low latency) is critical to provide immersive experience for XR users. Typically, the overall processing of XR service consists of several parts, such as media rendering, media transmission over 5G network, etc. The XR application servers may have different capabilities to perform the intensive processing, such as media rendering, which results in differentiated processing delay. In other aspects, the traffic flow between XR application client and XR application may have the different transmission quality due to the network handling. The E2E performance of XR service is impacted not only by data transmission, but also by data processing. Therefore, further study the E2E KPI optimization mechanism considering the processing delay of XR application server, to satisfy real-time XR service is required. For example, as the enable layer, how to discover or initiate the appropriate XR application server and/or how to interact with 5GS is critical to satisfy the E2E performance of XR service. This key issue includes the following aspects:

• How to support the E2E KPI optimization to meet real-time XR service requirements, taking the processing delay of XR application server into account, e.g. considering the potential enhancements to EDGEAPP in XR application server discovery or instantiation.
• What available information from 5G network can be used by enable layer to optimize the real-time XR service requirements.

SA2 and SA4 introduced PDU set based handling to support XR traffic. As mentioned in TS 23.501 and TS 26.522, for multi-modal flows transported in different QoS flow, the importance of PDU set can be used to help RAN to discard PDUs belonging to the same PDU set across flows, when needed. The PDU set identification and corresponding set-based policy enforcement are performed in CN and RAN, and inclusion of PDU set information is done in application layer. For XR DL data, PSA UPF can mark PDU set information in GTP based on received protocol extension, e.g., RTP extension. Then during AN congestion, 5G-RAN and/or UPF will perform specific packet handling (e.g. drop) for PDUs in a set and also for PDU sets in the same SDF based on PDU set information in GTP. For XR UL data, UE lower layer can mark PDU set information in AN-protocol based on received protocol extension, e.g., RTP extension. Then during AN congestion, 5G-RAN will perform packet handling for PDUs in a set and also for PDU sets in the same SDF based on PDU set information in AN-protocol. SEALDD was specified in 3GPP since Rel-18, the user plane protocol stack over 5GS is depicted in Figure 4.8-1. The Application content including SEALDD layer information and VAL payload can be transferred between the SEALDD client in the UE and the SEALDD server in the data network.

Since the inclusion of PDU set information is done in application layer, the application enablement layer, in coordination with 5G CN, can also facilitate PDU set related handling for a single flow or multiple flows in XR traffic. This key issue will study:

• Whether and how SEALDD or other application enabler may be enhanced to facilitate XR communication flows between application clients and application servers involved in the same application service in relation to PDU set (e.g., support for PDU set handling, QoS measurement)?