throbber
BROADCAST OPERATION
`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-SymbolInterference
`(ISD. In effect, this makes the MBSEFN 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 componentsofa single-cell transmission without incurring any additional
`complexity. Thisis 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 MBSEN 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. GPS’) or possibly synchronized backhaulprotocols(e.g. [6]).
`
`Synchronized eNodeBs
`transmitting MBMS data
`
`E
`
`SignalsfromdifferenteNodeBs
`arrivewithin cyclicprefixat UE
`
`|
`
`|
`
`OFDM symbol duration
`
`Cyclic
`Prefix ee
`SSSI
`
`ISI free window
`
`Figure 13.3: [SI-free operation with MBSEN 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 (SINR). 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 poweris increasedat the
`sametime as the interference powerbeing largely removed.
`An example of the improvementin performance achievable using MBSEN 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
`packetloss rate < 1%) is plotted against spectral efficiency of the MBMSdata transmissions
`(a measure of MBMSdata rate in a given bandwidth). A hexagonalcell-layout is assumed,
`with the MBSFN area comprising one, twoorthree 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 MBSEN area is increased and hence the surrounding inter-cell interference
`is reduced. A 1 km cell radius is assumed, with 46 dBm eNodeBtransmission power, 15 m
`eNodeBantenna height and 2 GHzcarrier frequency.
`
`
`—#-—Central cell surrounded by 3 rings of MBSFN cells
`—® Central cell surrounded by 2 rings of MBSFN cells
`
`
`__4__i.] —-&—Central cell surrounded by 1 ring of MBSFN cells
`|.
`;----| —¥—Central cell surrounded byinterferers
`Lt
`ae
`
`
`
` Coverage(ProbabtyofPacketErrorRate<1%)
`
`
`
`0.0
`
`05
`
`1.0
`
`1.5
`
`2.0
`
`2.5
`
`3.0
`
`Spectral Efficiency (bps/Hz)
`
`Figure 13.4: Reduction in total downlink resource usage achievable using MBSFN
`transmission [7]. Reproduced by permission of © 2007 Motorola.
`
`MBSEN data transmission takes place via the Multicast CHannel (MCH) transport
`channel, which is mapped to the Physical Multicast CHannel (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 effect a composite channel from multiple cells, it is necessary for the UE to perform
`a separate channel estimate for MBSEN 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 MBSEN in the same subframe, frequency-division multiplexing
`of the PMCH and PDSCHis 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
`
`LTE— THE UMTS LONG TERM EVOLUTION
`
`e Both MBSEN areas use a CSAperiod of 160 ms;
`e Two subframesare allocated to MCCH.
`
`HPAES) soe
`l
`,
`:,
`-
`i ccu
`
`SESE 1
`[I MsI(of MCH with same shade) i
`
`Figure 13.11: An example of MBMSresource allocation.
`
`Every MSP, a UEthatis 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 13.4,
`participating cells transmit exactly the same content in a synchronized mannerso it appears
`as one transmission to the UE. Mechanismsare therefore provided to ensure synchronization
`of the MBMScontent— i.e. to ensure thatall participating eNodeBsinclude the same MBMS
`control information and data in the corresponding time-synchronized subframes.
`For the MBMScontrol 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 ‘MCCHupdate time’.
`For the synchronization of MBMSuserdata, a specific protocol was designed: the SYNC
`protocol as specified in [8]. Each MBMSbeareroperates a separate instance of the SYNC
`protocol, which uses a timestampto 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 commontime reference and should be set taking into accounttransfer delays that
`may occur. All packets that the BM-SCallocates to a synchronization sequence are given
`the same timestamp. The MSPis the sameas, or a multiple of, the synchronization sequence
`values applicable for the services carried by the MCHin 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 lost, the SYNC protocol provides the eNodeB with all the information required
`to continue filling the transmission buffer correctly. In such cases, the eNodeB only needs to
`mute the subframes affected by the lost packets (rather than muting all subsequent subframes
`until the end of

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket