Nested harmonic broadcasting for scalable video over mobile datacast channels

Transcription

1 WIRELESS COMMUNICATIONS AND MOBILE COMPUTING Wirel. Commun. Mob. Comput. 2007; 7: Published online in Wiley InterScience ( DOI: /wcm.476 Nested harmonic broadcasting for scalable video over mobile datacast channels Thomas Stockhammer 1, Tiago Gasiba 1, Wissam Abdel Samad 2 *,y, Thomas Schierl 3, Hrvoje Jenkac 4, Thomas Wiegand 3 and Wen Xu 2 1 Nomor Research, Munich, Germany 2 BenQ mobile, Munich, Germany 3 Fraunhofer HHI, Berlin, Germany 4 Institute for Communications Engineering, Munich University of Technology, Munich, Germany Summary The integration of reliable Video-on-Demand (VoD) broadcasting schemes in mobile datacast systems, specifically in DVB-H, is studied and enhanced. Sophisticated VoD broadcasting schemes such as Harmonic Broadcasting (HB) allows receivers to tune into the ongoing transmission of a video stream at arbitrary time, while still being able to receive the multimedia sequence from beginning to end, after short initial playout latency. In addition, we address service enhancements by using scalable video coding (SVC) to support heterogeneous receiver capabilities and receiving conditions as well as the reception of the signal from more than on transmission site. We present and discuss options for the integration of VoD broadcasting schemes in combination with fountain codes. Optimizations in parameter selection are discussed. A realistic protocol environment is only slightly modified to support our system concept. Simulation results show the benefits of the discussed VoD scheme compared to existing approaches if integrated in DVB-H. Copyright # 2007 John Wiley & Sons, Ltd. KEY WORDS: H.264/AVC; scalable video coding; fountain codes; application layer FEC; mobile datacasting; multiple site reception 1. Introduction 3G networks have been designed for individual point-to-point (p-t-p) connections and have been optimized for high-data rates, quality-of-service support, and the flexible transmission to multiple users. However, they do not address the distribution of high-quality popular content to a large number of users. Therefore, next generation mobile networks beyond 3G will have to include broadcast distribution for efficient dissemination for such content. Especially mobile TV and wireless streaming services to mobile users are recently experiencing rejuvenation due to advanced terminal capabilities, new network infrastructure and significant improvements in media-coding efficiency. To deliver such high-quality video services efficiently to a multitude of mobile terminals in parallel, point-to-multipoint (p-t-m) transmission schemes are favorable and have already been adopted in recent standardization efforts. For *Correspondence to: Wissam Abdel Samad, BenQ mobile, Munich, Germany. y wissam.abdel-samad@nomor.de Copyright # 2007 John Wiley & Sons, Ltd.

2 236 T. STOCKHAMMER ET AL. example, 3GPP has recently enhanced the existing mobile systems EGPRS and UMTS by introducing additional p-t-m transmission bearers to provide Multimedia Broadcast/Multicast Services (MBMS) [1,2]. Furthermore, the terrestrial Digital Video Broadcasting (DVB) system, DVB-T, has been enhanced to meet the requirements of moving receivers and the DVB-H (DVB for Handheld) standard was released [3]. Whereas DVB-T, -S, and -C mainly aim at Digital TeleVision (DTV) broadcast over MPEG-2 transport streams, the DVB-H system is IP-based [3]. DVB-H not only enables DTV, but also IP data services by the definition of appropriate content delivery protocols (CDP). Broadcasting data are usually referred to as datacasting. Traditional video broadcast services such as plain TV services only allow that all receivers retrieve an identical media stream synchronously. Arbitrary tune-in of receivers into ongoing program streams is supported by random access points in the media streams. Despite the capability to almost instantaneously join such a stream, this does not prevent that the user will miss a significant amount of earlier content, for example, first part of a movie. However, especially for mobile users, services are highly desirable in which the content can be arbitrarily accessed anytime and anywhere. To accomplish this Video-on- Demand (VoD) feature, trivial schemes offer the service over conventional p-t-p connections, for example, as provided by GPRS or UMTS packetswitched data channels. However, with increasing number of subscribers, the system may not scale appropriately. Then, the service will consume a significant amount of transmission resources and cellular systems get congested and overloaded. To avoid the drawbacks of multiple p-t-p connections, numerous VoD broadcasting schemes have been proposed and evaluated [4 6]. All of them have in common that media can be requested asynchronously by receivers without the necessity for individual p-t-p connections. This media stream, or more appropriately, the media file encapsulating the stream, is segmented and each segment is transmitted with some individual bitrate. This enables that with only some reasonable bandwidth expansion, numerous independent receivers can access the media stream on demand within a short time. The most prominent VoD broadcasting schemes are known as Harmonic Broadcasting (HB) [4] and Pyramid Broadcasting (PB) [5]. Initially designed to operate in error-free conditions, these schemes have recently been extended to operate in packet loss and noisy environments [7 9]. In Reference [10], practical aspects for the integration of PB into the DVB-H CDP framework have been studied. The concept relies on using a type of fountain erasure codes, known as Raptor Codes [11,12], as application layer FEC for file delivery in DVB-H, in addition to introducing some modifications on the transmission scheme to satisfy the download delivery protocol constraints. In this work, we propose a generalized framework for the transmission of VoD content over a broadcast network in different ways. First, we integrate scalable video in the transmission framework such that receivers have the possibility to trade playout delay with playout quality under different reception conditions, different terminal capabilities, etc. For this purpose, we use the currently specified scalable extension to H.264/AVC [14], known as scalable video coding (SVC) [16,17]. Second, we consider a DVB-H service area where the participating terminals can possibly benefit from the reception from multiple transmission sites. By appropriately adjusting parameters relating to source and channel coding as well as transmission we obtain flexibility for receivers in terms of playout delay and playout quality. The developed framework, referred to as Nested HB, is quite generic to many applications, for example, peer-to-peer streaming, mobile adhoc networks [22], or cellular mobile systems and is, therefore, an interesting concept for other networks beyond classical 3G architectures. However, for the sake of conciseness, we restrict ourselves here to the distribution of SVC video data over DVB-H networks. The paper is organized as follows: Section 2 provides a basic system overview and formulates the problem. Section 3 is dedicated to introduce the various system components. Section 4 describes the Nested HB framework and proposes and discusses system optimizations. Selected but representative simulation results are given in Section 5, and some conclusions are drawn in Section Video-on-Demand Services Over Mobile Broadcast Networks Assume a mobile broadcast network as depicted in Figure 1. To have good coverage, it is expected that multiple transmission sites are in place to service mobile users anytime and anywhere. Assume now that within the service area, many users try to access the content. The receivers distinguish themselves by different capabilities, for example, they have different

3 NESTED HARMONIC BROADCAST 237 Fig. 1. Mobile broadcast scenario multiple site reception. display sizes, different processing power, some are mobile and some are more stationary, etc. In general, their reception conditions might be quite different and heterogeneous. Despite these harsh transmission conditions, reliability is a major concern for many services as, for example, the loss of just a transport packet of data may destroy the entire file. Specifically, VoD services shall provide certain user experience: whenever a user decides to join the service, it is desirable that the content can be played error-free from beginning with a startup latency as low as possible. As unicast distribution does not scale to many users, broadcast approaches are desirable. Assume that receivers tune into an ongoing broadcast distribution without any coordination among receivers and between transmitter and receivers. Although trivial broadcast disks may solve the problem, their inefficiency has triggered significant efforts for better exploitation of the available bandwidth with low startup delay, see, for example, References [4 6] and references therein. These methods have in common that the media bit-stream is segmented into segments S i, where each segment is periodically broadcast on different parallel channels, and each channel is assigned a different transmission rate R t;i. The segments S i with i ¼ 1;...; N S are obtained by segmenting the media file into N S segments, each of length L i. Each segment is also assigned a relative due time T i representing the decoding time of the first media unit in the segment relative to the first media unit in the file. In Reference [5], HB has been proposed as a bandwidth optimal solution for constant bit rate (CBR) media. It suggests to segment the media stream into N s segments of equal size or duration, where segment S i is broadcast with a bit rate R i ¼ R m =i. The bandwidth extension is E ¼ i 1=i and the maximum initial waiting time max ¼ T m =N s : Figure 2 sketches the principle of an example HB, where the media bitstream is segmented into N s ¼ 4 segments. As can be observed, each segment S i is broadcast with different transmission rate R t:i on individual virtual channels (Ch1 Ch4). Assume that two receivers (Rx1, Rx2) tune into the broadcast at arbitrary time. The highlighted bars within the channels indicate data which are consumed by receiver Rx1. After the first segment S 1 has been completely received, the receiver starts the playout of the first media segment and immediately stops listening to the first channel. The scheme is designed such that after finishing the playout of segment S i, it is guaranteed that segment S iþ1 is completely available at the receiver in order to allow a smooth playout. Originally, VoD broadcasting schemes have been designed to operate over lossless transmission channels, for example, delivery over Local Area Networks (LAN). Since wireless networks suffer from losses, we will discuss in the following how such broadcast

4 238 T. STOCKHAMMER ET AL. Fig. 2. Harmonic broadcasting (HB): the original media stream is segmented and segments are transmitted at different rates. Receivers can tune in at arbitrary time and retrieve the media stream from beginning after a short waiting time. The spaces between segments are for illustration purposes only. schemes can be extended by using Forward Error Correction (FEC) to operate over packet loss channels. Obviously, as long as a carousel transmission of segments is applied, packet losses can be compensated by waiting for the next replica of a lost packet. However, due to the possibly long waiting time for the next replica, it has been proposed to not just carousel the packets of the segments, but to transmit a certain amount of parity packets in addition to the original information packets [4,8] by the application of forward error correction. In the referred works, it was shown that by applying the advanced fountain codes, the initial playout latency will only increase to a small extent. We base on these findings, but extend the work to realistic protocols and networks as well as that we consider broadcasting and reception from multiple sources, and the extension to scalable media coding for multidimensional user experience tradeoff in terms of playout and video quality. 3. Overview on System and Components 3.1. Content Delivery Protocol Stack Before presenting the proposed system concept, we introduce the considered protocol stack as well as system components. In the awareness and experience on the difficulties when realizing new services, we investigate the integration of such a service as discussed in Section 2 in existing system architectures. Specifically, we consider the DVB-H IP datacast (IPDC) protocol stack [18] which is designed to transport different types of media such as audio, video, text, pictures, and binary files. The CDP protocol stack is depicted in Figure 3 with only two proposed modifications in order to support efficient scalable and reliable VoD service: SVC encapsulation and VoD as indicated by the shaded box. In DVB-H, bearers provide the mechanism by which IP data are transported over IP multicast. SubSections 3.4 and 3.5 are dedicated to this aspect. When delivering content, either download or streaming delivery may be used. We decide for download delivery in the remainder as reliable VoD services generally rely on file delivery rather than streaming delivery which is more appropriate for live content. The delivery layer provides functionalities such as security and key distribution, reliability control by means of FEC techniques and associated delivery procedures such as file repair and reception reporting. Furthermore, the media rate and delivery rate usually do not and need not match. File delivery in DVB-H builds on the FLUTE protocol [15] which allows reliable delivery of files and other discrete binary objects over unidirectional channels. For more details

5 NESTED HARMONIC BROADCAST 239 Fig. 3. IP Datacast (IPDC) protocol stack in DVB-H. The red box shows our proposed extension discussed in the next sections. on the protocol and specifically on the applied FEC we refer to Subsections 3.6 and 3.7, respectively. To realize adaptivity to different reception conditions, the scalable video coding (SVC) is employed. To transmit SVC-encoded data over CDP, they need to be appropriately encapsulated in a file format. This aspect will be addressed in Subsection Scalable Video Coding (SVC) SVC [16,17] is currently being standardized within the Joint Video Team (JVT) of ITU-T and ISO/IEC as an extension to the H.264/MPEG-4 AVC [14] videocoding standard. It generates an H.264/AVC compliant, that is, backward-compatible base layer, and one or several nested enhancement layer(s). From an SVC media bit-stream, different operation points can be extracted, each representing a different level of bit rate, frame rate and/or spatial resolution. The way of extraction results in adaptation types which are referred as H.264/AVC performance even if lower bitrate resolutions are embedded in the bit-stream. The temporal scaling functionality of SVC is typically based on a temporal decomposition using hierarchical B pictures as shown in Figure 4. Each B picture of a higher temporal enhancement level is encoded with a higher Quantization Parameter, QP, (cascaded QP assignment), thus the fidelity per picture is decreasing with the decreasing importance in terms of the number of succeeding references by other pictures. In Figure 5 the structure of an SVC stream Temporal scalability: adaptation of frame rate Spatial scalability: adaptation of picture resolution SNR scalability: adaptation of video quality Thus, scalability within SVC is a functionality that allows the removal of parts of the bit-stream while achieving a reasonable coding efficiency at reduced temporal, spatial, or SNR resolution. Depending on the application requirements, SVC can achieve a ratedistortion performance which is close to non-scalable Fig. 4. Temporal and reference structure of an SVC stream with a base layer and a spatial enhancement layer including progressive refinement.

6 240 T. STOCKHAMMER ET AL. moov trak video mdat (AU 1-video, AU 2-video,..) trak audio mdat (AU 1-audio, AU 2-audio,..) mdat moov trak video trak audio (AU 1-video, AU 1-audio, AU 2-video, AU 2-audio,..) Fig. 5. 3gp file structure containing non-scalable media types. is shown, which comprises a group of pictures (GOP) of size eight for this example. GOPs can be independently decoded, if the preceding key picture is available and has random access properties. Spatial scalability is achieved by different encoder loops with an over-sampled pyramid for each resolution (e.g., QCIF, CIF, and 4CIF), including motioncompensated transform coding with independent prediction structures for each layer and inter-layer prediction as shown in Figure 4. In contrast to the encoder, the decoder can be operated in single loop, that is, for decoding inter-layer dependencies it does not need to perform motion compensation in lower layers on which it depends. SNR scalability is based on a Progressive Refinement (PR) approach, where the extension layers contain refinement quality information of the base layer in a progressive way. Thus, cutting byte-wise from the end of a PR fragment is possible. A PR layer only contains refinements for the residual (texture) data, which is also used for prediction in next higher temporal levels. By coding and organizing the progressive refinement information in a cyclic and prioritized way for a video frame, the truncation property is realized. Up to three PR layers can exist in a stream. Typically, the quality of each layer is enhanced by a QP delta value of 6. Finally, each layer of each slice is stored in a separate Network Abstraction Layer (NAL) unit, which can be transported individually. Due to the support of scalability, the emerging SVC standard has slightly higher but still reasonable complexity than the non-scalable counterpart [14,28]. A manageable complexity especially at the decoder is achieved, since SVC is based on a single-loop decoding process. Note that SVC is only one possible candidate for the realization of scalability in the presented framework. However, due to its good performance and its practical relevance when compared to other approaches such as MPEG-2 [29] and MPEG-4 Part 2 [30], we consider it as a prime candidate for our proposed system SVC in 3G File Format As we deliver objects in our VoD system, the media stream needs to be encapsulated in an appropriate container format to provide aspects as timing, access, or synchronization. The proposed file container format for SVC [19] is based on ISO base file format [20]. Note that the file format used by 3GPP-3gp file format [21] is also based on the ISO base file format such that the integration into an ISO file format is basically the only promising candidate for our framework. An extension to the 3G file format in alignment to the specification in Reference [19] may eventually be required for using SVC within 3GPP. It is necessary that the file is composed such that layers and segments within each layer are appropriately stored and are appropriately accessible for smart delivery in our context. In ISO base file format, media data (Access Units/ AUs) of different media types belonging to a media file are generally stored in the so-called mdat containers. Additional meta information about size, timing and location within mdat of the media data/ Access Units is stored separately in the so-called trak containers, thus, for each media type a trak and a mdat container exist. Additionally, all AUs of different media types can also be contained in an interleaved way within one mdat container for efficient file access. The overall container for the whole media file is called moov. Figure 5 shows the two different options of media arrangement within 3gp files as an example for storing non-scalable media. For SVC, AUs typically contain data of different scalability layers (different temporal, spatial or quality representations of the stream), which are stored in

7 NESTED HARMONIC BROADCAST 241 moov trakvideo all layers mdat (AU1-video: <NALUnits of layer L0, L1, L2>, AU2-video:<L0, L1, L2>, AU3-video:<L0, L1, L2>,...) moov trak video layer L0 mdat (AU1:<NALUs L0>, AU2:<L0>,..) trak video layer L1 mdat (AU1: <NAL Units of layer L1>, AU2:<L1>,..) trak video layer L2 mdat (AU1: <NAL units of layer L2>, AU2:<L2>,..) Fig. 6. SVC file structure containing scalable video data. separate SVC NAL units [17]. A set of SVC NAL units belonging to different scalability levels but to the same instance of time represent an SVC access unit.in the upper part of Figure 6, an SVC file is shown, for which each AU contains the NAL units for all layers in the file. The encapsulation of data would also be possible by using Reference [21]. The lower part of Figure 6 shows the encapsulation of data, which uses new definitions made in Reference [19]. The main problem if separating SVC data layer-wise in a file as shown in Figure 6 is the missing information in the file for rebuilding the NAL unit order of AUs, which is required by the decoder. Therefore, new NAL unit types are defined in Reference [19] allowing referencing NAL units of AUs in different tracks, thus the resulting SVC file can be separated layer wise onto different transport channels. With these extensions, the video layer-wise arrangement of SVC data as well as the access to individual segments within a file is enabled such for the file being used within the harmonic broadcast approach as proposed later in the framework. Within each layer, the data are stored such that the progressive download feature (see Reference [21]) is enabled. In this way, other DVB services can also be timesliced and multiplexed in the transmitted stream. Each receiver can tune into its intended service(s). At the same time, a non-time-sliced MPEG-2 DVB-T stream can be multiplexed with the time-sliced DVB-H streams as shown in Figure 7. Time slicing also enables receivers to support efficient cell-to-cell transfer. During the off-time between bursts, the receiver can monitor the same signal/service from other sites and switch between them if different sites have nonaligned time slice bursts as shown in Figure 7. This latter characteristic of a multi-site DVB-H transmission scheme can possibly be exploited by terminals 3.4. DVB-H Time-Slicing DVB-H extends DVB-T in a sense such that decoding in mobile environments and for handheld devices is enabled. For a comprehensive overview on DVB-H transport, we refer to Reference [3]. In DVB-T, TV channels are multiplexed to different OFDM subcarriers. In order to demodulate and decode a certain channel, all sub-carriers have to be demodulated in parallel. Since this process of demodulating and decoding the total received signal consumes significant battery power, a time-slicing mechanism has been introduced for DVB-H. High data rate bursts are transmitted in a short period of time, enabling the receiver to be power-off for most of the time. Each burst contains notification to the receiver of when to wake for the next burst. Fig. 7. Time slicing in DVB-H.

8 242 T. STOCKHAMMER ET AL. with advanced receiver capabilities. Terminals might not only listen and receive the service from a singletransmission site, but from multiple sites. A typical macro diversity or selective combining effect is experienced. We will exploit this property by the appropriate use of application layer FEC such that receivers with appropriate capabilities can receive multiple independent copies of signal Multi-Protocol Encapsulation (MPE) As DVB-H relies on DVB-T, natively MPEG-2 transport streams are transmitted. However, DVB-H introduces a multiprotocol encapsulation (MPE) scheme to map different packet-switched protocols, primarily IP, on these transport streams. A major component of the MPE is the so-called MPE-FEC. This additional FEC scheme is based on Reed Solomon codes to compensate the performance degradations due to Doppler effects in mobile channels. It is integrated in DVB- H in such a way that MPE-FEC ignorant receivers, for example, stationary ones, can also receive the service. An MPE-FEC frame can be envisioned as a matrix of 255 columns and a variable number of rows, as shown in Figure 8. Row sizes of 256, 512, 768, and 1024 are supported. Each entry in the matrix is 1 byte. The first 191 columns of the matrix are reserved for IP-datagrams and so this part of the frame is called the Application Data Table (ADT). Received datagrams are written into the frame column-wise one after another. The last 64 columns of the matrix are reserved for Reed Solomon parity bytes, and so this part of the frame is called the RS Data Table (RSDT). RS (255, 191) FEC is performed on the ADT row-wise and thus providing interleaving. By either padding some broadcast data with zero bytes or by puncturing some parity columns, the additional error correction may be strengthened or weakened according to broadcast operator s needs or service-specific adaptation. After the MPE-FEC frame is constructed, MPE sections are built from the ADT table according to the DVB standard. Each IP datagram is preceded by a 12-byte header, containing information of its start and end position in the MPE-FEC frame. Additional 4 bytes of CRC-32 are appended. If the CRC of some section fails at the receiver, all the bytes of this section are marked as erroneous and thus, the RS parity bytes are exploited to perform erasure correction instead of error correction. Similarly, FEC can be built from the RSDT, where each RS column constitutes a section. After the MPE and the FEC sections are formed, they can be mapped directly to Transport Stream (TS) packets. Each TS packet has 183 bytes of payload, 5 bytes of header information, and 16 bytes resulting from another Reed Solomon (n RS ¼ 204, k RS ¼ 188) error protection. Note that MPE-FEC ignorant receivers can still be supported. They can simply neglect Fig. 8. Multi-protocol encapsulation of IP-packets and MPE-FEC Reed Solomon encoding.

9 NESTED HARMONIC BROADCAST 243 TS packets that contain parts of RS parity sections, of course, at the expense of lower error resilience. The MPE-FEC, however, is not applicable to reliably transport our VoD service as it is restricted to a single time slice burst. It has neither sufficient block length or flexibility to protect an entire segment, nor it provides the fountain code property. Therefore, alternative solutions are desired and will be discussed in the following Reliable Download Delivery With FLUTE File Delivery over Unidirectional Transport (FLUTE) [15] is a protocol for the unidirectional delivery of files and other binary objects, for example, images, text, documents, software updates, video, and audio files. FLUTE was originally designed for transmission over the Internet on top of UDP/IP and is particularly suited for one-to-many delivery in transmission environments without feedback channel. It is adopted as a content delivery protocol for download delivery services in DVB-H (see protocol stack shown in Figure 3). In general, files or, more general, transport objects might span several kbytes or MBytes, that is, the file size is usually magnitudes larger than the Maximum Transmission Unit (MTU) of the underlying network. Therefore, an appropriate packetization before delivery is required. FLUTE basically supports a two-step segmentation of transport objects to be delivered. Assume that the size of the transport object size is denoted as L in bytes. In first step, the binary representation of the transport object can be segmented into a certain number N B smaller blocks, referred to as source blocks by a blocking algorithm. The blocking algorithm determines the source block structure, that is, number of source blocks N B and assigns for each source block j, a certain source block size B j. The maximum source block length may be determined by some memory constraints in receivers or limitations of the applied FEC. However, in general, the blocking is quite flexible in a sense that the minimum and maximum source block size is not significantly restricted. Each source block j is further fragmented into K j equal-sized source symbols with source symbol length T in bytes. Source symbols are the smallest data units to be transmitted over the network. Usually, the source symbol length is selected such that in combination with all additional headers, the MTU size of the underlying network is not exceeded. Figure 9 visualizes the blocking and symbol encoding employing a generic FEC scheme. FLUTE supports the usage of an optional symbolencoding algorithm, that is, an FEC code, in order to provide reliability. FEC encoding is performed for each source block individually. Encoding symbols have the same length as source symbols, T. In case that a systematic FEC code is applied, the first K j encoding symbols are identical to the source symbols and the remaining N j K j symbols are parity symbols. The selection of N j, K j and T is quite flexible and is up to the transmitter. The encoding symbols are encapsulated in FLUTE packets and mapped to UDP/ IP packets before being forwarded to the MPE protocol or any other IP-based bearer. In order to allow appropriate reconstruction at the receiver, all parameters along with the position of each encoding symbol within the encoding blocks, the assignment to encoding blocks and the Transport Object Identifier (TOI) have to be communicated to the receiver. For this, two methods are foreseen within FLUTE, namely, either the FLUTE header which precedes each encoding symbol or a group of encoding symbols, or a special transport object, that is, the Fig. 9. Blocking of transport objects into encoding symbols and mapping to FLUTE packets [23].

10 244 T. STOCKHAMMER ET AL. Fig. 10 Raptor code encoder structure random symbol generation. File Delivery Table (FDT). The position of each encoding symbol within the encoding block, the corresponding source block number as well as the TOI are communicated within the FLUTE header, which allows the receivers to make use of the received packets. Additional and insightful information on signaling can be found for example in Reference [23] and references therein Application Layer FEC Raptor Codes In DVB-H FLUTE receivers may reconstruct lost encoding symbols by applying FEC decoding. According to Reference [18] DVB-H receivers should support Raptor FEC scheme. We briefly summarize the encoding and decoding algorithms of systematic Raptor codes as specified in Reference [2], Annex B. A thorough description of the code can be found in Reference [11] and detailed implementation guidelines for MBMS can be found in Reference [12]. Raptor codes can be viewed as a serial concatenation of an inner high-rate block code followed by an LT encoder as shown in Figure 10. The rateless property and low-decoding complexity of the Raptor code is inherited from the inner LT code, while its increased performance is due to the outer block code. Source symbols are encoded into intermediate symbols using a block code to guarantee that the first K encoding symbols are equal to the source symbols. Note that each encoding symbol E i can be individually identified through its encoding symbol identifer (ESI) i. In general, Raptor codes have significantly less encoding and decoding complexity compared to, for example Reed Solomon or LT codes and are independent of the code rate due to the proper dimensioning of a sparse inner code. The inner LT code provides the rateless or fountain property. It is worth noting that the performance of the standardized Raptor code is very close to that of an ideal fountain code for which the decoder is able to decode the source symbols from any set of K received encoding symbols. In fact, about K þ 2 symbols on average are usually sufficient for the Raptor code to recover the K source symbols. 4. Nested Harmonic Broadcasting From Multiple Transmission Sites 4.1. System Concept Assume now that a reliable, efficient, and scalable VoD service shall be provided in an environment depicted in Figure 1 with the protocol stack and components presented in Section 3. Assume that the media file is represented by M layers whereby the media rate of the layer is denoted as R m;j, with j ¼ 1;...; M. Note that we apply the common notion for scalable coding that R m;j 1 is contained in the rate of the higher layer R m;j. Furthermore, each layer is further divided into time segments at some predetermined times i with i ¼ 1;...; N s such that we have in total N s M segments, referred to as S j;i. In the case of Figure 11, N s ¼ 5 segments are generated z for M ¼ 4 layers. Each of these segments is now mapped to an individual source block which is encoded by a fountain encoder, for example a Raptor encoder, to z Note that in general that the number of segments on each layer is also another optimization parameter. However, our aim here is to present a concept and in order not to complicate the presentation in this work, we restrict ourselves to same segmentation on each layer.

11 NESTED HARMONIC BROADCAST 245 Fig. 11. Scalable and reliable video on demand broadcast service. obtain an infinite amount of encoding symbols. The individual fountain streams are denoted as F j;i. Each of the fountains is now transmitted from a transmitting site for a virtually infinite amount of time (in practice, a content has a certain amount of lifetime for which it is worth to transmit it over broadcast channels) with transmission rate R t;j;i. We assume that the fountains are transmitted in parallel and defer realization aspects in DVB-H to subsection 4.3. Furthermore, we assume that an independent copy of the fountain is transmitted from different transmission sites (TS) x for multi-source-based delivery of video data. This approach basically makes all the data useful despite being received from different transmission sites. A simple realization of the multi-source fountain is achieved by appropriately distributing the initial seed of the random generator of the Raptor encoder over the different transmission sites. In general, it is also not necessary that each transmission site transmits with the same rate and the frame work is easily generalized by assigning a third index to the transmission rate indicating the transmission site, that is, R t;j;i;x. The total transmission rate for a certain transmission site x can then be written as R tx;x ¼ i j R t;j;i;x. Assume now that the signal transmission is in place as proposed. Furthermore, let us assume initially that a specific receiver receives the signal from a single transmission site only. It starts collecting symbols from all the observed fountains F i,j where some symbols can be lost due to hostile transmission conditions or any other events, for example, interception of a voice call with higher priority. For each fountain F i,j only if sufficient symbols are collected, the source block corresponding to the segment S j,i can be decoded. For ideal fountain codes, the number of necessary symbols is exactly the number of source symbols, K j,i. For good practical fountain codes, such as the Raptor code, only slightly more than K j,i symbols in

12 246 T. STOCKHAMMER ET AL. average are needed for successful decoding. The time at which a certain segment S i,j can be decoded, referred to as t RX,j,i mainly depends on the transmission rate of each fountain, R t,j,i,x, the size of the included segment, K j,i, and the reception conditions (packet loss, C/I observed from this transmission site). Note that the reception from multiple sites is easily established as the received symbols from different transmission sites can be included in the decoding process. Assume now that at arbitrary time t > 0, the receiver has the reception time t RX,j,i of each segment available, for example, through appropriate estimation of its reception rate (see e.g., Reference [8]) and/or from the knowledge of the source block structure. The receiver decides if early playout of the media streams is successful. More precisely, the receiver wants to obtain the lowest playout delay j for each layer with the bit rate R m,j such that smooth playout is guaranteed, that is, all data will be available at the time it needs to be played out. Note that segment S j,i is only decodable if all segments S j 0,i 0 for i0 ¼ 1,...,N s and j 0 < j are available. Then the minimum initial playout delay j for a given set of reception times t RX,j,i, and a set of media rates R m,j, is obtained as j ¼ max i¼1;...;n s ; j j 8 Pi 1 K j 0 ;yt 9 >< >= y¼1 t RX; j 0 ; i R m; j 0 R m; j0 1 >: >; ð1þ That is, if the receiver waits for a time j after it joins the broadcast session, it is able to playout the media layer j. This equation corresponds to the constraint that the playout curve for the layer of interest, j, needs to be such that it never intersects with the receiver curve [25]. The playout delay needs to be delayed by j such that this constraint is fulfilled. An important property of the proposed delivery framework is that the transmission rates and the media rates are completely decoupled, which differentiates this deliveryfromacommonlyused real-time streaming delivery System Design Options and Optimizations The transmitter now has a significant amount of options to choose from if such a flexible transmission scheme is provided, or more precisely, if the receivers are capable to deal with 3G files including SVC data, the FLUTE protocol with Raptor FEC, and also the multiple-site reception. Among others, the transmitter needs to decide on the following transmission parameters: The total amount of video layers M. The quality of each media layer j ¼ 1,..., M supported by the media stream in terms of PSNR j, spatial resolution SR j and frame rate f j. The total bit rate of each video layer R m,j. The number of segments in each layer, N S,j, in our case, it is layer-independent and restricted to N S. The segment times i for each segment i ¼ 1,..., N s. The Raptor symbol size T. The transmission rates R t,j,i for each segment i ¼ 1,..., N S and each layer j ¼ 1,..., M. The selection of these parameters should be optimized for the system constraints, since the requirements for different sequences, networks, applications, etc. may be quite different. In general, the optimization is connected to some utility function which is maximized for the different parameters. However, in the considered environment, a single obvious utility function is not available. Therefore, reasonable settings will be applied and different system design options and optimizations will be discussed in the following. We apply a conceptual approach that the transmitter selects the parameters such that it guarantees some quality-of-services for certain target receivers with individual receiving conditions. The reception conditions are expressed in terms goodput or reception rate, referred to as R RX. This measure corresponds to the average rate of correctly received FLUTE symbols multiplied by the FLUTE symbol size T. As already mentioned only the reception rate is of interest for the determination of the service parameters, not necessarily the transmission rate of an individual transmission site. Indeed, the total transmission rate is even not necessarily specified, especially if independent transmission and reception over multiple sites are carried out. However, we assume that all transmitters emit the session stream in a way that all segments S i,j and the corresponding fountains F i,j are transmitted in parallel, whereby fountain F i,j gets assigned some fraction w j,i of the total transmission rate from each transmission site. Obviously, the fractions need to be constrained as j i w j,i ¼ 1. Assuming some appropriate distribution of the FLUTE symbols from different fountains F i,j, we

13 NESTED HARMONIC BROADCAST 247 can assume that the reception rate for a specific fountain F i,j is determined as w j,i R RX. Assume now that all coding and transmission parameters except for the rate fractions w j,i are predetermined. We attempt to design the system such that specific target receivers, specified by their reception rate R RX,j, with j ¼ 1,..., M are able to receive the corresponding layer j such that playout delay j is minimized. The expected reception time t RX,j,i is given as the time at which sufficient data are available to successfully decode the corresponding segment S i,j. Assuming an ideal fountain code, the transmitter can estimate the reception time for segment for S i,j as t RX,j,i (K i,j T)/(w i,j R RX,j ). Then, by inserting it into (1) the transmitter can obtain an estimate of the initial playout delay for layer j assuming a target receiver with reception rate R RX,j as j ¼ max i¼1;...;n s ; j j 8 9 Pi 1 >< K j0 ;yt K >= j0 ;it y¼1 w j0 ;ir RX; j R m; j 0 R m; j0 1 >: >; ð2þ with R m,0 ¼ 0. For further simplification assume that HB is applied in each layer which is known to be optimal under the assumption of CBR-encoded media and the reception rate of the first segment, R RX,i ¼ 1,j would match the media rate R m,j. For HB we obtain within each layer the rate fractions as w j,i ¼ C(N s )w j /(in s ) for i ¼ 1,..., N s, C(N s ) ¼ N s /( i 1/i) and w j the rate fraction for layer j. The segments in each layer have equal size, i.e., K j,i ¼ K j /N s and K j ¼ (R m,j R m,j 1 )T m /T. Then, the initial playout delay in (2) becomes j ¼ T m max i¼1;...;n s ; j 0 j 8 9 >< R m;j 0 R m;j 0 1 R RXCðN S Þ i w j 0 N S R RX CðN S Þ þ 1 >= N S >: fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} >; ð3þ For a specific layer j, it is clear that the argument in the maximization in Equation (3) becomes maximum for i ¼ 1, if <0, and becomes maximum for i ¼ N S, if 0. Note that < 0 corresponds to the case that the differential media rate of layer j, R m,j R m,j 1,is smaller than the reception rate of the first segment S i ¼ 1,j in layer j. Therefore, the maximization can be simplified to j 1 j ¼ T m max ; R m;j R m;j 1 T m w j R RX CðN s Þ ; N s ðr m;j R m;j 1 Þ N s 1 w j R RX CðN s Þ N s ð4þ We refer to the system as Nested HB, as HB is integrated into each layer, and the layers themselves are transmitted each with a different rate, though in general not harmonic. Based on Equation (4), the transmitter can now choose an appropriate rate fraction vector w ¼ [w 1,...,w M ] to guarantee some playout delay j for some layer j. Some design options are discussed in the following: (1) Assume that the transmitter wants to guarantee a receiver with a certain reception rate R RX,j, the playout of layer j in a harmonic broadcast manner. For a specific reception rate R RX,j, we obtain the necessary w j by setting to 0 in Equation (3). In this case we obtain: w j ¼ N sðr m;j R m;j 1 Þ R RX;j CðN s Þ and j ¼ T m N s ð5þ In this case, for example M 1 layers can be predetermined for a given R RX,j and layer M is then transmitted in some best effort manner with rate fraction w M. However, note that the constraint on rate fractions, in this case, is not employed and the fulfilling of this constraint is not necessarily guaranteed. (2) In another scenario, assume that some for a set of reception rates R RX,j, j ¼ 1,..., M we set the playout delay for each layer to the same value,, and the w j s are obtained such that they fulfill the rate constraint and is minimized as Rm;j R m;j 1 j ¼ T m max w j R RXj CðN s Þ ; N s ðr m;j R m;j 1 Þ N s 1 w j R RXj CðN s Þ N s ¼! min w (3) Other scenarios which guarantee some playout delay, or minimum playout delay, for receivers with certain reception rates. (4) Combinations of the above, for example, the first layer according to Equation (1) and the remaining layer according to Equation (2).

14 248 T. STOCKHAMMER ET AL. Obviously, the definition of the w j s determines the transmission scenarios and the expected playout delays for some target receivers. Still, the actual receiver behavior for an arbitrary receiver is determined by Equation (1) Integration in DVB-H Environment The concepts presented in Subsections 4.1 and 4.2 are quite generic and are not directly transferable to the system and components introduced in Section 3. For clarity purposes, the integration of Nested HB is done verbally rather than applying complex and confusing detailed description based on a formal framework. Assume that the media file is encoded with JVSM4.0 [16] and is encapsulated to the 3G file format such that each layer fulfills progressive download and the layers are sequentially ordered in the file. This allows the blocking algorithm of FLUTE to apply the source blocks boundaries directly on the encapsulated SVC data. Once decided on the number of segments, N s, the blocking is applied such that the segments correspond to equal times as shown in Figure 11. Note that the segment size (corresponding to the source block size) can only be assumed to be equal for each layer if CBR-encoded video is included. In the general case of video, the source block size might slightly differ. In case that the blocking with granularity of symbol size T does not allow an exact boundary, the blocking is applied such that the last symbol of a source block contains an entire segment. Therefore, indeed segments and source blocks are not same which is important for the implementation, but of little relevance for the above analysis. Once having generated the source blocks, fountain coding based on Raptor is applied to each of the source blocks. With the Raptor code specified in DVB-H, independent encoding symbols can be generated. We assume that different transmission sites start distributing the Raptor symbols with different random seeds. For example, by applying a certain reuse pattern, transmission sites start transmitting at different start points, namely the first cluster at ESI 0, the second one at /, etc. In addition, time slicing is also applied such that different clusters transmit in different slice bursts and independent reception is feasible. Finally, each transmission site applies the rate fraction w i,j to each source block fountain to its overall transmission rate assigned for the service. This is done by appropriately weighted interleaving of the encoding symbols on the IP bearer. Due to the inherent signaling of the FLUTE protocol, the interleaving scheme needs not to be signaled and can be adjusted quite flexible, for example, depending on some information of receiver capabilities in the system, lower layers might get more or less transmission rate. The necessary information in terms of transmission rates, source blocking structure, layering information, etc., is conveyed in some initial setup, for example, by the application of an SDP file. Obviously, the proposed scheme still needs some more consideration in terms of reception rate estimation, receiver memory and processing capabilities, details for variable bit rate (VBR) coded video, integration of audio, etc. However, we believe that the generic scheme as presented in Subsections 4.1 and 4.2 is quite easily integrated into the existing DVB-H CDP protocol stack and therefore dissemination of such schemes is feasible in the near future. 5. Selected Simulation Results 5.1. Simulation Environment We will briefly explain our simulation environment to evaluate the integration of scalable VoD services in DVB-H download delivery. For this purpose, different existing simulation platforms, many of them publicly available and endorsed by different standardization organizations have been applied, modified, and combined. Figure 12 shows the simulation environment which implements the protocol stack as shown in Figure 3. For the SVC video encoder, we apply JVSM4.0 and we produce a 3G file format by appropriate encapsulating. The protocol simulator consists of several main modules. For the CDP/FLUTE part, we make use of the open-source implementation of FLUTE from the MAD project [24]. Modifications were integrated in MAD to support our new proposed blocking algorithm and Raptor FEC according to the specification in DVB-H CDP was added. For the DVB-H IPDC part, we implemented a DVB-H simulator according to the DVB-H standards which is based on the description of the simulator implementation in Reference [25]. The simulator includes MPE- FEC as well as time slicing. The DVB transport stream is simulated using traces generated from offline simulations [25]. The error traces include effects To speed up simulations, a Raptor code emulation has been used aligned to the software available for 3GPP video testing [25].

