`13.3.5 MBMS Interfaces
`For MBMS in LTE, two new control plane interfaces have been defined (M3 and M2), as
`well as one new user plane interface (M1), as shown in Figure 13.2.
`
`297
`
`13.3.5.1 M3 Interface (MCE – MME)
`An Application Part (M3AP) is defined for this interface between the MME and MCE. The
`M3AP primarily specifies procedures for starting, stopping and updating MBMS sessions.
`Upon start or modification of an MBMS session, the MME provides the details of the MBMS
`bearer while the MCE verifies if the MBMS service (or modification of it) can be supported.
`Point-to-point signalling transport is applied, using the Stream Control Transmission Protocol
`(SCTP) [4].
`
`13.3.5.2 M2 Interface (MCE – eNodeB)
`Like the M3 interface, an application part (M2AP) is defined for this interface between the
`MCE and eNodeB, again primarily specifying procedures for starting, stopping and updating
`MBMS sessions. Upon start or modification of an MBMS session, the MCE provides
`the details of the radio resource configuration that all participating eNodeBs shall apply.
`In particular, the MCE provides the updated control information to be broadcast by the
`eNodeBs. SCTP is again used for the signalling transport.
`
`13.3.5.3 M1 Interface (MBMS GW – eNodeB)
`Similarly to the S1 and X2 interfaces (see Sections 2.5 and 2.6 respectively), the GTP-U4
`protocol over UDP5 over IP is used to transport MBMS data streams over the M1 interface.
`IP multicast is used for point-to-multipoint delivery.
`
`13.4 MBMS Single Frequency Network Transmission
`One of the targets for MBMS in LTE is to support a cell edge spectral efficiency in an
`urban or suburban environment of 1 bps/Hz – equivalent to the support of at least 16 mobile
`TV channels at around 300 kbps per channel in a 5 MHz carrier. This is only achievable
`by exploiting the special features of the LTE OFDM6 air interface to transmit multicast or
`broadcast data as a multicell transmission over a synchronized ‘single frequency network’:
`this is known as Multimedia Broadcast Single Frequency Network (MBSFN) operation.
`
`13.4.1 Physical Layer Aspects
`In MBSFN operation, MBMS data is transmitted simultaneously over the air from multiple
`tightly time-synchronized cells. A UE receiver will therefore observe multiple versions of the
`signal with different delays due to the multicell transmission. Provided that the transmissions
`from the multiple cells are sufficiently tightly synchronized for each to arrive at the UE within
`
`4GPRS Tunnelling Protocol – User Plane [5].
`5User Datagram Protocol.
`6Orthogonal Frequency Division Multiplexing.
`
`Samsung Ex. 1010
`901 of 1365
`
`
`
`298
`
`LTE— THE UMTS LONG TERM EVOLUTION
`
`the Cyclic Prefix (CP) at the start of the symbol, there will be no Inter—Symbol Interference
`(ISI). In effect, this makes the MBSFN transmission appear to a UE as a transmission from
`a single large cell, and the UE receiver may treat the multicell transmissions in the same
`way as multipath components of a single-cell transmission without incurring any additional
`complexity. This is illustrated in Figure 13.3. The UE does not even need to know how many
`cells are transmitting the signal.
`The method of achieving the required tight synchronization between MBSFN transmis-
`sions from different eNodeBs is not defined in the LTE specifications; this is left to the
`implementation of the eNodeBs. Typical implementations are likely to use satellite-based
`solutions (e.g. GPS7) or possibly synchronized backhaul protocols (e.g. [6]).
`
`Syndirorized eNodeBs
`transnitting MBMS data
`
`E
`
`Signals fromdifferenteNodeBs
`arrive with‘n cycicprefix at UE
`
`I
`
`I
`
`OFDM syn'bot duration
`+—————>
`
`cyan /:l:l
`Prefix I::I
`
`I:I:l
`Ef—J
`ISI free window
`
`Figure 13.3: ISI-free operation with MBSFN transmission.
`
`This single frequency network reception leads to significant improvements in spectral
`efficiency compared to UMTS Release 6 MBMS, as the MBSFN transmission greatly
`enhances the Signal-to—Interference-plus—Noise Ratio (SlNR). This is especially true at the
`cell edge, where transmissions which would otherwise have constituted inter-cell interference
`are translated into useful signal energy — hence the received signal power is increased at the
`same time as the interference power being largely removed.
`An example of the improvement in performance achievable using MBSFN transmission
`compared to single-cell point-to-multipoint transmission is shown in Figure 13.4. In this
`
`7Global Positioning System
`
`Samsung Ex. 1010
`902 of 1365
`
`
`
`BROADCAST OPERATION
`
`299
`
`example, the probability of a randomly located UE not being in outage (defined as MBMS
`packet loss rate < 1%) is plotted against spectral efficiency of the MBMS data transmissions
`(a measure of MBMS data rate in a given bandwidth). A hexagonal cell—layout is assumed,
`with the MBSFN area comprising one, two or three rings around a central cell for which the
`performance is evaluated. It can be seen that the achievable data rates increase markedly as
`the size of the MBSFN area is increased and hence the surrounding inter-cell interference
`is reduced. A 1 km cell radius is assumed, with 46 dBm eNodeB transmission power, 15 m
`eNodeB antenna height and 2 GHz carrier frequency.
`
`+Cemdcellwmmedw3nmsotm$flcdls
`
`
`+Cerlrdcsllsimomdedby2nngsotMBSFch|s
`
`,
`+Centrdcdlsunundadty1dmolmsmodts
`._
`
`,
`a +Cemdcellsunomdedbyhbflm
` '--i--r------r---
`
`
`‘-+-i‘--I--i---
`1 km cel realm
`
`
`46dBm eNB pour
`15 mananna helgtl
`
`
`
`,
`:3:
`":23 2 35.; :2,
`
`:3??? 3" é;
`' "
`* 5__I§§z_;s_.;_;._.;_22.31;:
`f
`-
`>
`i
`"
`
`
`
`on
`0.5
`1.0
`1.5
`2.0
`2.5
`3.0
`
`Spectral Efficiency (bps/Hz)
`
`
`
`
`
`Coverage(ProbabtyofPacketErrorRate<1%)
`
`Figure 13.4: Reduction in total downlink resource usage achievable using MBSFN
`transmission [7]. Reproduced by permission of © 2007 Motorola.
`
`MBSFN data transmission takes place via the Multicast CHannel (MCH) transport
`channel, which is mapped to the Physical Multicast Cl-lannel (PMCH) introduced in
`Section 9.2.3.
`
`The basic structure of the Physical Multicast Channel (PMCH) is very similar to the
`Physical Downlink Shared Channel (PDSCH). However, as the channel in MBSFN operation
`is in efiect a composite channel from multiple cells, it is necessary for the UE to perform
`a separate channel estimate for MBSFN reception from that performed for reception of
`data from a single cell. Therefore, in order to avoid the need to mix normal Reference
`Signals (RSs) and RSs for MBSFN in the same subframe, frequency-division multiplexing
`of the PMCH and PDSCH is not permitted within a given subframe; instead, time-division
`multiplexing of unicast and MBSFN data is used - certain subframes are specifically
`designated as MBSFN subframes, and it is in these subframes that the PMCH would be
`
`Samsung Ex. 1010
`903 of 1365
`
`
`
`300
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`transmitted.8 Certain subframes are not allowed to be used for MBSFN transmission: in a
`Frequency Division Duplex (FDD) system, subframes 0, 4, 5 and 9 in each 10 ms radio frame
`are reserved for unicast transmission in order to avoid disrupting the synchronization signals
`or paging occasions, and to ensure that sufficient cell-specific RSs are available for decoding
`the broadcast system information; in a Time Division Duplex (TDD) system, subframes 0, 1,
`2, 5 and 6 cannot be MBSFN subframes.
`The key differences from PDSCH in respect of the PMCH are as follows:
`• The dynamic control signalling (PDCCH and PHICH9 – see Section 9.3) cannot
`occupy more than two OFDM symbols in an MBSFN subframe. The scheduling of
`MBSFN data on the PMCH is carried out by higher-layer signalling, so the PDCCH is
`used only for uplink resource grants and not for the PMCH.
`• The PMCH always uses the first redundancy version (see Section 10.3.2.4) and does
`not use Hybrid ARQ.
`• The extended CP is used (∼17 μs instead of ∼5 μs) (see Section 5.4.1). As the
`differences in propagation delay from multiple cells will typically be considerably
`greater than the delay spread in a single cell, the longer CP helps to ensure that the
`signals remain within the CP at the UE receivers, thereby reducing the likelihood of
`ISI. This avoids introducing the complexity of an equalizer in the UE receiver, at the
`expense of a small loss in peak data rate due to the additional overhead of the longer CP.
`Note, however, that if the non-MBSFN subframes use the normal CP, then the normal
`CP is used in the OFDM symbols used for the control signalling at the start of each
`MBSFN subframe. This results in there being some spare time samples whose usage is
`unspecified between the end of the last control signalling symbol and the first PMCH
`symbol, the PMCH remaining aligned with the end of the subframe; the eNodeB may
`transmit an undefined signal (e.g. a cyclic extension) during this time or it may switch
`off its transmitter – the UE cannot assume anything about the transmitted signal during
`these samples.
`• The Reference Signal (RS) pattern embedded in the PMCH (designated ‘antenna port
`4’) is different from non-MBSFN data transmission, as shown in Figure 13.5. The RSs
`are spaced more closely in the frequency domain than for non-MBSFN transmission,
`reducing the separation to every other subcarrier instead of every sixth subcarrier. This
`improves the accuracy of the channel estimate that can be achieved for the longer delay
`spreads. The channel estimate obtained by the UE from the MBSFN RS is a composite
`channel estimate, representing the composite channel from the set of cells transmitting
`the MBSFN data. (Note, however, that the cell-specific RS pattern embedded in the
`OFDM symbols carrying control signalling at the start of each MBSFN subframe
`remains the same as in the non-MBSFN subframes.)
`
`The latter two features are designed so that a UE making measurements of a neighbouring
`cell does not need to know in advance the allocation of MBSFN and non-MBSFN subframes.
`The UE can take advantage of the fact that the first two OFDM symbols in all subframes use
`the same CP duration and RS pattern.
`
`8LTE does not currently support dedicated MBMS carriers in which all subframes would be used for MBSFN
`transmission.
`9Physical Downlink Control Channel and Physical HARQ Indicator Channel.
`
`Samsung Ex. 1010
`904 of 1365
`
`
`
`BROADCAST OPERATION
`
`301
`
`0%6)15HIHUHQFH
`6\PERO
`
`IUHTXHQF\
`
`PV
`
`WLPH
`
`Figure 13.5: MBSFN RS pattern for 15 kHz subcarrier spacing.
`Reproduced by permission of © 3GPP.
`
`In addition to these enhancements for MBSFN transmission, a second OFDM parame-
`terization is provided in the LTE physical layer specifications, designed for downlink-only
`multicast/broadcast transmissions. However, this parameterization is not supported in current
`releases of LTE. As discussed in Section 5.4.1, this parameterization has an even longer CP,
`double the length of the extended CP, resulting in approximately 33 μs. This is designed
`to cater in the future for deployments with very large differences in propagation delay
`between the signals from different cells (e.g. 10 km). This would be most likely to occur for
`deployments at low carrier frequencies and large inter-site distances. In order to avoid further
`increasing the overhead arising from the CP in this case, the number of subcarriers per unit
`bandwidth is also doubled, giving a subcarrier spacing of 7.5 kHz. The cost of this is an
`increase in Inter-Carrier Interference (ICI), especially in high-mobility scenarios with a large
`Doppler spread. There is therefore a trade-off between support for wide-area coverage and
`support for high mobile velocities. It should be noted, however, that the maximum Doppler
`shift is lower at the low carrier frequencies that would be likely to be used for a deployment
`with a 7.5 kHz subcarrier spacing. The absolute frequency spacing of the reference symbols
`for the 7.5 kHz parameterization is the same as for the 15 kHz subcarrier spacing MBSFN
`pattern, resulting in a reference symbols on every fourth subcarrier.
`
`13.4.2 MBSFN Areas
`A geographical area of the network where MBMS can be transmitted is called an MBMS
`Service Area.
`A geographical area where all eNodeBs can be synchronized and can perform MBSFN
`transmissions is called an MBSFN Synchronization Area.
`The area within an MBSFN Synchronization Area, covered by a group of cells participat-
`ing in an MBSFN transmission, is called an MBSFN Area. An MBSFN Synchronization Area
`may support several MBSFN Areas. Moreover, a cell within an MBSFN Synchronization
`Area may form part of multiple MBSFN Areas, each characterized by different transmitted
`content and a different set of participating cells.
`
`Samsung Ex. 1010
`905 of 1365
`
`
`
`302
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`Figure 13.6 illustrates an example of the usage of MBSFN areas in a network providing
`two nationwide MBMS services (N1 and N2) as well as two regional MBMS services, R1
`and R2 (i.e. with different regional content), across three different regions.
`The most natural way to deploy this would be to use four different MBSFN areas, as
`shown in the figure. It should be noted that the control information related to a service is
`transmitted by the same set of cells that transmit the data – e.g. MBSFN area N provides
`both control and data for the two nationwide services. This kind of approach implies that
`within a geographical area the resources allocated to MBMS need to be semi-statically
`divided between the MBSFN areas, and UEs that are potentially interested in receiving both
`nationwide and regional services need to monitor the control information of multiple MBSFN
`areas. Indeed, UEs are expected to be capable of monitoring control information of multiple
`MBSFN areas, although simultaneous reception of multiple services is optional regardless
`of whether they are part of the same MBSFN area. Further details of UE capabilities can be
`found in Section 13.5.2.
`
`0%6)1$UHD1
`
`6HUYLFH1
`
`6HUYLFH1
`
`0%6)1$UHD5D
`6HUYLFH5D
`
`0%6)1$UHD5E
`
`0%6)1$UHD5F
`
`6HUYLFH5E
`
`6HUYLFH5F
`
`6HUYLFH5D
`
`6HUYLFH5E
`
`6HUYLFH5F
`
`&HOOV
`
`Figure 13.6: Example scenario with overlapping MBSFN areas.
`
`Figure 13.7 illustrates how the same services can be provided without overlapping
`MBSFN areas. It should be noted that for the nationwide services this approach results
`in reduced MBSFN transmission gains and potential service interruptions upon change of
`MBSFN area.
`
`0%6)1$UHD
`
`0%6)1$UHD
`
`0%6)1$UHD
`
`6HUYLFH1
`
`6HUYLFH1
`
`6HUYLFH1
`
`6HUYLFH1
`
`6HUYLFH1
`
`6HUYLFH1
`
`6HUYLFH5D
`
`6HUYLFH5E
`
`6HUYLFH5F
`
`6HUYLFH5D
`
`6HUYLFH5E
`
`6HUYLFH5F
`
`&HOOV
`
`Figure 13.7: Example scenario without overlapping MBSFN areas.
`
`Samsung Ex. 1010
`906 of 1365
`
`
`
`BROADCAST OPERATION
`
`303
`
`Current releases of LTE do not support dynamic change of the MBSFN area; the counting
`procedure introduced in Release 10 (see Section 13.6.5) is used only to decide whether or not
`to use MBSFN transmission for an MBMS service but not to change set of cells used for an
`MBSFN transmission.
`
`13.5 MBMS Characteristics
`
`13.5.1 Mobility Support
`
`Mobility for MBMS is purely based on the procedures defined for unicast operation. No
`additional mechanisms are provided to direct UEs to the carrier frequency providing MBMS,
`nor to reduce MBMS service interruption when moving from one MBSFN area to another.
`E-UTRAN can assign the highest cell reselection priority to the carrier frequency
`providing MBMS. However, in connected mode, when E-UTRAN controls the mobility, the
`network is aware neither of whether the UE supports MBMS nor of whether it is interested
`in actually receiving any particular MBMS service.
`
`13.5.2 UE Capabilities and Service Prioritization
`
`All UEs need to support some MBMS-related behaviour, including those that do not support
`MBMS reception and UEs that conform to the initial Release 8 version of LTE (which does
`not include MBMS). These UEs must be aware of the MBSFN subframes that are configured,
`since the RS pattern is different. Release 8/9 UEs not supporting MBMS may also benefit
`from knowing that no regular downlink resource assignments will occur for them in the
`MBSFN subframes.
`As unicast and MBMS transmissions are time-division multiplexed, parallel reception of
`unicast and MBMS on the same carrier should be relatively straightforward. Nevertheless,
`a UE may of course have other limitations preventing parallel support, for example due to
`memory or display restrictions. Consequently, there is no requirement for a UE that supports
`MBMS to support simultaneous reception of unicast, nor to support simultaneous reception
`of multiple MBMS services.
`In the case of a UE that cannot receive all the services in which it is interested, it should be
`able to receive the service (unicast or MBMS) that it prioritizes most. This implies that a UE
`that is receiving a service should at least be able to detect the start of other services (unless
`the currently received service is always considered as having the highest priority).
`The UE itself performs the prioritization of MBMS services for reception. The E-UTRAN
`is neither aware of which MBMS services a UE is interested in receiving (a UE may, for
`example, have successfully received an earlier transmission of a repeated session), nor about
`the priority ascribed to reception of each service by the UE. The details of prioritization
`are not specified, being left instead to UE implementation. A UE may, for example, choose
`to terminate a unicast service at the application layer if it prevents reception of an MBMS
`service that it has prioritized.
`
`Samsung Ex. 1010
`907 of 1365
`
`
`
`LTE – THE UMTS LONG TERM EVOLUTION
`304
`13.6 Radio Access Protocol Architecture and Signalling
`13.6.1 Protocol Architecture
`The LTE radio protocols have been extended in Release 9 to accommodate MBMS:
`• Two new types of logical channels are introduced in Release 9: the Multicast Control
`CHannel (MCCH) and the Multicast Traffic CHannel (MTCH) for MBMS control and
`user data respectively.
`• A new transport channel, the Multicast Channel (MCH), is introduced, mapped onto
`the PMCH to support the multicell MBSFN transmission mode.
`
`User data for an MBMS session may employ one or more radio bearers, each of which
`corresponds to an MTCH logical channel. The Medium Access Control (MAC) layer may
`multiplex information from multiple logical channels (MCCH and one or more MTCH)
`together in one transport block that is carried on the MCH.
`The MBMS control information is mainly carried by the MCCH, of which there is one per
`MBSFN area. The MCCH primarily carries the MBSFNAreaConfiguration message, which
`provides the radio bearer and (P)MCH configuration details, as well as the list of ongoing
`MBMS sessions. The remainder of the MBMS control information, consisting of the MCCH
`configuration and parameters related to the notification of changes in the MCCH information,
`clearly cannot be carried by the MCCH itself and is instead carried by the Broadcast Control
`CHannel (BCCH), in SIB13 (see Section 3.2.2). In Release 10, a further MCCH message
`was introduced for the counting procedure, as explained in Section 13.6.5.
`Figure 13.8 illustrates the radio protocol extensions introduced to accommodate MBMS.
`
`55&
`
`5DGLR
`%HDUHUV
`
`3'&3
`
`5/&
`
`/RJLFDO
`&KDQQHOV
`
`0$&
`
`7UDQVSRUW
`&KDQQHOV
`
`3+<
`
`3K\VLFDO
`&KDQQHOV
`
`0%06FRQWURO
`LQIRUPDWLRQ
`
`05%
`
`05%
`
`'5%
`
`6HJPHQWDWLRQ
`
`6HJPHQWDWLRQ
`
`6HJPHQWDWLRQ
`
`6HJPHQWDWLRQ
`
`0&&+
`
`07&+
`
`07&+
`
`07&+
`
`0XOWLSOH[LQJDQGG\QDPLFVFKHGXOLQJ
`
`0&+
`
`3K\VLFDOOD\HUIXQFWLRQV
`
`30&+
`
`Figure 13.8: LTE protocol extensions to support MBMS.
`
`Samsung Ex. 1010
`908 of 1365
`
`
`
`BROADCAST OPERATION
`13.6.2 Session Start Signalling
`As a result of the relative simplicity of MBMS in LTE Release 9, the main signalling
`procedures are for ‘session start’ and ‘session stop’. The absence of multicast support means
`that procedures for subscription and joining/leaving are not required; furthermore, service
`announcement is assumed to be an application-specific procedure, not part of the main
`MBMS signalling procedures.
`Figure 13.9 provides an overview of the session start message sequence.
`
`305
`
`8(
`
`H1%
`
`0&(
`
`&1
`
`6HVVLRQ6WDUW5HTXHVW
`
`6FKHGXOLQJ,QIRUPDWLRQ
`
`6HVVLRQ6WDUW5HVSRQVH
`
`6FKHGXOLQJ,QIRUPDWLRQ
`5
`
`6HVVLRQ6WDUW5HTXHVW
`
`6HVVLRQ6WDUW5HVSRQVH
`
`0&&+FKDQJHQRWLILFDWLRQ
`
`0%6)1$UHD&RQILJXUDWLRQXSGDWHG
`
`Figure 13.9: The MBMS session start message sequence.
`
`The BM-SC may initiate multiple subsessions with different content, distinguished by
`flow identifiers. The ‘Session Start Request’ message from the BM-SC includes the following
`parameters:
`• QoS: Used for the admission control and radio resource configuration in the MCE.
`• Service area: Used to decide to which eNodeBs the session start signalling should be
`forwarded.
`• Session duration: Used by admission control in the MCE.
`• Time to data transfer: Used by the MCE to ensure all UEs receive the control
`information in time.
`• Access indicator: Indicates in which Radio Access Technologies (RATs) the service
`will be broadcast.
`
`Upon receiving the session start request, the MCE performs admission control, allocates
`IP multicast addresses, and allocates and configures the radio resources. The MCE provides
`the relevant session parameters (e.g. the multicast address) to the eNodeB by means of
`the ‘Session Start Request’ message. Likewise, the MCE transfers the radio resource
`configuration within a ‘scheduling information’ message to the eNodeB. Upon receiving
`these messages, the eNodeB notifies the UEs about a change of MCCH information and
`subsequently provides the updated MBMS radio resource configuration information within
`the MBSFNAreaConfiguration message. The eNodeB also joins the transport network IP
`multicast address.
`The actual data transfer starts after a (configurable) duration, such as 10 s.
`
`Samsung Ex. 1010
`909 of 1365
`
`
`
`LTE – THE UMTS LONG TERM EVOLUTION
`306
`13.6.3 Radio Resource Control (RRC) Signalling Aspects
`13.6.3.1 Scheduling
`
`MBMS does not use the PDCCH for dynamic scheduling. In an MBSFN subframe, the MCH
`uses all the resources in the frequency domain, so MCH-related scheduling only relates to
`the subframe allocation in the time domain.
`The subframes that carry MCCH are indicated semi-statically by SIB13. For MTCH,
`the scheduling of which subframes are used for a particular MBMS bearer is somewhat
`more dynamic: once per ‘MCH Scheduling Period’ (MSP), E-UTRAN indicates which
`subframes are used for each MTCH. This ‘MCH Scheduling Information’ (MSI) is provided
`independently for each MCH by means of a MAC control element (see Section 4.4.2.7).
`One design goal for LTE MBMS was to avoid long service interruptions when the user
`switches from one service to another (i.e. channel switching). Assuming that the UE stores
`the complete MCCH information, the channel switching time is mainly determined by the
`length of the MSP; if E-UTRAN configures a reasonably low value for this parameter (e.g.
`320 ms), users can smoothly switch channels without noticeable delays.
`
`13.6.3.2 MBMS Control Information Validity and Change Notification
`
`As mentioned above, the MBMS control information is mainly carried by the MCCH; the
`BCCH merely carries the control information needed to acquire the MCCH and to detect
`MCCH information changes.
`Transmission of MBMS control information on the BCCH (i.e. in SIB13) is performed
`according to the usual procedures for SIBs (see Section 3.2.2.2). The transfer procedures
`for MBMS control information on the MCCH are similar: control information can only
`change at specific radio frames with System Frame Number (SFN) given by SFN mod m = 0,
`where m is the modification period. The MBSFNAreaConfiguration message is repeated a
`configurable number of times within the modification period.
`When an MBMS session is started, E-UTRAN notifies the UEs about an MCCH
`information change. This change notification is provided a configurable number of times
`per modification period, by means of a message on the PDCCH using Downlink Control
`Information (DCI) Format 1C (see Section 9.3.5.1), using a special identifier, the MBMS
`Radio Network Temporary Identifier (M-RNTI). This message indicates which of the
`configured MCCHs will change. UEs that are interested in receiving an MBMS session
`that has not yet started should try receiving the change notification a minimum number of
`times during the modification period. If the UE knows which MBSFN area(s) will be used
`to provide the MBMS session(s) it is interested in receiving, it has to meet this requirement
`only for the corresponding MCCH(s).
`Figure 13.10 illustrates a change of MBMS control information, affecting both the BCCH
`and the MCCH. In this example, E-UTRAN starts to use the updated configuration at an
`SFN at which the BCCH and MCCH modification period boundaries coincide. The figure
`illustrates the change notifications provided by E-UTRAN in such a case. Initially, the change
`notification indicates only that MCCH-2, which has a modification period of 10.24 s, will
`change. Later, the notification indicates that both MCCH-1 (which has a modification period
`of 5.12 s) and MCCH-2 will change.
`
`Samsung Ex. 1010
`910 of 1365
`
`
`
`307
`
`8SGDWHG%&&+DQG0&&+
`
`BROADCAST OPERATION
`
`%&&+
`FKDQJH
`QRWLILFDWLRQ
`
`0&&+
`FKDQJH
`QRWLILFDWLRQ
`
`%&&+
`
`0&&+
`
`0&&+
`
`
`
`
`
`
`
`
`
`6)1
`
`6)1
`
`6)1
`
`6)1
`
`6)1
`
`6)1
`
`Figure 13.10: An example of a change of MBMS control information.
`
`The change notification procedure is not used to inform UEs about modifications of
`ongoing sessions. UEs that are receiving an MBMS session are therefore required to acquire,
`every modification period, the MBMS control information of the MBSFN area used for that
`session.
`
`13.6.3.3 Radio Resource Allocation
`
`The network broadcasts in SIB13 a bitmap indicating to the UEs the set of subframes that is
`allocated to the MCCH. This bitmap covers a single radio frame. It is possible to configure a
`more robust Modulation and Coding Scheme (MCS) for the subframes that include MCCH.
`Semi-static resource allocation signalling indicates which subframes are allocated to a
`particular MBSFN area; this is known as the Common Subframe Allocation (CSA).10 The
`CSA is defined by up to eight patterns. Each pattern specifies the allocated subframes by a
`bitmap, that covers one or four radio frames, and repeats with a periodicity of up to 32 radio
`frames. The MCCH subframes are included in the CSA.
`Next, the subframes assigned to the MBSFN area are allocated to each of the MCHs using
`the MBSFN area. Within a CSA period, the MCHs are time-multiplexed, with each MCH
`using one or more subframes which are consecutive within the set of subframes in the CSA;
`as the subframes are consecutive in this way, only the last allocated subframe is signalled for
`each MCH. This is known as the MCH Subframe Allocation (MSA).
`The MBMS resource allocation is illustrated in Figure 13.11 for an example with two
`MBSFN areas:
`
`• In even-numbered radio frames, subframes 3 and 6 are allocated, while in odd-
`numbered radio frames only subframe 6 is allocated;
`• Within a period of 80 ms, the MBSFN areas are not interleaved – MBSFN area 1 takes
`the first 4.5 radio frames while area 2 takes the next 3.5;
`• Both MBSFN areas use two MCHs, one with an MSP of 160 ms and one with an MSP
`of 320 ms;
`
`10The term ‘common’ here indicates that the CSA subframes are shared by all the MCHs of the MBSFN area.
`
`Samsung Ex. 1010
`911 of 1365
`
`
`
`308
`
`L713 — THE UMTS LONG TERM EVOLU'HON
`
`0 Both MBSFN areas use a CSA period of 160 ms;
`o 'I\vo subframes are allocated to MCCH.
`
`III II IIIIIIIIII"III|III1 II IIIIIIIIII'IIII
`ll
`‘
`‘
`'
`
`“9"“
`IMOCH
`
` UmrumnvrMsm-am)
`
`------------v:
`
`.3.
`
`MBSFN
`sea 1
`
`ABSFN
`area 2
`
`..
`.
`
`mm m-
`
`Mmb
`
`:
`
`a.I.
`
`sm 0
`
`SH} 16
`
`SH] 32
`
`Figure 13.] I: An example of MBMS resource allocation.
`
`Every MSP, a UE that is receiving, for example, MCH-2b via MBSFN area 2 acquires the
`initial subframes to acquire MCCH (if present in this MSP), the MSI MAC control element
`(see Section 13.6.3.1) and subsequently the subframes dynamically allocated to the service
`in question.
`
`13.6.4 Content Synchronization
`
`the basic property of MBSFN transmission is that all
`As explained in Section [3.4,
`participating cells transmit exactly the same content in a synchronized manner so it appears
`as one transmission to the UE Mechanisms are therefore provided to ensure synchronization
`of the MBMS content — i.e. to ensure that all participating eNodeBs include the same MBMS
`control information and data in the corresponding time-synchronized subframes.
`For the MBMS control information, whenever the MCE updates the control information
`it indicates the modification period from which the updated control information applies by
`means of a parameter called ‘MCCH update time’.
`For the synchronization of MBMS user data, a specific protocol was designed: the SYNC
`protocol as specified in [8]. Each MBMS bearer operates a separate instance of the SYNC
`protocol, which uses a timestamp to indicate the time at which the eNodeB should start the
`transmission of a first packet belonging to a synchronization sequence. The timestamp is
`based on a common time reference and should be set taking into account transfer delays that
`may occur. All packets that the BM-SC allocates to a synchronization sequence are given
`the same timestamp. The MSP is the same as, or a multiple of, the synchronization sequence
`values applicable for the services carried by the MCH in question.
`
`Samsung Ex. 1010
`912 of 1365
`
`
`
`BROADCAST OPERATION
`
`309
`
`Before considering the details of the SYNC protocol, it is important to understand the
`overall architecture, which can be summarized as follows:
`• The BM-SC performs traffic shaping: it discards packets as necessary to ensure that,
`for each synchronization sequence, the actual bit rate of each MBMS bearer does not
`exceed the guaranteed bit rate (see Section 2.4).The BM-SC also decides in which
`synchronization sequence each packet should be transmitted.11
`• The MCE semi-statically configures which services are multiplexed together, as well
`as the radio resources allocated to the relevant MCH. The MCE also semi-statically
`configures the order in which the services are scheduled.
`• The participating eNodeBs first buffer all the packets of an entire MSP. The eNodeBs
`then dynamically schedule the services, taking into account the order pre-defined by
`the MCE. If the BM-SC allocates more packets to an MSP than actually fit into the
`allocated radio resources, the eNodeBs discard some of the packets, starting with the
`last packets of the service scheduled last according to the pre-defined order (so-called
`tail-dropping). Finally the eNodeBs compile the MSI. The resulting MAC control
`element is transmitted at the start of the MSP.
`
`Figure 13.12 illustrates the SYNC protocol by means of a typical sequence of the different
`SYNC Protocol Data Unit (PDU) types.
`
`H1%
`
`%0 6&
`
`6\QFSHULRGQ
`
`3'8W\SH8VHUGDWDXQFRPSUHVVHG
`!7LPHVWDPSSDFNHWQXPEHUHODSVHGRFWHWFRXQWSD\ORDG
`
`'DWD
`WUDQVIHU
`SKDVH
`
`6\QF
`SHULRG
`Q
`
`&RQFOXVLRQ
`SKDVH
`
`3'8W\SH6\QFLQIRZLWKRXWSD\ORDG
`!7LPHVWDPSSDFNHWQXPEHUHODSVHGRFWHWFRXQWWRWDOQXPEHURISDFNHWV
`
`3'8W\SH6\QFLQIRZLWKRXWSD\ORDG
`
`
`
`6\QFSHULRGQ
`
`Figure 13.12: An example of a SYNC protocol PDU sequence.
`
`11In a future release of LTE, it may become possible for the BM-SC to perform ‘radio-aware traffic shaping’
`– i.e. knowing which services share a given radio resource and their respective bit rates, the BM-SC may handle
`temporary rate fluctuations by moving some packets to a previous or later scheduling MSP.
`
`Samsung Ex. 1010
`913 of 1365
`
`
`
`310
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`The BM-SC transfers the data allocated to one synchronization sequence by means of a
`number of PDUs of ‘type 1’. These PDUs all include the same timestamp, a packet number
`that is reset at the start of the synchronization sequence and increases for every subsequent
`packet, and an elapsed octet counter that indicates the number of octets transferred since the
`start of the synchronization sequence.
`After transferring all the user data, the BM-SC may provide additional information by
`means of a PDU ‘type 0’ or ‘type 3’. These PDUs may be repeated to increase the likelihood
`the PDU is received correctly. PDU type 0 not only includes the regular timestamp, the
`packet number and the elapsed octet counter but also indicates the total number of packets
`and the total elapsed octets within the synchronization sequence. PDU type 3 provides the
`same information, but in addition provides the length of each packet in the synchronization
`sequence.
`The eNodeB has a buffer corresponding to one MSP, in which it inserts the received
`packets in accordance with the pre-defined service order. If one or more non-consecutive
`packets are