Content for  TS 23.433  Word version:  20.0.0

The VAL server decides to use SEALDD service for multi-modal traffic transfer and allocates address/port as SEALDD-S Data transmission connection information for receiving the data packets from SEALDD server. The VAL server sends Sdd_multi-modalTransmission request to the SEALDD server discovered by CAPIF. The service request includes UE ID/address, VAL server ID, VAL service ID, list of requested flows, including SEALDD-S Data transmission connection information of the VAL server side, and optionally, the protocol description, the QoS information for the application traffic, e.g. QoS requirements. As one of key parameters for multi-modal application, Crossflow measurement can be measured as procedure in clause 9.7.2.2 step 1.

Same as step 2 of clause 9.2.2.2. For application multi-modal service, the SEALDD server derives PDU Set related assistance information based on received VAL service ID and/or VAL server ID, and protocol description for interacting with NEF/PCF. The SEALDD server may send the AF request to provide the required QoS information to 5GC via N33/N5 for each requested flow provided in step 1. The AF request may also include the Multi-modal Service ID, which could be determined by the SEALDD server according to VAL service ID and/or VAL server ID.

Same as step 3-5 of clause 9.2.2.2.

The SEALDD client establishes multi-modal transmission connection with the SEALDD server. The request includes the SEALDD client ID, VAL user/UE ID, VAL server ID, VAL service ID, SEALDD-UU flow IDs, and traffic descriptors for the multiple flows from the SEALDD client side. The SEALDD server sends the SEALDD traffic descriptors for multiple flows from SEALDD server side (e.g. address/port for multiple SEALDD-UU flow) to the SEALDD client, and may send the protocol description (UL related info) received from the VAL server to the SEALDD client in the multi-modal transmission connection response. The response also includes a multi-modal SEALDD flow ID which the SEALDD server allocates. And the SEALDD client policy may also be included in its response. The SEALDD client shall then perform authorization checks and reply with a policy configuration response as specified in clause 9.10.2.4.

Same as step 8-9 of clause 9.2.2.2.

An on-going multi-modal data transmission connection is established according to the steps 1-8 of clause 9.12.2.1.2.

Upon the multi-modal flows alignment policy triggered, the SEALDD server may help to provide the flows alignment assistance information (e.g. timestamp in the RTP header, RTCP) to the SEALDD client. If the maximum acceptable duration for traffic flow alignment is not provided, then the SEALDD server may determine the maximum acceptable duration for traffic flow alignment based on VAL service ID, flows transmission requirement, transmission quality, and the synchronization threshold. The server may translate the traffic descriptor into multi-modal SEALDD flow ID. The SEALDD server may communicate with the 5GS to get the analytics and prediction for the RAN congestion as per clause 6.6, clause 6.7, and clause 6.8 of TS 23.288. Based on the RAN congestion analytics and prediction information, synchronization threshold and/or multi-modal flow alignment policy, the SEALDD server derives the delay introduced by the RAN and adjusts the flow alignment assistance information like DL/UL transmission timing advance or delay period. In case flow alignment is required, the flow alignment assistance information may contain UL/DL transmission timing advance period, UL/DL transmission timing delay period and the associated flow IDs in the multi-modal flows. The UL flow alignment assistance information may be sent to the SEALDD client in the Transmission quality management request specified in clause 9.9.3.1.

Upon the multi-modal flows alignment policy triggered, the SEALDD client initiates the multi-modal flows alignment based on the policy. The flows need to be aligned are identified by the VAL service ID, multi-modal SEALDD flow ID, and flow alignment assistance information. If the flow alignment assistance information is provided, the SEALDD client identifies the associated packets (e.g., those with the same RTP timestamp) in the multi-modal flows. After all associated packets in the multi-modal flows have arrived, the SEALDD client sends the associated packets to the application client. If the maximum acceptable time duration is provided, once this maximum acceptable time is reached, the SEALDD client will no longer wait for the associated packets in multi-modal flows, even if they have not arrived yet. For the UL synchronization, the SEALDD client sends the UL packets as per the flow alignment assistance information. The UL transmission timing advance period indicates SEALDD client to advance the UL packet transmission by advance period. The UL transmission timing delay period correction mode indicates SEALDD client to delay the transmission of the UL packet by UL delay period units. After all associated packets in the multi-modal flow have arrived at the SEALDD server, then the SEALDD server sends the associated UL packets to the VAL server.