15 NESTED HARMONIC BROADCAST 249 Fig. 12. Block diagram of the simulation environment. such as fading in a typical urban environment, shadowing, and different Doppler frequencies. For our simulation results we concentrate on Doppler frequency of 1 Hz. Traces are provided for carrier-tointerference ratios (C/I) of {9, 12, 15, 18, 21, 24} db which reflect different reception conditions. It is also assumed that an independently coded version is transmitted from different transmission sites and the signal can be possibly observed with different C/I from different transmission sites. The DVB-H IPDC simulator allows to simulate the delay and loss characteristic of each inserted IP packet. The MPE-FEC strength can be selected, for the following simulations we apply two modes: with MPE-FEC refers to an MPE-FEC rate of RS (191, 255) and without MPE-FEC uses the entire available bandwidth for the transmission of the IP stream. Different bearer bit rates can be controlled by appropriate access and time-slicing schemes. The applied bit rates will be discussed in more detail in the simulation results. Figure 12 shows the file-based simulator operation. Assume a file to be broadcast. The extended MAD software takes care of partitioning this file into source blocks, adding FEC, and producing the FLUTE packets. Then, DVB-H emulator reads these packets, adds UDP and IP headers, constructs the MPE-FEC frames, and segments the resulting sections into TS packets. This represents the transmitter side. Error patterns corresponding to different users and receiving conditions are then mapped to the TS stream. At the receiver side, the TS stream is used to reconstruct the MPE-FEC frame. If applicable, MPE-FEC erasure correction is performed, and only correctly received FLUTE packets are delivered. MAD receiver software then receives these packets and attempts to reconstruct the original file, applying FEC decoding. At the receiver, it is evaluated at which time after the receiver starts listening to the ongoing broadcast session a certain source block can be reconstructed. This depends on the source block size, on the observed loss patterns, on the FEC applied, and obviously on the receiving conditions. For worsereceiving conditions, the time to recover the source block is expected to be longer. In order to provide early playout functionality and to guarantee smooth playout, it is necessary that all source blocks are available at the time they have to be played out. We evaluate the necessary initial start-up latency such that all segments can be played out smoothly. Note that the determination of this value during the reception phase is non-trivial, but rather uncritical. Details are discussed in Reference [8]. In any case, we report the average initial playout delay. For statistical

