MBMS

IEEE Communications Magazine • November 201268 0163-6804/12/$25.00 © 2012 IEEE

TECHNOLOGY UPDATES ON LTE ADVANCED

David Lecompte, Huawei Technologies France

Frédéric Gabin, Ericsson

Evolved Multimedia Broadcast/MulticastService (eMBMS) in LTE-Advanced:Overview and Rel-11 Enhancements

INTRODUCTION

There has been tremendous growth in data traf-fic, most particularly video, over mobile broad-band networks in the last few years. This growthhas been enabled by the increase in the numberof users, improved content availability, take-upof smartphones with higher media capabilities,and deployments of higher-capacity and -capa-bility access and core networks. These networksare constantly challenged, and many ways tooptimize video traffic are being studied andimplemented. It has been foreseen for manyyears now that a broadcast mode should comple-ment unicast delivery of content.

The multimedia broadcast/multicast service(MBMS) standard defined by the Third Genera-tion Partnership Project (3GPP) covers the ter-minal, radio network, core network, and user

service aspects. MBMS is a point-to-multipointservice in which data are transmitted from a sin-gle source entity to multiple recipients. TheMBMS standard was introduced in the 3GPPspecification version called Release 6 (Rel-6)and has evolved in subsequent releases. ThisMBMS standard was first specified on the Uni-versal Mobile Telecommunications System(UMTS) and has been updated in 3GPP Rel-9to include Long Term Evolution (LTE) in acommon solution relying on the same core net-work. MBMS on LTE is also called evolvedMBMS (eMBMS). eMBMS brings improvedperformance thanks to higher and more flexibleLTE bit rates, single frequency network (SFN)operations, and carrier configuration flexibility.3GPP Rel-11 also brings improvements in theareas of the service layer with, for example, avideo codec for higher resolutions and framerates and forward error correction (FEC), andthe radio network with procedures to ensureMBMS reception in a multifrequency LTE net-work. eMBMS allows LTE network and back-haul offload. It creates new revenueopportunities by enabling delivery of premiumvideo content to many users with secured qualityof service (QoS) in defined areas, and byenabling pushed content services via user equip-ment (UE) caching.

This article describes the relevant use casesfor eMBMS in terms of service. It then gives anoverview of eMBMS and highlights the evolutionover MBMS. The scope comprises the radioaccess, core network, and service layer.

USE CASES FOR BROADCASTThere are three methods of pushing media fromcontent servers to end-user devices: unicast,broadcast, and multicast. The unicast case is theone we all know today on mobile broadbandaccess like high-speed packet access (HSPA) andLTE. Media is transported from the contentserver to the end-user device on a dedicatedradio and core network link. There are as manybidirectional links as there are end-user devices.The broadcast case is known today for, as anexample, terrestrial television. The media istransported from the content server to the end-

ABSTRACT

The Third Generation Partnership Projectdefined multimedia broadcast/multicast servicein 2005 to optimize the distribution of video traf-fic. This standard covers the terminal, radio,core network, and user service aspects. ThisMBMS standard has evolved into enhancedMBMS (eMBMS) that builds on top of the3GPP Long Term Evolution standard. eMBMSevolution brings improved performance thanksto higher and more flexible LTE bit rates, singlefrequency network operations, and carrier con-figuration flexibility. 3GPP Rel-11 also bringsimprovements in the areas of service layer with,for example, video codec for higher resolutionsand frame rate, and forward error correction.eMBMS allows offloading of the LTE networkand backhaul. It enables the possibility to deliverpremium content to many users with securedquality of service in defined areas. Other impor-tant use cases are pushed content via user equip-ment caching and machine-to-machine services.This article describes the relevant use cases foreMBMS in terms of service. It then gives a tuto-rial on eMBMS, in particular highlighting theevolution over MBMS. The scope comprises theradio access, core network, and service layer.

GABIN LAYOUT_Layout 1 10/24/12 12:06 PM Page 68

IEEE Communications Magazine • November 2012 69

