Scalable push file delivery with MBMS

MBMS push services give operators the ability to deliver multimedia content,
simultaneously, to all users in a specifi c location, without overloading a mobile network.
tent increase proportionally with the number of subscribers and the size of
the transferred content.
The scalability problem can be solved
by using broadcast technologies for
pushing content in the form of fi les.
Popular push services can use broadcast
distribution technology to complement
existing unicast schemes. The
resources needed to distribute a fi le are
independent of the number of subscribers,
and the time needed to reach all
subscribers depends only on fi le size.
By defi ning separate broadcast channels
for different services, it is possible
to let users opt-in to the content of
their choice. This provides a degree of
personalization.
Multimedia broadcast/multicast service
(MBMS) is the native broadcast technology
of third-generation mobile system
(3G) networks.1 It offers two delivery
methods: streaming and download.
Streaming is typically used for mobile
TV services, while download (here
called MBMS push fi le delivery service)
is used for distributing content in fi les of
any size and arbitrary format.
The use of MBMS for mobile TV has
been described in a previous article.2
For the purpose of this article, we note
that the MBMS push fi le delivery service
is not orthogonal to mobile TV but
rather it is a key enabler for the mass market
distribution of podcast TV as
part of a rich mobile TV offering.
What makes MBMS particularly well
suited for push services is an effective
paging mechanism that can selectively
wake up terminals when a transmission
is about to start. This allows terminals
to remain in standby mode (preserving
battery capacity) while waiting for
a transmission. As well, MBMS allows
precise control of the broadcast area of
any transmission, from one cell up to
the entire network.
THORSTEN LOHMAR, JUAN-ANTONIO IBANEZ, AURELIE ZANIN AND
MIGUEL BLOCKSTRAND
Push services are popular on the
internet and in mobile environments.
Internet push services
often use podcast mechanisms,
while mobile push services use
SMS and WAP-push. Technical
realizations today are based on
dedicated point-to-point delivery.
This article presents MBMS
push fi le services as a scalability
extension to unicast services.
MBMS is thus used as a “capacity
booster” for distributing
popular content services.
Push services, which provide content
to mobile phones without direct user
involvement, have long been of interest
to mobile operators. The most common
technologies used to realize push
services in mobile networks are short
message service (SMS) and wireless
application protocol push (WAP-push).
On the internet, the common technology
is podcasting. Existing podcast services
employ the really simple syndication
(RSS) protocol, and are actually a
pseudo-push service — clients periodically
poll a server to check for updates
and new content, which is then downloaded
to user devices. The rationale
for periodic polling is that it works in
the presence of fi rewalls and network
address translators, which are common
obstacles on today’s internet.
These point-to-point delivery techniques
do not scale well, however. The
resources needed to distribute the con-
BOX A Terms and abbreviations
3G Third-generation mobile system
ADP Associated delivery procedure
description
API Application programming interface
BCAST Mobile broadcast
BM-SC Broadcast/multicast service center
C2P Content-to-person
CBS Cell broadcast service
ESG Electronic service guide
FD File delivery
FDT File delivery table
FLUTE File delivery over unidirectional
transport
FR File repair
GPRS General packet radio service
HSPA High-speed packet access
HTTP Hypertext transfer protocol
MBMS Multimedia broadcast/multicast
service
MBSFN Multimedia broadcast single frequency
network
MCCH MBMS control channel
MICH MBMS indicator channel
MMS Multimedia messaging service
MTCH MBMS traffi c channel
OMA Open Mobile Alliance
PTP Point-to-point
RNC Radio network controller
RR Reception reporting
RSS Really simple syndication
SDP Session description protocol
SMS Short message service
TCP Transmission control protocol
TMGI Temporary mobile group identifi er
UDP User datagram protocol
USD User service description
WAP Wireless application protocol
XML Extended markup language
12
ERICSSON REVIEW • 1 2009
Simultaneous delivery of multimedia content
Business incentives for push
services
Today’s consumers expect to access content
at will, wherever they are. Market
research consistently shows that
the adoption of new services is ruled
by consumer convenience and value.
Consumers want to stay informed and
updated within their areas of interest,
and they want immediate access to
information of their choosing. Market
studies show consumer willingness
to pay a moderate fee for fast and easy
access. Alternately, indirect payment,
through the acceptance of advertisements,
is already established in internet
usage behaviors. Users accept advertisements
if they are not intrusive or if
users have an option to control how they
are rendered.
The value of push services to users
lies in their ability to receive any type
of multimedia content, through a simple
interface with a single subscription.
Ultimately, users will not care about
how content reaches them as long as it
is available when they want it, whether
they are online or not.
Pushing content in the background
according to user preference and storing
it in the terminal for later consumption
signifi cantly reduces service startup
and content access times. In most cases
the content is already available in the
terminal when the user decides to consume
it. Any missing content may still
be fetched on demand.
Existing push services are rarely
timely or simultaneous, since they rely
on point-to-point transmissions that can
only be parallelized to a limited extent
and otherwise require sequential transmission
of the same content. In addition,
mobile operators are looking for ways to
distribute more of their own content
to subscribers without risking network
overload. One solution is to broadcast
popular services.
From a business perspective, the key
questions that arise are what kind of content
is interesting to deliver, what costs are
involved to deliver it, and how will revenues
be generated?
The types of content and services
operators deliver will range from
immediate real-time services, such
as emergency alert messages, to less
time-critical background delivery for
later consumption, such as news and
weather updates, active wall papers,
sport highlights, selected clips or
tunes, and so forth. The content can
also be for machine-to-machine
communications, such as software
updates, maps, or other kinds of system
application data.
Business cases developed by Ericsson
show that revenues as low as EUR 1 per
user per month can motivate a complete
investment in MBMS infrastructure at
relatively small service penetration levels.
Past that break even point, any additional
subscriber brings pure profi t.
Moreover, operators can obtain this revenue
either through subscription fees
or from advertising. Typical advertising
models to mobile users include static
or dynamic banners, (preload) contentrelated
advertisement, or opt-in models.
MBMS fi le delivery can be used with
all common advertisement models, and
it can be closely tied to the service and
type of content.
MBMS push fi le delivery enabler
MBMS system and notifi cation
mechanism
Essentially, MBMS offers a scalable
mechanism for delivering multimedia
content over 3G networks. The MBMS
architecture is the same for the two
supported delivery methods: streaming
(used for mobile TV) and download
(used for fi le delivery services). The general
characteristics of MBMS have been
described in an earlier article and still
apply.3 Recent enhancements introduced
in the MBMS standards, such as
the support of single-frequency networks
(MBSFN), also apply to both delivery
methods.
There are, however, differences in
how the MBMS features are used by
RNC receives
session start
Cyclic retransmission
of control info
MTCH access
information
MICH
MCCH
MTCH
MBMS transmission session
File 1 File 2 File N
RNC receives
session stop
FIGURE 1 Push fi le delivery on MBMS traffi c channels (MTCH).
Reception reporting
Phase 2:
Associated
delivery
procedures
Phase 1:
MBMS
transmission
session
GGSN
Mobile
network
PTP file-repair procedure
Interactive bearers (PTP)
BM-SC
(FD sender)
MBMS bearers
(PTM)
MBMS session start
MBMS session stop
File delivery table (FDT) instance
Object transmission via MBMS
BM-SC
(RR)
Random
wait
Random
wait
time
BM-SC
(FR)
FIGURE 2 MBMS fi le-delivery principle with point-to-point fi le repair.
13
ERICSSON REVIEW • 1 2009
forward error correction (FEC) code
from Digital Fountain. For MBMS download,
terminals must support Raptor
FEC. The BM-SC decides on the usage
and the coding rate.
The Raptor FEC code is a lowcomplexity
code that allows entire fi les
of up to several megabytes to be used as
a single FEC source block. Raptor’s special
property is the generation of a high
number of independent FEC symbols
from a single source block.
In addition to using FLUTE for MBMS
transmission sessions, 3GPP has defi ned
complementary procedures for service
discovery, security, and associated delivery
procedures, all of which may use an
interactive bearer.
Figure 2 schematically shows MBMS
fi le delivery. It is assumed that the
BM-SC hosts the content and communicates
to the mobile network through
the gateway GPRS support node (GGSN).
MBMS bearers are established, used,
and released during phase 1 of the procedure,
while phase 2 shows the pointto-
point (PTP) fi le repair and receptionreporting
functions. Point-to-point fi le
repair allows terminals to request missing
data (lost packets) using interactive
bearers, for example, HSPA. The “random
wait time” between phase 1 and
phase 2 is introduced to avoid uplink
congestion. The reception reporting
function allows operators to monitor
how many terminals have received the
content.
the different types of services. For
instance, live TV services produce a continuous
packet stream for typically a
long period (several hours). File delivery
services produce bursts of data, the size
of a burst being determined by the fi le
size and the selected bit rate. The radio
resources are only reserved for the duration
of the burst and are then released
and can be used by other services.
MBMS defi nes three MBMS-specifi c
radio bearers:
MICH (MBMS indicator channel), used to
notify terminals about the imminent
start of an MBMS transmission session;
MCCH (MBMS control channel), which
carries control information about all
on going MBMS transmission sessions;
and
MTCH (MBMS traffi c channel), which
carries the actual data of an MBMS
transmission session.
Figure 1 illustrates the relationship
between these channels. While in standby
mode, the terminal monitors MICH
during its regular paging occasions.
MICH indicates upcoming changes in
the MCCH for a particular service identifi
ed by its temporary mobile group identifi
er (TMGI). Triggered by MICH, the
terminal fully powers on its receiver
and reads MCCH to fi nd detailed information
about the session. The terminal
then tunes to MTCH and starts receiving
data.
The MICH and MCCH channels are
always active in a cell, whereas MTCH is
set up only for the duration of an MBMS
transmission session. Upon reception of
the session-start message from the broadcast/
multicast service center (BM-SC),
the radio network controller (RNC) triggers
the notifi cation on MICH, establishes
the corresponding MTCH, and
updates MCCH with MTCH access information.
The RNC releases the MTCH
resources on reception of an MBMS
session-stop message. MTCH is thus
only active for the duration of the fi le
transfer.
Pushing fi les over MBMS
Figure 2 depicts the general principle
of an MBMS fi le-delivery session. It is
assumed that the terminal has discovered
the service and already activated
reception. Because TCP and HTTP
do not support multicast/broadcast
addressing and are bidirectional by
nature, the 3GPP has selected the IETF
FLUTE (fi le delivery over unidirectional
transport) protocol for transferring
fi les over MBMS, which is unidirectional.
Files are fragmented and sent in UDP
packets. Transmission robustness may
be increased using the DF RaptorTM
BOX B Overall architecture
Figure 3 schematically depicts a possible MBMS
push fi le delivery architecture. The BM-SC hides the
transmission complexity by providing a web service
API to application servers. The service and download
managers handle the abstraction of internal mobilenetwork
procedures to web service methods.
The service manager registers new applications
and generates the corresponding service attributes
and description fi les: user service description
(USD), session description (SDP), and associated
delivery procedure description (ADP).
The download manager handles transmission
requests issued by the applications. Files and
transmission parameters are locally stored for
subsequent fi le repair (FR) actions. The fi le delivery
(FD) sender partitions the fi les to fi t into UDP
packets. FEC redundancy is optionally added to increase
transmission reliability. The “job” scheduler
controls the transmission and uses the Gmb interface
to establish and release the necessary MBMS
bearers. The reception reporting (RR) function collects
reception acknowledge ments.
Applications
Service
manager
Download
manager
HTTP (Service discovery) Services and service
parameters
File and parameter
storage
Podcast
Pod AW
MBMS download
client
MBMS
UE
…
FR
FD sender
Job scheduler
BM-SC
FEC
RR
RBS RNC SGSN GGSN
Gmb
Active
wallpaper
Emergency
alert
…
HTTP (Associated procedures)
HTTP
FLUTE (MBMS transfer)
Uu
lub lu Gn
Gi
FIGURE 3 Architecture for MBMS push fi le delivery.
14
ERICSSON REVIEW • 1 2009
Simultaneous delivery of multimedia content
A FLUTE fi le delivery table (FDT)
instance is delivered to the terminals,
in-band with the actual content. This
describes the fi les and associated transport
parameters, which are provided during
the MBMS transmission sessions.
Service discovery and service activation
Service discovery refers to methods
that terminals use to obtain a list of
available services along with information
on those services.4 For example,
a terminal may use the Open Mobile
Alliance Mobile Broadcast (OMA BCAST)
Electronic Service Guide (ESG), although
not all parts are necessary for “unscheduled”
push services.5
The advantage of BCAST-ESG is that
it allows seamless integration of unicast
and broadcast offerings by relating
several access methods to the same service.
Service identifi ers communicated
to the terminal during service discovery
are independent of the actual
access system.
Users can register to available services
once they have discovered them via
the ESG. Registration has two objectives:
it triggers activation of service reception
in the terminal, and it measures the size
of a service’s audience. Popular services
should use MBMS; the rest should use
OMA-push (unicast).
In the case of MBMS, service activation
means a terminal starts to monitor
MICH/MCCH in anticipation of
MBMS transmission sessions. In the
context of OMA-push delivery, the terminal
sends the service identifi ers to
the BM-SC, which uses SMS technology
(that is, OMA-push) to inform the
terminal about new content.6 The terminal
then uses HTTP to retrieve the
content.
Push fi le delivery systems
In the following example, we use a
“Football Breaking News” video service
to illustrate the pros and cons of technical
realizations of a push service. When
a team scores, the service pushes a short
video clip of the goal to interested fans.
A 30-second video clip of reasonable
quality can easily reach 500KB in size.
Multimedia messaging service (MMS)
is often used for content-to-person (C2P)
services. MMS uses SMS (OMA-push)
to notify interested terminals about
new content. A modern MMS installation
with a capacity of 200 messages
per second can deliver a message to
100,000 terminals in less than 10 minutes.
However, being unicast, the delivery
duration is directly related to the
size of the target group. Increasing the
target group size to 200,000 terminals
doubles the delivery duration.
Cell broadcast service (CBS) uses
broadcast radio bearers, but it does not
implement any notifi cation or paging
mechanism. This typically means that
battery drain is high. In addition, CBS
only defi nes the delivery of short (text)
messages (up to a size of 1230 octets or
1.2KB). A typical ringtone, by comparison,
is about 150KB. In summary, CBS is
not suitable for multimedia services.
Modern terminals are often shipped
with podcast clients (unicast only).
Podcast allows the distribution of multimedia
clips. Since podcast push is realized
by a periodic poll of the service status,
the delivery delay depends on the
polling interval. For example, to ensure
that video events are delivered within
ten minutes, the polling interval must
be set to ten minutes or less. The high
polling frequency affects the capacity
of terminals, the radio network, and
the service layer. In the terminal, the
frequent establishment of a dedicated
radio bearer for the short polling message
drains the battery; and in the radio
access network, resources must be allocated
to terminals that are otherwise
idle and can be released only after a predefi
ned period of inactivity. In the service
layer, servers must be able to handle
a constant fl ow of polling messages
from a large number of terminals.
MBMS is ideally suited to realize a massmarket
video goal service. Interested terminals
monitor MICH for the temporary
mobile group identifi er (TMGI) of the video
goal service. This approach does not
consume dedicated radio resources nor
does it increase battery consumption
during idle mode. The duration of time
needed to deliver the video clip when
a team scores depends only on the size
of the clip and the bit rate of the bearer.
Given a 64Kbps MBMS bearer, it typically
takes about 1.5 minutes (including
notifi cation and bearer setup) to deliver
a 500KB video clip regardless of the size
of the target group.
BOX C Podcast on MBMS
Podcast is a popular enabler used by internet applications.
A podcast is an unscheduled push service
— the internet itself does not offer any real push
mechanisms. The push perception is realized by
a continuous, periodic retrieval (polling) of an extended
markup language (XML) document from a
server. RSS-formatted XML documents describe
in a general section the nature of the podcast feed,
followed by the description of one or more content
items. Content items may describe video clips, MP3
fi les, or news headlines. The actual content is not
embedded in the XML document. Instead, an HTTP
link is provided to, say, a video clip (or general enclosure).
In contrast, MBMS provides a real push mechanism.
Terminals continuously monitor the paging
channel for incoming transmissions. MBMS fi le
delivery allows for the transmission of one or more
fi les in a single transmission session. The transmission
session may contain the descriptive XML document
as well as content enclosures, such as video
clips (Figure 4).
RNC receives
session start
Cyclic retransmission
of control info
MICH
MCCH
MTCH
Podcast document and enclosures
XML Video MP3
RNC receives
session stop
FIGURE 4 Podcast on MBMS.
15
ERICSSON REVIEW • 1 2009
Summary
This article presents the general concept
of push fi le services and discusses
the scalability issues of today’s realizations.
All realizations on the internet
and in mobile environments use dedicated
point-to-point (unicast) resources.
This works fi ne, but resources must be
provided for each user. If the popularity
of such services increases, the resources
must increase proportionally.
Pushing content to terminals in the
form of fi les has several advantages:
The content is stored in the terminal’s
memory giving end-users the perception
that service response time is fast.
Operators may either decide to preload
the terminals during non-busy hours and
employ unused network resources or to
use external events to trigger content
push. Football highlights or stock market
updates are examples of eventbased
services that have real-time delivery
requirements.
Operators can use MBMS push services
to complement existing unicast services.
MBMS can be regarded as a capacity
booster for popular services, while unicast
serves the remainder. Service personalization
can be provided by mapping
each push service to a separate
broadcast channel. Terminals monitor
a set of broadcast channels to receive
the wanted information. This way, each
terminal receives its own, personal mix
of content.
Because MBMS is based on broadcast
transmissions in the network and over the
air, transmission duration becomes independent
of the size of the target group.
This is particularly important in fulfi lling
real-time delivery requirements.
Push services generally enable operators
to control when the content is distributed.
In this way, they can push nontime-
critical content whenever resource
usage is low (for example, at night), optimizing
their use of the network.
MBMS features an effective paging
mechanism that can selectively wake
up terminals when a transmission is
about to start. This makes it possible to
have the MBMS push fi le delivery service
continuously active in terminals
without draining their batteries.
Juan-Antonio Ibanez
joined Ericsson Eurolab
Germany in 1999 as system
designer for the GPRS
support nodes. He actively
contributed to the standardization of
the GPRS and UMTS packet-switched
architecture in 3GPP before taking on
the role of technical coordinator within
the Network Integration and Verifi cation
department. In 2006, he moved to
Ericsson in Stockholm, Sweden, where
he holds a senior specialist position in
the area of mobile TV and broadcast
system architecture at Business Unit
Networks. Juan-Antonio holds an M.Sc.
in communication systems from the
Swiss Federal Institute of Technology in
Lausanne, Switzerland.
Aurelie Zanin
joined Ericsson Sweden
in 2005 to work with mobile
TV prototyping at
Ericsson Research. In
2006, she moved to the
development unit in Shanghai, working
on the Ericsson Content Delivery System.
At present, Aurelie serves as system
manager in Shanghai where she
coordinates several technical studies
within the mobile TV area. She holds an
M.Sc. in engineering from Ecole Nationale
Superieure de Physique de Strasbourg,
France.
Miguel Blockstrand
joined Ericsson in 1989 to
work with integration and
verifi cation — he has,
among other things, been
involved in the fi rst release and deployment
of GSM, the fi rst implementation
of the PDC system, and the fi rst introduction
of WCDMA, where he was responsible
for the implementation of a
demonstration service layer for 3G applications.
Miguel has worked with mobile
TV and broadcast technologies
since early 2007, and is currently responsible
for Ericsson’s mobile TV and
broadcast strategies within Business
Unit Networks.
Thorsten Lohmar
received a diploma degree
in electrical engineering
from the University of
Aachen (RWTH) in 1997. In
1998, he joined the Mobile Multimedia
Networks department of Ericsson
Research in Germany, where he has
worked on a variety of aspects relating
to mobile communication systems, including
quality of service, hybrid networking,
and integrating WLAN into cellular
environments. In 2000, he turned
his focus to mobile multicast and broadcast
services. Thorsten has led Ericsson’s
MBMS standardization team since 2003
and the mobile multimedia delivery
research project since 2007.
3G TS 1. 23.246: Multimedia Broadcast/Multicast
Service (MBMS): Architecture and functional
description
2. Ibanez, J.-A., Lohmar, T., Turina, D. and Zanin, A.:
Mobile TV over 3G networks — Service and
enablers evolution. Ericsson Review,
Vol. 85(2008):1, pp. 38-42
3. Bakhuizen, M. and Horn, U.: Mobile broadcast/
multicast in mobile networks. Ericsson Review,
Vol. 82(2005):1, pp. 6-13
4. 3G TS 26.346: Multimedia Broadcast/Multicast
Service (MBMS): Protocols and codecs
5. BCAST-ESG: Service Guide for Mobile
Broadcast Services. Open Mobile Alliance,
OMA-TS-BCAST_Service-Guide-V1_0
6. OMA-push V2.2. www.openmobilealliance.org/
Technical/release_program/push_v2_2.aspx
References
16
ERICSSON REVIEW • 1 2009
Simultaneous delivery of multimedia content