US20160007319A1

US20160007319A1 - Method and apparatus for multimedia broadcast multicast service (mbms) control information delivery

Info

Publication number: US20160007319A1
Application number: US14/766,858
Authority: US
Inventors: Hong He; Yujian Zhang; Seunghee Han; Jong-Kae Fwu; Mo-Han Fong; Kamran Etemad
Original assignee: Intel IP Corporation
Current assignee: Intel Corp
Priority date: 2013-03-01
Filing date: 2013-12-17
Publication date: 2016-01-07
Also published as: CN108322914B; CN104995852B; US20150373510A1; CN104982074B; EP2962485A1; WO2014133603A1; EP2962435A4; WO2014133642A1; CN104956631A; EP2962487A1; CN104956766B; US20210014828A1; ES2701858T3; US10743288B2; US10420073B2; CN105009664B; US9814021B2; CN104956766A; CN104956721B; US20140334380A1

Abstract

Apparatuses and methods for providing multimedia broadcast multicast service (MBMS) on carriers of a new carrier type (NCT) are described herein. A user equipment (UE) may transmit a message to indicate an interest in receiving MBMS transmissions on a target cell that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink frame. The UE may receive, in response to transmitting the message, identification information of a notification cell on which to receive MBMS control information change notification for the target cell. The UE may receive MBMS traffic from the target cell using the MBMS control information received from the notification cell. The UE may receive the MBMS control information on a second carrier of a second carrier type different from the first carrier type.

Description

PRIORITY CLAIM

This application claims the benefit of priority to U.S. Provisional Patent Application No. 61/771,698, filed on Mar. 1, 2013, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments described herein pertain generally to wireless communications. More particularly, the present disclosure relates to provisioning of multimedia broadcast multicast service (MBMS) on carriers of a new carrier type (NCT).

BACKGROUND

Current 3rd Generation Partnership Project (3GPP) long term evolution (LTE) specifications allow operators to provide broadcast and multicast services. Technologies such as Multimedia Broadcast Multicast Service (MBMS) can provide sought-after services such as live streaming in public areas, pushed content via user equipment caching, and machine-to-machine services. There is an ongoing need to provide these services in an efficient manner.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating a system in which some embodiments may be implemented.

FIG. 2 illustrates change notification in accordance with a first embodiment.

FIG. 3 illustrates change notification in accordance with a second embodiment.

FIG. 4 is a block diagram of the basic components of a user equipment (UE) in accordance with some embodiments.

FIG. 5 is a block diagram showing details of an eNodeB according to some embodiments.

FIG. 6 is a flow chart of a method, performed by a UE, for communicating in a wireless network.

FIG. 7 is a flow chart of a method, performed by an eNodeB, for communicating in a wireless network.

DETAILED DESCRIPTION