user device on a single unidirectional link sharedby several users in one radio cell, and any usercan receive the broadcast service. Multicast fur-ther allows us to know which users have activat-ed a particular service, e.g. to only activate areaswhere a number of end-user devices have joinedthe service beforehand or to charge users basedon the services actually received. In eMBMS,multicast is only used for the transport of datawithin the network.

Unicast is efficient to cover all services requir-ing a bidirectional link such as the Real-timeVoice and video communication, Web, email orsocial media. Unicast is also efficient for servicesdealing with users spread out over multiple radiocells, consuming different content at differenttimes such as on-demand video streaming.

Broadcast more efficiently covers all servicesfor which many users located in the same areasconsume the same content at the same time. Forexample, many users located in a stadium towatch a game or an event can also access the liveevent video stream on their devices. Using unicastfor such a scenario would likely require overdi-mensioning to avoid overload and congestion.

Broadcast is also efficient to quickly push thesame content to many devices at the same timewithout interaction with the user; for example,caching of popular content like podcasts, newsand music clips, and advertisements or pushingof popular software upgrades. In this manner, allend-user devices get the latest content and soft-ware as soon as it is made available, but usersand applications can access the content withoutany connection to the network. Using unicast forsuch use cases would require much more time tocover a large population of devices.

At the time MBMS over UMTS terrestrialradio access network (UTRAN) was standard-ized, the industry was focused on the mobile TVuse case. Digital video broadcasting for handheld(DVB-H) networks was being deployed in severalcountries, and MBMS seemed like a way formobile broadband operators to offer the sameservices over the UTRAN access. However, itturned out that the service was not a big success.One of the reasons was that mobile users utilizetheir devices in general for killing time [1] (e.g.,while waiting for the bus). Mobile users do notwait for the start of a program, as expected fromlinear TV users, and prefer on-demand videowhere they can start a program wherever andwhenever. This trend is obvious on the web butalso now observed on IP television (IPTV) catch-up TV and video on demand (VoD) services. Sowhile broadcast is efficient for live streaming in astadium to many users, it should also be used ina general case to give an efficient on-demandexperience. Another reason was that the videoquality was somewhat limited by achievablebandwidth over MBMS UTRAN (e.g., up to 20channels of 64 kb/s or 5 channels of 256 kb/s [2,3]) in comparison to, say, web video. In Rel-7,the introduction of MBMS over SFN transmis-sion (MBSFN) allows increasing the capacity bya factor up to 3 or 4 in certain deployment condi-tions [3], but if used on existing UMTS deploy-ments, it would not be possible to use the samefrequency for MBMS and non-MBMS transmis-sions, making it a rather costly solution.

USE CASES AND SERVICES

AUDIOVISUAL STREAMING OVER EMBMSThe industry of video streaming has in the lastfew years moved from Real Time Transport Pro-tocol (RTP) based streaming to Hypertext Trans-fer Protocol (HTTP) based streaming protocolslike Apple HTTP Live Streaming (HLS) [4].HTTP streaming has the benefit of using plainHTTP servers, and overcoming Network AddressTranslator (NAT) and firewall traversal issues.For HTTP streaming of files, the client requestsmedia segments that are then pushed by theHTTP server. 3GPP standardized an AdaptiveHTTP Streaming (AHS) protocol in Rel-9 [5].An overview of 3GPP streaming standardsincluding AHS is available in [6]. AHS was thenintroduced into eMBMS Rel-9 to allow forstreaming of AHS content via eMBMS. AHSwas then adopted by the Moving Picture ExpertsGroup (MPEG) as the baseline of what subse-quently became MPEG-DASH [7] (DynamicAdaptive Streaming over HTTP). 3GPP thendefined its Rel-10 version of DASH, called 3GP-DASH [8], which is a compatible profile ofMPEG-DASH.

Figure 1 gives an overview of DASH on uni-cast. DASH allows the client to retrieve, viaHTTP, continuous segments of an audiovisual3GP file [5] to realize both live and on-demandaudiovisual streaming. Each piece of media maybe made available over different versions of seg-ments called representations, which have differentquality and bandwidth characteristics (e.g., low,medium, and high quality). Although the repre-sentations have different characteristics, they arecompatible with each other in that they can beplayed in sequence. A manifest file describes themeans for the client to fetch the correct seg-ments of the selected representations. The clientcan then at any time pick the representation ofits choice, so the content rate can be adapted tothe observed bandwidth of the link.

Both 3GP-DASH and MPEG-DASH contentcan be streamed over eMBMS. However, in thiscase the client cannot request particular repre-sentations; it simply gets the media segments

Figure 1. 3GP-DASH overview.

t

HTTP GET requests

Media segments

RAN EPGServer

t+8

3841 1

2

t+16 t+24 t+32t t+8

2222

111

Time

1

384384384384

t+16 t+24 t+32


IEEE Communications Magazine • November 201270

being delivered to it over eMBMS. The manifestfile in this case contains only one representationof audio and video. 3GPP currently specifiesRel-11 evolution of DASH and eMBMS suchthat continuity can be achieved between DASHover eMBMS and DASH over HTTP unicast.

EMBMS ENHANCEMENTS TOUNICAST APPLICATIONS

Smartphone applications today can run in non-interactive mode to retrieve content, notifica-tions, or software updates over unicast access.The content can be, for example, audio podcaststo which the user is subscribed, in-game dynamicadvertisement banner images, pre-roll video ads,application software, and map database updates.This use case can be performed more efficientlyfor a large end-user device population by broad-casting content rather than relying on unicast.The principle is depicted in Fig. 2. Prior to anyMBMS sessions, the content/software isannounced to all targeted end-user devices viaunicast. The scheduling is such that the sessionswill occur during off peak times so as not to takevaluable time for live streaming events. In a firststep, the end-user device caching applicationtunes in to the relevant sessions to downloadcontent/software and store it into a cache. In asecond step, when a certain application needsthe data it will access it via HTTP requests. Andif the data is in the cache then no unicast accesswill be used. The user may not be even involvedwhen the more important applications of itsSmartphone are updated. This improves networkusage, reaction times and therefore user satisfac-tion.

END-USER DEVICE ANDNETWORK SERVICE LAYERS INTERACTIONS

The eMBMS service layer architecture involvesthe same entities as for video streaming servicesand content/software download. These entitiesare end-user devices, application servers, videostreaming servers, content/software servers andContent Delivery Networks (CDN). However,for the purpose of eMBMS, the end-user devicewill neither connect directly to a video streamingservers nor content/software servers on unicast

IP connections. For the connection to be usingbroadcast, a new entity is needed to controlbroadcast sessions of the MBMS gateway(MBMS-GW) and map incoming server trafficon broadcast bearers. This new entity is calledthe broadcast/multicast service center (BM-SC).The BM-SC has multiple roles.

The BM-SC owns the schedule of its servicesas configured by the operator. Such scheduleinformation is delivered to end-user registereddevices so that applications or users themselvescan decide to tune in to a particular service. Thedelivery of the scheduling information to end-user devices can be done by service guides (e.g.,OMA BCAST [9]) or by proprietary means (e.g.,via a dedicated smartphone application). Theservice announcement gives enough informationto users and applications on when and how totune in to receive relevant files of the service.The information is typically accessed from ser-vice guides or dedicated smartphone applica-tions, but can be fetched by any meansappropriate. This is called the user servicedescription and gives information about scheduli-ing, file delivery session description, encryption,FEC, and associated delivery procedures (ADPs)like file repair and reception reporting.

The BM-SC activates and releases the MBMStransmission resources for file delivery sessionson the MBMS-GW via the SGmb interface. TheBM-SC provides the relevant eMBMS servicearea and the required information for distribu-tion of the user-level multicast flow into theMBMS-GW. SGmb is based on the DiameterBase protocol [10] and uses TCP transport.

The BM-SC transmits user plane data usingIP multicast all the way to the UE. The interfacebetween BM-SC and MBMS-GW, and betweenthe gateway and eNodeBs can be operated inmulticast to optimize transport. The BM-SC isthe source of the SYNC protocol used to ensureeNBs receive precisely the same data packets forPtM transmission.

DOWNLOAD OVER EMBMSBecause HTTP cannot be used on unidirectionallinks, a unidirectional protocol was introducedfor delivery of files or file segments. This is theFile Delivery over Unidirectional Transport(FLUTE) protocol. FLUTE protocol is carriedover the User Datagram Protocol (UDP) and IPmulticast toward end-user devices.

The receiver needs to know what files itshould receive and how to construct those filesfrom the data it will receive during the session.The files to be delivered in a session are listed ina file delivery table (FDT). Each file has a file-name and location, a content type (used for cor-rect dispatching at the receiver), identification(TOI — transport object identification), expiryinformation, and a hash (MD5 — MessageDigest — to be able to differentiate file ver-sions). When FEC is used, the necessary param-eters are included so as to enable decoding.When encryption is used to reserve files toreceivers with a decryption key, the identifier ofsuch key is also indicated.

Files can be of very different sizes (a fewkilobytes to several gigabytes). They are first seg-mented into source blocks. When FEC is used,

Figure 2. eMBMS UE caching use case.

Step 1. Receivemedia/software

Step 2. Consumemedia/software

MBMS

SW

Local cache

Server

Stor

e



those source blocks are transformed into newblocks called encoding symbols. Furthermore,these blocks can be GZip encoded prior to trans-mission.

The FDT sent to the receiver has a file objectitself (with reserved TOI = 0) during the broad-cast session and can be updated regularly. It alsocontains cache directives like for HTTP. Thereceiver must maintain the FDT up to date so asto be able to correctly build files from receivedFLUTE data (identified by the TOI).

FILE REPAIRAlthough the radio layer can provide an arbitrar-ily high level of QoS on unicast bearers, it can-not guarantee error free reception of data in thecontext of broadcast. This is due to the inherentimpossibility to use hybrid automatic repeatrequest (HARQ) on lower layers of unidirec-tional bearers. Therefore, a mechanism wasintroduced to allow end-user devices to retrievemissing parts of a file after their broadcast ses-sion is over. This mechanism is called file repair.The file repair procedure is activated only ifindicated in the service description and only atthe end of the file reception session. The princi-ple is that the device will connect over unicast tofetch more file segments in order to be able toconstruct the whole file. Because it is a unicastprocedure, mechanisms like selection of serverand backoff timer are in place to limit the risksof overload situations. Enhancements are beingspecified in 3GPP for the file repair proceduresin Rel-11 to support conventional HTTP serversand prevent overload situations with server spe-cific retry timers.

APPLICATION LAYERFORWARD ERROR CORRECTION

File repair is relevant to content files and soft-ware delivery. However, it cannot be used forstreaming sessions where data has to be deliv-ered with a minimal delay. For this reason, appli-cation layer FEC (AL-FEC) is also specified toallow end-user devices to improve the probabili-ty of reception of data. The eMBMS AL-FECcode currently specified for eMBMS is the Rap-tor code [11]. The code is systematic and used toproduce encoding symbols from the FLUTEsource symbols. The receiver can then use thereceived source and encoding symbols to retrievemissing source symbols lost during transmission.This code is very efficient in that it requires onlyreceiving a little more than the file size to have ahigh probability of recovering the file. This FECcan be decoded using software implementations.FEC can be used for file segment streaming aswell as file delivery, reducing the probability offile repair procedures. At the time of writing,enhancements to the AL-FEC are being definedin 3GPP Rel-11. The new AL-FEC code shouldallow better performance while being manage-able on software-based implementations.

EMBMS QUALITY OF SERVICEOne major benefit of using LTE for eMBMS isthat bit rates for real-time services like videostreaming are much higher than for UTRANMBMS. 3GPP Rel-11 video and audio codecs

[12] are state-of-the-art codecs providing thebest compromise between bandwidth and quali-ty. 720p (1280 ¥ 720) HDTV resolution at 30frames/s video is supported with the H.264(AVC) High Profile Level 3.1 codec. Full bandaudio is supported. Bit rates ranging from 500kb/s to 1 Mb/s offer the best compromise onquality and bandwidth. These codecs are alignedwith those defined for DASH unicast streaming.

