Product Releases

The MBMS Mobile Multimedia Standard and Application-Layer Forward Error Correction

Fri, 10/27/2006 - 12:36pm
By Mark Watson and Thomas Stockhammer
The 3rd Generation Partnership Project (3GPP) has taken the lead in the definition of mobile multimedia broadcast services by integrating Multimedia Multicast/Broadcast Service (MBMS) in its Release 6 specifications. The MBMS specification was completed in the fall of 2005 and was approved in early 2006. Developments on the network and terminal side have been initiated such that first deployments are expected in 2008.
MBMS extends the existing 3GPP architecture by the introduction of an MBMS Bearer Service and MBMS User Services. The MBMS Bearer Service is provided by

click to enlarge

Figure 1. Simplified MBMS Architecture
the packet-switched domain to deliver IP multicast data-grams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones. This is accomplished by point-to-multipoint (p-t-m) transmission. Furthermore, the end user is provided two MBMS User Services. In streaming services, a continuous data flow of audio and/or video is delivered to the end user's handset; in download services, data for the file is delivered in a scheduled transmission timeslot. Streaming services are suitable for near-real-time content, while download services support multimedia content that are not so time-sensitive as to warrant streaming. MBMS also makes use of the most advanced multimedia codecs, namely H.264/AVC for video coding and enhanced AAC for audio coding.

The p-t-m MBMS Bearer Service does not allow retransmitting lost radio packets and, because of this, the Quality-of-Service (QoS) provided by the MBMS Bearer Service for the transport of multimedia applica The p-t-m MBMS Bearer Service does not allow retranstions is in general not high enough to support a significant portion of the users for either download or streaming applications.

click to enlarge

Table 1. A wide range of user services can be delivered via MBMS
Even though multimedia codecs provide error resilience tools, their usage would neither be efficient nor sufficient in terms of quality in case of losses. Therefore, 3GPP has recognized the urgent need to introduce additional QoS components in the MBMS User Services. In a very selective evaluation process, 3GPP decided to mandate the use of Digital Fountain's advanced erasure code technology, DF Raptor™ forward error correction (FEC), for both MBMS streaming and download delivery.

By using such application-layer FEC techniques, MBMS is able to provide both streaming and file delivery services with the quality and reliability necessary for 3G network operators to develop multimedia services that will engage their subscribers and provide a new source of revenues. It is expected that the migration to MBMS will be seamless, i.e. existing file download services and Mobile TV applications will gradually be moving to MBMS delivery especially for popular content and in areas where many users request the same content. However, the deployment of MBMS will also allow innovative services.
MBMS Architecture
Until MBMS is deployed; multimedia content must be delivered as IP packets via unicast transmission, where each individual user consumes network resources to receive video

click to enlarge

Figure 2. MBMS Protocol stack
streams and to download content such as music or ring tones that are unique to that individual. MBMS represents a way for 3G network operators to offer popular multimedia content over their GPRS/EDGE or W-CDMA 3G networks without unnecessarily consuming capacity for personal communication such as voice or video calls, data services, etc. By transmitting the same data to multiple recipients, the costly network resources are shared. The MBMS architecture (see Figure 1) enables the efficient usage of radio-network and core network resources, with emphasis on the radio efficiency. In the bearer plane, this service provides delivery of IP Multicast data-grams to UEs. A new functional entity, the Broadcast Multicast Service Center (BM-SC) provides a set of functions for MBMS User Services such as session announcement and establishment, data transfer and associated delivery procedures.
Established and Innovative User Services
MBMS is initially just a technology to preserve capacity or reduce costs — by providing an efficient means to reliably distribute multimedia content over 3G networks. It is expected that services such as ring-tone downloading, Mobile TV, or firmware and software upgrades will eventually make use of MBMS User services. However, MBMS also

click to enlarge

Figure 3. Raptor codes: Serial concatenation of different codes
provides an opportunity for 3G network operators to deliver new and innovative revenue-generating services to their subscribers.

From the 3G network operator's point of view, MBMS enables the creation of new revenue-generating services that augment and extend the value of the basic cellular voice network. The services that can be provided via MBMS are wide-ranging, varying in terms of the provided content and the time and place the services are made available.

