7 MBMS Client to Application Interfaces for Data
26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
7.1 General
The MBMS client when providing a DASH Streaming Application User Services should implement the generic HTTP interface as defined in clause 7.3.
In this case, the MBMS client shall implement at least on of the following:
– the functions of a DASH server as defined in clause 7.4.2, or
– the functions of a DASH-aware Network Element (DANE) for SAND4M mode as defined inclause 7.4.3. .
The MBMS client may act as a proxy and may proxy all HTTP requests from the DASH client or may only proxy selected requests, such as MPD updates. The details of operation are implementation specific.
The requirements for the DASH client are documented in clause 7.4.4.
For additional usage guidelines refer to TS 26.346 [5], Annex K and in this specification refer to Annex E.
7.2 File Copy Interface
The MBMS client may copy files delivered by MBMS User Services to a local file storage that is controlled by the MBMS aware application. The application is responsible for the management of the storage.
7.3 HTTP Interface
The MBMS client may provide an HTTP server such that the MAA can access the files delivered over the MBMS User services by using regular HTTP Methods. The MBMS client may act as an HTTP cache for the resources delivered through the MBMS system.
The MBMS client offering delivered files and Media Segments through HTTP Interface should comply with a server as specified in RFC 2616 [15]. MBMS Clients providing resources through an HTTP interface should implement relevant HTTP server functionalities to support HTTP GET methods as required by the APIs.
MAAs communicating with the MBMS client over HTTP should comply with a client as specified in RFC 2616 [15]. MAAs should use the HTTP GET method or the HTTP partial GET method, as specified in RFC 2616 [15] to access files offered at HTTP-URLs.
MAAs communicating with the MBMS client over HTTP should support partial-file-accept requests and partial file responses as defined in TS 26.346 [5], clauses 7.9.1, 7.9.2.1 and 7.9.2.2.
Without excluding other response options, as a response to a partial-file-accept request using a regular HTTP GET request an MAA may typically receive one of the following responses:
1) 200 OK with Content-Type set to the Media Type of the requested object
2) 200 OK with the Content-Type set to application/3gpp-partial and the message format according to the definition in clause 7.9.2.2 of TS 26.346 [5].
3) 416 Requested Range Not Satisfiable with the additional information according to the definition in clause 7.9.2.2 of TS 26.346 [5].
4) 404 Not Found.
Case 1 is the regular response.
Guidelines for handling request responses according to case 4 from above are provided in clauses 7.3.8 and A.7 of TS 26.247 [6].
Guidelines for handling request responses 2 and 3 from above are provided in clause A.9 of TS 26.247 [6].
7.4 DASH-Specific Interfaces
7.4.1 General
The MBMS client when providing a DASH Streaming Application User Services should implement the generic HTTP interface as defined in clause 7.3.
In this case, the MBMS client shall implement at least one of the following:
– the functions of a DASH server as defined in clause 7.4.2, or
– the functions of a DASH-aware Network Element (DANE) for SAND4M mode as defined inclause 7.4.3. .
The MBMS client may act as a proxy and may proxy all HTTP requests from the DASH client or may only proxy selected requests, such as MPD updates. The details of operation are implementation specific.
The requirements for the DASH client are documented in clause 7.4.4.
For additional usage guidelines refer to TS 26.346 [5], Annex K and in this specification refer to Annex E.
7.4.2 MBMS Client as DASH Server
7.4.2.1 General
If the MBMS client supports the DASH Server functionalities, the MBMS client shall support sufficient functionalities to provide a valid DASH Media Presentation as defined in TS26.247[7].
For this purpose, the MBMS client may rewrite the MPD to provide a valid service based on the data received in the DASH-over-MBMS service. Typical operations that the MBMS client may implement:
– Ensure that the URLs of the DASH Resources in the MPD resolve to the location at which the MBMS client provides the resources delivered through the MBMS User Service,
– Ensure that the timeshift buffer expressed in the MPD does not refer to non-available resources,
– Ensure that the availability times of the DASH resources on the MBMS clients DASH Server are correctly documented in the MPD,
– Ensure that MPD Updates are done sufficiently often, for example by setting the @minimumUpdatePeriod to 0 in order for the DASH client to revalidate the MPD prior to every Segment request.
Some specific functions are provided in the remainder of clause 7.4.2.
7.4.2.2 Time Synchronization
The MBMS client, if providing the content as a DASH server, should offer the Time Synchronization as defined in clause 11.5.2 of TS 26.247 [7].
7.4.2.3 Robustness
The MBMS client if providing the content as a DASH server may implement the Robustness Tools on the server as defined in clause 11.6 of TS 26.247 [7].
7.4.3 MBMS Client as DASH-Aware Network Element (DANE)
If the MBMS client acts as a DANE, it shall implement the DANE SAND4M functionalities as required in clause 13.10.2 of TS 26.247 [7].
If the MBMS client identifies that the DASH client ignores the SAND messages, it should use other means to provide the functionality for redirecting the client, e.g. the functions defined in clause 7.4.2.
7.4.4 DASH Client of MBMS-Aware Application
The DASH client of the MBMS aware application shall support general DASH client functionalities as required in TS 26.247 [7].
The DASH client of the MBMS aware application should support the Time Synchronization as defined in clause 11.5.3 of TS 26.247 [7].
The DASH client of the MBMS aware application should support the Robustness Tools on the client as defined in clause 11.5.3 of TS 26.247 [7].
The DASH client of the MBMS-aware application should support the the SAND4M functionalities in clause 13.10.3 of TS 26.247 [7].
7.5 RTP Streaming Delivery Method Interface
The MBMS Client should provide an interface such that the data delivered using the MBMS Streaming delivery method is provided as a packet stream that complies with a media format that can be decoded by the media receiver that is part of the MBMS client by offering a conforming SDP in the sdpURI. As a recommendation:
– The MBMS Client implements the functions of the "Hypothetical FEC Decoder" as defined in clause 8.2.2.11 of TS 26.346 [5],
– The MBMS Client provides the MAA with:
– A SDP that describes the packet stream.
– The network interface from which the data stream can be received. For that purpose, the MBMS Client may forward the packets locally, e.g. through a virtual network interface, or through the network to the client. In such an example, the MBMS client is expected to modify the SDP provided over in the User Service Description accordingly.
7.6 Packet Data Interface
The MBMS Client should provide an interface such that the data delivered using the MBMS Transparent delivery method can provide a packet stream that complies with the SDP provided in the value of the sdpURI.
The MBMS Client provides the application with:
– A SDP that describes the data stream.
– The network interface from which the data stream can be received. For that purpose, the MBMS Client may forward the packets locally, e.g. through a virtual network interface, or through the network to the client. In such example, the MBMS client is expected to modify the SDP accordingly to provide a session that conforms to the offered SDP.
7.7 HLS Specific interface
If the MBMS client supports the HLS Server functionalities, the MBMS client shall support sufficient functionalities to provide a valid HLS Media Presentation.
For this purpose, the MBMS client may rewrite the Master Playlist and the Media Playlist to provide a valid service based on the data received. An Example of operations that the MBMS client may implement is to ensure that the URLs of the HLS Resources in the Media Playlist or in the Master Playlist resolve to the location at which the MBMS client provides the resources delivered through the MBMS User Service. If the MBMS client has not received for any reason the resources, the MBMS Client may act as proxy to provide the resources or may perform an HTTP redirection (see Unicast Fall back in TS.26.346 Annex M [5]).