FIG. 1 is a schematic diagram illustrating a system 100 in which some embodiments may be implemented. The system 100 includes a user equipment (UE) 102, which can communicate wirelessly with a PCell 104 over a wireless communication link 108. Communication link 108 includes one or more communication channels. These channels can include a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH) with downlink control information (DCI) transmitted on the downlink (or DCI not transmitted on the downlink), and any other channel for transmitting control (e.g. scheduling or power) information or data on the uplink or downlink. Because system 100 may support carrier aggregation (e.g. may be an LTE-A system) these channels may include one or more aggregated component carriers.
PCell 104 may be a cell associated with a macro network, such as, but not limited to, a radio access network or cellular network. For example, in some examples, PCell 104 can include a PCell in LTE-Advanced communication environments. In various embodiments, PCell 104 may be associated with a PCell network entity 106. PCell network entity 106 can include one or more of any type of network module, such as an access point, a macro cell, including a base station (BS), node B, eNodeB, a relay, a peer-to-peer device, an authentication, authorization and accounting (AAA) server, a mobile switching center (MSC), a radio network controller (RNC). Additionally, the network entity associated with PCell 104 may communicate with one or more other network entities of wireless and/or core networks, such as, but not limited to, wide-area networks (WAN), wireless networks (e.g. 802.11 or cellular network), the Public Switched Telephone Network (PSTN) network, ad hoc networks, personal area networks (e.g. Bluetooth®) or other combinations or permutations of network protocols and network types. Such network(s) may include a single local area network (LAN) or wide-area network (WAN), or combinations of LANs or WANs, such as the Internet.
In a various embodiments, UE 102 may communicate with one or more SCells 110 via one or more communication links 112. In some examples, the one or more SCells 110 may include SCells in LTE-Advanced communication environments. UE 102 may be configured to communicate simultaneously with PCell 104 and the one or more SCells 110, for example, via a plurality of antennas of UE 102. Communication link 112 may include one or more communication channels, which may include a PUCCH, a PUSCH with DCI transmitted on the downlink (or DCI not transmitted on the downlink), and any other channel for transmitting control (e.g. scheduling or power) information or data on the uplink or downlink.
SCells 110 may be small cells or low power cells, controlled by or otherwise associated with one or more network entities 114 or modules, such as, but not limited to a low-power access point, such as a picocell, femtocell, microcell, WiFi hotspot, etc. Additionally, SCells 110 may communicate with one or more other network entities of wireless and/or core networks, such as, but not limited to, wide-area networks (WAN), wireless networks (e.g. 802.11 or cellular network), the Public Switched Telephone Network (PSTN) network, ad hoc networks, personal area networks (e.g. Bluetooth®) or other combinations or permutations of network protocols and network types. Such network(s) may include a single local area network (LAN) or wide-area network (WAN), or combinations of LANs or WANs, such as the Internet.
Additionally, system 100, which may include PCell 104 and one or more SCells 110, may comprise a Wideband Code Division Multiple Access (W-CDMA) system, and PCell 104 and one or more SCells 110 may communicate with one or more UEs 102 according to this standard. The actual telecommunication standard, network architecture, and/or communication standard employed will depend on the specific application and the overall design constraints imposed on the system. The various devices coupled to the network(s) (e.g. UE 102 and/or network entities serving PCell 104 and/or SCells 110) may be coupled to the network(s) via one or more wired or wireless connections.
The system 100 can use MBMS or evolved MBMS (eMBMS) to provide broadcast and multicast services over LTE. Using eMBMS, the system 100 can provide services such as live streaming in a stadium, pushed content via user equipment caching or machine-to-machine services, etc. New carrier types (NCTs), introduced with 3GPP Rel. 12, can provide more efficient usage of radio resources and backhaul resources. Operators may therefore wish to provide eMBMS on the NCT.
Network entities 106, 114, can provide MBMS over logical channels that can include a Multicast Traffic Channel (MTCH) and Multicast Control CHannel (MCCH). Network entities 106, 114, transmit MBMS control information to the UE 102, for one or more MTCHs, on the MCCH. Moreover, network entities 106, 114 can provide some MBMS control information, including scheduling information and MCCH information change notifications, in a MBMS-specific System Information Block (SIB), for example SIB13 defined in a standard of the 3GPP family of standards.
In some current systems, when a network entity 106, 114 changes certain MCCH information, the corresponding network entity 106, 114 notifies the UE 102 about which of the MCCHs will change by transmitting DCI using a cyclic redundancy check (CRC) scrambled with a MBMS radio network temporary identifier (M-RNTI) on the common search space (CSS) of a physical downlink control channel (PDCCH). However, NCT, introduced in 3GPP for LTE Rel. 12, may not support these methods of MBMS change notification. For example, because NCT may remove CRS on downlink subframes, and UE 102 uses CRS to decode control channels, a UE 102 cannot demodulate legacy control channels such as PDCCH, transmitted on NCT carriers. Further, current implementations of NCT do not support CSS on PDCCH. In some embodiments, NCT may suppress CRS on four out of five subframes, although the scope of the embodiments is not limited in this respect.
Example embodiments provide methods to address these and other challenges to deliver MBMS related system information and control information on NCT, thereby enabling MBMS on NCT in 3GPP Rel. 12 and later. In various embodiments, a network entity, for example network entity 106, provides MCCH configuration information acquisition and MCCH information change notification over carriers of other carrier types (e.g., legacy carrier types (LCTs)) other than NCT.
In some embodiments, an LCT network entity, for example a network entity 106 associated with a PCell 104, can transmit MCCH configuration information pertaining to an NCT SCell 110 associated with the network entity 114. The network entity 106 can transmit the MCCH configuration information to a UE 102 when the NCT SCell 110 is added if the UE 102 first informs the network entity 106 that the UE 102 wishes to receive MBMS traffic from the NCT SCell 110. Then other network entities associated with other LCT serving cells, for example network entity 106 associated with the PCell 104, can transmit notifications of MCCH information changes pertaining to the NCT SCell 110. While the description of example embodiments provided below refers to serving PCells transmitting MCCH information changes pertaining to an NCT SCell, embodiments are not limited thereto and serving LCT SCells can transmit MCCH information changes pertaining to an NCT SCell 110.

Acquisition of MCCH Configuration Information

In various embodiments, a network entity 106 can perform radio resource control (RRC) signaling to provide MCCH configuration information, pertaining to an NCT SCell 110, to the UE 102. An example RRC message expressed in Abstract Syntax Notation .1 (ASN.1) for providing MCCH configuration information is as follows:


--ASN1 START
RadioResourceConfigCommonSCell-r10 ::= SEQUENCE {
...

[[mbsfn-AreaInfoList-r9	MBSFN-AreaInfoList-r9 OPTIONAL,
--Need
OR
notificationConfig-r9	MBMS-NotificationConfig-r9
OPTIONAL, --
Need OR
]]
...
}
...

MBMS-NotificationConfig-r9 ::=	SEQUENCE {
notificationRepetitionCoeff-r9	ENUMERATED {n2, n4},

notificationOffset-r9

INTEGER (0...10),

notificationSF-Index-r9

INTEGER (1...6),

[[ NotificationCellId-r12	ServCellIndex-r10, OPTIONAL, --Need
ON
]]
}
--ASN1 STOP