Content that is intrinsically not time-sensitive can be simply provided via file download — so-called "clipcasting". Time-sensitive content can also be supported by file download simply by providing new, updated files to keep the content timely. Service providers can thus use MBMS file download services to "push" content that can be enjoyed by users at their convenience, even to users who are temporarily in places where the network is inaccessible. In this way, content can be delivered that can truly be consumed at the user's convenience, "anywhere" and "anytime".

Streaming services, by contrast, support real-time content, making it possible to deliver news, sporting events and other content virtually as it happens. Like a television or radio broadcast, MBMS streaming content must be viewed or heard as it is transmitted, although specific content can be repeatedly streamed in order to extend its availability.

While MBMS services can be made generally available wherever the user has network connectivity, MBMS streaming and download services can also be restricted to specific cell sites, allowing services to be localized to limited geographic areas. For example, airports, stadiums, convention centers, downtown locations, primary roads, major shopping areas, and other appropriate locales can all be targeted with different content at different times.

MBMS services can be readily combined with 2-way communications over the 3G network to allow interactivity to be associated with the MBMS content — users can vote their preferences, purchase advertised merchandise, bet on particular outcomes, or otherwise respond to the content that has been delivered via MBMS.

Billing for MBMS services can then be based on a monthly subscription to specific MBMS multicast groups, the actual usage in terms of downloaded bytes, or the particular

click to enlarge

Figure 5. Selected Result for MBMS Download Delivery
content that is accessed. Alternatively, 2-way interactive transactions can be used as another means to charge for MBMS services, thus encouraging impulse purchases, or certain MBMS services can be sponsored by advertising and offered at no charge to the user.

Although initially the download delivery was viewed as more promising, nowadays there is significant focus on MBMS streaming delivery in the context of mobile TV. In contrast to other systems such as DVB-h or T-DMB, MBMS as based on 3G technology provides excellent coverage and spectrum availability in many parts of the world.
MBMS Protocol Stack
The point-to-multipoint IP-based service is carried by the 3G air interface of WCDMA (UMTS Terrestrial Radio Access Network or UTRAN) or the 2.5G air interface of EDGE/GPRS (GSM EDGE Radio Access Network or GERAN). The W-CDMA air interface provides bearer rates up to 256 kb/s or greater, while the EDGE/GPRS air interface provides bearer rates up to 128 kb/s.

The MBMS protocol stack for streaming and download delivery is shown in Figure 2. Streaming data such as video streams, audio programs or timed text being encapsulated in RTP are transported over the streaming delivery network. In this case, application layer FEC is applied on UDP flows, either individually or on bundles of streams. Discrete objects such as still images, multimedia streams encapsulated in file formats, or other binary data are transported using the FLUTE protocol (RFC 3926 1) when delivering content over MBMS bearers. More details on application layer FEC and delivery methods will be presented later.

In both delivery services the resulting UDP flows are generally mapped on the MBMS IP multicast bearers. The MBMS Bearer services reuse most of the legacy UMTS protocol stack in the packet-switched domain. To avoid significant investments in network infrastructure and handheld chipsets, only minor modifications have been introduced in the access

click to enlarge

Figure 6. MBMS Streaming Framework
network to support MBMS. The new service relies on the 3G packet-based protocol stack: IP packets are received in the 3G protocol stack in the Packet Data Convergence Protocol (PDCP) layer. Functions provided at the Radio Link Control (RLC) layer are for example segmentation and reassembly, concatenation, padding, sequence numbering, reordering and out-of-sequence and duplication detection. The Medium Access Control (MAC) layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format. The MAC layer and physical layer appropriately adapt the RLC-PDU to the expected transmission conditions by applying, among others, physical layer FEC channel coding, power and resource assignment, and modulation.

Among others, an MBMS radio bearer defined by the physical layer FEC channel code rate and the transmission time interval (TTI). The TTI is transport-channel specific and can be selected from the set { 10 ms, 20 ms, 40 ms, 80 ms} for MBMS. The higher TTI values are supported by increasing the interleaving of the channel code and/or using longer codeword sizes of channel code. This has the advantage of increasing time diversity but at the expense of longer delays and more memory.
In general, forward error correction (FEC) technologies protect data by encoding the original source data at the sender such that redundant data is added. The FEC decoding algorithm then allows the receiver to detect and possibly correct errors in the original data based solely on the data that has been received. The error correction is "forward" in the sense that no feedback from the receiver to the sender or further transmission by the sender is required.

As observed, the MBMS system applies FEC on two layers in a complementary way, namely on the physical layer and on the application layer. The tradeoff in applying one or the other or suitable combinations of the two is an interesting question and is addressed further below.

On the physical layer FEC encoding and decoding algorithms are implemented in hardware as part of the W-CDMA or EDGE/GPRS air interface. Specifically for W-CDMA, the

click to enlarge

Figure 7. Video Quality with and without application layer FEC.
RLC/MAC blocks are mapped to code blocks such that the maximum length of a code block does not exceed 5114 bits. This limitation comes from the restrictions on complexity, memory and power consumptions of Turbo decoders in handheld devices. After the Turbo coding is applied, the resulting blocks are concatenated, interleaved and eventually rate matching is performed. Finally, radio frames are transmitted every 10 ms using a chip-rate of 3.84 Mcps and QPSK modulation.

The physical layer FEC code attempts to correct distortions that may have been induced by noise, interference, multipath and other impairments over the wireless channel. Signal variations on the time frame of a TTI shall be compensated by this processing. If the received signal is too weak in a data block for the FEC decoding algorithm to correct, then the block is unrecoverable. Generally any associated IP packet(s) is also entirely lost as reassembly is infeasible. The block error rate (BLER or block erasure rate) then represents the failure rate of the air interface FEC protection to recover the data blocks as partitioned at the physical layer.
FEC at the Application-Layer — DF Raptor Technology
To provide packet-level protection at the application layer, DF Raptor FEC encoding is implemented in software at the MBMS streaming or file delivery engine in the BM-SC. Furthermore, DF Raptor decoding software is integrated in each MBMS capable mobile receiver. DF Raptor FEC technology complements the physical layer FEC protection, recovering those IP packets that have been lost because the receiver's physical layer FEC was unable to fully correct the received data.
Raptor codes
Raptor codes can be viewed as regular block codes which are based on a generator matrix, but also as the serial concatenation of several codes as shown in Figure 3: two outer systematic high rate codes (HRC) and a non-systematic inner LT code. The LT code provides the unique fountain property of the Raptor code. A systematic realization of the code is obtained by applying some preprocessing (SYS) to the k source symbols. For detailed specification we refer to the MBMS specification 3GPP TS26.346 2, Annex B. The decoder relies on algebraic decoding algorithm and basically requires a matrix inversion of a high-dimensional matrix. Although this could possibly be accomplished by a standard Gaussian elimination, the complexity would be far out of reach for handheld device processors. However, due to the specific properties of the matrix, namely the fact that its inverse is sparse, a significantly more efficient implementation of the decoding is possible. Some insights in encoder and decoder implementation are for example provided in 3GPP TS26.346 2, Annex C and 3.

DF Raptor technology as adopted by MBMS has significant unique properties:

Raptor codes are 'Erasure codes', i.e. the Raptor code is applied to symbols which are known to be either received correctly or lost at the receiver. A 'symbol' can be relatively large — several bytes to several hundred bytes. Often 'Symbol' and 'Packet' are the same i.e. one symbol is transmitted in each packet. The Raptor code allows the decoder to recover lost symbols from received encoded symbols (=source data plus "repair data"). Raptor codes can be realized as 'Systematic Codes', i.e. the first k encoded symbols are identical to source symbols. This property has different advantages, namely that the original data is easily accessible in an encoded version, that delays at the transmitter can be minimized as the repair symbols can be generated after all source data has been transmitted and that the extension to legacy protocols is simplified. Raptor codes are 'Fountain Codes'. Traditional error correction codes generate a fixed amount of repair data, e.g. (255, 191) Reed-Solomon code generates 255-191 = 64 repair or parity symbols from k=191 original data ('source') symbols. In contrast, Fountain codes can generate an unlimited quantity of repair data, without repetition. Therefore no fixed code 'rate' is applied — the codes are also known as 'rateless codes'. The "rateless" property allows very large amount of redundant data to be generated which is especially advantageous for carousel services as repeated transmission of same data can be avoided. Raptor codes are almost an "Ideal Erasure Code". Ideal erasure code is able to recover the source block from any set of k received encoding symbols. On average, Raptor codes recover the k source symbols from less than k+2 received symbols (any mix of source/repair symbols). Chance of success increases dramatically as more symbols are received: With k+12 symbols received the chance of failure is as low as 0.1% and with k+24 symbols received the failure probability is 1e-6. Note that the success/failure depends on absolute number of symbols, not on k. In general, k is selected as 1000 or larger. In this case, the additional overhead for 1e-3 failure at k=1024 is 1.2%. Raptor codes are "low complexity codes": In terms of encoding and decoding complexity, systematic Raptor codes are basically symmetric. The decoding complexity is very low, and in contrast to many other codes it is only linear in the size of source data k and independent of packet loss rates. The complexity is such that it easily permits software implementation on constrained mobile platforms. Raptor decoding has been implemented and ported to several platforms including ARM9. A decoding speed of more than 25 Mb/s has been achieved on this platform. For example, computational complexity of Raptor codes is orders of magnitude less than Reed-Solomon codes, which would allow lower cost devices as well as lower device power consumption. The working memory requirement for MBMS Raptor codes in MBMS file download is, for example, at most 512 KB for all file sizes. Raptor codes are applied in different services in MBMS. The protocol allows source block sizes of up to k= 8192 and a total amount of independent encoding symbols of n=65536.
Application Layer FEC for File Download Services
To deliver a file in a MBMS multicast or broadcast session, File Delivery over Unidirectional Transport (FLUTE) as specified in RFC3926 1 applied. FLUTE provides mechanisms to signal and map the properties of a file to Asynchronous Layered Coding (ALC) protocol (RFC3451) such that receivers can assign these parameters to the received files. The file is partitioned in one or several source blocks (see Figure 4). Each source block is split into k source symbols, each of length T. Both parameters T and k are signaled in the session setup and are fixed for one session. For each source block, additional repair symbols can be generated by applying Raptor encoding.
DF Raptor Encoding of Files
Each encoded symbol, i.e. source and repair symbols, is assigned a unique encoded symbol ID (ESI) which identifies the given symbol. In particular, if the ESI is less than k, then it is a source symbol, otherwise it is a repair symbol. Symbols are either individually transmitted or multiple symbols are concatenated and mapped to a FLUTE packet payload. The source block number, the ESI of the first encoded symbol in the packet and other file parameters are signaled in the FLUTE header. FLUTE packets themselves are then encapsulated in UDP and then distributed over the IP multicast MBMS bearer. Receivers collect correctly received FLUTE packets, and with the information available in the packet header and the file session setup, the structure of the source block can be recovered. If no more encoded symbols for a source block are expected to be received, the Raptor decoder attempts to recover the source block from the received encoded symbols. Obviously, due to heterogeneous receiving conditions in mobile broadcasting, the amount as well as the set of received encoded symbols differs among the receivers. Nevertheless, for each receiver, if enough encoded symbols are received for a source block then that receiver is able to recover an exact copy of the original source block. If all source blocks belonging to the file are received correctly, the entire file is recovered. Only if recovery fails, a post-delivery repair phase might be invoked in MBMS.

In MBMS Download Delivery Service within UMTS has been investigated under realistic physical transmission conditions by considering sophisticated channel models that simulate a cellular mobile network in detail and take into account user mobility, shadowing, Doppler fading, intra-cell and inter-cell interference, noise, etc.3 The major interest of this study was the determination of the optimized system parameters on bearer and application level, e.g. code rates, transmission power, etc. The simulation system allows significant flexibility on the MBMS Bearer Service, among others the following parameters can be adjusted: transmit power, physical layer FEC code rate, physical layer segmentation and other radio parameters. For the MBMS Download Delivery Service the main parameter is the code rate k/n of the application layer FEC. For the results in Figure 5 a bearer which allows transmitting 240 kb/s natively over the UMTS network. A typical file of size 512 kByte, typical for ringtones or still images, is transmitted to an ensemble of 1000 users which are all randomly positioned in the cell area and move randomly according to a random walk model with 30 km/h.

