July 2014

Enhanced Multimedia
Broadcast Multicast Service
(eMBMS)

TOPICS
MBMS and eMBMS
Why eMBMS?
What is MBMS and eMBMS?
eMBMS - Logical Architecture, Services and Protocols
MBSFN - Multicast Broadcast Single Frequency Network
eMBMS - Channels, Signals and Procedures
Release 10, 11 and 12 Enhancements
eMBMS Testing
References




MBMS and eMBMS


Why eMBMS?
4
The number of mobile devices is increasing rapidly
Most people moving to smartphones in developed and developing markets
This is causing the currently observed traffic volume explosion
Results in increased congestion in the network
Already ~50% of traffic is video, predicted increase to ~70% by 2016



Why eMBMS?
5
Operators need solutions allowing them to decrease network
traffic while continuing to provide a similar level of service
to customers
One of these solutions is MBMS/eMBMS
What is MBMS?
6
Content distribution: Unicast approach
Cell
Cell
Multicast / Broadcast approach:
Multimedia Broadcast/Multicast Service
Point-to-multipoint transmission - all UEs
simultaneously receive the same
transmission

The same transmission
can also be received from
multiple cells
MBMS was first defined in 3GPP UMTS Release 6
Cell
Content provider
X kbps
MBMS Usage
7

Venue/region specific or nation-wide broadcast
Mobile TV, sports events, local events/news, breaking news,
Streaming for situational awareness
Disaster awareness, event coordination,
Emergency push-to-talk
One-to-many emergency communication
File delivery for non real time services
Advertisements, vouchers, news updates, SW upgrades
What is eMBMS?
8
eMBMS (Enhanced MBMS) is the LTE version of MBMS
Some work done in Rel8, but full functionality available first in Rel9
Only broadcast available
Designed to work with both FDD and TDD
Further enhancements in subsequent releases




eMBMS provides functionality similar to other broadcast
technologies such as DVB-H/T/SH, DMB or former MediaFLO,
but has some advantages over them:
No additional infrastructure required
No additional spectrum required
User feedback is possible (unicast uplink transmission)

UMTS Release 6 onwards
LTE Release 9 onwards
eMBMS
Logical Architecture, Services and Protocols


BSF
P-GW
BM-SC MBMS GW
Content provider
S-GW
MME MCE
eNB
M1
M2
M3
Sm
S11
S1-U
S5
SGi
SGi-mb Uu
HSS
Zh
Zn
Ub
Ua
eMBMS Logical Architecture
10
Multi-cell/multicast Coordination Entity
- Admission control, resource allocation
- Service suspension / resumption
- UE counting

MBMS Gateway
- eMBMS user plane distribution to eNBs
- eMBMS session control signaling via MME
Broadcast Multicast Service Center
- Source of eMBMS data (packet generation)
- Security (key management, encryption)
- Membership, session management
- Content synchronization
- Service announcement and management
Sync
Data
eMBMS Services and Protocols
11
Physical Layer
Layer 2 (MAC/RLC UM)
IP
UDP
MIKEY FLUTE
MTK
Security
S
e
r
v
i
c
e

D
i
s
c
o
v
e
r
y

P
T
M

F
i
l
e

R
e
p
a
i
r

DASH
Codecs
R
a
d
i
o

p
r
o
t
o
c
o
l
s

I
P

p
r
o
t
o
c
o
l
s

RTP/RTCP
S
e
r
v
i
c
e

l
a
y
e
r

Applications
Security
Download
Services
Streaming
Services

eMBMS reuses existing LTE, Core
Network and Internet Protocols
2 types of services available over
eMBMS:
Download, based on FLUTE (File
Delivery over Unidirectional Transport)
with the option of file repair over unicast
bearers
Streaming, based on DASH (Dynamic
Adaptive Streaming over HTTP) for
content stream formatting
eMBMS security is based on MIKEY
(Multimedia Internet KEYing) and
MTK (MBMS Traffic Key)
For details see: TS 26.346
MBMS Protocols and codecs
MBSFN
Multicast Broadcast Single Frequency Network


