ETSI TR 126 946 V10.0.0 (2011-04)

Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Multimedia Broadcast/Multicast Service (MBMS) user service guidelines (3GPP TR 26.946 version 10.0.0 Release 10)

RTR/TSGS-0426946va00

General Information

• Status: Published
• Publication Date: 19-Apr-2011
• Technical Committee: 3GPP SA 4 - Codec
• Current Stage: 12 - Completion
• Due Date: 20-Apr-2011
• Completion Date: 20-Apr-2011

Standards Content (Sample)

Technical Report
Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS);
LTE;
Multimedia Broadcast/Multicast Service (MBMS)
user service guidelines
(3GPP TR 26.946 version 10.0.0 Release 10)

3GPP TR 26.946 version 10.0.0 Release 10 1 ETSI TR 126 946 V10.0.0 (2011-04)

Reference
RTR/TSGS-0426946va00
Keywords
GSM, LTE, UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 2 ETSI TR 126 946 V10.0.0 (2011-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 3 ETSI TR 126 946 V10.0.0 (2011-04)
Contents
Intellectual Property Rights . 2
Foreword . 2
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Overview . . 9
4.1 Phasing model . 9
4.2 System overview . 10
5 Description of User Service procedures . 11
5.1 User Service Discovery / Announcement . 11
5.2 User Service Initiation / termination procedure . 11
5.3 Session Start / Stop . 12
5.4 Data transmission . 12
5.5 Associated-Delivery procedures . 12
5.5.1 File Repair service . 12
5.5.2 Content reception reporting . 12
6 Delivery methods . 12
6.1 Download delivery method . 12
6.1.1 SDL diagram of the download delivery method for the MBMS UE . 14
6.1.2 Transport of MBMS download data . 16
6.1.3 Repair Symbol Request . 18
6.1.3.1 Option 1: Determination of a minimum set of source symbols for repair . 18
6.1.3.2 Option 2: Determination of a sufficient set of consecutive encoding symbols for repair . 19
6.1.3.3 Maximum Gaussian elimination . 20
6.1.4 On choosing the SDU size . 20
6.1.4.1 Analysis . 21
6.2 Streaming delivery method. 21
7 Usage scenarios . 22
7.1 Service Discovery/Announcement . 22
7.2 MBMS download delivery method . 23
7.2.1 Example: Video clip download service use-case . 23
7.2.1.1 Use-case description. 23
7.2.1.2 Announced Metadata Fragments . 24
7.2.1.3 Reception of a video clip . 24
7.2.1.4 File Repair procedure . 26
7.2.2 The usage of the MBMS session Identity in file download delivery . 28
7.2.2.1 Introduction . 28
7.2.2.2 Example 1: Usage of the Session ID to detect repetition . 28
7.2.2.3 Example 2: Declaration of files of a different MBMS bearer session in the FDT . 29
7.2.2.4 Example 3: Declaration of files of an MBMS bearer session in several FDT Instances . 30
7.3 MBMS streaming delivery method . 31
8 Codecs and formats . 31
Annex A: MBMS Forward Error Correction performance. 33
A.1 Theoretical performance . 33
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 4 ETSI TR 126 946 V10.0.0 (2011-04)
A.2 Simulation results . 33
A.2.1 Simulation conditions and assumptions (UTRAN) . 34
A.2.2 Simulation conditions and assumptions (GERAN) . 35
A.2.3 Simulation results: UTRAN download. 36
A.2.4 Simulation results UTRAN streaming . 37
A.2.5 Simulation results GERAN download . 37
A.2.6 Simulation results GERAN streaming . 38
Annex B: Change history . 39
History . 40

ETSI
3GPP TR 26.946 version 10.0.0 Release 10 5 ETSI TR 126 946 V10.0.0 (2011-04)
Foreword
rd
This Technical Report has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
MBMS user services can be built on top of the MBMS bearer service. The present document describes the usage of the
two delivery methods, which are defined in [6]. The two delivery methods are streaming and download. Examples of
applications using the download delivery method are news and software upgrades. Delivery of live music is an example
of an application using the streaming delivery method.
The objective of the present document is to provide an overview of the MBMS System, and describes how the MBMS
User Services use the MBMS Bearer Services.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 6 ETSI TR 126 946 V10.0.0 (2011-04)
1 Scope
The present document is only informative. In case there are any contradiction between the present document and
26.346, then the 3GPP TS 26.346 takes precedence.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service (MBMS); Stage 1".
[3] 3GPP TS 22.246: "Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1".
[4] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional
description".
[5] 3GPP TS 25.346: "Introduction of the Multimedia Broadcast/Multicast Service (MBMS) in the
Radio Access Network (RAN); Stage 2".
[6] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
[7] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic bootstrapping
architecture".
[8] 3GPP TS 33.246: "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)".
[9] IETF RFC 3926 (October 2004): "FLUTE - File Delivery over Unidirectional Transport", T. Paila,
M. Luby, R. Lehtonen, V. Roca and R. Walsh.
[10] IETF RFC 3450 (December 2002): "Asynchronous Layered Coding (ALC) Protocol Instantiation",
M. Luby, J. Gemmell, L. Vicisano, L. Rizzo and J. Crowcroft.
[11] IETF RFC 3451 (December 2002): "Layered Coding Transport (LCT) Building Block", M. Luby,
J. Gemmell, L. Vicisano, L. Rizzo, M. Handley and J. Crowcroft.
[12] IETF RFC 3452 (December 2002): "Forward Error Correction (FEC) Building Block", M. Luby,
L. Vicisano, J. Gemmell, L. Rizzo, M. Handley and J. Crowcroft.
[13] IETF RFC 3695 (February 2004): "Compact Forward Error Correction (FEC) Schemes", M. Luby
and L. Vicisano.
[14] IETF RFC 2327 (April 1998): "SDP: Session Description Protocol", M. Handley and V. Jacobson.
[15] IETF RFC 2357 (June 1998): "IETF Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", A. Mankin, A. Romanow, S. Bradner and V. Paxson.
[16] IETF RFC 3550 (July 2003): "RTP: A Transport Protocol for Real-Time Applications",
H. Schulzrinne, S. Casner, P. Frederick and V. Jacobson.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 7 ETSI TR 126 946 V10.0.0 (2011-04)
[17] ITU-T Recommendation H.264 (2003): "Advanced video coding for generic audiovisual services"
| ISO/IEC 14496-10:2003: "Information technology - Coding of audio-visual objects -
Part 10: Advanced Video Coding".
[18] IETF RFC 3984 (February 2005): "RTP payload Format for H.264 Video", S. Wenger,
M.M. Hannuksela, T. Stockhammer, M. Westerlund and D. Singer.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
apply.
broadcast service: See 3GPP TS 22.146 [2].
broadcast session: See 3GPP TS 22.146 [2].
Local MBMS Area: area of a MBMS service, where the service content is the same. One MBMS service may have
different content in different local broadcast areas
Multimedia Broadcast/Multicast Service (MBMS): See 3GPP TS 22.146 [2].
MBMS user services: See 3GPP TS 22.246 [3].
MBMS user service discovery/announcement: user service discovery refers to methods for the UE to obtain the list of
available MBMS user services along with information on the user service
The user service announcement refers to methods for the MBMS service provider to make the list of available MBMS
user services along with information on the user service available to the UE.
MBMS user service initiation: MBMS user service initiation refers to the UE mechanism to set up the reception the
MBMS user service data
MBMS delivery method: mechanism used by a MBMS user service to deliver content
There are two MBMS delivery method instances: download and streaming.
MBMS download delivery method: delivery of discrete objects (e.g. files) by means of a MBMS download session
MBMS streaming delivery method: delivery of continuous media (e.g. real-time video) by means of a MBMS
streaming session
MBMS download session: time, protocols and protocol state (i.e. parameters) which define sender and receiver
configuration for the download of content files
MBMS streaming session: time, protocols and protocol state (i.e. parameters) which define sender and receiver
configuration for the streaming of content
multicast joining: See 3GPP TS 22.146 [2].
multicast service: See 3GPP TS 22.146 [2].
multicast session: See 3GPP TS 22.146 [2].
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 8 ETSI TR 126 946 V10.0.0 (2011-04)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ALC Asynchronous Layered Coding
APN Access Point Name
AVC Advanced Video Coding
BM-SC Broadcast-Multicast - Service Centre
CC Congestion Control
ERT Expected Residual Time
ESI Encoding Symbol ID
FDT File Delivery Table
FEC Forward Error Correction
FLUTE File deLivery over Unidirectional Transport
GGSN Gateway GPRS Serving Node
GPRS General Packet Radio Service
IP Internet Protocol
LCT Layered Coding Transport
MBMS Multimedia Broadcast/Multicast Service
MIME Multipurpose Internet Mail Extensions
MS Mobile Station
MSK MBMS Service Key
MTK MBMS Traffic Key
MUK MBMS User Key
PSS Packet Switch Streaming
PTM Point To Multipoint
PTP Point To Point
RTP Real-Time Transport Protocol
SBN Source Block Number
SCT Sender Current Time
SDP Session Description Protocol
TMGI Temporary Mobile Group Identity
TOI Transport Object Identifier
TSI Transport Session Identifier
UDP User Datagram Protocol
UE User Equipment
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML eXtensible Markup Language
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 9 ETSI TR 126 946 V10.0.0 (2011-04)
4 Overview
4.1 Phasing model
MBMBMMSS U UEE PPhhasasee
BM-BM-SSC PhC Phaassee
MBMS MulMBMS Multtiiccasast t BeBearearerr Se Servrvicicee PhaPhasseses
SubSubscriptiscriptionon
UUsseerr S Seerrvviicce Die Dissccoveoverryy
UUsserer Se Serrvvice Dice Diiscoscoveveryry
/ A/ Annnonouncunceemmenentt
// A Annnonoununcemcemeentnt
SSeerrvviicce ane annonoununcceemmeentnt
JoJoiniininngg
UUsseerr Se Serrvviceice in initiitiaattiioonn
SeSessiossionn
((SSeerrvicevice Activa Activattiioonn))
SesSesssion stion startart
StaStarrtt
MBMS nMBMS nootitifificacatitioonn
DaData Reta Recepcepttioionn
DDaattaa T Trranansmsmissiissionon
DDaattaa tra trannssfeferr
SessSession Stion Stopop
SeSessiossionn
UUsser Ser Seerrvviicce e
StStoopp
teterrmmininaattioionn
LeLeaviavinngg
Figure 1: Mapping between MBMS Bearer and User Service phases
This mapping is applicable for the MBMS Broadcast and Multicast Modes.
It is assumed that the MBMS bearer service phases "Session start" and "MBMS notification" are handled autonomously
and without interaction from the receiver application perspective.
It is assumed, that the Session Start phase "triggers" MBMS Notification phase.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 10 ETSI TR 126 946 V10.0.0 (2011-04)
4.2 System overview
Figure 2 gives an overview of functions for MBMS user services based on the MBMS download and the MBMS
streaming delivery methods. The figure includes the MBMS User service provision phases (arrow on the right side of
the figure). The Phase "MBMS User Service activation / deactivation" is an individual phase and is generally triggered
by a user action. The break in the sequence indicates that the service activation phases are independent from the session
start/stop and the data transfer phases. The service provider initiates the establishment of the MBMS User Plane
(Session Start/Stop and the Data Transfer Phases) when there is content to be transmitted.
InInterteraaccttiivvee B Beeararerer, e, ettcc
PPuullll--bbasase (e (ee.gg. v viiaa a P a Poorrttalal))
ee.g. hg. httpttp
LiLisstt o off sseerrvviciceses
MBMS UMBMS Usseerr
SMSMS/S/((CCBSBS))//MMMMSS,, e ettcc
EEnnvveelloope ipe innffoorrmmaattioion n
to sto seelleecctt
SeSerrvviiccee
PPuusshh--bbasase (e (ee.gg. v viia aa a P Poorrttalal))
ininclclududinging MET METAA I Innffoorrmmaattioion n
DisDisccovovereryy
e.e.g.g. S SAAPP//SSDDPP;; F FLLUTUTEE
liklike ae ann < g>
MMBBMMSS B Beareareerr
((iinnccll. M Muulltticicasastt//BBrroadoadccaasstt M Mooddee))
SeSelleeccttioionn
ofof S Seerrvvicicee
OOppttiiononalal
SShharareded S Seeccrret et
UsUserer
((hhttpttp--ddiiggesest-t-AAKKAA))
UUaa iinnteterrffaaccee:: http http--ddiiggesest (t (sseeee 33 33.22.2200))
DeDerriivvaatitionon o off
AuAutthheenntticicatatioion n
PaPasssswwoordrd
((NNoteote,, k keeyy mmaananagemgemeenntt no not agt agrreedeed in in S SAA33 y yeet)t)
((ee.g. B.g. BMM--SSC)C)
BMBM--SSCC
& Se& Servicrvicee
MMeemmberbersshhiipp
SSDDPP--InInfofo IGIGMMPP J Jooiinn / / lleeavavee DDeeffaaultultss B Beeararerer
((NNececesesssaarryy
((sseeee S Seerrvviicce Ae Acctivtivaatitionon
UsUserer
SSAA4 wor4 workk?)?)
SeServicrvicee Ac Acttiivavattiioonn (O(Onnllyy i inn (O(Onnllyy i inn
PPrrococededurure ie inn 2 233.224466))
ReRegigissttrraattiionon & &
/ D/ Deeaacctitivvaatitioonn MBMS MuMBMS Mulltticicaasstt Mo Moddee)) MBMBMMSS Mu Multlticaicasstt M Mooddee))
AAuuththenentiticcaatitionon
MBMSMBMS U UEE & & BS C BS Coonntteexxtt
((ccrreeatatiion /on / d deelleettiioonn))
MBMS MBMS
MBMSMBMS BS BS C Coonntteexxtt
BeBeaarreerr S Seervicrvicee
((aaccttivivaattioion /n / de deacacttiivvaattiionon))
OOpptitiononalal PaPaggee
TTrraannsmsmissiissioonn
CoContrntrooll
RTRTPP
CtCtrrll P Pllaneane CoContrntrooll TriTriggggeerr
StStrereaamm(s(s))
OOpptitiononalal
RTRTPP
StStrereaamm(s(s))
UsUseerr P Pllaneane
MCMC--RReellaayy
MBMS MBMS
&&
UUsserer S Seerrvvicice e
SoSouurrccee
fifillee TTrrananssmmiittetterr
fifillee
MBMS BMBMS Beeaarreerr AAuuththenentiticcaatitionon
((sseeee D Daata Trta Traannssfeferr i inn 2 233.24.2466))
MMuullttiiccasast trt traffaffiicc MMuulltticicasastt tr traffaffiicc UnUniiccasast ot orr M Muullttiiccasast trt traffaffiicc
PosPostt--DDeeliveliverryy
InInterteraaccttiivvee B Beeararerer
PPrrococesesssiinngg
UUnniiccasast trt traaffifficc
SeSerrvveerr
CliClieenntt NeNettwworkork P Prrovoviiddeerr SerServviice Prce Proovviidderer PhPhaseasess

Figure 2: MBMS system overview
The MBMS Bearer Services are embedded in MBMS User Service procedures. The major part of the data is transferred
via the MBMS Bearer Service. MBMS User Services include Associated-Delivery procedures (e.g. file repair) to
augment the original MBMS Bearer sessions. Security functions are incorporated into the overview figure. One
dedicated user authentication procedure is depicted in conjunction with the MBMS Bearer Service Activation procedure
within the Session Establishment phase.
The figure contains client and network functions. Interactions, which are only applicable for the MBMS Multicast
Mode, are marked accordingly.
ETSI
AAppplplicicatiatioonn ( (ee.g.g. ex. exisistitinngg mmeeddiiaa pl playayerer)) an and d
SSeervirviccee E Ennaabblleer (er (e.gg. OM OMA)A)
MBMBMS UMS Usseerr S Seerrvviiccee R Reecceeiivveerr
FEFECC FEFECC
UUDDPP/IP/IP
MBMSMBMS Be Beaarreerr S Seerrvviiccee
ReRecceeiivveerr
FEFECC FEFECC
SeSessssiioonn UUsseerr Se Serrvvicice e ininiittiiaattiioonn UsUserer S Seerrvvicice De Diissccovoveerryy / /
DDaata Trta Traannssmmiissssiionon
SSttaarrt / St / Sttopop
/ ter/ termmiinnatiatioonn AAnnnnounouncceemmeentnt

3GPP TR 26.946 version 10.0.0 Release 10 11 ETSI TR 126 946 V10.0.0 (2011-04)
5 Description of User Service procedures
5.1 User Service Discovery / Announcement
The "User Service Discovery / Announcement" phase provides all necessary information about available services and
needed parameters to become member of a service. User Service Discovery / Announcement mechanism can provide
information on available MBMS User services in pull mode, via the Web or WAP Portals, or in push mode, via SMS or
MBMS Download based User Service.
The User Service Discovery / Announcement phase provides all necessary information for the "Service Activation"
triggered by the UE. The necessary session parameters to configure the service activation are provided according to
Session Description Protocol (SDP) specification (RFC 2327 [14]), which are complemented by additional information
containing additional service parameters. Additionally, Service Discovery includes DRM/security descriptions.
In the case of a size-limited delivery method (e.g. SMS, MMS) being used during the Service Announcement /
Discovery phase, it should be recognized that Service Announcement messages are not of fixed length. Methods of
limiting the size of the message may be adopted. It is suggested that should a size-limited delivery method be selected,
parameters such as URI lengths and the number of Connection data and Media announcement fields should be chosen
appropriately.
5.2 User Service Initiation / termination procedure
For MBMS User service activation, the UE needs to perform a security function and the MBMS Bearer Service
activation procedures. In the case of MBMS Multicast Mode, an IGMP or MLD message is sent via a "default" PDP
context and triggers the creation of the MBMS UE context in various nodes. A MBMS Bearer Service (BS) context is
only created once when the very first MBMS UE context is created in a node. In the case of MBMS Broadcast Mode,
network-side elements establish the MBMS BS context without requiring user initiated messaging. The basic idea
behind these procedures is that several UEs share one single bearer. The IP Multicast address and information for the
MBMS User Service receiving application is given via the MBMS Service Discovery mechanism.
In case the service requires user authentication, security procedures are performed before the MBMS bearer Service
Activation procedure. The "user authentication" procedure is a service optional security procedure. A password is
derived from the shared secret (result of a GBA run) and used in the http-digest security procedure to authenticate the
user (see 3GPP TS 33.220 [7] and 3GPP TS 33.346 [8] for further details).
The "User Authentication & Service Membership" phase provides procedures to register and authenticate users. The
procedures shall follow the security specifications. In the case of MBMS Multicast Mode, this phase may authorize the
service activation request from the UE. This function is present when security procedures like authentication and traffic
encryption are required.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 12 ETSI TR 126 946 V10.0.0 (2011-04)
5.3 Session Start / Stop
According to the 3GPP TS 23.246 [4], the BM-SC controls the activation and the release of the MBMS User plane
(switching of the MBMS BS context between "Active" and "Idle"). The Service Provider might trigger this process on
the availability of new content. The release of the user plane resources depends on the transmission duration of the
content. The transmission duration depends in case of the MBMS Download User Service on the content size, on the
(optional) Forward-Error-Correction (FEC) overhead for error protection and the bitrate of the MBMS bearer.
5.4 Data transmission
The "MBMS User Service Transmitter" contains the MBMS User Service specific transmission protocols. Optionally,
the content is protected by a Forward Error Correction (FEC) code. The traffic is sent using either IP unicast addressing
or IP Multicast addressing via the BM-SC onto the MBMS Bearer Service. Note, the BM-SC is able to take IP Unicast
and IP Multicast traffic as input according to 3GPP TS 23.246 [4].
In case of IP Unicast, the BM-SC is directly addressed by the MBMS User Service Transmitter and relays the traffic to
IP Multicast. In case of IP Multicast, the traffic is forwarded by the BM-SC and the MBMS User Service Transmitter
forwards the data to an IP Multicast group. Additionally the MC-Relay in the BM-SC may perform additional source
authentication procedures to avoid unauthorized traffic entering the Core Network.
The "MBMS User Service Receiver" combines the reception via the MBMS Bearer Service and interactive bearer
services in a controlled way. Optional "Associated-Delivery Processing Servers" are invoked after the actual MBMS
data reception from the clients. A typical associated-delivery procedure is a point-to-point file repair mechanism for
delivering missing data to clients of an MBMS Download session, which perceived packet losses that are unrecoverable
during the broadcast/multicast transmission. The load of the point-to-point repair mechanism may be spread randomly
in time and also across network elements. The MBMS Bearer Service may be configured to provide a constant or
variable bit rate as requested by the MBMS User Service. The MBMS Bearer Service is expected to be service
independent and can be configured by a Network Provider for MBMS Download and MBMS Streaming User Services.
5.5 Associated-Delivery procedures
Associated-delivery procedures may also include the usage of MBMS bearers.
5.5.1 File Repair service
It should be possible for UEs to repair erroneous files, delivery by the download delivery method, by means of repair
request and response operations.
5.5.2 Content reception reporting
It should be however possible for the operator to collect statistical data such as lost frames, assigned resources, bit-rates
achieved, etc. (3GPP TS 22.246 [3]).
6 Delivery methods
6.1 Download delivery method
The MBMS Download Delivery Method allows the error-free transmission of files via the unidirectional MBMS Bearer
Services. The files are "downloaded" and stored in the local files-system of the user equipment. The network triggers
the transmission since the users are registered to the download service. There is no further user request necessary after
the service registration. Files may contain multimedia components or any other binary data. The MBMS Download
Delivery Method allows the transmission of an arbitrary number of files within a single data transfer phase.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 13 ETSI TR 126 946 V10.0.0 (2011-04)
MBMMBMSS DoDowwnnlload Sessoad Sessiion #n on #n MBMS DMBMS Doowwnnlload oad SessSessiioon #n+1n #n+1
FDFDTT ins instt. FDFDTT ins instt.
FilFilee 1 1 FFile 2ile 2 FiFilele 1 1 FFile 2ile 2 FFile 3ile 3
#y#y ##((y+1y+1))
MMBBMMSS B Beearerarer SerServviicce #e #xx
tt
MBMS MBMS DowDownnload Userload User S Seervicervice

Figure 3: Definition of MBMS Download Sessions
Figure 4 is an example of an MBMS User Service based on the Download Delivery Method. The file transmission
events are organized in MBMS Download Sessions. Each session is started with a File Delivery Table (FDT) instance,
which describes in this example each file within the MBMS Download Session in terms of file name and file type
(MIME Content Type). The service operator and the actual service would determine the timing of MBMS Download
Sessions.
Users of the download-based MBMS User Service are not required to recognize the MBMS Downloading process itself,
the reception may be happening completely in background. The user may be only informed about the completion of a
MBMS download and that there is new content available on the terminal. Depending on the service, the MBMS
Download session may require time-critical delivery of content.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 14 ETSI TR 126 946 V10.0.0 (2011-04)
6.1.1 SDL diagram of the download delivery method for the MBMS UE
Figure 4 and figure 5 describes the operation of an MBMS download receiver. The MBMS UE performs the steps
described in the SDL diagram for each received Transport Object. An MBMS FDT may include a number of
transmission objects, each identified by a unique Transmission Object Identifier (TOI).
The SDL identifies four states of the MBMS UE. A brief description of these states follows:
- The "standby" state reflects the state of the MBMS UE, in which MBMS download receiver is initialized and
bound to one specific download channel (IP Multicast Address/Port plus Source Address). Note, the MBMS
bearer is not in active state.
- The "Object Reception" state reflects the state of the MBMS UE, in which the MBMS UE is receiving data for
transport objects. The Transport Object Identifier (TOI) identifies one transport object. The UE may receive FDT
Instance updates related to the object being downloaded, in which case it should update the corresponding
information for that object.
- The "defer file repair" state reflects the state of the MBMS UE, in which the MBMS UE deferring the file
repair request message. Deferring the file repair request message is described in clause 9.3.4 of
3GPP TS26.346 [6].
- The "defer reception reporting" state reflects the state of the MBMS UE, in which the MBMS UE deferring the
file repair request message. Deferring the file repair request message is described in clause 9.4.4 of
3GPP TS 26.346 [6].
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 15 ETSI TR 126 946 V10.0.0 (2011-04)
Standby
FDT Instance for
Data packet
object received
received
Object
Reception
Packet with A-flag
Data Packet FDT Instance
or B-flag
Received timer expired
Received.
Consume Data Consume Data
No Yes
P-t-P Repair
Mechanisms defined?
No Yes
Enough data to
Yes No
Enough data to
recover Object?
recover Object?
Select Repair Server
and Start Backoff Timer
Yes No
P-t-M Repair
Mechanisms defined?
defer file
repair
Indication of
Backoff Timer
P-t-M Repair
Expired
Session
Activate MBMS
P-t-P Repair
bearer
request
(if necessary)
Yes No
Redirection to P-t-M
repair Session received?
Server not available,
No Yes
redirection to other
server, error case?
Reception
Receive
Reporting
repair data
Yes No
HTTP
Data packet
Enough data to
Timeout
received
recover Object?
Consume Data
Figure 4: SDL diagram for the file download process of the MBMS UE
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 16 ETSI TR 126 946 V10.0.0 (2011-04)
Reception
Reporting
No Yes
Send a statistical
Report?
Yes No
Reception Reporting
defined?
Select Reception
Reporting and Start
Backoff Timer
Yes No
Statistical Reporting?
defer
reception
reporting
Determine Randomly
whether to send a
report.
Yes No
Complete File
Backoff Timer Reception?
Expired
Send
Reception
Report
End of
Reception
NOTE: Statistical Reports for download are only sent, if either a "Close session flag" (see clause 7.2.6) is received
or a the "time to" value of the session description (from "t=" in SDP) is reached or a UE decides to exit the
session.
Figure 5: SDL diagram for the reception reporting of the file download process of the MBMS UE
6.1.2 Transport of MBMS download data
This clause explains briefly how files are constructed for and transported during a FLUTE session.
The BM-SC takes a file, e.g. a video clip or a still image, which is used as the transport object for FLUTE (see figure 6).
The BM-SC constructs source block by breaking the file into contiguous portions of approximately equal size. Each
source block is broken into source symbols. One or more encoding symbols are carried as the payload of a FLUTE
packet, thus the encoding symbol size must divide the FLUTE packet size. The target FLUTE packet size is configured
by the BM-SC and, together with the file size, is used to determine the encoding symbol length. Note that when FEC is
used with smaller files it is often necessary to include several symbols in each FLUTE packet. This means that the
FLUTE packets cannot be fixed at a specific arbitrary size by the operator, because they must be a multiple of the
number of symbols required per packet in size. Based on the transport object length, the encoding symbol length and the
maximum source block length, FLUTE calculates the source block structure (i.e., the number of source blocks and their
length).
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 17 ETSI TR 126 946 V10.0.0 (2011-04)
Constructing FLUTE Packets
1010101101 00000
FLUTE/
=
0000000000 11111
1111111111 UDP/
11111 Header 11111
0110010110 IP
packet
transport source encoding
file FLUTE packet
object block(s) symbol(s)
Figure 6: Constructing FLUTE packets
The BM-SC communicates the transport object length, the encoding symbol length and the file size to the receivers
within the FLUTE session transmission. Thus the receiver can also calculate the source block structure in advance of
receiving a file.
The FLUTE packet is constructed from FLUTE header and payload containing one or more encoding symbols.
The distinction between file and transport object is that the file is the object provided to the BM-SC and played-out or
stored at the MBMS UE. Within the scope of FLUTE sessions, content encoding may be used, for instance to compress
the file with gzip for delivery. In the presence of FLUTE session content encoding, the file and the transport object will
be different binary objects, and in the absence of content encoding the transport object will be identical to the file. Any
symbol calculations (including FEC) are performed on transport objects.
EXAMPLE 1: File size: 1 MB (1 048 576 bytes)
Target packet size (payload): 500 bytes
Maximum source symbols: 8 192 (defined by FEC code)
Minimum source block target: 1 024 (recommended by FEC code)
Symbol alignment parameter: 4 bytes
Based on the recommendations of 3GPP TS 26.346 [6], clause B.3.4.1, then the above parameters would lead to
1 symbol of 500 bytes per packet and the file would be treated as a single source block with 2 098 symbols.
EXAMPLE 2: File size: 16 MB (16 777 216 bytes)
Target packet size (payload): 250 bytes
Maximum source symbols: 8 192 (defined by FEC code)
Minimum source block target: 1 024 (recommended by FEC code)
Symbol alignment parameter: 4 bytes
This would result in 1 symbol of 248 bytes per packet and the file being broken into 9 source blocks, 2 source blocks
will have size 7616 symbols and the remaining 7 will have size 7 517 symbols.
EXAMPLE 3: File size: 256 KB (262 144 bytes)
Target packet size (payload): 500 bytes
Maximum source symbols: 8 192 (defined by FEC code)
Minimum source block target: 1 024 (recommended by FEC code)
Symbol alignment parameter: 4 bytes
This would result in 2 symbols of 248 bytes each per packet and the file being treated as a single source block of
1 058 symbols.
ETSI
3GPP TR 26.946 version 10.0.0 Release 10 18 ETSI TR 126 946 V10.0.0 (2011-04)
6.1.3 Repair Symbol Request
In 3GPP TS 26.346 [6], clause 9.3.3, on "Identification of Missing Data from an MBMS Download", it is stated that an
MBMS UE is able to identify the ESI values of required source and/or repair symbols that would complete the
reconstruction of a source block (of a file) and that the corresponding symbols can be requested from the server.
Especially for the case when MBMS FEC scheme is used, the MBMS client should either:
1. identify a minimal set of source symbols that, combined with the already received symbols, allow the MBMS
FEC decoder to recover the file; or
2. identify a number, r, of symbols such that reception of r previously non-received symbols will allow the MBMS
FEC decoder to recover the file.
Option 1 (clause 6.1.3.1) is more appropriate if only very few symbols are lost as the signalling of only very few
symbols is more efficient. In contrast, option 2 (clause 6.1.3.3) is appropriate in the case where a significant amount of
symbols are not available. To minimize the uplink traffic, sending only the initial symbol ESI and the amount of
requested consecutive symbols is more appropriate. The decision which option to use is up to the MBMS client.
For both options, example algorithms to determine a suitable set of repair symbols are presented in the following. For
option 1 the derivation of a minimum set of source symbols and for option 2 the derivation of a sufficient set of
consecutive repair symbols is described based on the initial matrix A as constructed in 3GPP TS 26.346 [6],
clause C.2.1. In both cases, a maximum Gaussian elimination as described below is performed on A. Then, the matrix is
virtually extended by those rows which, for option 1, represent the missing source symbols and, for option 2, a set of
consecutive repair symbols. Maximum Gaussian elimination is again performed on this new matrix. With appropriate
tracking of row and column labels this process allows finding an appropriate set of ESIs for repair of the source block as
requested in 3GPP TS 26.346 [6], clause 9.3.3. Note that almost all parts of described algorithms can be included in the
regular FEC decoding process as specified in annex C such that the decoding complexity is minimized. Nevertheless,
the description of the following algorithms is based on the unmodified matrix A.
6.1.3.1 Option 1: Determination of a minimum set of source symbols for repair
The following algorithm o
...