For the results in Figure 5, different transmit power values, different physical layer FEC code rates between 0.33 and 1 are applied and different application layer FEC code rate. The combination of the physical layer code rate FEC and the transmit power results in a certain loss rate of the RLC-PDU after physical layer channel decoding which is reported on the y-axis. We evaluate the number of application layer repair symbols which are necessary such that 95% of the users in the cell are satisfied. The number of source and repair symbols map to a delivery time of the file. Assuming an operator would target that 95% of the users receive the file perfectly, the minimum energy derived as the product of the delivery time and the transmit power is the measure of interest and is shown in y-axis in Figure 5. It is seen that for a typically considered operation point on the upper left corner, with physical layer FEC code rate 0.33 and Raptor overhead 15% and high transmit power of 8 W, the delivery energy is about one magnitude higher compared to the optimal case configured with low transmit power of 0.5W, slightly higher physical layer code rate 0.43, but significantly higher Raptor overhead of 175%. The resource reductions are significant, and the delivery time is not even doubled.

This specific result as well as many others as reported in 3 show the benefits of applying application layer FEC to MBMS download delivery. It is apparent that by appropriately trading transmit power, lower layer FEC, and application layer FEC resource-optimized distribution of files in wireless cellular networks can be achieved.
Application Layer FEC for Streaming Delivery Services
The MBMS streaming framework operates on RTP packets or more precisely UDP payloads, incoming at same or different UDP ports. According to Figure 2 the FEC layer for streaming delivery is based on top of the UDP layer. The legacy RTP packets and the UDP port information are used in order to generate FEC repair symbols. Original UDP payloads become FEC source packets by appending a 3 byte FEC source payload ID field at the end of each UDP payload. These packets are then UDP encapsulated and transported on the IP multicast bearer.

According to Figure 6, a copy of these packets is forwarded to the FEC encoder and is arranged in a source block with row width T bytes at the first empty row. The encoding symbol starts at the beginning of a new row, but it is preceded by a 3 byte field containing the UDP flow ID (1 byte) and the length field (2 bytes). In case the length of the packet is not an integer of the symbol, the remaining bytes in the last row are filled up with zero bytes. The source block is filled up to k rows whereby k is flexible and can be changed dynamically for each source block. The selection of k depends on the desired delay, the available terminal memory also might depend on aspects such as desired zapping time in mobile TV applications.

After processing all packets to be protected within one source block, the FEC encoder generates n-k FEC repair symbols of size T by applying Raptor encoding as shown in Figure 3. The generated FEC repair symbols can be transmitted individually or as blocks of symbols as payload of a single UDP packet. Each FEC source and repair packet contains sufficient information such that the receiver can correctly insert them in the receiver source and repair block.

In a selected experiment, video streams have been transmitted over MBMS Bearer Service with different configurations in the video encoder and the application layer FEC. The test video sequence "Foreman" (30 Hz, 300 frames, QCIF) was encoded with H.264/AVC baseline at a constant frame rate of 7.5 fps with regular IPPP structure at IDR frame rate 10 seconds. Video is encoded such that it can be made resilient to packet losses (use of slices, flexible macroblock ordering and increased intra macroblock frequency). In addition, the bitrate is modified to fit the available throughput when applying FEC with some overhead. In any case the video is encoded such that the bitrate matches the residual application layer throughput and the intra macroblock frequency is adapted to the residual loss rate after FEC. The results in Figure 7 show results for a 64 kbit/s MBMS bearer with 10% RLC-PDU loss rates, i.e. the physical layer code rate is applied such that 10% residual loss rate is experienced. The average PSNR (common measure for video quality) over the available throughput is shown for different system configurations, namely slices with slice size of maximum 600 bytes, flexible macroblock ordering, and video unit fragmentation with 300 and 600 bytes. In any case, the end-to-end delay does not exceed 5 seconds. For further details we refer to [4].

