2013 Sixth International Workshop on Selected Topics in Mobile and Wireless Computing

Relative Time based MBSFN Content

synchronization
JunHyuk Song , Ishwinder Singh, Rick Phung, HanSeok Kim, JaeJin Lim, DaejoongKim
Samsung

Electronics
junhyuk.song, hs365.kim, daejoong, jjlim@samsung.com
Qualcomm Technologies Inc.
isingh@qti.qualcomm.com
Aritsu Inc.
rick phung@anritsu.com@aritsu.com
Abstract
In LTE, enhanced MBMS (eMBMS) allows the combining
of MBMS transmission from tightly synchronized cells,
in a technique known as Multimedia Broadcast Single
Frequency Network (MBSFN). In MBSFN transmission,
all eNodeBs in a given MBSFN area must have the
radio frames transmitted with the same physical symbol
timing. With use of the Extended Cyclic Prex and the
Synchronization Protocol(SYNC) running between the BMSC (Broadcast/Multicast Service Center) and eNB(eNodeB),
it is possible to synchronize content transmission from
multiple eNBs. The synchronization protocol layer in BMSC shall set Time Stamp value that indicates the relative
time value of the synchronization sequence. This paper
investigates how eNodeB can ensure synchronized MBSFN
content transmission with the use of common relative time
reference.
Keywords: LTE, eMBMS, SYNC.
I. I NTRODUCTION
The introduction of the smart phones have made Internet access ubiquitous on mobile devices. Nowadays more users surf
the web and watch multimedia content using mobile devices
than ever before. According to a Cisco Visual Networking
Index (VNI) Global Mobile Data Trafc Forecast for 2011
to 2016 [1], mobile video trafc would make up for more
than 50% of all mobile data trafc. The mobile entertainment
market is expected to grow exponentially in the next four
years. However, due to the very nature of Unicast transmission
namely, the inefcient bidirectional point to point transmission
between each of the users and the network, most of the cellular
operators have very limited streaming service options. This
led to the development of the Broadcast/Multicast service
over cellular network. In LTE, enhanced MBMS (eMBMS)
denes two broadcast transmission schemes: Single-cell transmission and Multicast Broadcast Single Frequency Network
transmission (MBSFN). MBSFN allows combining of MBMS
transmissions from tightly time-synchronized cells by using
the same radio conguration in each of the cells with use of
Extended Cyclic Prex. In order to achieve MBSFN transmission in LTE, Multi-cell/Multicast Coordination Entity (MCE),
978-1-4799-0428-0/13/$31.00 2013 IEEE

as well as the time synchronization protocol running between

eNB and BM-SC (Broadcast Multicast Service Center) is
introduced. The Synchronization protocol is an additional
layer above the Transport protocol to synchronize the delivery
of eMBMS content from multiple eNBs by reordering and
detecting lost SYNC packets.
The real challenge, however is that the physical symbols
are required to be aligned among eNBs located in the same
MBSFN area. The MBSFN area as dened in TS 36.300
[2], is an area in which cells transmit the same Multimedia
content with same radio conguration controlled by a single
MCE. Like other data trafc types in the IP network, the
backhaul trafc in LTE is very likely to experience packet
delay, jitter and packet loss. If any radio frame contains
slightly time delayed data in the same MBSFN area, it acts
as an interference to the UE. The physical symbol level
synchronization for eMBMS is left to the eNB implementation,
although the requirement is explicitly specied in [2]. Thus,
in order to transmit identical radio frames simultaneously,
the eNBs must be congured with the same RLC/MAC/PHY
conguration (assuming the same eMBMS service), and have
their radio frame timing synchronized.
This paper considers that eNB and BM-SC do not share
any common Absolute time reference. Instead, we propose that
they share a common Relative time reference to schedule MCH
(Multicast Channel). This is in contrast with past work [3],
which had only considered the use of absolute time reference.
The main result of this paper connects MCCH (Multicast
Control Channel) modication period to the temporal point
where physical symbol level synchronization is taking place.
We show that with the given MCCH modication period, and
the newly proposed Reference SFN (R SFN) synchronization
algorithm provides an efcient signaling method for temporal SFN (System Frame Number) alignment among multiple
eNBs.
II. E MBMS OVERVIEW
In this section, we briey introduce eMBMS architecture
and its related functions [2]. As depicted in Fig 1, MBSFN
requires new network entities to enable MBSFN transmission:
BM-SC, MBMS Gateway, and MCE. BM-SC acts as a proxy

