13.7 Use of SAND for Proxy Caching

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

13.7.1 Introduction

To realize partial representation caching, SAND can be used to inform DASH clients about partially cached representations, e.g., via use of the PER messages ResourceStatus, DeliveredAlternative and MPDValidityEndTime, described in clause 13.7.3. Moreover, toward realizing next segment caching, SAND can be used by DASH clients to inform the network (i.e., DANE) anticipated DASH segments, acceptable alternative content, etc. leading to next segment caching, e.g., via use of the status messages AnticipatedRequests and AcceptedAlternatives, described in clause 13.7.2. An example workflow realizing next segment caching is presented in clause 13.7.4. Further details of the proxy caching use case are in TR 26.957 [55].

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

13.7.2 Status Messages for Proxy Caching

13.7.2.1 AnticipatedRequests

This message allows a 3GP-DASH client to announce to a DANE its interest to a specific set of segments. The intent is to signal the set of segments in representations that the DASH client is likely to select and request soon.

3GP-DASH clients sending an AnticipatedRequests message shall follow the syntax and semantics in Table 3 of ISO/IEC 23009-5 [54], and shall include the sourceUrl parameter.

13.7.2.2 AcceptedAlternatives

This message allows 3GP-DASH clients to inform DANEs on the media delivery path (typically caching DANEs), that when they request a given DASH segment, they are willing to accept other DASH segment(s) as an alternative. A 3GP-DASH client shall not include alternative segments unless it is ready to receive them and be able to play them.

3GP-DASH clients sending an AcceptedAlternatives message shall follow the syntax and semantics in Table 5 of ISO/IEC 23009-5 [54], and shall the sourceUrl parameter.

13.7.3 PER Messages for Proxy Caching

13.7.3.1 ResourceStatus

This message allows for a DANE to inform a 3GP-DASH client – typically in advance – about knowledge of segment availability including the caching status of the segment(s) in the DANE.

3GP-DASH clients receiving a ResourceStatus message shall follow the syntax and semantics in Tables 10-12 of ISO/IEC 23009-5 [54].

13.7.3.2 MPDValidityEndTime

This message provides the ability to signal to the client that a given MPD, whose @type is set to ‘dynamic’ and @minimumUpdatePeriod is present, can only be used up to at a certain wall-clock time.

3GP-DASH clients receiving an MPDValidityEndTime message shall follow the syntax and semantics in Table 17 of ISO/IEC 23009-5 [54].

13.7.3.3 DeliveredAlternative

As a response to an AcceptedAlternatives message sent by a 3GP-DASH client, a DANE may deliver an alternative segment rather than the requested segment. If so, the DANE shall send a DeliveredAlternative message to the 3GP-DASH client to inform that the response contains a segment alternative and not the requested segment.

3GP-DASH clients receiving a DeliveredAlternative message shall follow the syntax and semantics in Table 23 of ISO/IEC 23009-5 [54].

13.7.4 Example Workflow on SAND Use for Proxy Caching

An example workflow realizing next segment caching is depicted in Figure 13.2, where DANE (PSS Server) caches content based on SAND-based status messages received from the DASH client (PSS client). For the SAND messages depicted in Figure 13.2, the messageType codes in Table 2 of ISO/IEC 23009-5 [54] are used.

Figure 13.2: Example SAND workflow for Proxy Caching

Step 1: The SAND capability exchange between the DANE and client will negotiate the use of the related SAND messages for proxy caching (using the SAND messages ClientCapabilities and DaneCapabilities as described in Clause 13.4). More specifically, the DANE and DASH client negotiate the use of the following SAND messages:

– PER: ResourceStatus, DeliveredAlternative, MPDValidityEndTime, DaneCapabilities

– Status Messages: AnticipatedRequests, AcceptedAlternatives, ClientCapabilities

Step 2a: Client issues an HTTP GET and sends request for media to the DANE. In the header of the HTTP request (per the standardized formats in ISO/IEC 23009-5 [54], as described in Clause 13.4), client includes the SAND header that contains the status messages on proxy caching, namely on anticipated requests, accepted alternatives and/or next alternatives. DANE receives these status messages, processes them and then forwards the SAND header that contains the status messages.

Step 2b: The DANE forwards the HTTP request for the desired media to the content server, since the DANE does not have a cached version of the media. DANE forwards the HTTP headers carrying SAND messages to without any modification.

Step 3a: Content server responds with HTTP 200 OK with body containing media.

Step 3b: In the HTTP response, DANE includes SAND header to advertise availability of PER messages on proxy caching with the URI hosted at the DANE for the corresponding PER messages, namely on resource status, DANE resource status and/or delivered alternatives.

Step 4: Client issues an HTTP GET request targeting the URI hosted at the DANE to fetch the PER messages on proxy caching, namely on resource status, DANE resource status and/or delivered alternatives. In the header of the HTTP request, client may include the SAND header that contains further status messages on proxy caching, namely on anticipated requests, accepted alternatives and/or next alternatives.

Step 5: DANE responds with the HTTP OK with body containing the PER message on proxy caching, namely on resource status, DANE resource status and/or delivered alternatives.

Steps 6,7: Client requests and downloads cached media from DANE.