16 250 T. STOCKHAMMER ET AL. Table I. Quality and Bit rates of different encoding methods Quality Spatial Temporal PSNR (db) H.264/AVC SVC resolution resolution (fps) Bit rate Bit rate Bit rate (kbit/s) (Single stream) (kbit/s) (Simulcast streams) (kbit/s) Q1 QCIF Q2 CIF Q3 CIF significance, 400 receivers are investigated which randomly join the broadcast session at arbitrary and independent times Video Streams We have generated video streams which allow us comparing the benefits of the proposed scalable approach with single-layer transmission as well as simulcast using H.264/AVC. Example bit-streams have been generated at QCIF at 15 fps, CIF at 15 fps, and CIF at 30 fps with a GOP size of 32 frames and one IDR Picture at the beginning. The GOP size results in an initial playout delay of the media stream itself of about 1.07 s. The original video sequence is looped such that in total a size of T m ¼ 300 s is obtained. Random access points are not required, since with the proposed scheme the whole media stream will be downloaded anyway. The tested example sequence was foreman. We distinguish three different qualities Q1, Q2, and Q3. In all cases, namely, single-layer transmission, simulcast, and scalable coding, it is attempted to keep the quality, that is, the PSNR, the temporal, and the spatial resolution, identical. The bit rates for the single layer case are obviously lower, but in case of simulcast transmission, the different qualities need to be transmitted in parallel. The detailed results for our sample sequence are shown in Table I. Transmitting in the example SVC compared to simulcasting the single layer streams saves nearly a quarter of required transmission bit rate. Obviously, these results can be further optimized, but as an initial guideline on the SVC performance, they are quite helpful Download-and-Play versus Harmonic Broadcasting In a first set of results, a HB is compared with download-and-play. The results are in line with what has been presented in Reference [10]. Figure 13 shows the delay normalized by the media stream length T m versus the number of segments N s for a media Delay over # segments for T m =300 sec: 1Hz, w/o MPE-FEC, H.264 Q1. Delay over # segments for T m =300 sec: 1Hz, w/o MPE-FEC, H.264 Q2. Case 1 : 24dB, ideal, m=1 Case 2 : 24dB, Raptor, m=1 Case 3 : 15dB, ideal, m=1 Case 4 : 15dB, Raptor, m=1 Case 5 : 9dB, ideal, m=1 Case 6 : 9dB, Raptor, m= Delay /T m Delay /T m Case 1 : 24dB, ideal, m=1 Case 2 : 24dB, Raptor, m=1 Case 3 : 15dB, ideal, m=1 Case 4 : 15dB, Raptor, m=1 Case 5 : 9dB, ideal, m=1 Case 6 : 9dB, Raptor, m= # segments # segments Fig. 13. Delay versus number of segments for a media stream of 300 s, 1 Hz Doppler, without MPE-FEC, and H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 on the right hand side and with quality Q2 on the left hand side, respectively, for different reception conditions and different codes.