The SEALDD server performs data transmission quality measurement, as defined in clause 9.7.2.1 or clause 9.7.2.3, in SEALDD-UU interface based on the mapping information for multiple flow association information between SEALDD-S interface and SEALDD-UU interface. Upon receiving the packets from multiple associated flows in SEALDD-S interface, the SEALDD server performs the packet encapsulation with sending timestamp information in the corresponding SEALDD-UU interface, and calculates the transmission delay measurement result of multiple associated flows after obtaining the receiving timestamp from the SEALDD client. As one of key parameters for XR application, delay difference can be measured as procedure in clause 9.7.2.3 step 10.

Based on the data transmission quality measurement results obtained for multiple associated flow over SEALDD-UU interface in step 4, and the synchronization threshold for multi-modal application as described in pre-condition, the SEALDD server determines the service flow(s) (i.e. address/port for SEALDD-UU flow) that needs to be adjusted among the multiple associated flows in SEALDD-UU interface, and the corresponding required QoS information (i.e. transmission delay). E.g., the SEALDD server evaluates whether the difference of the packet delay measurements for the flows that need to be in synchrony is above the synchronization threshold, and if it is so, the SEALDD server takes the corresponding corrective actions. The SEALDD server may advance or delay the transmission of the DL packets according to the flow assistance information to maintain the synchronization of DL flows. The DL transmission timing advance period correction mode indicates SEALDD server to advance the DL packet transmission by advance period. The DL transmission timing delay period correction mode indicates SEALDD server to delay the transmission of the DL packet by DL delay period units. The SEALDD server may further update the flow alignment assistance information like DL/UL transmission timing advance or delay period to fine-tune as per the data transmission quality measurement results.

The SEALDD server sends the AF request to 5GC via N33/N5 with the SEALDD traffic descriptor of the adjusted flow(s) (i.e. address/port for the adjusted SEALDD-UU flow) and the corresponding required QoS information determined in step 5, by utilizing the AF session with required QoS procedure in clause 4.15.6.6 of TS 23.502. The SEALDD traffic descriptor of the adjusted flow(s) contains the address or port in SEALDD server side, and/or SEALDD client side.

The PIN is successfully created and in use. The 3GPP UE acts as PEGC and PEMC, and the Tethered XR devices act as a PINE. During the PIN creation, the detailed information of the tethered device has been provided to PEMC on 3GPP UE from PINAPP server as defined in clause 8.5.2 of TS 23.542.

The regular data transmission connection is established, with the information received in step1. The connection between the SEALDD server and 3GPP UE is established as defined in clause 9.2.2.2.

The VAL server sends a SEALDD transmission quality measurement subscription request to the SEALDD server as defined in clause 9.7. If authorization is successful, the SEALDD server sends a response to the VAL server with the subscription ID, expiration time.

The SEALDD server starts the transmission quality measurement as defined in clause 9.7.2.3. The SEALDD server sends a SEALDD transmission quality measurement subscription request to the SEALDD client and the SEALDD client responds to the SEALDD server.

The SEALDD client, acting as a PINE, gets the information of the tethered device from the PEMC over PIN-1, as defined in the clause 8.5.8 of TS 23.542, to identify the tethering link.

The SEALDD client on the 3GPP UE interacts with XR client on the tethered UE to do the measurement based on ICMP ping protocol.

The SEALDD client sends the report to the SEALDD server using the transmission quality measurement notification.

The SEALDD server reports the data transmission quality measurement results to the VAL server via the notification message.

The PIN is successfully created and in use. The 3GPP UE acting as PEGC and PEMC, the Tethered XR devices acting as a PINE. During the PIN creation, the detail information of the tethered device has been provide to PEMC on 3GPP UE from PINAPP server as defined in clause 8.5.2 of TS 23.542.

The regular data transmission connection is established, with the information received in step1. The connection between the SEALDD server and 3GPP UE is established as defined in clause 9.2.2.2. Optionally, the SEALDD client gets the tethered device information form PEMC(e.g., the MAC address, PINE Address, Port number.) and sends the direct data transmission connection request to the tethered UE using the information form PEMC to establish a SEALDD-UUc connection between the 3GPP UE and tethered device as defined in clause 9.12.2.3.4.

