26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS
This clause provides service announcement, content authoring and distribution guidelines for services as described in Annex X.1 using DASH over MBMS. These guidelines do not replace the general MBMS UE capabilities specified in the present specification. However, the guidelines can describe services requiring MBMS UEs to support certain typical capabilities that are not necessarily mandatory.
K.2.2 Content Authoring
The content is encoded or transcoded according to a 3GP-DASH profile using the MBMS codecs (see clause 10). The encoder in particular ensures that the client has enough data for a continuous playout.
K.2.2.2 Media coding
High Definition video at 720p@30fps and Standard Definition at 480p@30fps are supported with H.264 (AVC) Progressive High Profile Level 3.1, if a video component is present. Audio is supported at 32kbps or higher with Enhanced aacPlus (HE-AAC v2) (see clause 10.3).
According to TR 26.906  , the observed minimum bit rate to achieve MOS (Mean Opinion Score)=3.5 ("Good Quality") varies with the device type e.g. tablets or smartphone, the resolution, the display size, the encoder, and the content.
The audio bitrates and recommended codec depending on content are depicted in clause 10.3.
In case subtitles (a.k.a. Closed Caption) are provided, the use of Timed Text format as specified in TS 26.245 carried with the video segments is defined.
K.2.2.3 DASH formatting
The encoded bitstreams are segmented and packaged according to the 3GP-DASH specification TS 26.247 according to a 3GP-DASH profile. In addition, the constraints of MPEG DASH  ISO BMFF live profile apply. This includes, but is not limited to:
– The Segment Template is used for URL addressing of segments.
– Each segment starts with a stream access point of type 1 or 2.
– Certain tools such as Subsets, Segment lists and so on are not used.
The duration of the media data in the segments (segment duration) is typically constant signalled by the @duration attribute. The maximum tolerance of segment duration does not typically exceed ±50% and the maximum accumulated deviation over multiple segments is ±50% of the signaled segment duration. Such fluctuations in actual segment duration may be caused by for example ad replacement or specific IDR frame placement. Note that the last segment in a Period may be shorter.
For video, the signalling of width, height and frame rate are added.
For audio, the signalling of the language are added.
For subtitles, the signalling of the role of the subtitles is to be added. In addition, the signalling of the language is to be added if different than the language of the audio.
For providing a linear media streaming service based on DASH the following parameter settings are suitable:
– MPD@type is set to dynamic
– MPD@availabilityStartTime is set to any suitable value that expresses the start time of the Media Presentation such that segment availabilities can be computed.
– MPD@minimumUpdatePeriod is expected to be present. If the MPD@minimumUpdatePeriod is provided, i.e. the exact end time of the Media Presentation is unknown. Setting the value of the minimum update period primarily affects two main service provider aspects: A short minimum update period results in the ability to change and announce new content in the MPD on shorter notice. However, by offering the MPD with a small minimum update period, the client requests an update of the MPD more frequently. However, a small value does not mean that the MPD does have to be updated, it just defines the request interval of the DASH client. Therefore, in DASH over MBMS, the MPD@minimumUpdatePeriod may most suitably be set to be as small as 0 and in this case MPDs can be updated basically instantaneously. Note that the value 0 implies that all segments with availability start time less than or equal to the request time of the MPD are available at the location advertised in the MPD and no Segments-URLs can be deduced and declared valid for any segment with availability start time larger than the request time of the MPD. This means for extending the list of Segments, a DASH client is expected to revalidate the MPD with the request of every new Segment.
– Segment Duration (SDURATION)
– The segment duration typically influences the end-to-end latency, but also the switching and random access granularity as in DASH-264/AVC each segment starts with a stream access point which can also be used as switch point. In DASH over MBMS, i.e. no use of dynamic bitrate adaptivity, switching is of less relevance. The service provider sets the value taking into account at least the following:
– the desired end-to-end latency
– the desired compression efficiency
– the start-up latency
– the desired switching granularity, if content is for example offered also for unicast distribution
– the desired amount of HTTP requests per second
– the variability of the expected network conditions
– Reasonable values for segment durations are between 1 second and 10 seconds.
– More considerations in the context of DASH over MBMS are considered in clause X.2.5
– MPD@minBufferTime (MBT) and Representation@bandwidth (BW)
– the value of the minimum buffer time does not provide any instructions to the client on how much media data to buffer. The value describes how much buffer a client would have under ideal network conditions. As such, MBT is not describing the burstiness or jitter in the network, it is describing the burstiness or jitter in the content encoding. Together with the BW value, it is a property of the content. Using the "leaky bucket" model, it is the size of the bucket that makes BW true, given the way the content is encoded. The minimum buffer time provides information that for each Stream Access Point (and in the typical case that each Media Segment starts with a SAP, this holds for the start of the each Media Segment), the property of the stream: If the Representation (starting at any segment) is delivered over a constant bitrate channel with bitrate equal to value of the BW attribute then each segment with presentation time PT is available at the client latest at time with a delay of at most PT + MBT. The MBT typically may for example be set to the coded video sequence size of the content.
– MPD@timeShiftBufferDepth (TSB):
– If the content is to be consumed at the live edge, then the time shift buffer depth is set short. However, it is recommended that the TSB is not smaller than the recommended value of 4*SDURATION and 6 seconds in media time in order for the client to do some pre-buffering in more difficult network conditions.
NOTE: The shorter the timeShiftBufferDepth the better the time synchronization between client and segmenter.
– No restrictions on the accessibility of the content are provided, then the TSB may be set to a large value that even exceeds the media presentation duration. However, the TSB cannot exceed the capabilities of the client.
– When joining, the MBMS client may change this value in the MPD before forwarding it to the application to avoid that the client requests data, which is not yet received.
– MPD@suggestedPresentationDelay (SPD):
– If synchronized play-out with other devices adhering to the same rule is desired and/or the service providers wants to define the typical live edge of the program, then this value is provided. The service provider sets the value taking into account at least the following:
– the desired end-to-end latency;
– the typical required buffering in the client, for example based on the network condition;
– the segment duration SDURATION;
– the time shift buffer depth TSB.
– In general ,reasonable value may be 2 to 4 times of the segment duration SDURATION, but it is recommended as a guideline that the time is not smaller than 4 seconds in order for the client to enable building sufficient buffer. However, for DASH over MBMS the value may be smaller as delivery guarantees minimize the jitter.
K.2.3 User Service Description (USD) and Media Presentation Description (MPD)
As a guideline, the User Service Description is usually constructed such that it contains
– At least one download delivery method. i.e. a deliveryMethod element is included in the userServiceDescription element, with a reference to an SDP indicating FLUTE;
– No streaming delivery method;
– Possibly additional download delivery methods to carry associated files;
– A reference to one Media Presentation Description fragment. That Media Presentation Description describes all transported video representations and audio representations. Note, the UE may receive MPD updates in-band with the file delivery session instance.
– Note that only a single quality representation is made available for each content component as Adaptive Bitrate streaming is not used.
– The MPD@type element contains the value "dynamic".
– No File Repair definition in the Associated Delivery Procedure (ADP) description;
– Possibly a Reception Reporting ADP to collect QoE (Quality of Experience) statistics from MBMS or DASH clients; Note, ADP for reception reporting may also be provided in-band with the file delivery session instance
– Possibly a Security Description if the service requires a registration;
– The FEC scheme is described in-band with FLUTE File delivery;
– A Schedule Description when the delivery session instance is not always present; Note, the UE may receive schedule fragment updates inband within the file delivery session instance.
Additional application specific metadata may be provided together with the transport control metadata or out of band.
NOTE: The MPD is typically provided before the reception starts together with the other service description fragments. When the content of the MPD changes the updated MPD is delivered during the session in-band with the media segments on the same download delivery session. The MBMS client keeps the latest MPD until an updated MPD is received so that the DASH player can fetch the MPD locally. It is assumed that these updates occur seldom, for instance once the session end time becomes known.
In the absence of receptions of A and B flags, the end of transmission of an object is the expires time for the latest FDT describing the object. Objects are to be described on an FDT instance with the Expires attribute indicating a time short after (e.g. 1 or 2sec) the expected transmission of the last packet for that object.
Furthermore, the client ensures that:
– media is delivered and available on time at the receiver in order for the DASH client to schedule the playout;
– it does not have to process the MPD for regular operation of the service, or at least no modifications of the MPD are necessary in order to properly operate the service.
The MBMS bearer is dimensioned such that it accommodates the aggregated 3GP-DASH representations bitrate for all content at any times, including header and FEC overhead.
The encoder is set such that in particular it ensures that the clients have enough data such that they are able to perform a continuous playout.
A single FLUTE Delivery Session is used. In case the linear stream is composed by multiple media components such as several audio track, timed text or video, the encoder can multiplex all components into a single media segment (using individual tracks) or generate a separate segments sequence for each component. In the latter case, all media components are carried as individual files within the same FLUTE Delivery Session.
In some cases, metadata fragments such as MPD updates, Schedule Fragment updates or Associated Delivery Procedure Description Fragments may be delivered in-band with the DASH segments on the same FLUTE delivery session.
The FEC overhead is typically adjusted to the radio conditions and the used radio configurations of the MBMS area such as to achieve a satisfactory quality of experience. Audible and visible impairments are then seldom. The target video and audio MTBF (Mean Time Between Failure) is usually set by the operator depending on the type of service.
NOTE: ITU-T G.1080 recommends <=1 error event per hour for SDTV and <=1 error event per 4 hours for HDTV.
K.2.5 Minimizing tune-in times, switching times and presentation delay
The presentation time end-to-end delay as well as start-up and switching times of a linear audio/video service are key factors impacting quality of experience of the users.
The choice of segment duration depends on the particular application.
– The segment duration constrains the tune-in time since the FLUTE receiver needs to buffer the segment to be able to perform FEC decoding. So one SAP at the beginning of the segment is enough.
– The segment duration constrains the end-to-end delay.
– The segment duration affects the robustness of the stream. The larger the segment durations (with multiplexed media components) the better the transport efficiency is.
– The segment duration affects the user experience on a segment loss. The larger the segment duration is the larger the disruption is. Clients can make use of partial segment data when possible to reduce the perceptual impacts.
Therefore, if the application is linear TV over an area where robustness for large coverage area is key and end-to-end delay a secondary objective, a large segment size of e.g. 10s with FEC is appropriate. In that case tune-in times can be improved with adding several SAP per segments. If the application requires a low end-to-end delay in an area where efficiency is a secondary objective then segment durations in the order of 1s are appropriate. In DASH unicast the DASH player requests the segments depending on their availability start time which describes the time at which the segment are supposed to be available on the server for download.
In MBMS, the Media Presentation Description (MPD) indicates an AST that describes the earliest time at which the segment are supposed to be available at the DASH client (on the UE). This value needs to be set and adjusted by the system according to a worst case delay to reach some level of confidence that all MBMS clients in all broadcast areas will receive the segments on time. The processing delay (e.g. due to FEC recovery) depends on the UE platform and implementation. It will therefore happen for several clients that the transmission delay is actually shorter. It is then possible for the DASH client to evaluate this actual segment availability time on the UE and adjust accordingly when it fetches the segments from the FLUTE receiver to minimize delay.
The client may adjust the segment availability start time by modifying the MPD@availabilityStartTime in the MPD prior to forwarding the MPD to the DASH client. However, for seamless operations such modifications are expected to be done consistently for any MPD updates i.e. adjusted by the same value.
As implementation guidelines, the client can optimize switching between video streams by enabling simultaneous reception of 2 video streams. In that case the device has to support at minimum decoding and rendering of two H.264 high profile streams, with each streams bit rate of 1.5 Mb/s, frame rate of 30fps, and resolution of 720p (1280×720). Also the device provides sufficient buffer to store at least 5 minutes of streaming video for 2 video streams at 1.5Mbps per stream and has at least 1GB memory to support concurrent multicast services
K.2.6 Robust DASH service offering
When operating DASH-based live services, errors and failures are typically unavoidable. In order to still provide continuous services, DASH-based service offerings should be offered in a robust manner and DASH client should implement measures to compensate any operational issues. In case of DASH-over-MBMS distribution, additional problems may occur due to segment losses or other problems. This section discusses typical problems and provides recommendations for robust service offerings. In general, DASH clients should implement the error handling technologies as defined in TS26.247 , Annex A.7.
K.2.6.2 Client Server Synchronization Issues
In order to access the DASH segments at the proper time as announced by the segment availability times in the MPD, client and server need to operate in the same time source, in general a globally accurate wall-clock. There are different reasons why the DASH client and the media generation source may not have identical time source, such as
– DASH client is off because it does not have any protocol access to accurate timing.
– DASH client clock drifts against the system clock and the DASH client is not synchronizing frequently enough against the time-source.
– The DASH segmenter is synchronized against a different time source than DASH client.
In order to avoid synchronization issues the following recommendations are provided:
– The segment availability times announced in the MPD should be generated from a device that is synchronized to a globally accurate timing source,.
– The MPD should contain at least one UTCTiming element: as defined in TS26.247 .
K.2.6.3 Synchronization Loss of Segmenter
The DASH segmenter may lose synchronization against the input timeline for reasons such as power-outage, cord cuts, CRC losses in the incoming signals, etc. In this case:
– Loss of synchronization may result that the amount of lost media data cannot be predicted which makes the generation of continuous segments difficult.
– The DASH segmenter cannot predict and correct the segment timeline based on media presentation timestamps, since the presentation timeline may contain a discontinuity due to the synchronization loss
– There are cases where no media segments are available, but the MPD author knows this and just wants to communicate this to the receiver.
In order to address synchronization loss issues at the DASH segmenter, the following options from should be considered with preference according to the order below:
– The server should always offer a conforming media stream. In case the input stream or encoder is lost, the content author may add dummy content. This may be done using a separate Period structure and is possible without any modifications of the standard.
– Early terminated Periods as defined in TS26.247 , section 8.4.2 may be used. This expresses that for this Period no more media is present and the client should await a new Period to restart. Such Periods should only be used if Media Presentation author is experiencing issues in generating media, e.g. due to failures of a live feed. The MPD is updated using the @minimumUpdatePeriod, i.e. the timeline is progressing. This permits the DASH segmenter to signal that there is an outage of media generation, but that the service is continuing. It is then up to the client to take appropriate actions, e.g. stall the content, but provide indication to the user that the service is expected to continue.
K.2.6.4 Encoder Clock Drift
In certain cases, the multi-bitrate encoder is slaved to the incoming TV feed, e.g. an MPEG-2 TS, i.e. it reuses the media time stamps also for the ISO BMFF. Annex A.8 of ISO/IEC 23009-1  handles drift control of the media timeline, but the impact on the segment availability time (i.e. MPD updates) is not considered or suggested. In particular when the segment fetching engine of the client is only working with the segment availability timeline (so is not parsing the presentation timeline out of the segments), the segment fetching engine will not fetch the segments with the correct interval, leading to buffer underruns or increased e2e delay.
In order to support robust offering even under encoder drift circumstances, the segmenter should avoid being synced to the encoder clock. In order to improve robustness, in the case of an MPD-based offering Periods may be added more frequently in a continuous manner as defined in TS26.247 , clause 18.104.22.168.
K.2.6.5 Segment Unavailability
When a server cannot serve a requested segment it gives an HTTP 404 response. If the segment URL is calculated according to the information given in the MPD, the client can often interpret the 404 response as a possible synchronization issue, i.e. its time is not synchronized to the time offered in the MPD. In the DASH-over-MBMS case, a 404 response is also likely to be caused by non-reparable transport errors. This is even more likely if it has been possible to fetch segments according to the MPD information earlier. Although the client, which is normally located in the same device as the DASH player, knows what segments have been delivered via broadcast and which ones are missing in a sequence, it cannot indicate this to the DASH client using standard HTTP responses to requests for media segments.
To address signalling of segment unavailability between the client and server and to indicate the reason for this, it is recommended to use regular 404s with the Date-Header specifying the time of the server. The DASH client, when receiving a 404, knows that if its time is matching the Date Header, then the loss is due to a segment loss.
K.2.6.6 Swapping across Redundant Tools
In case of failures of infrastructure, redundant tools may kick in. If the state is not fully maintained across redundant tools, the service may not be perceived continuous by DASH client. Depending on the swap strategy, the interruptions are more or less obvious to the client. Similar issues may happen if DASH segmenters fail, for example the state for segment numbering is lost.
To enable swapping across redundant tools, the following should be considered with preference in the order as listed.
– the content author is offering the service redundant to the client (for example using multiple Base URLs) and the client determines the availability of one or the other. This may be possible under certain circumstances.
– Periods may be inserted at a swap instance in order to provide the new information after swap. If possible, the offering should be continuous, but the offering may also be non-continuous from a media time perspective.
– A completely new MPD is sent that removes all information that was available before any only maintains some time continuity. Despite this is not fully specified in TS26.247, DASH clients should be prepared to continue the service.
Annex L (Normative):