Due to the unidirectional nature of eMBMSservices, the network operator cannot easilyknow from the session if end-user devices havecorrectly received the data or the user experi-ence of a streaming session was good. Quality ofexperience (QoE) metrics and reception report-ing were defined for this purpose. The serviceannouncement information configured by theoperator describes the parameters for QoE met-rics and reception reporting. These reports aresent unicast. These can be configured such thatonly samples of end-user devices report them.The QoE metrics indicates the number of lostHTTP streaming segments. This enables theoperator to evaluate the quality experienced by aparticular user. Reception reporting indicateswhether a particular file was actually received ornot.

RADIO TRANSMISSION

RADIO RESOURCESThe LTE network is a radio cellular network;that is, its total coverage area is divided intocells transmitting a unique radio signal whichcan be distinguished from the signals of othercells. Each LTE cell is allocated a reserved fre-quency spectrum for its transmission to mobileterminals within its coverage area, and each ele-mentary transmission of a piece of user data to amobile terminal requires the exclusive usage of aportion of the allocated spectrum for an elemen-tary time interval. For this reason, the allocatedfrequency spectrum or the portion in time orfrequency are often called radio resources.

MULTIPOINT TRANSMISSIONAn LTE base station is physical equipmenttransmitting the signals of one or more cells, forexample, in different direct directions (or sec-tors) or with a different frequency spectrum. Totransmit the data of MBMS services to mobileterminals, LTE base stations use the same anten-

Figure 3. High-level service layer architecture.

HTTP

Content over unicast

Content overbroadcast

Announcements,QoE receptionreporting, filerepair, keymanagement

MBMS/FLUTE

HTTP

Feeds/content

HTTPserver

EncodersBM-SC



nas and frequencies like for any other data totransmit to each LTE mobile terminal but foreach MBMS session, the associated data arebroadcast in each LTE cell of the area deter-mined by the BMSC, i.e. a single transmission ofMBMS data is received by all mobile terminalsserved by this cell.

COVERAGE AND EFFICIENCY:SFN TRANSMISSION

A naive view of broadcast transmissions could bethat if the same information is transmitted onlyonce for two receivers, it takes half the resourcescompared with two separate transmissions (i.e.,one for each receiver). However, in the case oftransmissions to a single mobile terminal, thenetwork adapts the signal modulation and cod-ing rate of its transmissions according to thereception conditions at the terminal, which areperiodically reported. This allows the amount ofradio resources for the transmission to bereduced.

In the case of a broadcast transmission, thenetwork is not aware of the reception condi-tions of each terminal and must use a robustenough modulation and a sufficiently high cod-ing rate so that even terminals near the borderof the cell coverage (also called cell edge) cansuccessfully decode the broadcast data. Termi-nals near the border of the cell coverage sufferfrom not only signal loss due to a larger dis-tance but also interference from transmissionsof neighbor cells. In the case of an MBMS ser-vice, this would require assuming the worst pos-sible conditions in all cells and thus largelyincrease the amount of radio resources requiredfor each service.

It is possible to overcome such a limitationby having neighbor cells transmitting exactly thesame signal in a fully synchronized manner sothat the radio signals from different cells areinterfering constructively and the received signallevel is increased. Such an effect is highly bene-ficial at the cell edge. This transmission tech-nique is often called single frequency networkas several radio transmitters, instead of avoidinginterference between their respective transmis-sions by using non-overlapping frequencies,

deliberately using the same frequency, andtransmitting identical signals that cannot be dis-tinguished at all.

When SFN transmission is used in the LTEnetwork, it takes much less radio resources tobroadcast a flow of data than to transmit thesame flow individually to two mobile terminalsin the same cell. Considering a wide deployment,with terminals randomly distributed in space sothat on average there is 0.5 or more user per cellinterested in a certain data content, providingthis content as a MBMS service allows savingradio resources, which allows to provide betterservice to other users or provide service to moreusers [13]. In the case of very popular services(e.g., video stream of a sporting event), provid-ing it as an MBMS service can greatly reducethe cost for the network or, given a certain net-work deployment, may be the only way to pro-vide the service to all interested users. Thespectral efficiency of LTE MBMS was evaluatedto 3 b/Hz in the case of a distance between LTEbase stations of 500 m, as compared with 0.25b/Hz in the case of UMTS.

