Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.433  Word version:  19.4.0

Top   Top   Up   Prev   Next
0…   4…   7…   8…   9.2…   9.2.2.3…   9.2.3…   9.2.4…   9.3…   9.3.2.2…   9.3.3…   9.3.4…   9.4…   9.5…   9.5.3…   9.5.4…   9.6…   9.7…   9.7.3…   9.7.4…   9.8…   9.9…   9.9.3…   9.10…   9.10.3…   9.11…   9.11.3…   9.12…   9.12.3…   9.13   10…   A…   C   D…

 

9.12  SEALDD enabled transmission for XR application |R19|p. 115

9.12.1  Generalp. 115

This clause provides the services to support the transmission for XR application based on SEALDD capabilities.

9.12.2  Proceduresp. 115

9.12.2.1  SEALDD enabled XR data transmission service for XR applicationp. 115

9.12.2.1.1  Generalp. 115
The following clauses specify procedures, information flows and APIs about SEALDD enabled data transmission for XR application, including the SEALDD facilate PDU set handling.
9.12.2.1.2  SEALDD enabled XR data transmission establishmentp. 115
Figure 9.12.2.1.2-1 illustrate the procedure for establishing XR data transmission connection, and the SEALDD facilitates the XR application to transmit its data between the VAL client and VAL server with RTP packetilization and PDU set inclusion.
Pre-condition:
  • The VAL server can discover and select the SEALDD server by CAPIF functions.
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.1.2-1: SEALDD enabled XR data transmission connection establishment procedure
Up
Step 1.
The VAL server decides to use SEALDD service for XR 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_XRTransmission request to the SEALDD server discovered by CAPIF. The service request includes UE ID/address, VAL server ID, VAL service ID, 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.
Step 2.
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.
Step 3-5.
Same as step 3-5 of clause 9.2.2.2.
Step 6.
The SEALDD client establishes XR 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 XR transmission connection response. The response also includes a multi-modal SEALDD-UU flow ID which the SEALDD server allocates.
Step 7-8.
Same as step 8-9 of clause 9.2.2.2.
The XR application traffic is exchanged between VAL client and VAL server via SEALDD layer as described in clause 9.2.2.2. If packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD/UDP/IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD/UDP/IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set inclusion (e.g. in RTP extension as defined in TS 26.522), and if needed, stream session and transport management (e.g. RTCP, RTSP).
Up

9.12.2.2  SEALDD enabled multi-modal flow synchronizationp. 116

9.12.2.2.1  Generalp. 116
The following clauses specify procedures, information flows and APIs about SEALDD enabled data transmission for XR application, including SEALDD enabled multi-modal flow synchronization.
9.12.2.2.2  SEALDD enabled multi-modal flow synchronizationp. 116
Figure 9.12.2.2.2-1 illustrate the procedure for SEALDD enabled multi-modal flow synchoronization, the SEALDD server determines/updates the required QoS information for multi-modal flow(s), and further interacts with 5G network.
Pre-condition:
  • The VAL server can discover and select the SEALDD server by CAPIF functions.
  • The SEALDD server has been provisioned with a multi-modal XR policy including the synchronization threshold, as specified in clause 9.10.3.1.
  • The SEALDD client has been provisioned with a multi-modal SEALDD policy, as specified in clause 9.10.2.3.
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.2.2-1: SEALDD enabled multi-flow synchronization procedure
Up
Step 1.
An on-going multi-modal data transmission connection is established according to the steps 1-8 of clause 9.12.2.1.2.
Step 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). 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.
Step 3.
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 can identify 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.
Step 4.
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 can calculate the transmission delay measurement result of multiple associated flows after obtaining the receiving timestamp from the SEALDD client.
Step 5.
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 can determine 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).
Step 6.
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.
After requesting the transmission quality optimization on 5G network with the required QoS for the adjusted flow(s), the multi-flow synchronization of multi-modal application can be satisfied.
Up

9.12.2.3  Tethering link measurement and provisioningp. 118