What is MBSFN?
13
MBSFN (Multicast Broadcast Single Frequency Network) refers to a
subset of LTE cells in a certain geographical area transmitting eMBMS data on
the same frequency. All such cells need to be tightly time synchronized

MBSFN Area consists of a group of cells within the MBSFN which are
co-ordinated to both advertise the availability of and transmit the contents for a
particular collection of services. MBSFN areas can overlap
5
7
8
10
6
13
11
12
15
16
17
18
19
20
21
14
23
22
3
2
4
9
1
MBSFN Area 1
MBSFN Area 2
MBSFN
Cells belonging
to both areas
Non-MBSFN
cells
Traffic Load Management
14
Allocation of resources between MBSFN and unicast
transmission should be configurable depending on time/needs
Scaled depending on time of day, amount of broadcast traffic in the
MBSFN Area, number of UEs interested in broadcast services, etc.
Unicast:
100%
Regular hours
Unicast:
40%
eMBMS:
60%
Event
(streaming)
Unicast:
80%
eMBMS:
20%
Night
(download)
MBSFN Subframes
15
Certain subframes in each radio frame can be assigned for
MBSFN operation:
FDD: possible subframes are 1, 2, 3 and 6, 7, 8
TDD: possible subframes are 3, 4 and 7, 8, 9
Other subframes are for unicast operation and control channels/signals
MBSFN subframe configuration is broadcast in SIB2 (also in
Release 8)
SF0 SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 SF9
LTE Radio Frame (10ms)
Unicast resources
MBSFN resources
FDD example
MBSFN Subframes
16
In MBSFN subframes, the first 1 or 2 symbols are used for unicast transmission of
common signals and control channels
Extended Cyclic Prefix is used in MBSFN subframes
Mitigates delay spread caused by multi-cell transmission
Longer symbols result in only 12 symbols in a subframe
SF0 SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 SF9
LTE Radio Frame (10ms)
S2 S3 S4 S5 S6 S7 S8 S0 S1 S9
S10 S11
Subframe (1ms) = 12 symbols
Symbol CP
Extended Cyclic Prefix
16.7 us
Non-MBSFN
region
MBSFN
region
Unicast resources
MBSFN resources
FDD example
Traffic Load Management
17
Scaling of radio resources assigned to eMBMS in each cell in
an MBSFN Area can therefore be based on semi-static
assignment of MBSFN subframes
The network can reconfigure cells as required
SF
0
SF
1
SF
2
SF
3
SF
4
SF
5
SF
6
SF
7
SF
8
SF
9
Unicast:
100%
Regular hours
SF
0
SF
1
SF
2
SF
3
SF
4
SF
5
SF
6
SF
7
SF
8
SF
9
Unicast:
40%
eMBMS:
60%
Event
(streaming)
Unicast:
80%
eMBMS:
20%
SF
0
SF
1
SF
2
SF
3
SF
4
SF
5
SF
6
SF
7
SF
8
SF
9
Night
(download)
eMBMS
Channels, Signals and Procedures


eMBMS Channels
19
New logical, transport and physical channels were added for
eMBMS:
MCCH
Multicast Control Channel
MTCH
Multicast Traffic Channel

MCH
Transport Multicast Channel

PMCH
Physical Multicast Channel
MCH DL-SCH BCH PCH Downlink
Transport
Channels
Downlink
Logical
Channels
MTCH MCCH DTCH DCCH CCCH BCCH PCCH
HI
DCI
CFI
PDSCH PBCH PMCH PDCCH/
EPDCCH
PCFICH PHICH
Downlink
Physical
Channels
MBSFN Reference Signal
20
MBSFN RS (Reference Signal) is transmitted in MBSFN
subframes
Transmitted in the MBSFN region of MBSFN subframes only when PMCH is transmitted
Transmitted instead of CRS (Cell Specific Reference Signal)
CRS is still transmitted in unicast (non-MBSFN) regions
It is used to assist demodulation of MBSFN symbols
Tailored to MBSFN transmission - channel estimation has to be improved because of
higher expected delay spread
Initialization sequence depends on MBSFN Area ID, which helps to distinguish between
MBSFN Areas
SF0 SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 SF9
LTE Radio Frame (10ms)