17 NESTED HARMONIC BROADCAST 251 stream of T m ¼ 300 s, 1 Hz Doppler, without MPE- FEC, and H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 on the right hand side and with quality Q2 on the left hand side, respectively, for different reception conditions and different codes. For the low quality, it is observed that in case of more segments and good reception conditions, the playout delay can be significantly reduced up to a factor of 6 for C/I ¼ 24 db and N s ¼ 4. However, for lower C/I, the reception rate is too low to benefit from HB and it actually worsens the playout delay. For the higher quality stream, the transmission rate of the system is too low to support HB and playout delays are only low for download-and-play. From these results, it is obvious that thorough system design is necessary to support low playout delays. Furthermore, diagrams compare the performance of ideal codes and Raptor codes. As they perform almost identically, it can be assumed that the proposed schemes can be realized with reasonable complexity Fountain Coding and MPE-FEC We investigate both schemes with and without MPE- FEC. To have a fair comparison, the resources consumed on the air interface (bandwidth) are identical for both FEC schemes. Specifically, we fix the rate of TS packets. Switching off MPE-FEC will therefore result in increased FLUTE channel bit rate. Figure 14 shows the normalized delay versus the receiver scenario in C/I in db for a media stream of 300 s, 1 Hz Doppler, N s ¼ 1 and 4, H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 for Raptor codes. It is observed that the use of MPE-FEC is always worse as the channel code is not adapted to the segmentation. Furthermore, it is observed for almost all reception conditions that the segmentation and HB with the use of Fountain coding only outperforms all other schemes with respect to initial playout delay Multiple Site Reception From the previous results, it is observed that the reception conditions and the reception rates are, in general, too low to support sufficiently satisfying VoD Broadcast services. One has to accept longer playout times, or lower media quality as seen from Figure 13. Therefore, reception from multiple sites is proposed and simulation results will be discussed in the following. In addition to the reception from a single site, we define several additional scenarios where a receiver Delay over RxScenario for T m =300 sec: 1Hz, H.264 Q1, Raptor. Case 1 : N s =1, w/o MPE-FEC, m=1 Case 2 : N s =1, with MPE-FEC, m=1 Case 3 : N s =4, w/o MPE-FEC, m=1 Case 4 : N s =4, with MPE-FEC, m= Delay /Tm dB 12dB 15dB 18dB 21dB 24dB RxScenario Fig. 14. Delay versus Receiver Scenario in C/I in db for a media stream of 300 s, 1 Hz Doppler, N s ¼ 1 and 4, H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 for Raptor codes.