In the above code fragment, mbsfn-AreaInfoList and notificationConfig are MCCH-related parameters for the pertinent NCT SCell defined in the information element (IE) RadioResourceConfigCommonSCell. These parameters are cell-specific and applicable to an NCT SCell. NotificationCellId indicates which cell, for example network entity 106 associated with a PCell, shall signal the MCCH information change notification for the pertinent NCT SCell.
In various other embodiments, the notification cell can be specified, for example the notification cell can be defined as a UE-specific PCell, rather than being configurable. In at least these embodiments, NotificationCellId-r12 will not be included in the MBMS-NotificationConfig-r9 IE described above. A range of values for notificationOffset may be set or extended so that multiple notifications for multiple information change notifications can be transmitted on a common carrier (CC) in a Time Domain Multiplexing (TDM) or Time Domain Duplexing (TDD) manner based on different notificationOffset values, as discussed in more detail below.

NCT MCCH Information Change Notification

The UE 102 can receive NCT MCCH information change notifications using one or more methods described below with respect to various embodiments.
In some embodiments, the UE 102 monitors the PDCCH of a PCell or SCell, for example the PCell associated with the network entity 106, for DCI format 1C identified by a M-RNTI in each CC-specific modification period for notification of MCCH changes on the intended NCT SCell. The MCCH(s) repetition period and modification period on NCT are independently configurable by parameters included in MBMS-NotificationConfig-r9 as described above.
FIG. 2 illustrates change notification in accordance with these and other embodiments. In FIG. 2, MBMS is deployed on an LCT PCell 205, an LCT SCell 210, and an NCT SCell (not shown in FIG. 2). MCCH is configured on each cell with a repetition period 215. A UE 102 (FIG. 1), which is CA and MBMS capable, receives MBMS services on LCT PCell 205, LCT SCell 210, and the NCT SCell. In the illustrative example of FIG. 2, PCell 205 has been configured as the notification cell for MCCH information changes on the NCT SCell. Accordingly, PCell 205 transmits notifications for MCCH information changes 220, 222 on the PCell and the NCT SCell respectively, on the CSS on a PDCCH in a TDM manner. The notifications 220, 222 can be transmitted periodically in repetition periods 215 with modifications occurring no more than once in any modification period 224. SCell 210 transmits notifications 226 of MCCH information changes on SCell 210, also in a TDM manner with the notifications transmitted on PCell 205. Therefore, some embodiments allow the UE 102 to receive notifications about changes of MCCH on an NCT SCell, even if CSS is unavailable on the NCT SCell. The UE 102 uses only one M-RNTI value for multiple target SCells, and the UE 102 determines which cell pertains to the detected PDCCH based on configured periodicity and offset parameters described above.
In other embodiments, a network entity, for example network entity 106 associated with a PCell 104, can transmit a MAC Control Element (CE) dedicated for MCCH information change notification. The notification-specific MAC CE is scheduled using the cell radio network temporary identifier (C-RNTI) of the UE 102. The C-RNTI can be identified by a MAC protocol data unit (PDU) subheader with a logical channel identifier (LCID) specified. In at least these embodiments, the network entity 106 can provide RRC signaling at least somewhat similar to that described above, except that MBMS-NotificationConfig-r9 may not be included. The MCCH information change notification MAC CE may include a field to indicate an index of an SCell to which the MCCH information change notification applies. The MCCH information change notification MAC CE may also include a field to indicate which of the MCCHs will change.
In other embodiments, notifications 320, 322 for several MBMS cells can be transmitted in the same subframe in one LCT serving cell 205, as shown in FIG. 3. The notifications 320, 322 can be transmitted periodically in repetition periods 315 with modifications occurring no more than once in any modification period 324. Different M-RNTIs can differentiate the MBMS cells to which a notification is applicable. In at least these embodiments, a field, for example mbsfnAreaInfoList, can be added into the RadioResourceConfigCommonSCell IE described above, as a non-critical extension. A network entity 106 can transmit this IE to a UE 102 when an NCT SCell is added. The IE can include at least two other fields, for example NotificationCellId and m-RNTI, to indicate which cell signals the MCCH information change notification, if applicable, and the exclusive m-RNTI used by DCI format 1C for notification. In at least these embodiments, the network entity 106 may not transmit the MBMS-NotificationConfig IE, described above, because the UE 102 can obtain the pertinent information from the serving cell indicated by NotificationCellId. An example RRC message expressed in ASN.1 for providing this information is as follows:


--ASN1 START
RadioResourceConfigCommonSCell-r10 ::= SEQUENCE {
...

[[mbsfn-AreaInfoList-r9	MBSFN-AreaInfoList-r9	OPTIONAL, --
Need
OR

NotificationCellId-r12	ServCellIndex-r10, OPTIONAL, --Need
OR

m-RNTI	M-RNTI	OPTIONAL, --
Need OR
]]
...
}
...
--ASN1 STOP

The above method implies that the range of M-RNTI values needs to be further extended so that multiple MBMS-specific M-RNTI values are available for configuration. M-RNTI can be indicated as below:


	--ASN1 START
	M-RNTI ::= BIT STRING (SIZE(16))
	--ASN1 STOP

In other embodiments, M-RNTI is defined by reserving to reserve a set of RNTIs, and the IE signals an index into the set:


	--ASN1 START
	M-RNTI ::= INTEGER (0...3)
	--ASN1 STOP