0 l 5 l 0 l 5 l
even-numbered slots odd-numbered slots
Antenna port 4
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
4
R
UE eMBMS Procedures
21
What does the UE have to do to receive eMBMS transmissions?
Get the MBSFN subframe schedule in the cell, from SIB2
Learn which MBSFN Areas are supported in the cell, from SIB13
Learn where to find the MCCH control channel, from SIB13
Learn which sessions are transmitted in the MBSFN Area, from MCCH
Learn which MTCH traffic channels do the sessions use and how to decode them, from MCCH
Learn where to find the MTCH traffic channels, from MSI MCE
Read and decode session data from the right MTCH
eMBMS Procedures
22
The UE has to get information about which subframes are allocated to MBSFN from SIB2
UEs not supporting eMBMS should also do this
SystemInformationBlockType2 ::= SEQUENCE {
...
mbsfn-SubframeConfigList MBSFN-SubframeConfigList OPTIONAL, -- Need OR
...
}

MBSFN-SubframeConfigList ::= SEQUENCE (SIZE (1..maxMBSFN-Allocations)) OF MBSFN-SubframeConfig

MBSFN-SubframeConfig ::= SEQUENCE {
radioframeAllocationPeriod ENUMERATED {n1, n2, n4, n8, n16, n32},
radioframeAllocationOffset INTEGER (0..7),
subframeAllocation CHOICE {
oneFrame BIT STRING (SIZE(6)),
fourFrames BIT STRING (SIZE(24))
}
}
Up to 8 patterns can be defined
How often should
the pattern repeat?
The pattern is a bit map
covering either
1 or 4 frames
0
1
2
3
4
5
Subframes
F
r
a
m
e
s

(
S
F
N
)

Example:

- 1 pattern only
- radioframeAllocationPeriod = n2
- radioframeAllocationOffset = 0
- oneFrame = {111111}
MCCH Position Acquisition
23
An eMBMS-capable UE has to find out MBSFN Areas that are covered by the cell by
reading SIB13
SIB13 contains only eMBMS-related information so is transmitted only in cells supporting MBSFN
For each MBSFN Area, SIB13 also points the UE to where can it find the MCCH
control channel
There is a single MCCH per MBSFN Area
MCCH is transmitted within the MBSFN region


SystemInformationBlockType13-r9 ::= SEQUENCE {
mbsfn-AreaInfoList-r9 MBSFN-AreaInfoList-r9,
notificationConfig-r9 MBMS-NotificationConfig-r9,
lateNonCriticalExtension OCTET STRING OPTIONAL, -- Need OP
...
}
MBSFN-AreaInfoList-r9 ::= SEQUENCE (SIZE(1..maxMBSFN-Area)) OF MBSFN-AreaInfo-r9

MBSFN-AreaInfo-r9 ::= SEQUENCE {
mbsfn-AreaId-r9 INTEGER (0..255),
non-MBSFNregionLength ENUMERATED {s1, s2},
notificationIndicator-r9 INTEGER (0..7),
mcch-Config-r9 SEQUENCE {
mcch-RepetitionPeriod-r9 ENUMERATED {rf32, rf64, rf128, rf256},
mcch-Offset-r9 INTEGER (0..10),
mcch-ModificationPeriod-r9 ENUMERATED {rf512, rf1024},
sf-AllocInfo-r9 BIT STRING (SIZE(6)),
signallingMCS-r9 ENUMERATED {n2, n7, n13, n19}
},
...
}
Up to 8 areas per cell
How many unicast symbols
left at start of MBSFN subframes
Where to find the MCCH for this Area:
- How often is the radio frame with MCCH repeated
- Repetition period offset (in radio frames)
- Subframe in the frame where MCCH can be found
Must fit within MBSFN subframes defined in SIB2
Modulation and Coding Scheme (MCS) for MCCH
MCCH Position Acquisition
24
0
1
2
3
4
5
Subframes
F
r
a
m
e
s

