Content for  TS 23.433  Word version:  19.3.0

An on-going regular data transmission connection is established according to clause 9.2.2.2.

The VAL server sends a SEALDD transmission quality measurement subscription request to the SEALDD server. The request includes the identifiers of the application traffic (e.g. VAL service ID, VAL server ID), requirement of transmission quality measurement (e.g. latency, jitter, bitrate, packet loss rate) and measurement target UE (e.g. a single UE, a group of UEs or all UEs), flow(s) traffic descriptor(s), and may also include reporting criteria, reporting frequency, spatial condition and temporal condition.

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 with the subscription ID, expiration time.

If the transmission quality measurement requirement list provided by VAL server in step 2, indicates that the latency is needed to be measured, the SEALDD server initiates the DL packet delay measurement. The SEALDD server encapsulates the DL monitoring packet (i.e. DL SEALDD packet with SEALDD DL monitoring header and VAL traffic as payload, or dummy DL SEALDD packet generated for data transmission quality monitoring) with local time T1 when the SEALDD server sends out the DL monitoring packets. The SEALDD server considers the spatial and/or temporal conditions when starting/resuming the transmission quality measurement. If the conditions are not satisfied, the SEALDD server stops/suspends the transmission quality measurement.

The SEALDD client receives the DL monitoring packet, and records the local time T2. If the endpoint for the SEALDD traffic is located at the tethered device, the SEALDD client in 5G UE measures the QoS between the SEALDD client in 5G UE and the SEALDD client (i.e. for architecture that has the SEALDD client on the tethered device) or the VAL client (i.e. for architecture that without the SEALDD client on the tethered device) in tethered device, e.g., the SEALDD client may measure the tethered link delay using the ICMP ping protocol as defined in RFC 792 [RFC792]).

Similarly, the SEALDD client encapsulates the UL monitoring packet (i.e. UL SEALDD packet with SEALDD UL monitoring header and VAL traffic as payload, or dummy UL SEALDD packet generated for data transmission quality monitoring) with local time T2 recorded in step 5 and local time T3 when the SEALDD client sends out the UL monitoring packet. If the endpoint for the VAL traffic is located at the tethered device, the measurement delay in the tethered link (step 5) is considered in T2 and T3 timestamps, e.g., T2 timestamp includes the half of the measurement delay and T3 timestamp excludes the half of the measurement delay.

The SEALDD server records the local time T4 when the SEALDD server receives the UL monitoring packet and calculates the latency with T1, T2, T3, T4. The SEALDD server can also calculate the bitrate, jitter and packet loss rate over a certain period over a specific SEALDD connection by recording the status of the SEALDD packets carrying VAL traffic or dummy SEALDD packets generated for transmission quality measurement reports. The SEAL DD server also evaluates the reporting criteria if present in the SEALDD transmission quality measurement subscription request in order to generate the transmission quality measurement report.

The SEALDD server reports the data transmission quality measurement results (e.g. latency, jitter, bitrate, packet loss rate) to the VAL server via the notification message.

The consumers (e.g. VAL server, SEALDD server, NSCE server, ADAE server) can send a SEALDD transmission quality query request to the SEALDD server to obtain the transmission quality measurement result. The request includes the identifiers of the application traffic (e.g. VAL service ID, VAL server ID), VAL UE ID or VAL UE group ID, flow(s) traffic descriptor(s), or crossflow measurement information.

The SEALDD server responds with the transmission quality measurement result (e.g. packet delay, bitrate, packet loss rate).

An on-going regular data transmission connection is established according to clause 9.2.2.2. The transmission quality measurement can be triggered by VAL server or VAL client, which is described in step 2 to step 5 and step 6, correspondingly. The request may include the crossflow measurement information (e.g. {[traffic descriptor 1, UL]; [traffic descriptor 2/DL]}) associated in the same multi-modal service for crossflow RTT measurement.

The VAL server sends a SEALDD transmission quality measurement subscription request to the SEALDD server. The request includes the identifiers of the application traffic (e.g. VAL service ID, VAL server ID), requirement of transmission quality measurement (e.g. latency, jitter, bitrate) and measurement target UE (e.g. a single UE, a group of UEs or all UEs), and may also include reporting criteria, reporting frequency, spatial condition and temporal condition.

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

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, based on the received service quality guarantee policy including thresholds and action, can take corrective action as described in clause 9.7.2.3. If crossflow RTT measurement requirement is received from the VAL server, the SEALDD server identifies the SEALDD connections for the involved VAL UEs and sends to the SEALDD client(s) with crossflow RTT measurement requirement including corresponding UL/DL flow information.

The VAL client triggers the SEALDD transmission quality measurement procedure to the SEALDD client, in order to collect the measurement report information.

After SEALDD client determines to start measurement process, upon UL packet arrival, the SEALDD client initiates the UL packet delay measurement. The SEALDD client encapsulates the UL monitoring packet (i.e. UL SEALDD packet with SEALDD UL monitoring header and VAL traffic as payload for VAL data transmission quality monitoring) with local time T1 when the SEALDD client sends out the UL monitoring packet. The SEALDD client considers the spatial and/or temporal conditions when starting/resuming the transmission quality measurement. If the conditions are not satisfied, the SEALDD client stops/suspends the transmission quality measurement. For crossflow RTT measurement, the SEALDD client received UL flow information starts recording local time T1 when sending out the 1st UL packet matching the UL flow information to the SEALDD server. The T1 is sent in the encapsulated UL monitoring packet to the SEALDD server.

The SEALDD server receives the UL monitoring packet, and records the local time T2.

Similarly, the SEALDD server encapsulates the DL monitoring packet (i.e. DL SEALDD packet with SEALDD DL monitoring header and VAL traffic as payload, or dummy UL SEALDD packet generated for data transmission quality monitoring in case there is no DL VAL traffic for DL packet delay monitoring) with local time T2 recorded in step 8 and local time T3 when the SEALDD server sends out the DL monitoring packet. For crossflow RTT measurement, when the 1st DL packet matching the received DL flow information is to be sent, the SEALDD server encapsulates the DL monitoring packet with previously received T1 and sends the DL monitoring packet to the SEALDD client.

The SEALDD client records the local time T4 when the SEALDD client receives the DL monitoring packet and calculates the latency with T1, T2, T3, T4. The SEALDD client can also calculate the bitrate and jitter over a certain period over a specific SEALDD connection by recording the status of the SEALDD monitoring packets. The SEALDD client also evaluates the reporting criteria if present in the SEALDD transmission quality measurement subscription request in order to generate the transmission quality measurement report. For crossflow RTT measurement, if T1 is received in the DL packet, the SEALDD client records local time T2 and calculates RTT based on T1 and T2. Depending on which entity triggers the data transmission quality measurement, step 11 and step 12 corresponds to step 2 to step 5, step 13 corresponds to step 6.

The SEALDD client reports the data transmission quality measurement results (e.g. latency, jitter, bitrate) to the VAL server via the SEALDD server.

The SEALDD client reports the data transmission quality measurement results to the VAL client.