285

Fig. 2.
Fig. 1.

Channel Structure

eMBMS Centralized MCE architecture

content server. It also manages the eMBMS subscriptions, service announcement, sessions control, SYNC protocol, MBMS
security, point to point retransmission, and AL-FEC (Application Level Forward Error Correction). MBMS gateway is
responsible for multicast IP address allocation and session
management. The MBMS gateway receives MBMS content
from BM-SC and then forwards MBMS service trafc to
the eNBs over IP multicast network. The MCE, acting as a
MBMS scheduler, allocates radio resources, performs session
admission control, and manages the MBMS services. Therefore, the scheduling of MBSFN transmission is performed
through a MCE. When MCE receives a Session Start request
from MME, it runs Session Admission Control function to
determine radio resource availability. Only if there are enough
radio resources available will the MCE allocate the required
radio frames. Besides the function of the new entities, eNBs
will also need to support some eMBMS related MAC and PHY
layer features, including 15 kHz sub-carrier spacing, Extended
CP, MBSFN Reference signal, PMCH Physical channel, MCH
Transport channel, MTCH/MCCH Logical channels, SIB2 and
SIB 13 System information, PDCCH with M-RNTI (MBMS
Radio Network Temporary Identier), RLC-UM mode, SYNC
protocol, and M2AP (M2 Application Part) Interface [8]. In
eMBMS system, a single eNB is served by a single MCE at a
time, although eNB can receive MBMS IP multicast packets
from multiple MBMS gateways in IP multicast Routing Tree.
A. MBMS channel description
The logical, transport, and physical channels associated
with eMBMS are depicted in Fig 2. LTE eMBMS requires
implementation of two new logical channels, Multicast Trafc
Channel (MTCH) and Multicast Control Channel (MCCH).
Both the MCCH and the MTCH logical channels are multiplexed to the Multicast Channel (MCH) transport channel. The
eNB performs MAC-level multiplexing for different MTCHs
to be transmitted on a single MCH. Multiple eMBMS services
can therefore be transmitted using a single MCH (because up
to 29 MTCHs can be multiplexed on one MCH instance),
provided that they use the same MBSFN area. At the Physical
Layer up to 15 MCH channels per MBSFN area can be time
multiplexed to a Physical Multicast Channel (PMCH) within
Common Scheduling Allocation Period (CSAP) interval.
B. MBSFN transmission
The delay spread is generated by different multipaths
between the transmitter and the receiver when those paths

have different delays. It causes Intersymbol Interference (ISI),

which can cause an irreducible error oor. However, when the
multiple paths of the signals with different delays are received
by the UE, the receiver may be able to combine them as a
single signal with different path delays. It is possible, if and
only if, the signals are from tightly time synchronized cells,
and are received within the CP (Cyclic Prex) at the beginning
of the symbol.
In MBSFN operation, given the CP length of 16.7s ensures
the signals arrive within the CP, the UE Receiver treats these
different signals as multi-path components of a Single Cell
transmission. The use of the Extended CP ensures that the signals remain within the CP at the UE, and thus, reducing intercell interference by using additional symbols for Extended CP.
The gain from MBSFN operation is signicant especially at
the cell edge, where the signals from edge cells causes ISI [4].
C. MBMS synchronization protocol
SYNC protocol dened in 3GPP TS 25.446 specication
ensures the ordered delivery of the MBMS content from BMSC to eNB. If there is a delay in transmission of MBMS
service PDUs from any eNBs in a MBSFN Area, it will act
as an interference. SYNC protocol denes a train of SYNC
sequences in a SYNC period. Each SYNC PDU contains
a time stamp that indicates the start time of the SYNC
sequence. The SYNC period provides the time reference for
the indication of the start time of each SYNC sequence. The
value range of the SYNC period is 60000 units of 10ms
which is 600 seconds. In Fig 3 example, it shows how SYNC
sequences are repeated in one SYNC period boundary. BM-SC
receives the rst packet at 10:01:00 in Hours:minutes:seconds
UTC time format.

Fig. 3.

SYNC Period

III. MBSFN C ONTENT SYNCHRONIZATION

There are generally two methods of achieving physical
symbol level synchronization among eNBs: (1) Using synchronized backhaul protocol with Absolute time based timestamp.

286

(2) Using synchronized backhaul protocol with Relative time

