Content for  TS 23.433  Word version:  19.3.0

The VAL server sends a Sdd_regularTransmission request to the SEALDD server. The request includes the identifiers of the application traffic (e.g. VAL service ID, VAL server ID), the VAL server's total bandwidth limit and the bandwidth limits (i.e. minimum bandwidth requirement and maximum bandwidth limit) for VAL users.

Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, the SEALDD server sends a response to the VAL server.

The VAL client sends a SEALDD service request to SEALDD client.

The VAL/SEALDD client discover and select the proper SEALDD server for the VAL application. After this step, the VAL server is discovered and selected along with the associated SEALDD server, the SEALDD client can get the SEALDD server's address.

The SEALDD client sends Sdd_RegularTransmissionConnection_Establish request to SEALDD server with the SEALDD client ID, the VAL user or UE identity.

The SEALDD server performs bandwidth limit check according to the VAL user's bandwidth limit, the current SEALDD traffic delivery status, the VAL server's total bandwidth limit and/or the related UE's current network status (i.e. via QoS monitoring report from the 5GC). If the available bandwidth (i.e. the remaining bandwidth that can be used for the VAL user without exceeding the VAL server's total bandwidth limit) cannot meet the VAL user's minimum bandwidth requirement, the SEALDD server will reject the SEALDD client's connection establishment request.

When the available bandwidth can meet the VAL user's requirement, the SEALDD client can establish the SEALDD connection with the SEALDD server. The SEALDD server can calculate the suggested traffic transmission bandwidth to the SEALDD client according to the VAL user's bandwidth limit and the related UE's current network status (i.e. via QoS monitoring report or ECN marking for L4S report from the 5GC).

If the bandwidth limit check is failed (i.e., the available bandwidth cannot meet the VAL user's minimum bandwidth requirement) in step 6, the SEALDD server can send Sdd_RegularTransmissionConnection_Establish response with the failed result (i.e., reject the connection establishment) and the pending timer to trigger the re-connection from SEALDD client. If the bandwidth limit check is successful (i.e., the available bandwidth can meet the VAL user's requirement) in step 6, the SEALDD server can send Sdd_RegularTransmissionConnection_Establish response with the successful result and/or the suggested traffic transmission bandwidth.

Same as clause 9.2.2.2 step 1 to step 7 with difference that in step 5 the SEALDD client includes also L4S feedback capability in Sdd_RegularTransmissionConnection_Establish request.

If the L4S feedback capability is received in step 5, the SEALDD server can request 5GC to perform the ECN marking for L4S for the required VAL applications by utilizing the AF session with required QoS procedure in clause 4.15.6.6 of TS 23.502.

Same as step 9 of clause 9.2.2.2.

For downlink traffic, if ECN marking is identified, the L4S feedback is performed in transport layer.

After receiving the L4S feedback in step 9, the SEALDD server may perform the congestion mitigation for downlink traffics from multiple VAL applications. For the same UE, the SEALDD server can determine differentiated congestion control/rate control with the calculated congestion level or the calculated transmission rate for multiple VAL applications based on internal policy considering the received QoS requirements of different VAL applications identified by VAL service ID in step 1.

[Optional] The SEALDD server sends Sdd_connection status notification to VAL server with the calculated congestion level for the VAL service.