The VAL server sends a SEALDD transmission quality measurement subscription request to the SEALDD server as defined in clause 9.7. If authorization is successful, the SEALDD server sends a response to the VAL server with the subscription ID, expiration time.

The SEALDD transmission quality measurement is defined in clause 9.7.2.3. The SEALDD server sends a SEALDD transmission quality measurement subscription request to the SEALDD client and the SEALDD client responds to the SEALDD server.

The SEALDD client gets the information of the tethered device from the PEMC over PIN-1, as defined in the clause 8.5.8 of TS 23.542, to identify the tethering link.

The SEALDD client on the 3GPP UE interacts with SEALDD client on the tethered UE to do the measurement based on ICMP ping protocol, or uses monitoring packet in established tethering link SEALDD connection.

The SEALDD client sends the report to the SEALDD server using the transmission quality measurement notification.

The SEALDD server sends the data transmission quality measurement results (e.g. latency, jitter, bitrate, packet loss rate) to the VAL server via the SEALDD enabled data transmission quality measurement notification as defined in clause 9.7.3.3.

SEALDD client on 3GPP UE sends a SEALDD-UUc connection request to SEALDD client on tethered UE. This message includes the UE identity, SEALDD-UUc data transmission connection information(e.g., address/port allocated).

SEALDD client on Tethered UE initiates the procedure for mutual authentication. The successful completion of the authentication procedure completes the establishment of the SEALDD-UUc connection.

SEALDD client on tethered UE sends a SEALDD-UUc connection response to SEALDD client on 3GPP UE.

The UE-to-UE communication is established between UE 1 and UE 2 via SEALDD client as specified in clause 6.4.3.1 of TS 23.304.

The SEALDD client in UE1/2 informs the SEALDD server about the establishment of direct SEALDD communication with Sdd_XRTransmissionConnnection_Inform operation.

Based on SEALDD UE-to-UE policy, the SEALDD server requests 3GPP CN (NWDAF/NEF) for UE relative proximity analytics for UE1 and UE2, requests 3GPP CN (GMLC/NEF) for SL/Ranging service exposure about the relative locations or distances and directions related to the UE1 and UE2, and requests ADAES for UE-to-UE application performance analytics as described in clause 8.4 of TS 23.436, requests NWDAF/NEF for QoS Sustainability Analytics and Service Experience Analytics for UEs and/or requests PCF/NEF for QoS monitoring.

According to the SEALDD UE-to-UE policy, if relative proximity analytics result shows that both UEs are not in vicinity to each other (distance between UEs > proximity threshold in UE-to-UE policy), and/or the QoS/QoE for UE-to-UE direct communication analytics result is no so good (e.g. PLR in analytics report > PLR threshold in UE-to-UE policy), the SEALDD continues with step 4 for indirect communication preparation; otherwise, the SEALDD keeps monitoring (as described in step 2) for the two UEs.

According to the SEALDD UE-to-UE policy, if the ProSe discovery result shows that both UEs are not in vicinity to each other(e.g., no discovery response received), and/or the UE-to-UE application performance result(collected as defined in clause 8.4 of TS 23.436 step 5) is not so good(latency in application performance result > latency in UE-to-UE policy), the SEALDD client(s) on either or both of the two UEs decides to perform path switching and continues with step 4 for indirect communication preparation.

After establishment of SEALDD connections for UE1 and UE2, the SEALDD traffic carrying XR flows are processed in the SEALDD server. The SEALDD server forwards traffic between UE1 and UE2, and may buffer data burst from originating UE and send it to destination UE smoothly.

If later on, both UEs are in proximity which is capable of direct communication and the QoS/QoE analytics result from ADAES for UE-to-UE direct communication shows good quality, the SEALDD server helps to establish direct SEALDD communication by informing the SEALDD client of any of the two UEs with Sdd_XRTransmissionConnnection_Trigger operation including the information of its peer SEALDD client (of UE1 or UE2). Then the SEALDD client 1 or 2 establishes SEALDD connection towards the peer SEALDD client via SEALDD-PC5 and the SEALDD traffic carrying XR flows are exchanged directly between UE1 and UE2 via SEALDD-PC5.