(
S
F
N
)

6
7
8
9
10
11
12
13
14
15
Example:

SIB13 parameters used to find MCCH:
- mcch-RepetitionPeriod = rf32
- mcch-Offset = 3
- sf-AllocInfo = {100000}
MCCH control channel position.
Next one will be in frame 35 (rf32 + 3)
MCCH Acquisition
25
The UE reads the MCCH control channel to find about MBSFN
area configuration and sessions in the MBSFN Area

RRC messages are transmitted on MCCH
MBSFNAreaConfiguration
MBMSCountingRequest (new in Release 10)





MCCH Acquisition
26
MBSFN Area Configuration describes:
MBSFN subframes reserved for the MBSFN Area
Subframes where each PMCH is transmitted. One PMCH can carry several sessions.

Information about eMBMS sessions on each PMCH
Service and session identifiers
MTCH Channel Identifier (which MTCH is the session on)
MCS for the MTCH, and size of allocation (in subframes) for the MTCH



MBSFNAreaConfiguration-r9 ::= SEQUENCE {
commonSF-Alloc-r9 CommonSF-AllocPatternList-r9,
commonSF-AllocPeriod-r9 ENUMERATED {
rf4, rf8, rf16, rf32, rf64, rf128, rf256},
pmch-InfoList-r9 PMCH-InfoList-r9,
...
}

CommonSF-AllocPatternList-r9 ::= SEQUENCE (SIZE (1..maxMBSFN-Allocations)) OF MBSFN-
SubframeConfig
MBSFN Area
subframe allocation,
CSA (Common Subframe Allocation).
Must fit within MBSFN subframes
defined in SIB2

Session Information
Common Subframe Allocation
27
CSA (Common Subframe Allocation) defines configuration of all PMCHs for this MBSFN
Area, i.e. the subset of all MBSFN subframes allocated to the MBSFN Area to which the MCCH on
which it was received relates.
CSA example:

MCCH parameters to find the MBSFN Area

- 1 pattern only
- radioframeAllocationPeriod = n2
- radioframeAllocationOffset = 0
- oneFrame = {111100}
- commonSF-AllocPeriod = rf16
0
1
2
3
4
5
Subframes
F
r
a
m
e
s

(
S
F
N
)

6
7
8
9
10
11
12
13
14
15
16
17
Resources reserved for this MBSFN Area
Resources that can be used for different MBSFN Areas, not
used in this example.

This enables MBSFN Area overlapping
Session Information
28
Session information is also carried in the MBSFNAreaConfiguration RRC
message on MCCH
PMCH-InfoList-r9 ::= SEQUENCE (SIZE (0..maxPMCH-PerMBSFN)) OF PMCH-Info-r9

PMCH-Info-r9 ::= SEQUENCE {
pmch-Config-r9 PMCH-Config-r9,
mbms-SessionInfoList-r9 MBMS-SessionInfoList-r9,
...
}

MBMS-SessionInfoList-r9 ::= SEQUENCE (SIZE (0..maxSessionPerPMCH)) OF MBMS-SessionInfo-r9

MBMS-SessionInfo-r9 ::= SEQUENCE {
tmgi-r9 TMGI-r9,
sessionId-r9 OCTET STRING (SIZE (1)) OPTIONAL, -- Need OR
logicalChannelIdentity-r9 INTEGER (0..maxSessionPerPMCH-1),
...
}

PMCH-Config-r9 ::= SEQUENCE {
sf-AllocEnd-r9 INTEGER (0..1535),
dataMCS-r9 INTEGER (0..28),
mch-SchedulingPeriod-r9 ENUMERATED {
rf8, rf16, rf32, rf64, rf128, rf256, rf512, rf1024},
...
}