COEXISTENCE OFSFN AND NON-SFN TRANSMISSION

In order to allow coexistence of SFN transmis-sions for MBMS services (called MBSFN trans-missions) and non-SFN transmissions for otherservices, the LTE network must reserve a pat-tern of time intervals for SFN transmissions andeach cell indicates this pattern as part of its sys-tem information broadcast to all terminals [14].This pattern should preferably remain fixedover, say, a few hours, so it is necessary todimension it according to the amount of MBMSdata expected to be transmitted. This procedureis required because most LTE terminals measurethe reception quality of each LTE cell at everyelementary time interval by decoding cell-specif-ic reference signals, and such a signal cannot beincluded in time intervals where the exact signalis transmitted across several cells.

Up to 60 percent of an LTE frequency carriermay be dedicated to MBMS transmissions. Inthe case of 5 MHz (i.e., like UMTS), with aninter-site distance of 500 m, it is possible totransmit 9 Mb/s of MBMS data (e.g., up to 140channels of 64 kb/s or up to 35 channels of 256kb/s), and there is no restriction on the channelsize. Using a 20 MHz LTE frequency carrier foreMBMS, simultaneous transmission of aboutfive HDTV channels is possible, parallel to uni-cast services.

MBMS SERVICE AREA ANDLTE NETWORK ARCHITECTURE

SFN transmissions across cells under the controlof the same LTE base station are possible with-out any impact to the existing LTE architecture.However, there is a strong interest in extendingthe SFN transmission to all cells where MBMSservice should be available, potentially acrosscells under the control of several LTE base sta-tions. Such a scenario can be supported bydeploying MBMS control entities in charge ofselecting the modulation and coding scheme of

Figure 4. RAN architecture for SFN across LTE base stations.

Data

MCE

Mobileterminals

LTE basestations

Control information(MBSFN area, modulation,coding)

Control information(session start/stop, area)

Control information(session start/stop, area)

Data(and syncinformation)

Control information(session start/stop,area)

MME

MBMSgateway

BMSC



each MBSFBN transmission and providing suchinformation to all involved LTE base stations. Inaddition, in order to ensure that the same dataare transmitted at the same time, the MBMSgateway provides each base station involved inthe transmission of MBMS service with starttimes of sequences of MBMS data to be sent.This architecture is depicted in Fig. 4 and fur-ther described in [15].

The set of cells participating in the same SFNtransmission is called an MBSFN area. If differ-ent services are transmitted in the same cell buthave different coverage areas, the cell may trans-mit them in different time intervals where a dif-ferent set of cells participate to the same SFNtransmission (the cell is said to belong to severalMBSFN areas). The maximum extension ofMBSFN areas is determined by the size of areaswhere cells are synchronized (called “synchro-nization area”). An example with two servicesand different service areas, synchronization areasand MBSFN areas is shown in Fig. 4.

MBMS SERVICE RECEPTIONAn LTE terminal which was granted access to amobile network can be in connected state, i.e. aradio connection to a serving cell is maintained,or in idle state, i.e. the terminals autonomouslyidentifies a suitable serving cell and will initiatea connection to request services or to respond tonotifications sent in all cells within an areawhere the UE previously indicated its presence.All LTE terminals supporting MBMS receptioncan receive MBSFN transmissions on the fre-quency of the serving cell, while idle or connect,without any action from the network.

MBSFN transmissions not only include thedata of the MBMS services but also periodicMBMS control and scheduling information mes-sages indicating which services are currentlytransmitted and in which time intervals they maybe transmitted,

Each LTE cell supporting MBMS transmis-sions periodically broadcasts, together with otherreference information such as cell and operatoridentity, the list of MBSFN areas of which it is amember and, for each MBSFN area, the timeintervals when the transmission of periodicMBMS control and scheduling information mes-sages occurs.

An LTE terminal receiving MBMS servicesfrom an MBSFN area reads all the periodic con-trol messages, in order to determine in whichtime intervals the desired services are transmit-ted and turn off its receiver in the other timeintervals in order to reduce its battery consump-tion.