18 252 T. STOCKHAMMER ET AL. Table II. Different multiple site reception scenarios: C/I from different sites 2BS4 2BS3 2BS2 2BS1 3BS6 3BS5 3BS4 3BS3 3BS2 3BS1 12 db 21 db 24 db 24 db 9 db 12 db 15 db 21 db 21 db 24 db 9 db 9 db 12 db 24 db 9 db 9 db 12 db 9 db 15 db 24 db 9 db 9 db 9 db 9 db 12 db 24 db might see additional sites. The sample cases are further specified in Table II, that is, the combination of C/Is observed from different sites is shown. Figure 15 shows the delay versus different receiver scenarios for a media stream of T m ¼ 300 s, 1 Hz Doppler, Ns ¼ 1, 2, and 4, H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 and quality Q2 and for Raptor codes only. Note that the connection of points is only for illustration purpose. Significant performance gains are observed for the case when multisite reception is applied, especially in the case for low C/I of the primary site. For multi-site reception, HB with N s ¼ 4 always outperforms download-and-play for the low-quality stream. The initial playout delay for very good reception conditions, for example, the case with 3BS1 can be reduced to only several seconds up to something like 30 s for 3BS2. For good reception rates, higher quality distribution of the video can be supported combined with reasonable playout times, especially if HB is applied Nested Harmonic Broadcasting In the previous scenarios, only a single quality stream, that is, for M ¼ 1, has been transmitted. This is obviously not desirable in a broadcast environment in which receivers with different reception capabilities and conditions might join the VoD session, and therefore either the high-quality receivers are limited to low reception quality or low-quality receivers are excluded from the service. In addition, due to different reception rates, certain receivers might want to decode and playout higher quality, others lower quality. Figures 16 and 17 show the initial playout delay versus different multiple sites receiver scenarios for a media stream of 300 s, 1 Hz Doppler, H.264/AVC (single layer, M ¼ 1) with quality Q1, Q2, and Q3, SVC coding with M ¼ 3, and simulcast with M ¼ 3 for download-and-play (N s ¼ 1) and HB (N s ¼ 4), respectively. Optimizations of rate fractions wi,j, in this case, have been done according to bullet 1 in 10 1 Delay over RxScenario for T m =300 sec: 1Hz, w/o MPE-FEC, Raptor Delay /T m 10-1 Case 1 : N s =1, H.264 Q1, m=1 Case 2 : N s =1, H.264 Q2, m=1 Case 3 : N s =2, H.264 Q1, m=1 Case 4 : N s =2, H.264 Q2, m=1 Case 5 : N s =4, H.264 Q1, m=1 Case 6 : N s =4, H.264 Q2, m= dB 12dB 15dB 18dB 21dB 24dB 2BS4 2BS3 2BS2 2BS1 3BS6 3BS5 3BS4 3BS3 3BS2 3BS1 RxScenario Fig. 15. Delay versus different receiver scenarios for a media stream of 300 s, 1 Hz Doppler, N s ¼ 1, 2, and 4, H.264/AVC (single layer, m ¼ M ¼ 1) with quality Q1 and quality Q2 and for Raptor codes only.