based time stamp. In this section, we describe how MBSFN content synchronization can be achieved among multiple
eNBs.

Fig. 4.

only indicates the relative time to start transmission from

the reference time. Finding the common time reference and
its actual transmission time among eNBs is left to eNB
implementation and may be proprietary to the Infrastructurevendors.
BM-SC should be able to estimate the propagation and the
processing delay, and set the time stamp as a delay parameter.
Upon reception of new chunk of data from DASH [7] encoder,
BM-SC shall increase the time stamp of SYNC sequence
by the length of the synchronization sequence. Each time
stamp only denotes a single synchronization sequence length.
If the Time stamp is set to 32, for example, it means SYNC
PDUs should complete its transmission within 320 ms period
from the reference time. The reference time to start MBSFN
transmission among multiple eNBs is set by the MCE, and it is
then signaled to the eNB. We give details of how to determine
the Reference transmission time in Section IV.
IV. R EFERENCE SFN ESTIMATION

Absolute timestamp

A. Absolute time based MBSFN content synchronization

Recently several methods have been proposed to use synchronized backhaul protocol to align MBSFN physical resource blocks in a MBSFN area. Those approaches set SYNC
time stamp by shared Absolute reference time to assist the
eNB in determining the MBSFN transmission timing [3]. The
BM-SC sets the time stamp of all SYNC packets based on
absolute reference time with consideration of the propagation
and processing delay from the BM-SC to the furthermost
eNB. Thus eNB and BM-SC share the common absolute time
reference with use of the GPS, SyncE [5], or IEEE 1588v2 [6].
Fig 4 illustrates a GPS Absolute Time based synchronization
example, and it shows that the eNB and BM-SC receive the
same Time of the Day in seconds from the GPS signal. Thus
every even seconds they are resynchronized. This approach
can provide guaranteed common reference time between eNB
and the BM-SC, however the main drawback of this approach
is the accessibility of GPS receiver in EPC (Evolved Packet
Core). Typically BM-SC is an Application server located in the
Core network and eNB is part of the Radio Access Network
(RAN). This Network Topology may require separate Time
reference source at different Network entities. The absolute
time reference requirement in core network may prove as a
physical deployment limitation in some scenarios. Operators
may require additional logistics to acquire and manage space
for GPS antenna accessibility towards having absolute time
reference for different network entities. Therefore, the absolute
time reference based schemes may have deployment limitations in certain commercial eMBMS deployment scenarios.
B. Relative time based MBSFN content synchronization
Unlike the Absolute reference time based MBSFN Content
synchronization solution, the Relative time based MBSFN
Content synchronization does not require the same Absolute
time reference between eNB and the BM-SC. The time stamp

In LTE, 10 ms system clock has numbers between 0 and

1023 and these numbers are called System Frame Number
(SFN). The estimation of the exact SFN, when MBSFN
transmission should take place from the relative time is
quite challenging. It requires tight physical symbol level
synchronization, coordination between eNB and MCE, and
interworking between RLC and MAC scheduler. In this paper,
we dene the Reference SFN, denoted as R SF N . It is the
SFN where MCH scheduling begins for MBSFN transmission
for each PMCH. R SF N is synchronized with reasonable
margin at physical symbol level among eNBs in the same
MBSFN area. This section starts with a brief description of
the MCCH modication procedure, the eMBMS session start
call procedure, the reference SFN algorithm, and a description
of the MBSFN MAC scheduling. We do not address the RLC
and MAC specic implementation details in this paper.
A. MCCH modication Procedures
When the network changes its eMBMS session information,
such as adding a new eMBMS session, the MCCH information should be updated accordingly. System information
normally changes only at specic radio frames whose System
Frame Number is given by SF N mod N = 0, where N
is congurable and denes the period between two radio
frames at which a change may occur, also known as the
MCCH modication period. Prior to performing a change of
the system information, the E-UTRAN noties the UEs by
means of a notication over the PDCCH. A UE interested in
receiving MBMS service acquires the new MCCH information
immediately from the start of the next modication period.
These MCCH modication processes are illustrated in Fig 5.
One interesting fact to note here is that MCCH modication
period is required to be synchronized among all eNBs in a
given MBSFN area. Moreover MCE may be located in the
Access network where the time synchronization is relatively
easier compared to BM-SC located in EPC. The relative
time based MBSFN Content synchronization sets the R SF N