TMGI-r9 ::= SEQUENCE {
plmn-Id-r9 CHOICE {
plmn-Index-r9 INTEGER (1..maxPLMN-r11),
explicitValue-r9 PLMN-Identity
},
serviceId-r9 OCTET STRING (SIZE (3))
}
Maximum of 29 sessions per PMCH
Max 15 PMCHs
Session Identifier
MTCH Identifier used for each session
Modulation and coding scheme (MCS)
for all MTCHs on the PMCH
Subframes allocated to this PMCH
When is L2 scheduling
information sent:
MSI-MCE
(MCH Scheduling Information
MAC Control Element)
MSI MAC Control Element
29
Each session is transmitted on a separate MTCH logical channel
The last bit of information the UE needs is MTCH allocation within each PMCH
This is provided by Layer 2, by sending a MSI MCE (MCH Scheduling Information
Medium Access Control Element)
Allows for dynamic scheduling based on how much data has to be sent for each
session in the particular subframe












eMBMS data is transmitted using standard MAC PDUs (Protocol Data Units)
Ref. 3GPP TS 36.321 cl. 6.1.2

LCID 1
Stop MTCH 1
Oct 1
Oct 2
...
Oct 3
Oct 4
Oct 2n-1
Oct 2n
Stop MTCH 1
LCID 2
Stop MTCH 2
Stop MTCH 2
LCID n
Stop MTCH n
Stop MTCH n
Logical Channel ID of the MTCH
Number of last MBSFN subframe within the PMCH
used by this MTCH
Session Allocation
30
Session allocation example:

- 1 PMCH
- mch-SchedulingPeriod = 8 (MCH spans 8 frames)

In the first scheduling period:
- First session on MTCH 1
- Stop MTCH 1 = 10 (first 10 subframes used)
- Second session on MTCH 2
- Stop MTCH 2 = 16 (6 subframes used)


0
1
2
3
4
5
Subframes
F
r
a
m
e
s

(
S
F
N
)

6
7
8
9
10
11
12
13
14
15
16
17
MCCH
Subframes allocated to PMCH 2, unused in this example
MBSFN subframes, unused by any MBSFN Area in this example
MCI-MCE
Session 1 on MTCH 1 (PMCH 1)
Session 2 on MTCH 2 (PMCH 1)
Non-MBSFN (unicast) subframes
MCCH Information Change
31
MCCH Information can change
Usually when a session is added or removed from the list of sessions transmitted in
a certain MBSFN Area
UE has to be notified that the session changed
Otherwise, the UE would have to constantly monitor PMCH which would cause use
UEs processing power and battery
MCCH can only change on notification period boundaries. The MCCH notification
period is broadcast in SIB13
When MCCH information is about to change, a notification on PDCCH (Physical
Downlink Common Channel) is sent to the UE, to the M-RNTI (Radio Network
Temporary Identifier)
Because all UEs need to monitor PDCCH, they will receive the notification

MCCH modification period (n)
Change notification Updated information
MCCH modification period (n+1)
MCCH repetition
period
Release 10, 11 and 12
Enhancements


eMBMS Release 10
33
Additional features added in Release 10:
UE counting so that the network knows how many UEs interested in
eMBMS are in a certain cell and can decide whether to enable/disable
eMBMS transmission in that cell
The RRC MBMSCounting Request is sent on MCCH
The response RRC MBMSCountingResponse is received in uplink on SRB1
(Signaling Radio Bearer 1)








MBMS Co unt ingRe sponse
MBMS Co unt ingRequest
UE EUTRAN
eMBMS Release 10
34
Additional features added in Release 10:
Allocation and Retention Priority (ARP) allowing to set priority
between eMBMS sessions in order to manage radio resources for different
eMBMS sessions

Subframe reuse enables unicast reception in MBSFN subframes
which are actually not used for MBSFN transmission
eMBMS Release 11
35
Additional features added in Release 11:

Service Continuity support
When eMBMS services are provided on more than one frequency layers, the
UE should not have to read eMBMS information on neighbour frequencies,
therefore:
Both MBSFN and non-MBSFN cells provide MBMS SAIs (Service area IDs) of the
current frequencies and of neighbour frequencies in SIB15
The application/service layer provides for each service key information including the
frequencies and the MBMS SAIs belonging to the MBMS service area

Service layer enhancements
Reception reporting
Improvements in providing content schedule information
Location filtering to allow selective reception of services
eMBMS Release 12
36
eMBMS enhancements in Release 12 are currently being:

Quality reporting for eMBMS
RSRP (Reference Signal Received Power) and RSRQ (Reference Signal
Received Quality) reporting per MBSFN area
MCH BLER (Block Error Rate) reporting per MCS, MCH and MBSFN area
Includes immediate and logged MDT reporting

Group communication using eMBMS
Group communications is the capability for the UE to dynamically join and leave
pre-set or ad-hoc groups and send messages to all members of those groups.
This can be useful for public safety, but not only
eMBMS can also be used for multicast distribution in case of group
communication
Includes service continuity between eMBMS and unicast bearers

eMBMS Testing


Content server
RF/cable
AT/MMI
Anritsus RTD with MD8430A Signaling Tester
Typical Test Setup
38
Cell #1
Cell #2
(optional)
Core
Network
Content server
MBSFN
transmission
Network Simulation
eMBMS Testing
39
Several features of eMBMS require testing at all stages of the UE production
life cycle:
PMCH/MCH demodulation and decoding
MCCH (control) information acquisition
MTCH (data) information acquisition
MCCH based session scheduling
Layer-2 based MTCH scheduling
Mobility within and between MBSFN areas
Mobility between different MBSFN frequency layers
Handling multiple sessions and data rates
Handling streaming and download sessions
Support of UE counting
eMBMS-related capability reporting

RTD allows to create and customize new test cases for all market segments
These and other scenarios can be tested using Anritsus ME7834 Mobile
Device Test Platform. CAT and PCT, offering ready made test cases, will be
supported
eMBMS Conformance Testing
40
eMBMS PCT test cases are already defined in 3GPP TSG RAN5












These test cases will be available on
Anritsus ME7834 Protocol Conformance Test System

17.1 MCCH Information Acquisition Rel
17.1.1 MCCH information acquisition/ UE is switched on 9
17.1.2 MCCH information acquisition/UE cell reselection to a cell in a new MBSFN area 9
17.1.3 MCCH information acquisition/UE handover to a cell in a new MBSFN area 9
17.1.4 MCCH information acquisition/ UE is receiving an MBMS service 9
17.1.5 MCCH information acquisition/UE is not receiving MBMS data 9
17.2 MBMS Data Reception
17.2.1 UE acquire the MBMS data based on the SIB13 and MCCH message / MCCH and MTCH are on the same MCH 9
17.2.2 UE acquire the MBMS data based on the SIB13 and MCCH message / MCCH and MTCH are on different MCHs 9
17.2.3 UE receives the MBMS data when this data is in the beginning of the MSP 9
17.2.4 Reception of PDCCH DCI format 0 and PHICH in MBSFN subframes. 9
17.3 MBMS Counting Procedure
17.3.1 MBMS Counting / UE not receiving MBMS service 10
17.3.2 MBMS Counting / UE receiving MBMS service 10
17.4 MBMS Service Continuity
17.4.1 Cell reselection to intra-frequency cell to continue MBMS service reception 11
17.4.2 Cell reselection to inter- frequency cell to start MBMS service reception 11
17.4.3 Handover to inter-frequency cell to start MBMS service reception 11
17.4.4 Handover to intra-frequency cell to continue MBMS service reception 11
17.4.5 Conditional retransmission of MBMS Interest Indication after handover 11
17.4.6 MBMS Interest Indication retransmission after returning from cell not broadcasting SIB15 11
17.4.7 MBMS Interest Indication after Radio Link Failure 11
17.4.8 Continued MBMS service reception after E-UTRAN release of unicast bearer 11
References
41
TS 26.246 Transparent end-to-end Packet-switched Streaming Service (PSS); 3GPP
SMIL language profile
TS 26.346 Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs
TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification
TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification
TS 36.523-1 - User Equipment (UE) conformance specification; Part 1: Protocol
conformance specification

http://www.3gpp.org