9.12.2.3.1  Generalp. 118
The following clauses specify procedures, information flows and APIs about SEALDD enabled Tethering link measurement and provisioning for XR application.
9.12.2.3.2  SEALDD and VAL coordination measurement based on PINp. 118
Figure 9.12.2.3.2-1 illustrates the procedure of SEALDD and VAL coordination Tethering link measurement based on PIN.
Pre-conditions:
  1. The UE or PINE has been pre-configured or has discovered the address (e.g. IP address, FQDN, URI) of the PIN server;
  2. The UE or PINE has already been registered in PIN server;
  3. The PEMC on the 3GPP device has already get the tethered device information from PIN server;
  4. There is business agreement between the VAL provider and the SEALDD provider, which request the VAL client to respond to ICMP Ping packet.
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.3.2-1: SEALDD and VAL coordination measurement based on PIN procedure
Up
Step 1.
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.
Step 2.
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.
Step 3.
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.
Step 4.
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.
Step 5.
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.
Step 6.
The SEALDD client on the 3GPP UE interacts with XR client on the tethered UE to do the measurement based on ICMP ping protocol.
Step 7.
The SEALDD client sends the report to the SEALDD server using the Transmission quality measurement notification.
Step 8.
The SEALDD server reports the data transmission quality measurement results to the VAL server via the notification message.
Up
9.12.2.3.3  SEALDD measurement based on PINp. 119
Figure 9.12.2.3.3-1 illustrates the procedures of SEALDD measurement based on PIN.
Pre-conditions:
  1. The UE or PINE has been pre-configured or has discovered the address (e.g. IP address, FQDN, URI) of the PIN server;
  2. The UE or PINE has already been registered in PIN server;
  3. The PEMC on the 3GPP device has already get the tethered device information from PIN server;
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.3.3-1: SEALDD measurement based on PIN procedure
Up
Step 1.
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.
Step 2.
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.
Step 3.
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.
Step 4.
The SEALDD 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.
Step 5.
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.
Step 6.
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 using monitoring packet in established tethering link SEALDD connection.
Step 7.
The SEALDD client sends the report to the SEALDD server using the Transmission quality measurement notification.
Step 8.
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.
Up
9.12.2.3.4  SEALDD-UUc Connection establishment between the SEALDD client on 3GPP UE and tethered devicep. 120
Depicted in Figure 9.12.2.3.4-1 is the procedure for establishment of SEALDD-UUc connection between the SEALDD client on 3GPP UE and tethered device.
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.3.4-1: Establishment of SEALDD-UUc Connection between the SEALDD client on 3GPP UE and tethered device
Up
Step 1.
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).
Step 2.
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.
Step 3.
SEALDD client on tethered UE sends a SEALDD-UUc Connection Response to SEALDD client on 3GPP UE.
Up

9.12.2.4  SEALDD enabled UE-to-UE communication based on policyp. 120

9.12.2.4.1  Generalp. 120
When two VAL UEs need to communicate with each other for exchanging gaming/interactive data in XR service, they can use servers in the DN as data relay or communicate with each other directly.
In order to improve service experience (esp. for reducing service latency), SEALDD server monitors distance of UEs involved in the XR communication. When SEALDD server finds that the two UEs are within direct communication range, the SEALDD server instructs the SEALDD clients to switch to direct communication mode. Such mode switch decision needs to take E2E communication performance into consideration.
If the UE-to-UE application performance analytics result from ADAE shows the quality in off-network mode will be degraded and the quality in on-network mode is estimated to be good, or vice versa, the mode switch is done in SEALDD layer.
Up
9.12.2.4.2  SEALDD enabled UE-to-UE communicationp. 120
The SEALDD servers has Data Delivery (DD) policy being provisioned for UE-to-UE communication. The DD policy is enforced by the SEALDD server to switch the SEALDD connection for UE-to-UE communication (either direct or indirect).
Pre-conditions:
  1. The SEALDD server has DD policies available.
  2. The SEALDD clients in UE1 and UE2 has discovered the same SEALDD server.
Reproduction of 3GPP TS 23.433, Fig. 9.12.2.4.2-1: Policy enforced by SEALDD server for connectivity between two UEs
Up
Step 1a.
The UE-to-UE communication is established between UE 1 and UE 2 via SEALDD client.
Step 1b.
The SEALDD client in UE1/2 informs the SEALDD server about the establishment of direct SEALDD communication with Sdd_XRTransmissionConnnection_Inform operation.
Step 2.
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.
Step 3.
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.
Step 4.
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.
Step 5.
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.
Based on the monitoring and analytics result (as requested in step 2), and SEALDD UE-to-UE policy:
  • if the current UE1-UE2 communication mode is direct and SEALDD server decides to switch to indirect communication mode, the SEALDD server establishes SEALDD connections with SEALDD client 1 and SEALDD client 2 as described in step 4, then triggers direct SEALDD communication release using Sdd_XRTransmissionConnnection_Trigger operation towards the SEALDD client which received establishment request in step 5 and the SEALDD client further releases the direct SEALDD connection towards its peer SEALDD client via SEALDD-PC5.
  • if the current UE1-UE2 communication mode is indirect and SEALDD server decides to switch to direct communication mode, the SEALDD server triggers direct SEALDD communication setup as described in step 5 and releases SEALDD connections towards SEALDD client 1 and SEALDD client 2.
Up

Up   Top   ToC