19 NESTED HARMONIC BROADCAST 253 Delay /T m Delay over RxScenario for T m =300 sec: N s =1, 1Hz, w/o MPE-FEC, Raptor. Case 1 : H.264 Q1, m= Case 2 : H.264 Q2, m=1 Case 3 : H.264 Q3, m=1 Case 4 : SVC M=3, m=1 Case 5 : SVC M=3, m=2 Case 6 : SVC M=3, m=3 Case 7 : SimC M=3, m=1 Case 8 : SimC M=3, m=2 Case 9 : SimC M=3, m= BS6 3BS5 3BS4 3BS3 3BS2 3BS1 RxScenario Fig. 16. Delay versus different multiple sites receiver scenarios for a media stream of 300 s, 1 Hz Doppler, H.264/AVC with quality Q1, Q2, and Q3, SVC coding, and simulcast for download-and-play (N s ¼ 1). Delay /T m Delay over RxScenario for T m =300 sec: N s =4, 1Hz, w/o MPE-FEC, Raptor. Case 1 : H.264 Q1, m=1 Case 2 : H.264 Q2, m=1 Case 3 : H.264 Q3, m=1 Case 4 : SVC M=3, m=1 Case 5 : SVC M=3, m=2 Case 6 : SVC M=3, m=3 Case 7 : SimC M=3, m=1 Case 8 : SimC M=3, m=2 Case 9 : SimC M=3, m=3 For Figure 16 with download-and-play, it is observed that obviously transmission of a single quality only is always superior to scalable transmission or simulcast. However, in this case, only a single quality is accessible by the different receivers, the other qualities are not available and might lead to the scenario that either some receivers are excluded due to their reception or display capabilities or might receive a too low quality. The playout delay for SVC and H.264 simulcast are identical for the first layer, that is, m ¼ 1, but for m > 1 significantly lower playout delays are observed. It is also observed that for most configurations, the low- and medium-quality play-out delay is in the range or below the media stream duration. The high quality is significantly delayed and might only be used if the stream is recorded and viewed offline, possibly also based on some conditional access subscription service. The benefits of the SVC approach are obvious as it gives significant flexibility to the receivers, which can decide, depending on its playout delay, which media quality to play. From Figure 17 which shows the results for HB (N s ¼ 4), quite similar conclusions can be drawn. However, the playout times are in general significantly lower for the lower and medium quality up to a factor of 2, whereas the higher quality is more delayed than for N s ¼ 1. In general, if sufficient reception rate can be expected, HB always outperforms download-and-play. Therefore, by the application of Nested HB a very flexible, scalable, and efficient service is provided which gives significant freedom and individual quality-of-service to the receivers despite the distribution via broadcast networks rather than individual connections BS6 3BS5 3BS4 3BS3 3BS2 3BS1 RxScenario Fig. 17. Delay versus different multiple sites receiver scenarios for a media stream of 300 s, 1 Hz Doppler, H.264/AVC with quality Q1, Q2, and Q3, SVC coding, and simulcast for Harmonic Broadcasting (N s ¼ 4). Subsection 4.2 for the first layer for reception rates equal to the media rate extended by the HB factor. The rate fraction for layers 2 and 3 has been determined according to bullet 2 assuming perfect reception from 2 and 3 sites, respectively. We only report results for multiple site transmission and reception as the benefits of this approach have been shown and for the reception of higher quality signals, this feature is essential. 6. Conclusions The integration of reliable VoD broadcasting schemes in mobile datacast systems, specifically in DVB-H, has been studied. In our case, HB has been used and extended to allow receivers tuning into the ongoing transmission of a video stream at arbitrary time, while still being able to receive the multimedia sequence from beginning to end, after short initial playout latency. In addition, we have addressed service enhancements by using SVC to address heterogeneous receiver capabilities and receiving conditions as well as multiple site reception. We presented and discussed options for the integration of VoD broadcasting schemes in combination with fountain codes. System parameters have been identified and optimizations in

20 254 T. STOCKHAMMER ET AL. the parameter selection are elaborated. The system design is integrated into an existing and practical protocol environment which needs to be modified only slightly to support our system concept. Simulation results show the benefits of the discussed VoD scheme compared to existing approaches if integrated in DVB-H. If the reception rates of the users are sufficient, Nested HB enables new service opportunities: A very flexible, scalable, and efficient service is provided which gives significant freedom and individual quality-of-service to the receivers despite the distribution via broadcast networks rather than individual connections. Currently, we are investigating extensions of the presented framework, for example, the consequences of up-switching and down-switching layers during playout in case the reception rate does not match the expectations, optimizations on the provided video quality layers in SVC encoding, and the application of this framework to other scenarios such as peer-to-peer streaming, mobile adhoc networks, or cellular mobile systems. Acknowledgments The authors would like to thank Heiko Schwarz from Fraunhofer HHI as well as Andreas Arnold from BenQ mobile for initial discussion on this work. References 1. 3GPP TS Multimedia multicast and broadcast service (MBMS) (Rel. 6). September GPP TS Multimedia multicast and broadcast service (MBMS); protocols and codecs (Rel. 6). September Faria G, Henrikson JA, Stare E, Talmola P. DVB-H: Digital broadcast services to handheld devices. Proceedings of the IEEE, Special Issue on Global Television: Technology and Emerging Services 2006; 94(1), pp Hu A, Video-on-Demand Broadcasting Protocols: A Comprehensive Study. Proceedings of the IEEE Infocom 2001, Anchorage, Alaska, Engebretsen L, Sudan M. Harmonic Broadcasting is Bandwidth-Optimal Assuming Constant Bit rate. Proceedings of the Annual ACM-SIAM Symposium on Discrete Algorithms 2002, San Francisco (CA), USA, Xu L. Efficient and Scalable on-demand Data Streaming using UEP Codes. Proceedings of ACM International Conference on Multimedia 2001 (MM 01), Ottawa, Ontario, Canada, Horn GB, Knudsgaard P, Lassen SB, Luby M, Rasmussen JE. A scalable and reliable paradigm for media on demand. IEEE Computer 2001; 34/9: Jenkac H, Stockhammer T. Asynchronous media streaming over wireless broadcast channels. Proceedings of International Conference on Multimedia and Expo (ICME), Amsterdam, The Netherlands, Huang C, Janakiraman R, Xu L. Loss-resilient media streaming using priority encoding. Proceedings of ACM International Conference on Multimedia 2004 (MM 04), New York (NY) USA, Jenkac H, Stockhammer T, Xu W, Abdel Samad W. Efficient video-on-demand services over mobile datacast channels. Journal of Zhejiang University SCIENCE A 2006; 7(5): Shokrollahi A. Raptor codes. Tech. Rep. DR , Digital Fountain, Luby M, Watson M, Stockhammer T, Gasiba T, Xu W. Raptor codes for reliable download delivery in wireless broadcast systems. Proceedings of IEEE Consumer and Communications Networking Conference (CCNC), Las Vegas (NV), USA, January Wenger S, Stockhammer T, Hannuksela MM, Westerlund M, Singer D, RTP payload Format for H.264 Video, IETF RFC3984, February Sullivan G, Wiegand T. Video Compression From Concepts to H.264/AVC Standard. Proceedings of the IEEE, Special Issue on Advances in Video Coding and Delivery, 93(1), pp , January Paila T, Luby M, Lehtonen R, Roca V, Walsh R. FLUTE File Delivery over Unidirectional Transport. IETF RFC3926, Oct Wiegand T, Sullivan G, Reichel J, Schwarz H, Wien M (eds). Joint Draft 6, Doc. JVT-S201, Joint Video Team (JVT), Geneve, Switzerland, April Schwarz H, Marpe D, Schierl T, Wiegand T. Combined Scalability Support for the scalable Extensions of H.264/AVC, ICME, Amsterdam, The Netherlands, July ETSI TS (V1.1.1), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of Specifications for Phase 1, April ISO/IEC JTC1/SC29/WG11 Coding of Moving Picture and Audio ISO/IEC /PDAM2 (SVC File Format), Montreux, April ISO/IEC JTC1/SC29/WG11 Coding of Moving Picture and Audio ISO/IEC (ISO Base Media File Format), April GPP TS ,. Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Rel. 6), September Schierl T, Gänger K, Hellge C, Stockhammer T, Wiegand T. Multi Source Streaming for Robust Video Transmission in Mobile Ad-Hoc networks, Submitted to IEEE International Conference on Image Processing, September 2006, Atlanta. 23. Peltotalo J, Peltotalo S, Harju J. Analysis of the FLUTE data carousel. Proceedings of 10th EUNICE Open European Summer School, Colmenarejo, Spain. 24. MAD/TUT. URL: Stockhammer T, Jenkac H, Kuhn G. Streaming video over variable bit-rate wireless channels. IEEE Transactions on Multimedia 2004; 6(2): GPP S Software Simulator for MBMS Streaming over UTRAN and GERAN, Siemens, Paris, France, September DVB TM-CBMS1361. Proposal for simulations for evaluation of Application Layer FEC for file delivery, June Wenger S, Wang Y, Hannuksela MM. RTP payload format for H.264/SVC scalable video coding. Journal of Zhejiang University SCIENCE A 2006; 7(5): ISO/IEC JTC1/SC29/WG :2000, Generic Coding of Moving Pictures and Associated Audio In-formation Part 2: Video, ISO/IEC JTC1/SC29/WG :2001, Coding of Audio- Visual Objects Part 2: Visual, 2nd Edition, 2001.