An LTE terminal searching for MBMS ser-vices reads all the periodic control and schedul-ing messages from all MBSFN areas which thecell belong to. In order to allow quickly findingthe desired services and to avoid a significantincrease of battery consumption, the controlmessages are repeated a pre-determined numberof times without any change over a time period(called modification period) and the LTE cellnotifies LTE terminals, in the same way asincoming unicast data, when there is a change incontrol information so that the UE can readMBMS control messages less frequently.

MBMS RECEPTION IN ANLTE MULTIFREQUENCY NETWORK

In an LTE network with multiple cells with dif-ferent frequency allocations, the terminal may beinterested in receiving MBMS services not pro-vided on the same frequency as the serving cell.In Rel-11, additional enhancements were intro-duced in order to ensure the continuity ofMBMS reception while the UE is moving withinan MBSFN area or to help UE find services pro-vided on other frequencies, as described in thissection.

To avoid the need for LTE terminals to readinformation broadcast on each MBSFN area ofeach neighbor cell on all LTE frequencies, thenetwork can indicate in the MBMS servicedescription the frequencies or the cell groupsselected by the BMSC to provide the service. Ifcell groups are indicated, each cell should alsoindicate in broadcast information the groups ofall neighbor cells per frequency. Indicating thefrequency is sufficient for services provided onthe same frequency in the whole network but forservices with local coverage or using differentfrequencies, cells groups provide more preciseinformation.

While in idle state, the LTE terminal selectsthe serving cell according to rules independentof MBMS reception, that is, the network mayindicate in system information that a particularfrequency must be prioritized (e.g., in order todirect terminals to a less loaded frequency). Toensure that MBMS reception is possible, theLTE terminal is allowed to prioritize cells on thefrequency providing the desired MBMS service.

When in connected state, to maintain the

Figure 5. Example with two MBMS services with different services areas.

Synchronizationarea

MBSFN area 3red service

MBSFN area 2yellow service

MBSFN area 1yellow and red services

LTE base station andcoverage area

MCE 1

MCE 2



connection as the terminal is moving, an LTEterminal reports the quality of the serving celland of other cells (neighbor cells), and the net-work instructs the terminal to use a different cellfor radio communications according to thereported quality. If there are multiple frequen-cies, the network may move the terminal to aless loaded frequency or configure reception onmultiple frequencies if supported. The LTE ter-minal interested in receiving MBMS servicesindicates the frequencies on which it wishes toreceive MBMS services and the network maytake this information into account to enableMBMS reception and avoid any interruption.

OVERALL, WHAT DOES IT TAKE TODEPLOY EMBMS SERVICE?

In summary, the deployment of eMBMS servicehas the following impacts. Device chipsets needhardware support for eMBMS modem. Networkprotocols and application software need to beupgraded. A BM-SC needs to be introduced inthe network along with the required interfaces tocontent servers and the service guide applicationservers. LTE base stations must be tightly syn-chronized in wide areas, preferably as wide asthe intended coverage of MBMS services inorder to maximize the benefits of SFN transmis-sion. For the expected coverage areas of MBMSservices, sets of existing LTE cells should beselected to create MBSFN areas, ensuring prop-er coverage, and MCEs should be deployed tocontrol the designed MBSFN areas.

CONCLUSIONThe MBMS framework allows providing con-tents to a number of users without the need toincrease network capacity as the number ofinterested users becomes very large. MBMS wasfirst introduced in 3GPP specifications at a timewhen voice calls were still the dominant usage ofmobile networks and LTE was not yet envisaged.eMBMS was introduced to support LTE andadapt to expected mobile network usage. 3GPPRel-11 brings enhancements to eMBMS byensuring that an LTE terminal can find thedesired MBMS service among multiple LTE fre-quency carriers, the Rel-11 eMBMS enhance-ments also make it possible to offer a widerrange of high-bit-rate services by increasing thenumber of LTE frequency carriers used forMBMS transmission. As the landscape of ser-vices and usages has changed, further evolutionsof certain MBMS features were introduced likebetter video resolutions and audio quality, betterFEC, and optimized file repair procedures overHTTP servers. While it is not possible to predictfuture usages of mobile networks and deploy-ment decisions of operators, the growing usageof mobile broadband multimedia services with