For all system configurations we observe that for low throughput the FEC is sufficient to receive error-free video such that only the distortion caused by the encoding process matters. However, too low video rate obviously significantly degrades the quality. With increasing throughput (corresponds to less FEC overhead), the quality increases as long as the FEC is sufficient to correct the errors. At low FEC overhead, the quality degrades again due to residual errors although the video is coded with higher bitrate and optimized MB updates are applied. For the end-points on the very right side, no FEC is applied and we only rely on video coding-based error resilience. Although the application of error resilience tools such as intra-macroblock refresh and flexible macroblock ordering are helpful, the system with FEC and no error resilience outperforms the video only system by about 5 dB. The optimum point suggests operating the application layer FEC such that very low loss rates of about 0.2% are achieved and about 60% FEC overhead is used.
Application Layer FEC beyond MBMS
MBMS was the first standard to specify in depth content delivery protocols for mobile multimedia broadcasting and therefore serves as a reference and benchmark for many other standard activities. The status of AL-FEC based on Raptor technology in other mobile multimedia broadcasting standard is as follows:

DVB-H (Digital Video Broadcasting — Handheld) — an ETSI standard adapted from the DVB-T (Digital Video Broadcasting — Terrestrial) standard to support IP datacasting to mobile devices. This standard also includes Digital Fountain's DF Raptor FEC technology as part of its file delivery service. BCMCS (BroadCast MultiCast Services) — a service comparable to MBMS that is currently being standardized by 3GPP2, the 3rd Generation Partnership Project 2, as part of its ongoing specifications for the evolution of worldwide cdma2000-based 3G networks. Initial proposals on AL-FEC have been made, the work is ongoing. DVB-SSP (Satellite Services to Portable Devices) is an activity within DVB which is currently pursuing the specification of a hybrid satellite and terrestrial broadcast system for mobile receivers to support mobile TV, audio programs, as well as data delivery. The blockage of line-of-sight in satellite transmission makes application layer FEC an essential component of this system Investigations on integrating reliable and efficient file delivery and streaming services in other mobile broadcast standards and systems such as ISDB-T (Integrated Service Digital Broadcasting - Terrestrial). MediaFLO (Media Forward Link Only), or T-DMB (Terrestrial Digital Multimedia Broadcasting) are considered, but no standard-related activity is stated yet.
Multimedia streaming and download services are today provided via unicast transmission, where the network bandwidth requirements are only manageable because demand is not yet that high. As MBMS is deployed, popular download and streaming services will scale with the number of users and can be delivered more efficiently. This will represent a cost savings to the network operator. At the same time, new high-quality multimedia services will help increase revenue and reduce subscriber churn, making MBMS a clear winner for 3G network operators around the world.

By employing application-layer FEC and Digital Fountain's DF Raptor technology to protect against packet loss caused by the hostile mobile channel conditions, MBMS is able to deliver its streaming and file download services with maximum quality and efficiency. The usage of application layer FEC is essential for sufficient quality and efficient deployment and will also leverage new and innovative services. For the subscriber, the effect is better quality streaming services, faster delivery of files, and better performance at the edge of coverage. For the network operator, the impact is even greater: higher revenues and lower costs.
1. T. Paila, M. Luby, R. Lehtonen, V. Roca, and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport," IETF, RFC3926, October 2004.
2. 3GPP TS 26.346 V7.0.0, Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service; Protocols and Codecs, June 2006.
3. M. Luby, M. Watson, T. Gasiba, and T. Stockhammer, "Reliable Multimedia Delivery in Cellular Broadcast Networks," submitted for IEEE Transactions on Broadcasting, Special on "Mobile Multimedia Broadcasting", July 2006.
4. T. Stockhammer, "Robust System and Cross-Layer Design for H.264/AVC-based Wireless Video Applications," In EURASIP Journal on Applied Signal Processing, Special Issue on Video Analysis and Coding for Robust Transmission, March 2006.

About the Authors
Mark Watson and Thomas Stockhammer are senior researchers at Digital Fountain, Inc. They can be reached at or (510) 284-1400.

Share this Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.