evolved multimedia broadcast multicast service

8/12/2019 Evolved Multimedia Broadcast Multicast Service

1/42

July 2014

Enhanced Multimedia

Broadcast Multicast Service

(eMBMS)


2/42

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


3/42


4/42


5/42

Why eMBMS?

5

Operators need solutions allowing them to decrease network

traffic while continuing to provide a similar level of serviceto customers

One of these solutions is MBMS/eMBMS


6/42


7/42

MBMS Usage

7

Venue/region specific or nation-wide broadcastMobile TV, sports events, local events/news, breaking news,

Streaming for situational awarenessDisaster awareness, event coordination,

Emergency push-to-talkOne-to-many emergency communication

File delivery for non real time servicesAdvertisements, vouchers, news updates, SW upgrades


8/42


9/42

eMBMS

Logical Architecture, Services and Protocols


10/42

BSF

P-GW

BM-SCMBMS GWContent provider

S-GW

MMEMCE

eNBM1

M2

M3

Sm

S11

S1-U S5

SGi

SGi-mbUu

HSSZh

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


11/42

eMBMS Services and Protocols

11

Physical Layer

Layer 2 (MAC/RLC UM)

IP

UDP

MIKEY FLUTE

MTK

Security

S

ervice

Discovery

PTM

File

Repair

DASH

Codecs

Radio

protocols

IP

protocols

RTP/RTCP

Service

laye

r

Applications

Security

Download

Services

Streaming

Services eMBMS reuses existing LTE, CoreNetwork 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


12/42

MBSFN

Multicast Broadcast Single Frequency Network


13/42

What is MBSFN?

13

MBSFN (Multicast Broadcast Single Frequency Network) refers to asubset 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 areco-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


14/42

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)


15/42

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


16/42

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



S2 S3 S4 S5 S6 S7 S8S0 S1 S9 S10 S11

Subframe (1ms) = 12 symbols

SymbolCP

Extended Cyclic Prefix

16.7 us

Non-MBSFN

region

MBSFN

region

Unicast resources

MBSFN resources

FDD example


17/42

Traffic Load Management

17

Scaling of radio resources assigned to eMBMS in each cell in

an MBSFN Area can therefore be based on semi-staticassignment 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)


18/42

eMBMS

Channels, Signals and Procedures


19/42

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

MCHDL-SCHBCHPCH DownlinkTransportChannels

DownlinkLogicalChannels

MTCHMCCHDTCHDCCHCCCHBCCHPCCH

HIDCI

CFI

PDSCHPBCH PMCHPDCCH/

EPDCCH

PCFICH PHICH

DownlinkPhysicalChannels


20/42

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



0l 5l 0l 5l

even-numbered slots odd-numbered slots

Antenna port 4

4R

4R

4R

4R

4R

4R

4R

4R

4

R

4R

4R

4R

4R

4R

4R

4R

4R

4R


21/42


22/42

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

Frames(SFN) Example:

- 1 pattern only

- radioframeAllocationPeriod = n2

- radioframeAllocationOffset = 0

- oneFrame = {111111}


23/42

MCCH Position Acquisition

23

An eMBMS-capable UE has to find out MBSFN Areasthat 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


24/42

MCCH Position Acquisition

24

0

1

2

3

4

5

Subframes

Frames(SFN)

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)


25/42

MCCH Acquisition

25

The UE reads the MCCH control channel to find about MBSFN

area configurationand sessionsin the MBSFN Area

RRC messages are transmitted on MCCH

MBSFNAreaConfiguration

MBMSCountingRequest (new in Release 10)


26/42

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


27/42

Common Subframe Allocation

27

CSA (Common Subframe Allocation) defines configuration of all PMCHs for this MBSFNArea, 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

Frames(SFN)

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


28/42

Session Information

28

Sessioninformationis 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)


29/42

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


30/42

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

Frames(SFN)

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


31/42

MCCH Information Change

31

MCCH Information can change

Usually when a session is added or removed from the list of sessions transmitted ina 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


32/42

Release 10, 11 and 12

Enhancements


33/42

eMBMS Release 10

33

Additional features added in Release 10:

UE counting so that the network knows how many UEs interested ineMBMS 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)

MBMSCountingResponse

MBMSCountingRequest

UE EUTRAN


34/42


35/42


36/42

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 groupcommunication

Includes service continuity between eMBMS and unicast bearers


37/42


38/42

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


39/42


40/42

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 Rel17.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. 917.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


41/42

References

41

TS 26.246Transparent end-to-end Packet-switched Streaming Service (PSS); 3GPP

SMIL language profile

TS 26.346Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs

TS 36.300Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved

Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2

TS 36.321Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access

Control (MAC) protocol specification

TS 36.331Evolved 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
http://www.3gpp.org/http://www.3gpp.org/


42/42

evolved multimedia broadcast multicast service

Documents