21 NESTED HARMONIC BROADCAST 255 Authors Biographies Thomas Stockhammer has been working at the Munich University of Technology, Germany and was visiting researcher at Rensselear Polytechnic } Institute (RPI), Troy, NY and at the University of San Diego, California (UCSD). He has published more than 80 conference and journal papers, is member of different program committees and holds several patents. He regularly participates and contributes to different standardization activities, for example, JVT, IETF, 3GPP, and DVB and has co-authored more than 100 technical contributions. He is acting chairman of the video adhoc group of 3GPP SA4. He is also co-founder and CEO of Novel Mobile Radio (NoMoR) Research, a company developing simulation and emulation of future mobile networks such as HSxPA, WiMaX, MBMS, and LTE. The company also provides consulting services in the respective areas. Between 2004 and June 2006, he was working as a research and development consultant for Siemens Mobile Devices, now BenQ mobile in Munich, Germany. Now he is consulting for Digital Fountain, Inc. His research interests include video transmission, cross-layer and system design, forward error correction, content delivery protocols, rate-distortion optimization, information theory, and mobile communications. Tiago Gasiba was born in Oporto, Portugal. He received his M.Sc. degree in telecommunication engineering from the Technical University of Munich }(TUM) Germany in 2004, and his Eng. degree in electrical engineering and computer science from the Faculdade de Engenharia da Universidade do Porto in He is currently working for Digital Fountain and NoMoR Research GmbH and working towards his Ph.D. degree under the supervision of Prof. Hagenauer and Prof. Shokrollahi. In 2005 he was a visiting researcher at the Laboratoire d Algorithmique et Laboratoire de Mathematiques Algorithmique (Algo þ Lma) in Lausanne, Switzerland. His current research interests include forward error correction codes in particular fountain codes, wireless communications networks and video and data broadcast. Wissam Abdel Samad received his Bachelor degree in Computer and Communications Engineering from the American University of Beirut (AUB), } Beirut, Lebanon in 2004, and his M.Sc. degree in Telecommunications Engineering from the Royal Institute of Technology (KTH), Stockholm, Sweden in Since then, he has been working for NoMoR Research GmbH and BenQ-Siemens Mobile in Munich as a research engineer focusing on MBMS, DVB-H, and DIMS technologies. His research interests include QoS in multimedia transmission, Video on Demand, application layer forward error correction, in particular fountain codes. Thomas Schierl received his Dipl.-Ing. degree in technical computer science from the Berlin University of Technology, Germany in December He is with Fraunhofer Institute for Telecommunications HHI since Mr. Schierl has done different research works on reliable real time transmission of H.264/MPEG-4 AVC and Scalable Video Coding (SVC) in mobile Point-To-Point, Multicast and Broadcast environments like used by 3GPP or DVB-H. He has submitted different inputs on real time streaming to standardization committees like 3GPP, ISMA, MPEG, and IETF. His current work mainly focuses on developing new real time streaming techniques for Mobile Ad Hoc Networks (MANETs). Further research interests are reliable transmission of real time media in mobile networks and joint source channel coding. Hrvoje Jenkac received his Diplom- Ingenieur degree in electrical engineering from the Munich University of Technology, Munich, Germany, in Since then, he is with the Institute for Communications Engineering at the Munich University of Technology as a research and teaching assistant, where he is currently pursuing his Dr. Ing. (Ph.D.) degree in the communications engineering field. His research interests are mainly in the area of reliable multimedia transmission over wireless (broadcast) channels. In particular, he is interested in channel coding, fountain coding, retransmission strategies for broadcast systems, cross-layer system design and optimization, ondemand broadcasting techniques, multi-user scheduling and buffer management for real-time traffic as well as iterative receiver concepts. Thomas Wiegand is the head of the Image Communication Group in the Image Processing Department of the Fraunhofer Institute for Telecommunications Heinrich Hertz Institute Berlin, Germany. He received the Dipl.- Ing. degree in Electrical Engineering from the Technical University of Hamburg-Harburg, Germany, in 1995 and the Dr.-Ing. degree from the University of Erlangen-Nuremberg, Germany, in From 1993 to 1994, he was a Visiting Researcher at Kobe University, Japan. In 1995, he was a Visiting Scholar at the University of California at Santa Barbara, U.S.A., where he started his research on video compression and transmission. Since then, he has published more than 100 conference papers and 25 journal papers on the subject and has contributed successfully to the ITU-T Video Coding Experts Group (ITU-T SG16 Q.6 VCEG)/ISO/IEC Moving Pictures Experts Group (ISO/IEC

22 256 T. STOCKHAMMER ET AL. JTC1/SC29/WG11 MPEG)/Joint Video Team (JVT) standardization efforts (about 150 submissions) and holds about 10 international patents in this field. From 1997 to 1998, he was a Visiting Researcher at Stanford University, U.S.A. and served as a consultant to 8 8, Inc., Santa Clara, CA, U.S.A. In October 2000, he was appointed as the Associated Rapporteur of ITU-T VCEG. In December 2001, he was appointed as the Associated Rapporteur/Co-Chair of the JVT. In February 2002, he was appointed as the Editor of the H.264/AVC video coding standard and its extensions (FRExt and SVC). In January 2005, he was appointed as Associated Chair of MPEG Video. In 1998, he received the SPIE VCIP Best Student Paper Award. In 2004, he received the Fraunhofer Award for outstanding scientific achievements in solving application-related problems and the ITG Award of the German Society for Information Technology. Since January 2006, he is an Associate Editor of IEEE Transactions on Circuits and Systems for Video Technology. He is a member of the technical advisory board of the two start-up companies Layered Media, Inc., Rochelle Park, NJ, U.S.A. and Stream Processors, Inc., Sunnyvale, CA, U.S.A. Wen Xu received his B.Sc. degree in 1982 and his M.Sc. degree in 1985 from Dalian University of Technology (DUT), China, and a Dr.-Ing. (Ph.D.) degree in 1996 from Munich University of Technology (TUM), Germany, all in electrical engineering. Since, 1995, he has been with the Siemens AG Mobile Phones (now BenQ Mobile), Munich, where he is responsible for several R&D projects and has actively participated and contributed to standardization activities of ETSI and 3GPP. Since 2000, he is head of the Baseband Algorithms and Standardization Lab which is responsible for physical layer and multimedia signal processing, and protocol stack aspects. As a competence center, his lab has been actively involved in different standardization activities such as 3GPP and DVB for 2G, 3G, beyond 3G mobile systems as well as DVB-H system. His research interests include image/video/speech coding and processing, channel coding, equalization, cross-layer system design, and mobile communications. Dr. Xu is a senior member of IEEE and a member of the Verband der Elektrotechnik, Elektronik, Informationstechnik (VDE), Germany. His ID is wen.xu@ieee.org.