Embodiments for Multicast Search Space and Embodiments for Single-Frequency Network Operation

In some embodiments, control channel elements (CCEs) can be reserved on the PDCCH of an LCT PCell or SCell for NCT SCell MCCH information change notifications, thereby construction an MBMS-specific search space (MSS). A network entity 106 or 114 can transmit DCI format IC including a Carrier Indicator Field (CIF) on the MSS for blind detection by the UE 102 on predefined subframe(s).
Some embodiments can also be used for single-frequency network (SFN) services. In some current systems a value, for example non-MBSFNregionLength defined in 3GPP TS 36.211 Table 6.7-1, indicates how many symbols from the beginning of a subframe constitute the non-MBSFN region. This value can be defined as “0” for systems in which all cells operate on carriers of NCT, because NCT does not need a non-MBSFN region as this region is only used for legacy PDCCH transmission. A non-MBSFN region length can be defined according to below:


MBSFN-AreaInfoList-r9 ::= SEQUENCE (SIZE(1...maxMBSFN-Area))
OF MBSFN-AreaInfo-r9
MBSFN-AreaInfo-r12 ::= SEQUENCE {
...
Non-MBSFNregionLength-r12 ENUMERATED {s0, s1, s2},
...
}

In some embodiments, the starting symbol of an MBSFN subframe can follow, for example the EPDCCH starting symbol, defined by, e.g., epdcch-StartSymbol-r11. In some embodiments, epdcch-StartSymbol-r12 is defined to include a possible value of “0.” In other embodiments, the starting symbol of an MBSFN subframe can follow, for example, a PDSCH starting symbol for cross-carrier scheduling, defined by, e.g., pdsch-Start-r10. In some embodiments, pdsch-Start-r12 is defined to include a possible value of “0.” The specified value for a starting symbol can be interpreted in at least two ways. For example, the value of the starting symbol minus 1 can correspond to orthogonal frequency division multiplexing (OFDM) symbols for a non-MBSFN region. As another example, the value of the starting symbol can correspond to the starting symbol for MBSFN region.

Example Device for Implementing Embodiments

FIG. 4 is a block diagram of the basic components of a UE 400 in accordance with some embodiments. The UE 400 may be suitable as a UE 102 (FIG. 1). The UE 400 may support methods for receiving MBMS from NCT SCells, in accordance with embodiments described above with respect to FIG. 1-3.
The UE 400 includes one or more antennas 410 arranged to communicate with a base station (BS), a network entity 106 or 114 (FIG. 1), or other types of wireless local area network (WLAN) access points. The UE 400 further includes a processor 420, instructions 425, and a memory 430. The UE 400 may further include a communications interface 440. In one embodiment, the memory 430 includes, but is not limited to, random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), double data rate (DDR) SDRAM (DDR-SDRAM), or any device capable of supporting high-speed buffering of data.
Example embodiments allow a UE 400 to transmit, using the communications interface 440, a message to indicate an interest in receiving MBMS transmissions on a target cell that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame. The target cell can include, for example, SCell 110 (FIG. 1). In at least one embodiment, the communications interface 440 is, for example, a wireless physical layer which operates according to a multiple input/multiple output (MIMO) operation.
The communications interface 440 may receive, in response to transmitting the message, identification information of a notification cell on which to receive MBMS control information change notification for the target cell. As described above with respect to FIG. 2-3, the communication interface 440 can receive an identity of the notification cell in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3GPP family of standards. The notification cell can include, for example, PCell 104 (FIG. 1).
The communications interface 440 can receive MBMS traffic from the target cell using the MBMS control information received from the notification cell. The communications interface 440 can receive the MBMS traffic on the first carrier and the MBMS control information on a second carrier of a second carrier type different from the first carrier type. The first carrier type can be a new carrier type (NCT) implemented in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards and the second carrier type can be a legacy carrier type on which CRSs are not suppressed.
The communications interface 440 can receive a change notification to notify of a change of the MBMS control information associated with MBMS traffic transmitted on NCT. The change notification can be received according to any of the embodiments described above with respect to FIG. 1-3. For example, the communications interface 440 can receive the change notification by decoding a physical downlink control channel (PDCCH) of the notification cell, using a cyclic redundancy check (CRC) scrambled with an MBMS radio network temporary identifier (M-RNTI) of the target cell. The PDCCH can be configurable by a parameter indicating a radio frame offset for a change notification transmitted on the PDCCH. As a further example, the communications interface 440 can receive the change notification in a media access control (MAC) control element (CE). The communications interface 440 can receive a plurality of change notifications for a plurality of MBMS serving cells, at least two of the plurality of change notifications being received in a same subframe of a change notification period and each of the at least two change notifications being scrambled based on a M-RNTI of the respective MBMS serving cell. As described above, the communications interface 440 can receive the plurality of notifications in different subframes in a TDD or TDM manner.
The UE 400 can store, for example in memory 430, resource assignment information representative of multicast search space (MSS) information on a PDCCH of the second carrier type. The communications interface 440 can then receive change notifications using the MSS.
The processor 420 may include logic or code to enable the UE 400 to process signals received from the network through the antenna 410. The processor 420 may include code or other instructions 425 to allow the UE 400 to transmit a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame, as described above with respect to FIG. 1-3. The instructions 425 may further allow the UE 400 to receive, in response to transmitting the message, identification information of a notification cell on which to receive MBMS control information change notification for the target cell. The instructions 425 may further allow the UE 400 to receive MBMS traffic from the target cell using the MBMS control information received from the notification cell, the MBMS traffic being received on the first carrier and the MBMS control information being received on a second carrier of a second carrier type different from the first carrier type.
The UE 400 may be a mobile device, such as, but not limited to, a smartphone, cellular telephone, mobile phone, laptop computer, tablet computer, or other portable networked device. The UE 400 may be referred to by those of ordinary skill in the art as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. In general, the UE 400 may be small and light enough to be considered portable.