287

1.
2.
3.
4.
Fig. 5.

3 t2 )
Compute = (t1 t0)+(t
2
Select n = M AX{1 , ...n}
n +
Compute R SF Nn =  SF Nn +


Return (R SF Nn )

MCCH Modication Period

to the beginning of the MCCH modication period. Upon

receiving SYNC packets from the BM-SC, eNB checks the
included time stamp in order to align R SF N and wait for
the next available MCH scheduling period for the transmission.
The waiting time for each eNB may be different depending
on the backhaul delay. Thus 512 RF(5120 ms) modication
period which is approximately 5 seconds gives enough time
for eNBs to synchronize while buffering eMBMS packets from
the BM-SC.
B. Session Start Procedure
When eMBMS Service start is impending, BM-SC sends
a Session Start Request message to MCE through MBMSGW and MME (Fig 6). It is to indicate the start of the
eMBMS service and to provide the session parameters, such
as QoS, estimated session duration, and estimated remaining
time before the session start (MinTimeToDataTransfer). Then,
MCE begins to allocate radio resources per the requested
GBR (Guaranteed Bit Rate) by scheduling Common Subframe
Allocation (CSA) patterns, MCH Subframe Allocation (MSA)
patterns, Modulation & Coding Scheme (MCS) for both Trafc
and Signaling channels. This radio conguration information
is sent to eNB over MBMS SCHEDULING INFORMATION
and M2 MBMS SESSION START message [8]. These messages shall be sent to every eNB belonging to the same
MBSFN area in a time synchronized manner.

When the scheduled eMBMS session is broadcasted, BMSC must communicate its start time of the transmission in
advance to the involved eMBMS network entities. This is
because it requires some time to allocate radio resources
and synchronize considerably many eNBs. This process is a
time critical operation, and it must complete within a given
MinTimeToDataTransfer time from BM-SC. (Note: Theoretically there could be up to 65536 M2 connections between
eNB and MCE, and only constraints are MCEs processing
capacity, backhaul and SCTP (Stream Control Transmission
Protocol) [9] connection processing delay. Therefore when
MCE computes the Reference SFN in advance, it must take
MinTimeToDataTransfer time into consideration. MinTimeToDataTransfer is the minimum time between the transmission
of the MBMS SESSION START REQUEST to the MCE and
the actual start of the data transfer. By reading the contents of
M3 Session Start message from BM-SC through MME, MCE
can obtain the MinTimeToDataTransfer. Assuming that every
eNB in the same Synchronization area [2] have a synchronized
radio frame timing, MCE can keep track of the same SFN as
eNB within a small tolerance.
To synchronize its R SF N with remotely located eNB,
MCE may compute the transmission delay offset. In general,
it might be necessary to perform the sampling at large number
of times to compute relative frequencies, and use these as
estimates of the round trip time delay offset. Assume that t0
is the time of the request packet transmission, t1 is the time
of the request packet reception, t2 is the time of the response
packet transmission and t3 is the time of the response packet
reception. Then (1) yields the approximated transmission
Delay offset.
=

Fig. 6.

(t1 t0 ) + (t3 t2 )
2

(1)

By sampling physically furthermost located eNB and nding its maximum, n (2), we can determine the MBSFN
area coverage. Note: It is possible to tune the MBSFN area
coverage more or less aggressively and, therefore trade-off
immediate video play with slightly time delayed video play
for larger service coverage and vice versa.

eMBMS session start callow

C. Reference SFN Algorithm

n = M AX{1 , ...n}

Reference SFN Algorithm

Input

MinTimeToDataTransfer:
Delay offset: n
Current SFN SF Nn
MCCH modication period

Output

Reference SFN R SF Nn

(2)

Lets denote MinTimeToDataTransfer as and MCCH

Modication Period as . Assume that MCE keeps track of
the SFN timing of eNB with marginal delay offset n , we
can denote estimated SFN as SF Nn + n .

288

R SF Nn = 

SF Nn + n +


(3)

In (3), SF Nn + n + denotes the minimum change of

SFN caused by the session preparation delay. Its granularity
is mostly determined by which is determined by the trafc
type. Now dividing by and ceiling it, we can set R SF N
within the duration of MCCH modication period boundary
which is synchronized among every eNB in a MBSFN area.
MCE shall send the computed R SF Nn to eNBs in the
MCCH Update Time parameter of the M2 Session Start
message.
D. Synchronized MCH Scheduling Procedure
By reading the contents of M2 Session start message,
eNB can easily compute next MCCH modication period and
the MBSFN transmission SFN by computing (R SF N
M CCH M odification P eriod + SY N C T ime Stamp).
Fig 7 is an example of MCH scheduling of MBMS during
640 ms with the given Reference SFN, 1536. When eMBMS
session begins, the trafc is encapsulated in SYNC PDUs
and transmitted to eNB from the BM-SC. The SYNC Frame
handler in eNB buffers the SYNC PDUs and reorders the
packets according to packet number and SYNC Time stamp
in SYNC header so that data associated with each sequence is
transmitted consecutively. When the reordering of each SYNC
sequence and checksum check are complete, SYNC PDUs are
sent to RLC with SYNC time stamp. The RLC buffers SYNC
PDUs until the right moment, when Reference SFN and MSP
(MCH Scheduling Period) are elapsed. In other words, data
transmission takes place when the expected transmission SFN
comes up within the next available MSP. This is because the
Physical Multicast Channel, PMCH can only be transmitted
during the pattern of radio frames which satisfy (4), and
MAC denes the allocated subframes for the PMCH scheduled
during the MSP.

SYNC sequence in that particular time frame, and continue to

transmit from the next SYNC sequence.
V. T EST R ESULTS
This section provides the Test results of Relative Time based
MBSFN Content synchronization presented in the previous
paragraphs. We tested with 15 PMCHs that were open sequentially between two eNBs, which were connected to the same
MCE and keep track of the RLC/MAC scheduling processes.
The parameters used in our Lab tests are presented in Table I.
TABLE I
L AB TEST SETTINGS

Parameter
3gpp spec.
Access Technology
Carrier Frequency
Cellular Layout
System Bandwidth
Extended Cyclic prex Duration
PDCCH Symbol Length
Data MCS
Signaling MCS
GBR
MCCH Modication Period
Common SF Alloc Period
MCH Scheduling Period
Allocated subframe number
Video Encoding
Transport Coding
Video Title

Value
Release 9
TDD
2.6 GHz
6 cell sites
20 MHz
16.7s
2
13
7
1.5 Mbps
512 RF
64 RF
640 ms
3, 4, 8, 9
H.264 AVC
DASH/FLUTE
Big Buck Bunny

Table II. shows the sample of RLC log that we captured during the Test. It shows that RLC kept track of MCH scheduling
period window between lower boundary (highlighted in red)
and upper boundary (highlighted in magenta), and ushed its
buffer accordingly. Yellow highlighted 1536 is the Reference
SFN, Green highlighted 64 is the SYNC PDU time stamp, and
1431 is the current system time.
TABLE II
RLC DATA LOG SAMPLE

Fig. 7.

DROP[0][ 1536 - 64 ]-[1431- 1600 - 1664 ]-74576-0-8185

DROP[0][ 1536 - 64 ]-[1431- 1600 - 1664 ]-74576-0-8186
DROP[0][ 1536 - 64 ]-[1431- 1600 - 1664 ]-74576-0-8187

Time synchronized MCH scheduling

SF N

mod RF AP = Offset

(4)

where, the Radio Frame Allocation Period (RFAP) can be a

range of values 1, 2, 4, 8, 16, or 32, and offset can be a value
between 0 through 7. It is important for RLC to keep track
of SYNC Time stamp and Reference SFN alignment through
the end of the session. This is because in case of a missing
SYNC PDU in the SYNC sequence, RLC should mute that

Figure 8, shows lower boundary and upper boundary of

RLC SYNC windows per each MCH. Each boundary is
exactly separated by MSP, in this case 640 ms. The lower
boundary is computed from Reference SFN and the SYNC
PDU Time stamp and upper boundary is computed from
lower boundary plus MSP duration. The initial Test results
showed a uctuating bit rate of Multimedia trafc that lead
to a large segment of video trafc being dropped at the end

289

RLC buffer flushing boundary

Reference Time based MBSFN Content synchronization, and

we evaluated the shortcomings of the Absolute Reference
Time approach. The Relative Reference Time based MBSFN
Content Synchronization scheme does not require Absolute
Time Reference source between the BM-SC and the eNB and
thus removes the requirement of maintaining separate Time
alignment sources at the eNB and the BM-SC. Moreover in
a Commercial eMBMS deployment, Radio Access Network
(RAN) and BM-SC might be provided by Infrastructurevendors which may lead to possible Interoperability issues.
The Relative Reference Time based approach will likely lead
to a more cost effective and simpler deployment solution
with a very minimal performance impact when compared
to Absolute Time based MBSFN Content synchronization
approach.
The step that follows this work could be the MBMS operation on demand which is currently Rel.12 Work item [12]. This
feature anticipates the user interest for the specic content,
and allows switching back and forth between Unicast and
Broadcast modes of Transmission. Additionally, we propose
that shorter MCCH modication period should be considered.
Our research found that use of the shorter MCCH modication
period, such as 256 RF, 128 RF, and 64 RF, is possible
and should be specied in the 3GPP specications. With
the current specications, in the worst case scenario, RLC
might buffer SYNC packets for the complete 512 RF MCCH
Modication period. The shorter MCCH modication period
would reduce the initial video lag time, in case of on demand
eMBMS service.

1740
Lower SYNC boundary
Upper SYNC boundary
1720

10ms System SFN

1700

1680

1660

1640

1620

1600

20

40

Fig. 8.

60
80
10ms time clock

100

120

140

RLC buffer SYNC boundary

Fig. 9.

eMBMS video clip

of MCH Scheduling Period. This was because of the bursty

Trafc characteristics [10] of DASH encoded H.264 Media.
To mitigate the effect of the uctuating bit rate, we enforced
BM-SC Link buffering for MPEG DASH data segments. With
link buffering enabled, BM-SC transmitted SYNC sequences
at a constant bit rate. After smoothening out the Trafc
pattern from BM-SC, the Test results showed the RLC/MAC
scheduling per MCH to be working as per the proposed
Reference SFN algorithm. Approximately 1% Packet loss was
observed due to RLC Fragmentation across MSP boundaries.
Figure 9, illustrates the reception of a video clip using
eMBMS Service. We visually evaluated the overall quality of
the video clip and in the start of each session, approximately
35 seconds of Video lag time was observed. This was due to
512 RF (5120 ms) MCCH modication period since the eNBs
must synchronize Reference SFN with MCCH modication
period in the beginning of the session. Besides that, the overall
quality of the eMBMS Service was observed to be as good as
Unicast Service, since the eMBMS session was GBR trafc
and there was no FLUTE [11] packet loss detected.
VI. C ONCLUSION
The main improvement brought by the use of MBSFN in
eMBMS is the improved Spectral Efciency by reducing ISI.
This achievement is expected to act as a catalyst for wide
deployment of eMBMS. In this paper, we proposed Relative

R EFERENCES
[1] Cisco
Visual
Networking
Index
(VNI)
Global
Mobile
Data Trafc Forecast for 2011 to 2016, Feb. 2012.
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/
ns705/ns827/white paper c11-520862.pdf
[2] 3GPP TS 36.300 V10.0.0 Technical Specication Group Services and
System Aspects; Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network (E-URTAN);
Overall description; Dec 2011.
[3] H Wang, H Vandervelde, S Kim, LTE MBMS SYNC Protocol for
support Synchronization of Content, IEEE Preceeding of ICCTA2009
[4] 3GPP R1-071049, Spectral efciency comparison of possible MBMS
transmission schemes: Additional Results, 2007
[5] ITU-T G.8262 : Timing characteristics of a synchronous Ethernet
equipment slave clock. International Telecommunication Union. July
2010.
[6] IEEE 1588 Systems. National Institute of Standards and Technology
(NIST)
[7] 3GPP TS 22.247 V10.0.0 Transparent end-to-end Packet-switched
Streaming Service (PSS); Progressive Download and Dynamic Adaptive
Streaming over HTTP (3GP-DASH) Dec 2011
[8] 3GPP TS 36.443 V10.0.0 Technical Specication Group Services and
System Aspects; M2 Application Protocol (M2AP) Dec 2011
[9] IETF, RFC 4960 Stream Control Transmission Protocol Sept 2007
[10] G. Van der Auwera, P.T. David, and M. Reisslein, Trafc Characteristics
of H.264/AVC Variable Bit Rate Video, Arizona State University,
Technical Report, March 2007.
[11] IETF, RFC 6726 File Delivery over Unidirectional Transport Sept 2012
[12] 3GPP MBMS operation on demand work item description
http://www.3gpp.org/ftp/Specs/html-info../WID-history590243.htm

290