smartphones over UMTS HSPA and now LTEnetworks are creating the conditions in whicheMBMS becomes a very attractive solution.

REFERENCES[1] T. Lohmar, Reliable File Distribution over Mobile Broad-

cast Systems, thesis.[2] 3GPP TR 25.993, “Typical Examples of Radio Access

Bearers (RABs) and Radio Bearers (RBs) Supported byUniversal Terrestrial Radio Access (UTRA).”

[3] 3GPP TR 25.905, “Improvement of the MultimediaBroadcast Multicast Service (MBMS) in UTRAN.”

[4] Apple HLS, HTTP Live Streaming draft-pantos-http-live-streaming-08 (IETF draft).

[5] 3GPP TS 26.234, “Transparent End-to-End Packet-Switched Streaming Service (PSS); Protocols andCodecs.”

[6] Gabin et al., “3GPP Mobile Multimedia Streaming Stan-dards,” IEEE Sig. Proc. Mag., Nov. 2010.

[7] ISO/IEC 23009-1:2012, “Information Technology —Dynamic Adaptive Streaming over HTTP (DASH) — Part1: Media Presentation Description and Segment For-mats.”

[8] 3GPP TS 26.247, “Transparent End-to-End Packet-Switched Streaming Service (PSS); Progressive Down-load and Dynamic Adaptive Streaming over HTTP (3G).”

[9] Open Mobile Alliance BCAST Service Guide V1.0.[10] 3GPP TS 29.061, “Interworking Between the Public

Land Mobile Network (PLMN) Supporting Packet BasedServices and Packet Data Networks (PDN).”

[11] IETF RFC 5053, “Raptor Forward Error CorrectionScheme for Object Delivery.”

[12] 3GPP TS 26.346, “Multimedia Broadcast/Multicast Ser-vice (MBMS); Protocols and Codecs.”

[13] R1-071433, additional results on EMBMS transmissionconfigurations, Motorola.

[15] 3GPP TS 36.300, “Evolved Universal Terrestrial RadioAccess (E-UTRA) and Evolved Universal Terrestrial RadioAccess (E-UTRAN); Overall Description; Stage 2.”

[14] 3GPP TS 36.331, “Evolved Universal Terrestrial RadioAccess (E-UTRA); Radio Resource Control (RRC); Proto-col Specification.”

ADDITIONAL READING[1] 3GPP TS 26.244, “Transparent End-to-End Packet

Switched Streaming Service (PSS); 3GPP File Format(3GP).”

[2] T. Paila et al., IETF RFC 3926 , “FLUTE — File Deliveryover Unidirectional Transport,” Oct. 2004.

[3] Open Mobile Alliance Broadcast Distribution SystemAdaptation — 3GPP/MBMS.

[4] Lohmar et al., “Dynamic Adaptive HTTP Streaming ofLive Content,” 2011 IEEE World of Wireless, Mobile andMultimedia Networks.

BIOGRAPHIESFRÉDÉRIC GABIN ([email protected]) is standard-ization manager for Ericsson since 2008. He leads andcoordinates the development of media and mobile broad-band multi-screen TV standards and participates in particu-lar in 3GPP TSG WG4 since 1998. He graduated in 1997from Telecom Paris, started his career as a signal process-ing research engineer, and since then has been involved inresearch, system design, and standards for both networkand mobile terminal vendors.

DAVID LECOMPTE ([email protected]) joinedHuawei Technologies France in 2010. He obtained a Masterof Engineering in 1997 at Telecom Paris, France. He workedin communication software design and development. Since2005, he is participating in 3GPP standardization, mainly inthe Radio Access Network Working Group 2 (RAN2, radiointerface architecture and layer 2/3 protocols) for UMTSand LTE.

The growing usage

of mobile broadband

multimedia services

with smartphones

over UMTS HSPA

and now LTE net-

works are creating

the conditions in

which eMBMS

becomes a very

attractive solution.

GABIN LAYOUT_Layout 1 10/24/12 12:06 PM 4

MBMS

Documents

Transcript of MBMS