Example eNodeB for Implementing Embodiments

FIG. 5 is a block diagram showing details of an eNodeB 500 according to some embodiments. The eNodeB 500 may be suitable as a network entity 106 or 114 (FIG. 1). The eNodeB 500 includes a processor 510, a memory 520, a transceiver 530, and instructions 535. The eNodeB 500 may include other elements (not shown).
The processor 510 comprises one or more central processing units (CPUs), graphics processing units (GPUs), or both. The processor 510 provides processing and control functionalities for the eNodeB 500. Memory 520 comprises one or more transient and static memory units configured to store instructions 535 and data for the eNodeB 500.
The transceiver 530 comprises one or more transceivers including a multiple-input and multiple-output (MIMO) antenna to support MIMO communications. The transceiver 530 receives UL transmissions and transmits DL transmissions, among other things, from and to UE 102 (FIG. 1).
The transceiver 530 can receive an indication that UE 102 desires to receive MBMS transmissions from an SCell (for example SCell 110 (FIG. 1)) that operates on a first carrier of a first carrier type on which CRSs are suppressed at one or more downlink subframes of a downlink radio frame. The transceiver 530 can provide notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.
The transceiver 530 can receive notification cell information in a transmission of a second carrier of a second carrier type different from the first carrier type. The first carrier type can be an NCT implemented in accordance with a standard of the 3GPP family of standards and the second carrier type can be a legacy carrier type on which CRSs are not suppressed.
The transceiver 530 can transmit, on a physical downlink control channel (PDCCH), change notifications to notify of a change of the MBMS control information for the MBMS traffic transmitted on the SCell. The transceiver 530 can transmit a plurality of MBMS control information change notifications according to a TDD scheme.
The instructions 535 comprise one or more sets of instructions or software executed on a computing device (or machine) to cause such computing device (or machine) to perform any of the methodologies discussed herein. The instructions 535 (also referred to as computer- or machine-executable instructions) may reside, completely or at least partially, within the processor 510 and/or the memory 520 during execution thereof by the eNodeB 500. The processor 510 and memory 520 also comprise machine-readable media.
As those of ordinary skill in the art will readily appreciate, various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures and communication standards. By way of non-limiting example, various aspects may be extended to other Universal Mobile Telecommunications System (UMTS) systems. Various aspects can be used in systems employing Long Term Evolution (LTE) (in FDD, TDD, or both modes), and LTE-Advanced (LTE-A) (in FDD, TDD, or both modes).
Examples, as described herein, may include, or may operate on, logic or a number of components, components, or mechanisms. Components are tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g. internally or with respect to external entities such as other circuits) in a specified manner as a component. In an example, the whole or part of one or more computer systems (e.g. a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g. instructions, an application portion, or an application) as a component that operates to perform specified operations. In an example, the software may reside (1) on a non-transitory machine-readable medium or (2) in a transmission signal. In an example, the software, when executed by the underlying hardware of the component, causes the hardware to perform the specified operations.
Accordingly, the terms “component” and “component” are understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g. hardwired), or temporarily (e.g. transitorily) configured (e.g. programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which components are temporarily configured, one instantiation of a component may not exist simultaneously with another instantiation of the same or different component. For example, where the components comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different components at different times. Accordingly, software may configure a hardware processor, for example, to constitute a particular component at one instance of time and to constitute a different component at a different instance of time.
Additional examples of the presently described method, system, and device embodiments include the following, non-limiting configurations. Each of the following non-limiting examples may stand on its own, or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure. The preceding description and the drawings sufficiently illustrate specific embodiments to enable those of ordinary skill in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments.
FIG. 6 is a flow chart of a method 600, performed by a UE, for communicating in a wireless network. The method can be performed by, for example, UE 102 (FIG. 1).
In operation 610, the UE 102 transmits a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell, the target cell transmitting on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame.
In operation 620, the UE 102 receives, responsive to the message and in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards, an identity of a notification cell, different from the target cell, on which to receive MBMS control information and MBMS control information change notifications of the target cell.
In operation 630, the UE 102 receives MBMS traffic from the target cell using the MBMS control information received from the notification cell. The MBMS traffic can be received on the first carrier and the MBMS control information being received on a second carrier of a legacy carrier type different from the NCT on which CRSs are not suppressed.
As described above with respect to FIG. 2-3 and FIG. 4, the UE 102 can receive, in a physical downlink control channel (PDCCH) of the notification cell or in a media access control (MAC) control element, a change notification to notify of a change of the MBMS control information corresponding to the target cell. The UE 102 can receive a plurality of change notifications for a plurality of MBMS serving cells. By way of nonlimiting example, at least two of the plurality of change notifications can be received in a same subframe of a change notification period. In at least this illustrative example, each of the at least two change notifications are scrambled based on a MBMS radio network temporary identifier (M-RNTI) of the respective MBMS serving cell.
The UE 102 can also receive MBMS traffic in a multicast-broadcast single-frequency network (MBSFN) from a plurality of cells that use NCT. The UE 102 can receive a message on a physical control format indicator channel (PCFICH) that indicates that a non-MBSFN region shall not be included in at least one MBSFN subframe of the MBMS traffic.
FIG. 7 illustrates a method 700, performed by an eNodeB such as network entity 106 (FIG. 1), for operating in a network. The eNodeB can be, for example, network entity 106 (FIG. 1). In operation 710, the network entity 106 receives an indication that a user equipment (UE) desires to receive multimedia broadcast multicast service (MBMS) transmissions from a secondary cell (SCell) that operates on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame.
In operation 720, the network entity 106 receives notification cell information in a transmission of a second carrier of a second carrier type different from the NCT and on which CRSs are not suppressed.
In operation 730, the network entity 106 provides notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.
Example embodiments described above may allow a UE to receive MBMS traffic on NCT carriers. Because NCT carriers can be more efficient than some legacy carriers, operators can provide in-demand MBMS services in a more cost-effective fashion.
The embodiments as described above may be implemented in various hardware configurations that may include a processor for executing instructions that perform the techniques described. Such instructions may be contained in a suitable storage medium from which they are transferred to a memory or other processor-executable medium.
It will be appreciated that, for clarity purposes, the above description describes some embodiments with reference to different functional units or processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from embodiments. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Although the present inventive subject matter has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. One of ordinary skill in the art would recognize that various features of the described embodiments may be combined in accordance with the disclosure. Moreover, it will be appreciated that various modifications and alterations may be made by those of ordinary skill in the art without departing from the scope of the disclosure.
The Abstract is provided to comply with 37 C.F.R. Section 1.72(b) requiring an abstract that will allow the reader to ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to limit or interpret the scope or meaning of the claims. The following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Additional Notes & Examples

Example 1 can include the subject matter embodied by a wireless communication device such as a user equipment (UE), comprising circuitry to transmit a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame; receive in response to transmitting the message, identification information of a notification cell on which to receive MBMS control information change notification for the target cell; and receive MBMS traffic from the target cell using the MBMS control information received from the notification cell, the MBMS traffic being received on the first carrier and the MBMS control information being received on a second carrier of a second carrier type different from the first carrier type.
Example 2 may include, or may optionally be combined with the subject matter of Example 1 to optionally include an aspect wherein the first carrier type is a new carrier type (NCT) implemented in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards and wherein the second carrier type is a legacy carrier type on which CRSs are not suppressed.
Example 3 may include, or may optionally be combined with the subject matter of Examples 1 and/or 2 to optionally include an aspect wherein an identity of the notification cell is received in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3GPP family of standards.
Example 4 may include, or may optionally be combined with the subject matter of any of Examples 1-3, to optionally include an aspect wherein the physical layer circuitry is further arranged to receive a change notification to notify of a change of the MBMS control information associated with MBMS traffic transmitted on NCT.
Example 5 may include, or may optionally be combined with the subject matter of any of Examples 1-4, to optionally include an aspect wherein the physical layer circuitry is further arranged receive the change notification by decoding a physical downlink control channel (PDCCH) of the notification cell, using a cyclic redundancy check (CRC) scrambled with an MBMS radio network temporary identifier (M-RNTI) of the target cell.
Example 6 may include, or may optionally be combined with the subject matter of any of Examples 1-5, to optionally include an aspect wherein the PDCCH is configurable by a parameter indicating a radio frame offset for a change notification transmitted on the PDCCH.
Example 7 may include, or may optionally be combined with the subject matter of any of Examples 1-6, to optionally include an aspect wherein the physical layer circuitry is further arranged to receive the change notification in a media access control (MAC) control element (CE).
Example 8 may include, or may optionally be combined with the subject matter of any of Examples 1-7, to optionally include an aspect wherein the physical layer circuitry is further arranged to receive a plurality of change notifications for a plurality of MBMS serving cells, at least two of the plurality of change notifications being received in a same subframe of a change notification period and each of the at least two change notifications being scrambled based on a M-RNTI of the respective MBMS serving cell.
Example 9 may include, or may optionally be combined with the subject matter of any of Examples 1-8, to optionally include a memory to store resource assignment information representative of multicast search space (MSS) information on a PDCCH of the second carrier type, and wherein the physical layer circuitry is further arranged to receive change notifications using the MSS.
Example 10 may include, or may optionally be combined with the subject matter of any of Examples 1-9 to optionally include an aspect wherein the UE is further configured to receive MBMS traffic from the target cell according to a higher-layer configured parameter that indicates a number of symbols, from a start of a subframe, shall constitute a non-multicast broadcast single frequency network (MBSFN) region.
Example 11 may include subject matter (such as an apparatus, mobile apparatus, MTC device, user equipment, network device, eNodeB, communication apparatus or device, hardware, component, or component), including a transceiver arranged to receive an indication that a user equipment (UE) desires to receive multimedia broadcast multicast service (MBMS) transmissions from a secondary cell (SCell) that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink frame; and provide notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.
Example 12 may include subject matter (such as an apparatus, mobile apparatus, MTC device, user equipment, network device, eNodeB, communication apparatus or device, hardware, component, or component), which may optionally be in addition to any one or combination of Examples 1-11, to optionally include an aspect wherein the transceiver is arranged to receive notification cell information in a transmission of a second carrier of a second carrier type different from the first carrier type.
Example 13 may include subject matter (such as an apparatus, mobile apparatus, MTC device, user equipment, network device, eNodeB, communication apparatus or device, hardware, component, or component), which may optionally be in addition to any one or combination of Examples 1-12, to optionally include an aspect wherein the first carrier type is a new carrier type (NCT) implemented in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards and the second carrier type is a legacy carrier type and wherein the second carrier type is a legacy carrier type on which CRSs are not suppressed.
Example 14 may include subject matter (such as an apparatus, mobile apparatus, MTC device, user equipment, network device, eNodeB, communication apparatus or device, hardware, component, or component), which may optionally be in addition to any one or combination of Examples 1-13, to optionally include an aspect wherein the transceiver is further arranged to transmit, on a physical downlink control channel (PDCCH), change notifications to notify of a change of the MBMS control information for the MBMS traffic transmitted on the SCell.
Example 15 may include subject matter (such as an apparatus, mobile apparatus, MTC device, user equipment, network device, eNodeB, communication apparatus or device, hardware, component, or component), which may optionally be in addition to any one or combination of Examples 1-14, to optionally include an aspect wherein the transceiver is further arranged to transmit a plurality of MBMS control information change notifications according to a time division duplex (TDD) scheme.
Example 16 may include subject matter (such as a method or means for performing actions), including transmitting a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell, the target cell transmitting on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame; receiving, responsive to the message and in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards, an identity of a notification cell, different from the target cell, on which to receive MBMS control information and MBMS control information change notifications of the target cell; and receiving MBMS traffic from the target cell using the MBMS control information received from the notification cell, the MBMS traffic being received on the first carrier and the MBMS control information being received on a second carrier of a legacy carrier type different from the NCT on which CRSs are not suppressed.
In Example 17, the subject matter of Example 16 can optionally include receiving, in a physical downlink control channel (PDCCH) of the notification cell or in a media access control (MAC) control element, a change notification to notify of a change of the MBMS control information corresponding to the target cell.
In Example 18 the subject matter of examples 16-17 can optionally include receiving a plurality of change notifications for a plurality of MBMS serving cells, wherein at least two of the plurality of change notifications are received in a same subframe of a change notification period and each of the at least two change notifications are scrambled based on a MBMS radio network temporary identifier (M-RNTI) of the respective MBMS serving cell.
In Example 19, the subject matter of examples 16-18 can optionally include an aspect wherein the MBMS traffic is received in a multicast-broadcast single-frequency network (MBSFN) from a plurality of cells that use NCT, and the method further comprises receiving a message on a physical control format indicator channel (PCFICH) that indicates that a non-MBSFN region shall not be included in at least one MBSFN subframe of the MBMS traffic.
Example 20 may include subject matter (such as a method or means for performing actions), including receiving an indication that a user equipment (UE) desires to receive multimedia broadcast multicast service (MBMS) transmissions from a secondary cell (SCell) that operates on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink frame; receiving notification cell information in a transmission of a second carrier of a second carrier type different from the NCT and on which CRSs are not suppressed; and providing notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.
In Example 21, the subject matter of Example 20 can optionally include transmitting, on a physical downlink control channel (PDCCH), change notifications to notify of a change of the MBMS control information for the MBMS traffic transmitted on the SCell.
In Example 22, the subject matter of Example 20-21 can optionally include optionally include an aspect wherein the eNodeB transmits change notifications for the SCell and at least one other cell according to a time division duplex (TDD) scheme.

Claims

1.-22. (canceled)

23. A user equipment (UE) for operating in a network, the UE comprising physical layer circuitry to:

transmit a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame;

receive, in response to transmitting the message, identification information of a notification cell on which to receive MBMS control information change notification for the target cell; and

receive MBMS traffic from the target cell using the MBMS control information received from the notification cell, the MBMS traffic being received on the first carrier and the MBMS control information being received on a second carrier of a second carrier type different from the first carrier type.

24. The UE of claim 23, wherein the first carrier type is a new carrier type (NCT) implemented in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards and wherein the second carrier type is a legacy carrier type on which CRSs are not suppressed.

25. The UE of claim 24, wherein an identity of the notification cell is received in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3GPP family of standards.

26. The UE of claim 25, wherein the physical layer circuitry is further arranged to receive a change notification to notify of a change of the MBMS control information associated with MBMS traffic transmitted on NCT.

27. The UE of claim 26, wherein the physical layer circuitry is further arranged receive the change notification by decoding a physical downlink control channel (PDCCH) of the notification cell, using a cyclic redundancy check (CRC) scrambled with an MBMS radio network temporary identifier (M-RNTI) of the target cell, the M-RNTI and notification cell being configured using RRC signaling from an evolved NodeB.

28. The UE of claim 27, wherein the PDCCH is configurable by a parameter indicating a radio frame offset, a repetition coefficient, and a subframe index for a change notification transmitted on the PDCCH.

29. The UE of claim 26, wherein the physical layer circuitry is further arranged to receive the change notification in a media access control (MAC) control element (CE).

30. The UE of claim 26, wherein the physical layer circuitry is further arranged to: receive a plurality of change notifications for a plurality of MBMS serving cells, at least two of the plurality of change notifications being received in a same subframe of a change notification period and each of the at least two change notifications being scrambled based on a corresponding M-RNTI of the respective MBMS serving cell, a number of M-RNTIs used by the UE being equal to a number of serving cells of a first carrier type configured by a higher layer for MBMS.

31. The UE of claim 26, further comprising:

a memory to store resource assignment information representative of multicast search space (MSS) information on a PDCCH of the second carrier type, and wherein the physical layer circuitry is further arranged to receive change notifications using the MSS.

32. The UE of claim 23, wherein the UE is further configured to receive MBMS traffic from the target cell according to a higher-layer configured parameter that indicates a number of symbols, from a start of a subframe, shall constitute a non-multicast broadcast single frequency network (MBSFN) region.

33. An evolved NodeB (eNodeB) for operating in a network, the eNodeB comprising:

a transceiver arranged to

receive an indication that a user equipment (UE) desires to receive multimedia broadcast multicast service (MBMS) transmissions from a secondary cell (SCell) that operates on a first carrier of a first carrier type on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink frame; and

provide notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.

34. The eNodeB of claim 33, wherein the transceiver is arranged to receive notification cell information in a transmission of a second carrier of a second carrier type different from the first carrier type.

35. The eNodeB of claim 34, wherein the first carrier type is a new carrier type (NCT) implemented in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards and the second carrier type is a legacy carrier type and wherein the second carrier type is a legacy carrier type on which CRSs are not suppressed.

36. The eNodeB of claim 34, wherein the transceiver is further arranged to:

transmit, on a physical downlink control channel (PDCCH), change notifications to notify of a change of the MBMS control information for the MBMS traffic transmitted on the SCell.

37. The eNodeB of claim 36, wherein the transceiver is further arranged to transmit a plurality of MBMS control information change notifications according to a time division duplex (TDD) scheme.

38. A method performed by a user equipment (UE), the method comprising:

transmitting a message to indicate an interest in receiving multimedia broadcast multicast service (MBMS) transmissions on a target cell, the target cell transmitting on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink radio frame;

receiving, responsive to the message and in a Radio Resource Control (RRC) message transmitted in accordance with a standard of the 3rd Generation Partnership Project (3GPP) family of standards, an identity of a notification cell, different from the target cell, on which to receive MBMS control information and MBMS control information change notifications of the target cell; and

receiving MBMS traffic from the target cell using the MBMS control information received from the notification cell, the MBMS traffic being received on the first carrier and the MBMS control information being received on a second carrier of a legacy carrier type different from the NCT on which CRSs are not suppressed.

39. The method of claim 38, further comprising:

receiving, in a physical downlink control channel (PDCCH) of the notification cell or in a media access control (MAC) control element, a change notification to notify of a change of the MBMS control information corresponding to the target cell.

40. The method of claim 39, further comprising:

receiving a plurality of change notifications for a plurality of MBMS serving cells, wherein at least two of the plurality of change notifications are received in a same subframe of a change notification period and each of the at least two change notifications are scrambled based on a MBMS radio network temporary identifier (M-RNTI) of the respective MBMS serving cell.

41. The method of claim 38, wherein the MBMS traffic is received in a multicast-broadcast single-frequency network (MBSFN) from a plurality of cells that use NCT, and the method further comprises receiving a message on a physical control format indicator channel (PCFICH) that indicates that a non-MBSFN region shall not be included in at least one MBSFN subframe of the MBMS traffic.

42. A method performed by an evolved NodeB (eNodeB) for operating in a network, the method comprising:

receiving an indication that a user equipment (UE) desires to receive multimedia broadcast multicast service (MBMS) transmissions from a secondary cell (SCell) that operates on a first carrier of a new carrier type (NCT) on which cell-specific reference signals (CRSs) are suppressed at one or more downlink subframes of a downlink frame;

receiving notification cell information in a transmission of a second carrier of a second carrier type different from the NCT and on which CRSs are not suppressed; and

providing notification cell information, responsive to receiving the indication, which indicates an identity of a notification cell in the network, other than the SCell, that has been configured to provide MBMS control information of the SCell.

43. The method of claim 42, further comprising:

transmitting, on a physical downlink control channel (PDCCH), change notifications to notify of a change of the MBMS control information for the MBMS traffic transmitted on the SCell.

44. The method of claim 43, wherein the eNodeB transmits change notifications for the SCell and at least one other cell according to a time division duplex (TDD) scheme.