13.8 Use of SAND for Consistent QoE/QoS

26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

SAND can be an enabler for video-aware network resource management to provide consistent QoE/QoS for DASH clients. As such, DANE placed at the network core can allow the service provider to perform video-aware resource management. The DANE is also considered to contain a QoE reporting server to receive periodic feedback of media buffer levels from the DASH clients. This is done by establishing an application-level feedback connection between the DASH client and the DANE for each streaming flow, e.g., via an HTTP POST connection. Hence the DANE has a synthetic view of the buffer levels of all the connected streaming clients. It computes a maximum bit rate (MBR) MBR_j for each flow j and communicates the MBR_j of each flow j to the respective DASH client using SAND messages. Further details of the consistent QoE/QoS use case are in TR 26.957 [55].

Thus the DANE indirectly manages the network resources at various parts of the network by setting the QoS parameters that influence the DASH client adaptation behavior. The DANE controls the rate adaptation of the video clients by communicating the respective MBR parameters to each client.

The video-aware resource management can be realized at the DANE via the use of SAND, where DASH clients can indicate their desired bandwidth levels through the use of the SAND status message SharedResourceAllocation and also can report QoE metrics. In addition, when the DANE determines the resource allocation across the DASH clients, it can inform the DASH clients about their resource assignments and throughput / QoS, which can be achieved by the SAND PER messages SharedResourceAssignment, Throughput and QoSInformation, as specified in clauses 6.5.3, 6.5.5 and 6.5.7 of ISO/IEC 23009-5 [54], respectively.

DANE discovery procedures relevant for the Consistent QoE/QoS mode are described in clause 13.3. SAND messages and protocols for the Consistent QoE/QoS mode are described in clause 13.4. SAND message handling behaviors for DANEs and 3GP-DASH clients in the Consistent QoE/QoS mode are described in clause 13.5.

The SAND status message SharedResourceAllocation shall follow the syntax and semantics in Table 4 of ISO/IEC 23009-5 [54]. 3GP-DASH clients sending the SharedResourceAllocation message shall include the bandwidth parameter. In addition, the SAND message common envelope shall contain the senderId parameter.

The SAND PER message SharedResourceAssignment shall follow the syntax and semantics in Table 16 of ISO/IEC 23009-5 [54]. 3GP-DASH clients receiving the SharedResourceAssignment message shall recognize the clientId and bandwidth parameters.

The SAND PER message QoSInformation shall follow the syntax and semantics in Table 22 of ISO/IEC 23009-5 [54].

An example workflow realizing the consistent QoE/QoS is depicted in Figure 13.3, where the use of the WebSocket protocol [56] is considered and the DANE functionality is hosted at the PSS server and SAND-capable DASH client capabilities are hosted in the PSS client (consistent with the SAND support in PSS as described in [2]). For the SAND messages depicted in Figure 13.3, the messageType codes in Table 2 of ISO/IEC 23009-5 [54] are used.

Figure 13.3: Example SAND workflow for Consistent QoE/QoS

Step 1: Client issues an HTTP GET and sends request for MPD to the content server. In the header of the HTTP request, client includes the SAND header that contains the status messages on client capabilities.

Step 2: Content server responds with HTTP 200 OK with body containing the MPD. As specified in ISO/IEC 23009-5 [54], the MPD contains a sand:Channel element whose @schemeIdUri is "urn:mpeg:dash:sand:channel:websocket:2016" and WebSocket URI in the @endpoint attribute.

Steps 3, 4: The 3GP-DASH Client parses the MPD starts downloading the segments. In addition, the sand:Channel element is located in the MPD element. Using this information, the 3GP-DASH client initiates the WebSocket connection with the out-of-band DANE (e.g., located in the PSS server) as specified in RFC 6455 [56].

It is noted here that WebSocket-based SAND channel announcement may also be accomplished by the use of OMA DM [22].

Steps 5, 6, 7, 8: Upon successful establishment of the WebSocket connection between a 3GP-DASH Client and DANE, the 3GP-DASH client starts listening for incoming PER messages and may send metrics and status messages when needed. Since the WebSocket Protocol establishes a full-duplex connection, the DANE and the 3GP-DASH client may exchange SAND messages travelling simultaneously in opposite directions over the channel.

The DANE sends the DANE capabilities message to the 3GP-DASH Client (Step 5). When received, the 3GP-DASH Client replies with a client capabilities message (Step 6). As specified by ISO/IEC 23009-5 [54], the messages are WebSocket messages sent in the text format and formatted in XML. More specifically, the DANE and 3GP-DASH client negotiate the use of the following SAND messages for consistent QoE/QoS:

– PER: SharedResourceAssignment, DaneCapabilities

– Status Messages: SharedResourceAllocation, ClientCapabilities

– QoE Metrics: BufferLevel, PlayList

When the capabilities messages have been exchanged, the WebSocket connection stays open and further SAND messages relevant for consistent QoE/QoS may be exchanged, namely PER messages on shared resource assignment, QoS information and throughput, QoE metrics and status messages shared resource allocation.