HK1224839B - System and method for sharing a control channel for carrier aggregation - Google Patents

Description

Systems and methods for sharing a control channel for carrier aggregation

This application is a divisional application of the Chinese patent application with application number 201180031944.X (System and method for sharing a control channel for carrier aggregation).

This application claims priority to U.S. Provisional Application Serial No. 61/330,157, filed April 30, 2010, which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates generally to data transmission in a mobile communication system, and more particularly to a method for sharing a control channel of carrier aggregation.

Background Art

As used herein, the term "user agent" (UA) may refer to a wireless device, such as a mobile phone, a personal digital assistant, a handheld or laptop computer, and similar devices or other user equipment ("UE") that has communication capabilities. In some embodiments, a UA may refer to a mobile wireless device. The term "UA" may also refer to a device that has similar capabilities but is generally non-portable, such as a desktop computer, a set-top box, or a network node.

In traditional wireless communication systems, transmitting equipment in a base station sends signals in a geographical area called a cell. As technology has evolved, more advanced equipment has been introduced that can provide services that were not previously possible. This advanced equipment may include, for example, an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (eNB), which is more highly evolved than its counterpart in traditional wireless communication systems. Such advanced or next generation equipment may be referred to herein as Long Term Evolution (LTE) equipment, and a packet-based network using such equipment may be referred to as an Evolved Packet System (EPS). Further improvements to LTE systems/equipment will ultimately lead to LTE Advanced (LTE-A) systems. As used herein, the term "access device" will refer to any component that can provide a UA with access to other components in a communication system, such as a traditional base station or an LTE or LTE-A access device (including an eNB).

In mobile communication systems such as E-UTRAN, an access device provides wireless access to one or more UAs. The access device includes a packet scheduler, which dynamically schedules downlink traffic data packet transmissions and distributes uplink traffic data packet transmissions among all UAs communicating with the access device. The scheduler's functions include partitioning available air interface capacity among UAs, determining the transport channel to be used for packet data transmission for each UA, and monitoring packet allocation and system load. The scheduler dynamically allocates resources for physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) data transmissions and sends scheduling information to UAs via a scheduling channel.

Several different downlink control information (DCI) message formats are used to convey resource assignments to UAs, including DCI format 0 for specifying uplink resources, DCI formats 1, 1A, 1B, 1C, 1D, 2, and 2A for specifying downlink resources, and DCI formats 3 and 3A for specifying power control information. Uplink-specific DCI format 0 includes several DCI fields, each of which includes information specifying different aspects of the allocated uplink resources. Example DCI fields for DCI format 0 include a transmit power control (TPC) field, a cyclic shift for a demodulation reference signal (DM-RS) field, a modulation and coding scheme (MCS) and redundancy version field, a new data indicator (NDI) field, a resource block assignment field, and a frequency hopping flag field. Downlink-specific DCI formats 1, 1A, 2, and 2A each include several DCI fields that include information specifying different aspects of the allocated downlink resources. The DCI fields of example DCI formats 1, 1A, 2, and 2A include a Hybrid Automatic Repeat Request (HARQ) process number field, an MCS field, a New Data Indicator (NDI) field, a Resource Block Assignment field, and a Redundancy Version field. Each of DCI formats 0, 1, 2, 1A, and 2A includes an additional field for specifying the allocated resources. The other downlink formats 1B, 1C, and 1D include similar information. An access device selects one of the downlink DCI formats used to allocate resources to a UA based on several factors, including the capabilities of the UA and the access device, the amount of data the UA must send, communication (channel) conditions, the transmission mode to be used, the amount of communication traffic in the cell, and so on.

DCI messages are synchronized with subframes so that they can be implicitly associated with them rather than explicitly, which reduces control overhead requirements. For example, in an LTE frequency division duplex (FDD) system, a DCI message for uplink resources is associated with an uplink subframe four milliseconds later, so that, for example, when a DCI message is received at a first time, the UA is programmed to use the resource grant indicated therein to transmit a data packet in a subframe four milliseconds later than the first time. Similarly, a DCI message for downlink resources is associated with a downlink subframe transmitted at the same time. For example, when a DCI message is received at the first time, the UA is programmed to use the resource grant indicated therein to decode a data packet in a traffic data subframe received at the same time.

During operation, LTE networks use a shared physical downlink control channel (PDCCH) to distribute DCI messages between UAs. DCI messages for each UA, along with other shared control information, are encoded separately. In LTE, the PDCCH is transmitted in the first few orthogonal frequency division multiplexing (OFDM) symbols across the entire system bandwidth, which may be referred to as the PDCCH region. The PDCCH region includes multiple control channel elements (CCEs), which are used to transmit DCI messages from an access device to a UA. The access device selects a CCE or an aggregation of CCEs to use to transmit a DCI message to a UA, with the subset of CCEs selected for transmission depending at least in part on the perceived communication conditions between the access device and the UA. For example, if a high-quality communication link is known to exist between the access device and the UA, the access device may transmit data to the UA via a single CCE, whereas if the link is of lower quality, the access device may transmit data to the UA via a subset of two, four, or even eight CCEs, where the additional CCEs facilitate more robust transmission of the associated DCI message. The access device may select a CCE subset for DCI message transmission based on many other criteria.

Because a UA does not precisely know which or which CCE subsets an access device uses to send a DCI message to the UA, in existing LTE networks, the UA is programmed to attempt to decode multiple different CCE subset candidates when searching for a DCI message. For example, the UA can be programmed to search for multiple single CCEs, as well as multiple subsets of two CCEs, subsets of four CCEs, and subsets of eight CCEs for a DCI message to locate the DCI message. To reduce the number of possible CCE subsets that need to be searched, the access device and UA can be programmed so that each access device only uses a specific CCE subset to send a DCI message to a specific UA corresponding to a specific data traffic subframe, so that the UA knows which CCE subsets to search. For example, in current LTE networks, for each data traffic subframe, the UA searches a total of 16 CCE subsets for a DCI message: six single CCEs, six 2-CCE subsets, two 4-CCE subsets, and two 8-CCE subsets. The 16 CCE subsets depend on the specific Radio Network Temporary Identifier (RNTI) assigned to the UA 10 and vary from subframe to subframe. A search space that is specific to a given UA is hereinafter referred to as a "UA-specific search space."

In many cases, an access device may need to send a large amount of data to a UA, or a UA may need to send a large amount of data to an access device in a short period of time. For example, a series of pictures may need to be sent to an access device in a short amount of time. In another example, a UA may be running several applications that all need to receive data packets from the access device at substantially the same time, making the combined data transmission very large. One way to increase the data transmission rate is to use multiple carriers (i.e., multiple frequencies) to communicate between the access device and the UA, as is the case with LTE-A. For example, a system may support five different carriers (i.e., frequencies) and eight HARQ processes, so that five separate eight uplink HARQ and five separate eight downlink HARQ transmission streams can be generated in parallel. Communication via multiple carriers is referred to as carrier aggregation.

In the case of carrier aggregation, a control channel structure is allocated to each carrier to distribute DCI control messages. As a simple approach, each carrier can include a separate PDCCH region, which allows control channel information to be transmitted between the access device and the UA independently for each carrier. Although this scheme allows control channel information to be distributed for each carrier, this method requires a large amount of resources to be allocated on each carrier. In addition, because the interference level varies between carriers, it may be difficult to implement the PDCCH region equally on all carriers. In some cases, for example, the interference level on a particular carrier may be so large that it is difficult or impossible to implement a PDCCH region on that carrier. Alternatively, the DCI message format for control messages on the first carrier can be modified to provide an additional field for indicating the specific carrier associated with each DCI message.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, reference is now made to the following brief description, taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

FIG1 is a schematic diagram illustrating components of a communication system including a user agent (UA) for sharing a control channel of carrier aggregation;

FIG2 is an illustration of carrier aggregation in a communication network, where each component carrier has a bandwidth of 20 MHz and the total system bandwidth is 100 MHz;

FIG3 is an illustration of aggregation levels and search spaces that may appear in a PDCCH region;

FIG4 is a table showing different aggregation levels of UA-specific search spaces and common search spaces;

Figures 5a and 5b illustrate two example PDCCH region design options for control channels of two or more carriers implementing carrier aggregation;

FIG6 illustrates an example PDCCH region with CCE sets, where each CCE set is allocated to a different carrier, and also illustrates example aggregation levels and search spaces for allocating DCI control messages between carriers f1 and f2;

FIG7 illustrates an example PDCCH region with CCEs allocated to two carriers, wherein the CCEs allocated to each carrier may be distributed via the PDCCH region, and further illustrates example aggregation levels and search spaces that may appear in the PDCCH region for distributing DCI control messages between carriers f1 and f2;

FIG8 is an illustration of aggregation levels and search spaces that may appear in a PDCCH region, where, for each aggregation level, PDCCH candidates for a particular carrier may be shifted by a multiple of the number of CCEs in the next smaller aggregation level;

FIG9 is an illustration of aggregation levels and search spaces that may appear in a PDCCH region, where the carrier index of a particular PDCCH candidate may be calculated from the CCE index of the PDCCH candidate;

FIG10 is a table showing the aggregation levels of the UA-specific space, the size of each aggregation level (in number of CCEs), and the extended number of PDCCH (CCE subset) candidates to be searched at each aggregation level;

Figures 11a-11b illustrate resource element group (REG) reordering, which can be used to distinguish between carriers potentially associated with PDCCH candidates;

FIG12 is an illustration of an example construction of PDCCH candidates for each of carriers f1 and f2 at aggregation levels 2, 4, and 8, where the ordering of CCEs constituting each potential PDCCH candidate varies for aggregation levels higher than aggregation level 1;

FIG13 is a diagram of a wireless communication system including a UA operable for use in some of the various embodiments of the present disclosure;

FIG14 is a block diagram of a UA operable for some of the various embodiments of the present disclosure;

FIG15 is a diagram of a software environment that may be implemented on a UA operable for some of the various embodiments of the present disclosure;

FIG16 is an illustrative general-purpose computer system suitable for use with some of the various embodiments of the present disclosure;

FIG17 is a table showing the following: aggregation levels of UA-specific spaces, the size of each aggregation level (in number of CCEs), and an extended number of PDCCH (CCE subset) candidates to search at each aggregation level consistent with at least one embodiment of the present description;

FIG18 is a table showing the following: aggregation levels of UA-specific spaces, the size of each aggregation level (in number of CCEs), and an extended number of PDCCH (CCE subset) candidates to search at each aggregation level consistent with at least one embodiment of the present description;

FIG19 is a table showing the following: aggregation levels of UA-specific spaces, the size of each aggregation level (in number of CCEs), and an extended number of PDCCH (CCE subset) candidates to search at each aggregation level consistent with at least one embodiment of the present description;

FIG20 is a table showing the aggregation levels of UA-specific spaces, the size of each aggregation level (in number of CCEs), and an extended number of PDCCH (CCE subset) candidates to search for at each aggregation level consistent with at least one embodiment of the present description;

21 is a flow chart illustrating an example method for identifying resource grants for one or more carriers based on an activation signal;

22A is a flow chart illustrating an example method for identifying resource grants for one or more carriers based on a carrier identification field;

FIG22B is a flow chart illustrating an example method for identifying resource grants for one or more carriers based on a carrier identification field (CIF) in each DCI message corresponding to a particular aggregation level; and

22C is a flow chart illustrating an example methodology for identifying resource grants for one or more carriers based on a CIF in each DCI message corresponding to all aggregation levels.

DETAILED DESCRIPTION

It has been recognized that in a multi-carrier communication network system, a control channel may be shared between two or more carriers.

The present disclosure provides various embodiments of systems, software, and methods for processing control channels. In some aspects, a method is disclosed for performing operations of processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by a resource grant in a multi-carrier communication system, wherein the resource grant is specified by a control channel element (CCE) subset candidate, and the carrier used for data transmission and reception is a configured carrier. In one embodiment, the method includes: receiving an activation signal specifying activated and deactivated carriers in the configured carrier. For the activated carrier, identifying a certain number of CCE subset candidates to be decoded, and decoding the identified number of CCE subset candidates in one attempt to identify the resource grant. For the deactivated carrier, ignoring the associated CCE subset candidates.

In some embodiments, the activation signal may indicate that the uplink carrier is activated and the corresponding paired downlink carrier is deactivated, and the step of identifying CCE subset candidates may also include: for the activated uplink carrier to be decoded, only identifying candidates associated with the downlink control information (DCI) 0 format.

In some aspects, a method is disclosed for performing operations of processing a control channel at a user equipment (UA) to identify at least one of uplink and downlink resources allocated by a resource grant in a multi-carrier communication system, wherein the resource grant is specified by a CCE subset candidate. In one embodiment, the method includes determining a position of the CCE subset candidate for each carrier, receiving a DCI message, and, when the CCE subset candidate corresponds to more than one carrier, decoding the DCI message by identifying a CIF in the DCI message and using the CIF to identify the carrier associated with the CCE subset candidate. When the CCE subset candidate corresponds to only one carrier, using the position of the CCE subset candidate in a search space to identify the carrier associated with the CCE subset candidate.

In another embodiment, the method includes determining a position of CCE subset candidates for each carrier, receiving a DCI message, and, when the CCE subset candidates at a particular aggregation level correspond to more than one carrier, decoding all DCI messages for a subframe corresponding to the particular aggregation level by identifying a CIF in each DCI message, and using the CIF to identify the carrier associated with the CCE subset candidate. When each CCE subset candidate at the particular aggregation level corresponds to only one carrier, using the position of the CCE subset candidate in a search space to identify the carrier associated with each CCE subset candidate at the particular aggregation level of the subframe.

In yet another embodiment, the method includes determining a position of a CCE subset candidate for each carrier, receiving a DCI message, and, when a CCE subset candidate at any aggregation level corresponds to more than one carrier of a subframe, decoding all DCI messages at all aggregation levels of the subframe by identifying a CIF in each DCI message, and using the CIF to identify the carrier associated with the CCE subset candidate; and, when each CCE subset candidate at all aggregation levels of the subframe corresponds to only one carrier, using the position of the CCE subset candidate in the search space to identify the carrier associated with each CCE subset candidate at all aggregation levels of the subframe.

To achieve the foregoing and related purposes, the present disclosure includes the features fully described below. The following description and accompanying drawings set forth in detail certain illustrative aspects of the present disclosure. However, these aspects are merely indicative of some of the various ways in which the principles of the present disclosure may be used. Other aspects, advantages, and novel features of the present disclosure will become apparent from the following detailed description of the present disclosure when considered in conjunction with the accompanying drawings.

Various aspects of the present disclosure will now be described with reference to the accompanying drawings, wherein like reference numerals designate identical or corresponding elements throughout the figures. It should be understood, however, that the drawings and detailed description thereof are not intended to limit the claimed subject matter to the particular forms disclosed. Rather, the intent is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.

As used herein, the terms "component," "system," and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed across two or more computers.

As used herein, the word "exemplary" is used to mean serving as an example, instance, or illustration. Any aspect or design described herein is not necessarily to be construed as preferred or advantageous over other aspects or designs.

In addition, the disclosed subject matter can be implemented as a system, method, device, or article manufactured using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer-based or processor-based device to implement aspects described herein. As used herein, the term "article of manufacture" (or alternatively, "computer program product") is intended to encompass computer programs accessible from any computer-readable device, carrier, or medium. For example, computer-readable media can include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes ...), optical disks (e.g., high-density disks (CDs), digital versatile disks (DVDs) ...), smart cards, and flash memory devices (e.g., cards, sticks). In addition, it should be appreciated that carrier waves can be used to carry computer-readable electronic data, such as those used in sending and receiving emails, or those used in accessing networks (e.g., the Internet or local area networks). Of course, those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope or spirit of the claimed subject matter.

In general, an inventive system and method have been developed to share a single control channel resource, such as a physical downlink control channel (PDCCH), between two or more carriers. Thus, the system provides a multi-carrier control structure that allows downlink control information (DCI) control messages distributed via a PDCCH region to determine resource allocations on one or more carriers. In general, the system can be implemented using the existing DCI control message format described above. Thus, even after implementation of the system, the length of the existing DCI format can remain unchanged.

Referring now to the drawings, in which like reference numerals correspond to like elements throughout the several views, FIG1 is a schematic diagram illustrating an example multi-channel communication system 30 including a user agent (UA) 10 and an access device 12. UA 10 includes, among other things, a processor 14 that runs one or more software programs, at least one of which communicates with access device 12 to receive data from and provide data to access device 12. When data is sent from UA 10 to device 12, the data is referred to as uplink data, and when data is sent from access device 12 to UA 10, the data is referred to as downlink data. In one implementation, access device 12 may include an E-UTRAN Node B (eNB) or other network component for communicating with UA 10.

To facilitate communication, a number of different communication channels are established between access device 12 and UA 10. For the purposes of this disclosure, referring to FIG1 , the important channels between access device 12 and UA 10 include: PDCCH 70, physical downlink shared channel (PDSCH) 72, and physical uplink shared channel (PUSCH) 74. As the name implies, PDCCH is a channel that allows access device 12 to control UA 10 during downlink data communication. To this end, PDCCH is used to send scheduling or control data packets, called DCI packets, to UA 10, or to send specific instructions to the UA (e.g., power control commands, commands to perform random access procedures, or semi-persistent scheduling activation or deactivation). DCI packets indicate the schedule to be used by UA 10 to receive downlink communication traffic packets or transmit uplink traffic packets. A separate DCI packet can be sent by access device 12 to UA 10 for each traffic packet/subframe transmitted.

Example DCI formats include DCI format 0 for specifying uplink resources and DCI formats 1, 1A, 1B, 1C, 1D, 2, and 2A for specifying downlink resources. Other DCI formats are contemplated. An example DCI packet is indicated by communication 71 on PDCCH 70 in FIG. 1 .

1, an example traffic data packet or subframe on the PDSCH 72 is designated by 73. The UA 10 may use the PUSCH 74 to transmit a data subframe or packet to the access device 12. An example traffic packet on the PUSCH 74 is designated by 77.

Carrier aggregation can be used to support wider transmission bandwidths and increase the possible peak rate of communications between UAs 10, access devices 12, and/or other network components. In carrier aggregation, as shown in FIG2 , multiple component carriers are aggregated together and can be allocated to UAs 10 in subframes. FIG2 illustrates carrier aggregation in a communication network, where each component carrier has a bandwidth of 20 MHz and the total system bandwidth is 100 MHz. As shown, the available bandwidth 100 is divided into multiple carriers 102. Depending on the capabilities of the UA, the UA 10 can receive or transmit on multiple component carriers (up to a total of five carriers 102 in the example shown in FIG2 ). In some cases, depending on the network configuration, carrier aggregation can occur with the carriers 102 in the same frequency band and/or with the carriers 102 in different frequency bands. For example, one carrier 102 can be at 2 GHz and a second aggregated carrier 102 can be at 800 MHz.

3 , an example PDCCH region includes a plurality of control channel elements (CCEs) 110 for transmitting messages formatted as DCI from an access device 12 to a UA 10. The UA 10 can search for CCEs for transmitting the DCI message in a UA-specific search space 114 that is specific to the particular UA 10 and a common search space 112 that is common to all UAs associated with the access device 12. In the example shown, the PDCCH region includes 38 CCEs, however, other PDCCH instances may include more or fewer than 38 CCEs. The access device 12 selects a CCE or an aggregation of CCEs to use for transmitting the DCI message to the UA 10, with the subset of CCEs selected for transmitting the message depending at least in part on perceived communication conditions between the access device and the UA. For example, if a high-quality communication link is known to exist between the access device and the UA, the access device may transmit data to the UA via a single CCE (see 116), whereas if the link is of low quality, the access device may transmit data to the UA via a subset of 2 (see 118), 4 (see 120), or even 8 CCEs (see 122), wherein the additional CCEs facilitate more robust transmission of the associated DCI message. The access device may select a CCE subset for DCI message transmission based on many other criteria.

Hereinafter, unless otherwise indicated, a CCE subset comprising one CCE is referred to as an "aggregation level 1" or AL1 subset. Similarly, a subset comprising two CCEs is referred to as an "aggregation level 2" or AL2 subset, a subset comprising four CCEs is referred to as an "aggregation level 4" or AL4 subset, and a subset comprising eight CCEs is referred to as an "aggregation level 8" or AL8 subset. A higher aggregation level indicates that a larger number of CCEs are used to transmit a particular DCI (e.g., aggregation level 8 is higher than aggregation level 4) and is therefore more robust under a given set of channel conditions. Therefore, a UA 10 with poor channel conditions can be assigned a higher aggregation level to ensure that the UA 10 can successfully decode a DCI message received on the PDCCH.

Referring now to FIG4 , a table is provided that summarizes the information in FIG3 by showing the following: the aggregation level for each of the UA-specific search space 114 and the common search space 112 shown in FIG3 ; the size (in number of CCEs) of each aggregation level; and the number of PDCCH (CCE subset) candidates to be searched by the UA 10 at each aggregation level. In the UA-specific search space 114, at aggregation level 1, the search space is 6 CCEs with a total of 6 PDCCH candidates. At aggregation level 2, the search space is 12 CCEs with a total of 6 PDCCH candidates. At aggregation level 4, the search space is 8 CCEs with 2 PDCCH candidates, and at aggregation level 8, the search space is 16 CCEs with 2 PDCCH candidates. In the common search space 112, at aggregation level 4, the search space is 16 CCEs with 4 PDCCH candidates, and at aggregation level 8, the search space is 16 CCEs with 2 PDCCH candidates.

In general, the reliability of PDCCH transmissions can be set for an intended UA by using different aggregation levels among those shown in Figure 4. The set of PDCCH candidates to be monitored by a UA is defined in terms of a search space, where the search space _Sk ^(L) at aggregation level 1, 2, 4, or 8 is defined by the PDCCH candidate set. The CCE corresponding to a PDCCH candidate m of the search space _Sk ^(L) can be given by the following formula:

where Y _k (Y _k can be calculated as described in Section 9.1.1 of TS 36.213) is a random number used to define the UA-specific search space, L is the aggregation level, and i = 0, ..., L-1 and m = 0, ..., M ^(L) - 1. ^{M (L)} is the number of PDCCH candidates to monitor in a given search space.

In the case of carrier aggregation, each carrier is allocated a control channel structure for distributing DCI control messages. Figures 5a and 5b illustrate example PDCCH design options for implementing control channels for two or more carriers used in carrier aggregation. In Figure 5a, a separate PDCCH region is allocated for each carrier f1 and f2. Therefore, DCI control messages related to carrier f1 are distributed via PDCCH region 130, and DCI control messages related to carrier f2 are distributed via PDCCH region 132. While relatively straightforward to implement, the PDCCH structure of Figure _5a requires significant resource allocation on each carrier and does not allow for scenarios where a particular carrier does not have a PDCCH region. If PDCCH regions for multiple carriers are reserved on a single carrier, other carriers can be configured to transmit only PDSCHs without control regions, which increases the bandwidth efficiency of PDSCH transmissions. Furthermore, the coverage of each carrier can be different. Furthermore, in some cases, it may be necessary to transmit control messages on a single carrier to simplify UA implementation. Therefore, in many cases, a particular carrier may not implement a PDCCH region or may make the PDCCH region unusable.

Figure 5b shows an alternative PDCCH area design option, in which, in addition to zero or more other carriers, a PDCCH area can be configured to distribute DCI control messages for the carrier on which the PDCCH is sent. In Figure 5b, the DCI control messages associated with carrier f1 are distributed via PDCCH area 136. In addition, the PDCCH area 136 on carrier f1 can be configured to distribute DCI control messages associated with carrier f2 and/or additional carriers (not shown). Although it is possible to implement the PDCCH design option shown in Figure 5b using a new DCI field (which indicates the PDSCH/PUSCH carrier associated with the DCI control message), this solution is not popular because it will modify or increase the number of existing DCI formats.

The present system facilitates sharing a single control channel (e.g., a physical downlink control channel (PDCCH) region) between two or more carriers, which allows DCI control messages distributed via a PDCCH region on a first carrier to be used to determine resource allocations on each of the two or more carriers. Depending on the network configuration, the present system can be implemented using conventional DCI control message formats. In this way, even after implementing the present system, the length of the existing DCI format can remain unchanged. Although each solution is described separately below, it should be appreciated that aspects of different solutions can be combined in at least some embodiments to obtain other useful solutions.

Solution 1

In one implementation of the present system, CCEs on a single carrier PDCCH region are allocated to different groups, where each group is pre-assigned to a different carrier of a multi-carrier system. For example, referring to FIG6 , PDCCH region 140 is located on carrier f1. The CCEs of PDCCH region 140 are allocated into two groups, and each group is allocated to either carrier f1 or carrier f2. PDCCH region 140 includes a first CCE group 142 for PDCCH 140, where CCE group 142 is allocated to carrier f1. First CCE group 142 includes CCEs 0-17 of PDCCH region 140. Similarly, second CCE group 144 of PDCCH region 140 is allocated to carrier f2, and second CCE group 144 includes CCEs 18-35 of PDCCH region 140. In a system with three or more carriers, the CCEs on a single PDCCH region can be allocated into a certain number of groups (the number being equal to the number of carriers). Depending on the network implementation, the number of CCEs allocated to each group may be equal, or may differ between carriers.

Still referring to FIG. 6 , there is shown the aggregation levels and search spaces that may be present in PDCCH region 140 for allocating DCI control messages between carriers f1 and f2. PDCCH region 140 includes 36 CCEs. CCEs 0-17 are in a first group and are allocated to carrier f1 (the carrier containing PDCCH region 140), and CCEs 18-35 are in a second group and are allocated to carrier f2. Using PDCCH region 140, access device 12 selects one or more aggregations or subsets of CCEs to transmit a DCI control message to UA 10. The specific CCE subset selected by the access device may depend, at least in part, on the perceived communication conditions between access device 12 and UA 10. The selected CCE subset also determines on which carrier the DCI control message is allocated resources.

For example, where it is known that a high-quality communication link exists on carrier f1 between the access device 12 and the UA 10, the access device 12 may send a control message to the UA 10 via a single CCE (see 146) in the CCE group 142 allocated to carrier f1. Where the carrier f1 link is of low quality, the access device 12 may send data to the UA 10 via a subset of two (see 148), four (see 150), or even eight (see 152) CCEs, where the additional CCEs facilitate more robust transmission of the associated DCI message to the UA 10.

Similarly, if it is known that a high-quality communication link exists between the access device and the UA on carrier f1, the access device can transmit data to the UA 10 via a single CCE (see 154) in the CCE group 144 allocated to carrier f2. Since the PDCCH region of carrier f2 is transmitted on carrier f1, the channel quality on carrier f1 should be considered when determining the aggregation level. If the carrier f1 link is of low quality, the access device can transmit data to the UA 10 via a subset of two (see 156), four (see 158), or even eight (see 160) CCEs in the CCE group 144 allocated to carrier f2, where the additional CCEs facilitate more robust transmission of the associated DCI message. The access device can select the CCE subset for DCI message transmission based on many other criteria.

If UA 10 finds a valid DCI control message format in CCE space 142 designated for carrier f1, UA 10 can infer that the corresponding grant for carrier f1 is valid. Conversely, if UA 10 finds a valid DCI format in CCE space 144 designated for carrier f2, UA 10 can infer that the corresponding grant for carrier f2 is valid.

In many cases, the total number of CCEs available in the PDCCH region 140 may be more or less than 36, depending on system requirements. For example, a high number of CCEs in the PDCCH region may minimize the occurrence of PDCCH congestion, where an access device wishes to transmit to a particular UA during a given subframe, but the access device cannot find a suitable subset of CCEs in the PDCCH region where the desired DCI control message is placed. Furthermore, CCEs are not necessarily evenly distributed across carriers. For example, a carrier known to have a particularly strong or high-quality connection between the access device and the scheduled UA may be allocated a smaller total number of CCEs in the PDCCH region, since a higher aggregation level will be less likely to be required for that carrier. Conversely, a higher total number of CCEs may be allocated in the PDCCH region to carriers with very low-quality connections, since they will more often require a high aggregation level.

In one implementation, the Rel-8 signaling Physical Control Format Indicator Channel (PCFICH) is used to signal the CCE set 142 allocated to carrier f1, and an alternative signaling method is used to signal the CCE set 144 allocated to carrier f2. In this case, the Rel-8 UA may not be served by the CCE set 144.

In another implementation, the entire CCE space (including CCE sets 142 and 144) is signaled to Rel-8 UAs using PCFICH using Rel-8 signaling, and CCE sets 142 and 144 as two entities are signaled to Rel-10 UAs using Rel-10 signaling. For example, RRC signaling can be used to indicate CCE sets 142 and 144. In this case, a Rel-8 UA can have a single grant spanning the entire PDCCH space, while a single grant for a Rel-10 UA can be located in either CCE set 142 or CCE set 144. In both cases, the solution can be transparent to the Rel-8 UA because the UA uses the same PDCCH search process as currently defined, and the access device can ensure that a specific grant is located in the correct location for each UA.

In some cases, it may be difficult to define a sufficiently large PDCCH space to accommodate multiple carrier operations using Rel-8 technology. For example, if more than three orthogonal frequency division multiplexing (OFDM) symbols are required for the PDCCH, it may be difficult to offset the traffic channel (PDSCH) from the control channel (PDCCH). Thus, the system or a portion of the system can be implemented in the logical domain, where CCE set 142 is defined as in Rel-8, and CCE set 144 uses a specific set of radio resources, such as a set of physical resource blocks. However, this may require the UA to buffer the entire subframe and, therefore, may eliminate the micro-sleep advantages of the existing PDCCH structure.

For carriers f1 and f2, the first solution described above may not allow trunking between CCE subsets 142 and 144 in PDCCH region 140, and thus may result in a higher blocking rate compared to a completely common PDCCH space. Therefore, it may be necessary to use a common set of CCEs for allocation on both carriers f1 and f2 without changing the Rel-8 DCI format. Furthermore, it may be difficult to reserve search space for each carrier, especially for larger aggregation levels.

Signaling can be implemented to indicate to each UA 10 how to map a CCE set to a specific carrier. In some cases, broadcast signaling can be used to divide the PDCCH region into CCE groups. For example, referring again to FIG. 6 , broadcast signaling can be used to indicate that CCE set 142 corresponds to CCEs 0-17, and CCE set 144 corresponds to CCEs 18-35.

After configuring the CCE sets, the access device can indicate which carrier corresponds to which CCE set. In addition, the access device can indicate the carrier index in each CCE set. For example, when CCE set 142 is referred to as CCE set "0" and is used for three carriers (unlike Figure 6), and CCE set 144 is referred to as CCE set "1" and is used for one carrier, example signaling is shown in the following table.

Carrier Index CCE Collection Carrier index in CCE 0 0 0 1 0 1 2 0 2 3 1 0

Table 1

In this case, the DCI message may be modified to indicate the carrier index in the CCE set, or one of the following solutions may be used to indicate the carrier.

If there is only one defined CCE set, as shown in FIG6 , the carrier index in the CCE set may be equal to the carrier index, in which case signaling may not be necessary.

Solution 2

In other implementations, CCEs can be shared across multiple component carriers, provided that a first PDCCH DCI control message candidate for a first carrier at a particular aggregation level does not overlap with a second PDCCH DCI control message candidate for a second carrier at the same aggregation level. Referring to FIG7 , carriers f1 and f2 can each be allocated resources from any CCE available on the PDCCH region 162 of carrier f1 (in this example, a total of 36 CCEs, numbered from 0 to 35). To differentiate the CCE allocations for carrier f1 from those for carrier f2, the PDCCH 162 candidate for each non-anchor carrier at a certain aggregation level is offset relative to the position of each PDCCH candidate on the anchor carrier by a certain number of CCEs allocated on the anchor carrier.

FIG7 illustrates the aggregation levels and search spaces that may appear in PDCCH region 162 for allocating DCI control messages between carriers f1 and f2, where the DCI control messages for carriers f1 and f2 may be distributed throughout PDCCH region 162. In FIG7 , the DCI control messages for carriers f1 and f2 may each be allocated one or more CCEs numbered 0 to 35 (i.e., any CCE available in PDCCH region 162). To distinguish allocations for carrier f1 from those for carrier f2, the PDCCH candidates for carrier f2 are offset relative to the positions of the CCEs allocated to the anchor carrier (e.g., carrier f1).

For example, in Figure 7 , the PDCCH candidate for aggregation level 1 of carrier f2 is offset relative to the PDCCH candidate for carrier f1 by the number of CCEs allocated to the anchor carrier at aggregation level 1. In Figure 7 , the six CCEs starting with PDCCH candidate 166 are already allocated to the anchor carrier (carrier f1). Therefore, the starting CCE 164 of the PDCCH candidate for carrier f2 is offset from the same starting position as the anchor carrier by the number of CCEs allocated to the anchor carrier (in this case, 6). Thus, the starting position of PDCCH candidate 164 is shifted to the right by 6 CCEs.

7 , there are six PDCCH or CCE subset candidates for AL2 and carrier f1 (Cf1) starting from candidate 168. Because there are six PDCCH candidates on AL2, the first PDCCH candidate 170 of the six PDCCH candidates for carrier f2 (Cf2) on AL2 is offset by six candidates as shown.

A similar process can be repeated to specify and issue PDCCH candidates allocated between carriers at each aggregation level. This algorithm can also be applied when additional carriers are added to the system. For example, the PDCCH candidates for the third carrier are shifted right by the number of PDCCH candidates allocated to carriers f1 and f2. Similarly, the PDCCH candidates for the fourth carrier are shifted right by the number of PDCCH candidates allocated to carriers f1, f2, and f3.

If the UA 10 finds a valid DCI control message format at a particular aggregation level, the UA 10 can determine which carrier to allocate the grant to based on the CCE used to send the DCI message. If the CCE used to send the DCI message is among those allocated to the first carrier, then the grant is for resources on the first carrier. However, if the CCE is included in the set allocated to the second carrier, then the grant is for resources on the second carrier, and so on.

In Figure 7 , only a single carrier (e.g., the anchor carrier) can overlap with the common search space for aggregation levels 4 and 8. This requires special handling of AL4 and AL8 for PDCCH 162. In the example shown in Figure 7 , while there are two candidates 165 and 167 for carrier f2 on AL4, there are zero candidates for f2 on AL8 because the remaining candidates are used for either the UA 10-specific search space or the common search space on carrier f1.

In another implementation, the UA 10 can retrieve all DCI control messages distributed at the first aggregation level and, assuming that the control messages are evenly distributed across the carriers, determine the carrier associated with each control message based on the total number of DCI control messages at that aggregation level. For example, if there are a total of six DCI control messages distributed at aggregation level 1, and the UA 10 knows that the PDCCH serves two carriers, the UA 10 can determine that the first three control messages allocate resources on carrier f1, and the next three control messages allocate resources on carrier f2. In other words, the system can be configured to evenly distribute the PDCCH candidates across the carriers and also send out the candidates in the same order as the carriers. In the case of three carriers, for example (not shown), the first three control messages would allocate resources on carrier f1, the next three would allocate resources on carrier f2, and the last three would allocate resources on carrier f3. This process can be repeated for any number of carriers across all aggregation levels.

In some cases, it may be difficult to define a sufficiently large PDCCH space to accommodate multi-carrier operation using Rel-8 technology. Because a common search space can be shared between Rel-8 and Rel-10 UEs, Rel-8 signaling (such as PCFICH) can be used to signal the search space. Therefore, the search space can be limited to a total of 3 OFDM symbols (or 4 OFDM symbols for a carrier bandwidth of 1.4 GHz, although such narrow bandwidths are unlikely to be applicable to carrier aggregation).

In Figure 7, the PDCCH candidate for carrier f2 is adjacent to the PDCCH candidate for carrier f1. This is one positioning algorithm, and it should be understood that any positioning algorithm can be used. For example, the PDCCH candidate for carrier f2 can be pseudo-randomly located in the PDCCH, similar to the process used for the PDCCH candidate for carrier f1. In the event that the PDCCH candidate for carrier f1 overlaps with the PDCCH candidate for carrier f2, priority must be given to one carrier. For example, in the event of overlap, it can be known at the UA 10 and access device 12 that the PDCCH candidate corresponds to carrier f1.

Solution 3

In another implementation, for a particular aggregation level, the starting CCE of the PDCCH candidates allocated for each carrier at each aggregation level is offset based on the number of CCEs in the next smaller aggregation level. Figure 8 shows a PDCCH 180 where, for each aggregation level, the PDCCH candidates for a particular carrier may be offset by a multiple of the number of CCEs in the next smaller aggregation level. For example, at one aggregation level and for two carriers, the DCI control message for the second carrier may be offset from the control message for the first carrier by a number of CCEs that is equal to the number of CCEs aggregated into each PDCCH candidate at the next lower aggregation level. Note that the offset for aggregation level 1 is a unique case since there is no aggregation level less than 1. In this case, the offset for the aggregation level may be set to any integer (e.g., an offset of 6 as shown in Figure 8).

Still referring to FIG8 , for a specific example, the starting CCE of aggregation level 2 PDCCH candidate 184 for carrier f2 is offset by 1 CCE (equal to the number of CCEs aggregated at the next smaller aggregation level) relative to PDCCH candidate 182 for carrier f1. Similarly, aggregation level 4 PDCCH candidate 188 for carrier f2 is offset by 2 CCEs (equal to the number of CCEs aggregated at the next smaller aggregation level) relative to PDCCH candidate 186 for carrier f1.

By offsetting the PDCCH candidates of different frequencies at any given aggregation level by the number of CCEs in each PDCCH candidate at the lower aggregation level, the PDCCHs at different frequencies at each aggregation level will not overlap exactly, and therefore the CCE subset candidates are unique.

Here, it should be appreciated that this third solution can be generalized so that any offset smaller than the number Q of CCEs constituting PDCCH candidates at the same aggregation level can be used. More generally, the main restriction on the offset is that it is not an integer multiple of Q. For example, at aggregation level AL4 in FIG8 , the offset shown is equal to two CCEs. This offset can be changed to 1 CCE or 3 CCEs (i.e., Q-1) to achieve a similar effect. Similarly, the 4 CCE offset for AL8 shown in FIG8 can be any number from 1 CCE to 7 CCEs (i.e., also Q-1, where Q is the number of candidates for each AL8 CCE subset).

More generally, at least in some embodiments, a main restriction on the offset offset may be that it is not an integer multiple of the number of CCEs constituting a PDCCH candidate at the same aggregation level.

Solution 4

9 , in another embodiment, the carrier of a specific PDCCH candidate can be calculated by the CCE index of the PDCCH candidate. For example, assuming that the number of configured carriers is N, the carrier index of a specific PDCCH candidate can be determined by the following formula:

Carrier index = (I _cce /L)MOD N + 1 Formula (2)

Where I _cce is the index of the first CCE in a particular PDCCH candidate, and L is the aggregation level currently under consideration. In FIG9 (e.g., in 200), the carrier index of PDCCH candidate 202 can be determined using formula (2). PDCCH candidate 202 has an I _cce of 4 and an aggregation level of 1. The PDCCH includes 2 carriers, so the carrier index for PDCCH candidate 202 is equal to (4/1)MOD2+1=4MOD2+1=0+1=1. Similarly, PDCCH candidate 204 has an I _cce of 12 and an aggregation level of 4. Therefore, the carrier index for PDCCH 204 is equal to (12/4)MOD2+1=3MOD2+1=1+1=2. In this way, UA 10 can calculate the carrier assigned to each PDCCH candidate in FIG9. Thus, in some implementations, the system interleaves the PDCCH candidates for each carrier at a particular aggregation level.

In order to ensure that the UA 10 implements a unique carrier index using formula (2), the number of PDCCH candidates must be increased according to the number of configured carriers as shown in Figure 10. In Figure 10, a table showing the aggregation levels of the UA-specific space and the minimum required size of the search space (in units of the number of CCEs) for each aggregation level is provided. At aggregation level 1, the minimum search space is N CCEs, where N is the number of carriers. At aggregation level 2, the minimum search space is 2*N CCEs. At aggregation level 4, the minimum search space is 4*N CCEs, and at aggregation level 8, the minimum search space is 8*N CCEs. That is, the minimum search space size can be specified as AL*N CCEs, where AL is the aggregation level (1, 2, 4, or 8) and N is the number of carriers.

In other embodiments, in the case of carrier aggregation, when an access device is communicating with several UAs, blocking may occur if all PDCCH candidates associated with one of the UAs (at one or more aggregation levels) are currently being used and a delay occurs when grants are sent to one or more UAs. Therefore, it has been recognized that in the case of carrier aggregation, in at least some cases, it may be useful to increase the size of the CCE search space and the number of PDCCH candidates so that the UAs can blindly decode the increased number of candidates. For example, in some cases, it may be useful to increase the CCE search space size and the number of PDCCH candidates based on the number of configured carriers. An example manner of increasing the search space size and the number of PDCCH candidates based on the number of configured carriers is shown in FIG17 , where, for example, max(N, 6) means selecting the maximum of the number of carriers and 6 as the search space size (in CCEs) at aggregation level 1. Similarly, 2xmax(N, 6) means the maximum of 2 times the number of carriers and 12, and so on. Thus, for example, where the number of configured carriers is 4, the search space is 32 (in CCE units) (e.g., 8xmax(N, 2), where N is 4), and the number of PDCCH candidates is 4 (e.g., max(N, 2), where N is 4), so that there will be 4 candidates, each of which includes 8 CCEs.

In order to simultaneously receive downlink DCI and uplink DCI, the number of PDCCH candidates may be increased by twice the number of configured carriers as shown in FIG. 18 .

In another embodiment, a larger number of PDCCH candidates can be used to replace the number of PDCCH candidates used in the LTE Rel-8 system when carrier aggregation is configured, regardless of the number of carriers actually configured. Figure 19 shows an example scheme, where M1, M2, M3, and M4 represent the number of PDCCH candidates for aggregation levels 1, 2, 4, and 8, respectively, and where M1, M2, M3, and M4 should be greater than or equal to the number of PDCCH candidates used in LTE Rel-8, respectively. These values can be signaled or predefined in the specification. In at least some embodiments, the same value can be used for M1, M2, M3, and M4, or different values can be used. In Figure 19, it is noted that when only a single carrier is configured, the search space size and number of PDCCH candidates are the same as the space size and number of candidates in the Rel 8 system. Thus, here again, the number of configured carriers affects the search space size and number of PDCCH candidates.

Figures 10, 17, 18, and 19 show several different ways to extend the UA-specific search space, but the techniques can also be applied to the common search space if the PDCCH sent in the common search space is sent on a different carrier than the carrier that sends the PDSCH/PUSCH.

Depending on the eNB configuration, the number of carriers used for PDSCH transmission and the number of carriers used for PUSCH transmission may be different. In this case, N can be a larger number of carriers.

In another embodiment, referring to FIG. 20 , a first set of PDCCH candidate sizes (A1, A2, A3, and A4) can be used for single carrier operation (N=1) and a second set of PDCCH candidate sizes (C1, C2, C3, and C4) can be used for carrier aggregation, wherein the second set of PDCCH candidate sizes (C1, C2, C3, and C4) is defined using a function that includes the first set of PDCCH candidate sizes (A1, A2, A3, and A4) and a scaling parameter (B1, B2, B3, and B4) multiplied by the number of carriers (N) minus one. In at least some embodiments, the first set of PDCCH candidate sizes (i.e., A1, A2, A3, and A4) is equal to those used in LTE Rel-8.

This approach can be further generalized so that a single set of PDCCH candidates can be dedicated to a specific carrier aggregation in a non-uniform manner. For example, for two carriers, six PDCCH candidates can be allocated to one carrier, and three PDCCH candidates can be allocated to the other carrier. Alternatively, a formula can be used so that the position of the PDCCH candidates for a particular aggregation level is randomized for each carrier. This can be achieved, for example, by adding a carrier index field to the formula found in 3GPP TS 36.123, v8.6.0, March 2009.

In some cases, depending on the size of the PDCCH, PDCCH candidates from more than one carrier may collide. In this case, the PDCCH candidates may be assigned to a specific carrier, for example, the carrier with the lowest carrier index (eg, the anchor carrier).

In some cases, the search space size and number of PDCCH candidates increases with the number of carriers, up to a certain number of carriers, and remains constant even when more carriers are added. For example, considering N=1, the number of PDCCH candidates can be 6, 10, 14, 18, 18 for 1, 2, 3, 4, 5 carriers, respectively. In this case, no additional PDCCH candidates are used in the transition between 4 and 5 carriers.

The above-described embodiments of the present system may be implemented individually or in combination.

Solution 5

In some implementations of the present system, the C-RNTI of the anchor carrier or the RNTI of each UA may be used to determine the allocation of PDCCH candidates between carriers in the UE-specific search space. In the following examples, the search space may be of the same size or extended relative to Rel-8.

A UA can be assigned multiple RNTIs, one for each carrier. For example, for a system using two carriers, UA 10 can be assigned a first RNTI associated with the first carrier and a second RNTI associated with the second carrier. If the access device wishes to allocate resources on the second carrier to the first UA, the access device uses the UA's second RNTI when encoding the DCI control message. Similarly, if the access device 12 wishes to allocate resources on the first carrier to the UA, the access device 12 uses the UA's first RNTI when encoding the DCI control message. This allows the UA to determine which carrier the control message allocates services on by attempting to decode the message using both RNTIs. The number of the RNTI that successfully decodes the control message tells the UA which carrier the control message allocates resources on.

For example, after receiving a PDCCH candidate, each UA can attempt to blindly decode the candidate. After blind decoding, the CRC scrambling of the PDCCH candidate is compared with all RNTI values assigned to the UA. If the PDCCH candidate can be successfully descrambled using one of the RNTIs, the RNTI used to perform the descrambling identifies the specific carrier associated with the DCI control message for the PDCCH candidate. Alternatively, a different CRC mask can be used for each carrier to achieve a similar function.

In another implementation, the modulation symbols or resource element groups (REGs) in the PDCCH candidate may be rotated (or their order may be otherwise changed) as an indication of which carrier's resources the PDCCH candidate is assigned to. For example, after generating a log-likelihood ratio (LLR) for a particular PDCCH candidate, the UA 10 attempts to blindly decode the PDCCH candidate using a standard scheme (and a standard configuration of REGs).

If the decoding is successful, the PDCCH candidate is assigned to carrier f1. If the decoding fails, the UA 10 is configured to shuffle the LLRs (corresponding to the modulation symbols) of the REGs into an alternative order according to a predetermined algorithm and attempt blind decoding again. If the blind decoding using the first alternative ordering is effective, the PDCCH candidate is assigned to carrier f2. The shuffle algorithm can be implemented a second, third, or fourth time to, for example, identify a third, fourth, and fifth carrier. In this example, the standard order of the LLRs and any predefined alternative orderings correspond to different carriers. In some cases, two or more different ordering configurations can be defined for the REGs to allow the REG ordering to indicate the assignment of the PDCCH candidate to one of two or more carriers.

As an example, Figures 11a-11c illustrate REG reordering, where the REG ordering can be used to distinguish between carriers associated with a PDCCH. Figure 11a shows the REGs that can be defined for aggregation level 1. Figure 11b shows an example order of the REGs of Figure 11a for identifying carrier f1. Figure 11c shows an example order of the REGs of Figure 11a for identifying carrier f2. At aggregation level 1, nine REGs (as shown in Figure 11a) can be used to construct a CCE, which can then be blind decoded to determine whether a valid DCI control message exists. The first REG ordering is for carrier f1. If the blind decoding of the PDCCH candidate using the ordering of Figure 11b is successful, the UE 10 determines that the PDCCH candidate is allocated to carrier f1. However, if the blind decoding fails, the REGs can be reordered according to Figure 11c, and the UE can attempt a second blind decoding. If this blind decoding is successful, the UE 10 determines that the PDCCH candidate is allocated to carrier f2. However, if the blind decoding is also unsuccessful, the UA 10 may determine that the PDCCH candidate is invalid (eg, assigned to another UA) or is assigned to another carrier.

In Figures 11b and 11c, the reversal of the individual REGs is shown to distinguish the PDCCH assigned to carrier f2 from the PDCCH assigned to carrier f1. However, in other implementations, other reordering algorithms can be implemented. In one example, the individual resource elements or modulation symbols in each REG are reordered to implicitly signal different carriers. For example, the position of a specific number or combination of numbers in the REG can indicate the carrier.

Alternatively, for aggregation levels higher than aggregation level 1, the order of the CCEs constituting potential PDCCH candidates may vary, with the order indicating the carrier to which the PDCCH candidate is allocated. An example of such an approach is shown in Figure 12. Figure 12 shows an example construction of PDCCH candidates for each carrier f1 and f2 at aggregation levels 2, 4, and 8.

For each potential PDCCH candidate, a blind decode is first attempted on the aggregated CCEs in the currently specified order (e.g., according to the LTE specification). If the blind decode is successful, it may indicate that the PDCCH candidate is allocated to carrier f1. If the blind decode fails, the CCEs are reordered ( FIG. 12 shows rotating the CCEs by half the amount of the current aggregation level, but other CCE reorderings are possible) and a second blind decode is performed. If this blind decode is successful, it may indicate that the PDCCH candidate is allocated to carrier f2. This scheme will not work for aggregation level AL1 because it requires the use of multiple CCEs to construct the PDCCH candidate.

Thus, in Figure 12, on AL2 and carrier f1, CCEs 0 and 1 are processed in the normal order of 0 followed by 1. If decoding is successful, the DCI message corresponds to carrier f1. UA 10 also attempts to decode the CCEs in the reverse order of 1 followed by 0, where successful decoding results in a DCI message corresponding to carrier f2. The UA also attempts to decode CCEs 0, 1, 2, and 3 on level AL4 for carrier f1 and 2, 3, 0, 1 on carrier f2, and 0, 1, 2, 3, 4, 5, 6, and 7 on level AL8 for carrier f1 and 4, 5, 6, 7, 0, 1, 2, and 3 on carrier f2.

Finally, a toggle bit may be used in existing DCI formats, or the definition of one or more existing DCI format fields may be changed to allow the DCI control message to explicitly indicate to which carrier the grant corresponds.

The present system provides a multi-carrier control structure in which a PDCCH on one carrier may include PDCCH candidates that allocate resources across two or more carriers. In one implementation, the present system does not require modifications to the existing Rel-8 DCI control message format and does not change the length of the existing Rel-8 DCI format.

Furthermore, in LTE-A, for example, new DCI formats may be proposed in addition to existing DCI formats to support new features (e.g., 8x8 MIMO and CoMP). Thus, explicit bits may be added to any new DCI format to signal carrier identification. Even so, implementing implicit PDCCH allocation of carriers as described in this system may be beneficial. First, Rel-8 modes (e.g., transmit diversity and open-loop SM) can still be considered fallback modes or transmission modes for high-mobility UAs in LTE-A systems. Therefore, corresponding Rel-8 DCI formats, such as format 1A, can still be used in such systems. Second, if explicit bits for carrier identification are defined in the new DCI format, e.g., 3 bits, then any such bits may always need to be sent, and such bits may generally be wasted when only two carriers are aggregated or when no carrier aggregation is present. In this case, if the number of explicit bits varies, e.g., between 0 and 3 bits, such an implementation can increase blind decoding. In contrast, if the number of any such explicit bits is semi-statically specified for different carrier aggregation deployments, the number of variations of the DCI format may increase substantially.

Other solutions

In some embodiments, the set of configured carriers is the set of carriers used for actual data transmission and reception. In some embodiments, carriers may be configured but not activated. Thus, in some cases, after a UA is configured to use multiple carriers, the configured carriers may be activated or deactivated (i.e., via MAC signaling or physical signaling) by sending an activation signal from the access device to the UA. At least in some embodiments where the UA does not receive an activation signal (i.e., activation/deactivation is not applied), the configured carriers are always activated (i.e., the default is for the carriers to be activated). The primary purpose of activation/deactivation is to turn UA transmission/reception on/off more frequently based on actual data activity, which conserves UA battery power. MAC signaling or physical signaling is faster than RRC signaling and is therefore more optimized. However, RRC signaling may be used in some cases.

FIG21 is a flow chart illustrating an example method 2100 for identifying resource grants for one or more carriers based on an activation signal. Example method 2100 may be performed at UA 10. The process begins at step 2110. At step 2120, an activation signal is received at UA 10, indicating that multiple configured carriers may be used for data transmission. In some embodiments, the activation signal may be included in MAC signaling or physical signaling. At step 2130, the activation signal is decoded to identify activated and/or deactivated carriers among the multiple carriers. At decision step 214, UA 10 determines whether a carrier among the configured carriers is activated. If a carrier is deactivated, in at least some embodiments, UA 10 will not monitor PDCCH candidates assigned to the deactivated carrier because PDSCH or PUSCH resources will not be scheduled on the deactivated carrier. The UA may ignore CCE subset candidates associated with the deactivated carrier and return to step 2110. If the carrier is activated, the UA 10 proceeds to step 2150 where a number of CCE subset candidates are identified for decoding. At 2160, up to the identified number of CCE subset candidates are decoded to identify a resource grant.

When paired DL and UL carriers have different states for UL and DL (i.e., the DL carrier is deactivated while the associated UL carrier is activated, or vice versa), the UA can still be programmed to monitor PDCCH candidates associated with either the DL carrier or the UL carrier. Therefore, the total number of PDCCH candidates can be increased based on the number of activated carriers. In other words, N in the tables shown in Figures 17 and 18 can be defined as the number of activated carriers. If the DL and UL carriers are independently activated/deactivated, N can be the maximum of the number of activated DL carriers and the number of activated UL carriers.

Since only DCI 0 is used for UL grants, when an UL carrier is activated, the corresponding paired DL carrier is deactivated. In at least some embodiments, upon identifying at least one carrier as activated at step 2140, the UA 10 may proceed to an optional decision step 2145 to determine whether the UL carrier is activated and the paired DL carrier is not activated. If so, the UA may be programmed to perform blind decoding only for the DCI 0 format size at optional step 2155, which will reduce the required number of blind decodes by half. Otherwise, at 2150, the UE may perform blind decoding for all associated DCI formats to identify CCE subset candidates.

Depending on the search space design for multiple component carriers, it is possible for PDCCH candidates to overlap more than one carrier depending on the CCE positions.As mentioned above, one solution to this problem is to define PDCCH candidates such that they correspond to only one carrier in case of overlap.

In some embodiments, when a PDCCH candidate for a first carrier overlaps with a PDCCH candidate for a second carrier, the DCI control message may be modified to include a carrier indicator field (CIF) that indicates which carrier the PDCCH candidate belongs to. For example, in some embodiments, the CIF may be 3 bits, where each value of the CIF corresponds to a specific carrier.

Figure 22A is a flow chart illustrating an example method 2220A for identifying resource grants for one or more carriers based on a carrier identification field. Example method 2220A may be performed at a multi-carrier capable UA. The process begins at step 2210. At step 2220, the UA determines the location of a PDCCH candidate (or CCE subset candidate) for each of the multiple carriers. It should be understood that the location of the PDCCH candidate may also be determined by the access device for each carrier prior to transmission. At step 2230, information is received from the UA from a PDCCH, where the information includes a DCI message. At 2240, the UA identifies one or more CCE subset candidates transmitted on the PDCCH. At decision step 2250A, for the one or more identified CCE subset candidates, the UA determines whether each CCE subset candidate corresponds to only one carrier. If not, i.e., a single PDCCH candidate corresponds to more than one carrier, then at step 2270A, the UA decodes the DCI message by identifying the CIF in the DCI message. It will be appreciated that the access device may transmit a control message including a CIF in the event that a CCE subset candidate corresponds to more than one carrier, with the CIF indicating the carrier corresponding to the PUSCH/PDSCH. At step 2280A, the UA uses the CIF to identify the carrier associated with each identified CCE subset candidate. In the event that a single PDCCH candidate corresponds to only one carrier, the process 2200A proceeds to step 2260A, where the UA 10 decodes the DCI control message assuming that the CIF is not included, and uses the position of the PDCCH candidate to implicitly determine the PUSCH/PDSCH. It will be appreciated that in this case, the access device transmits a DCI control message that does not include a CIF, and the position of the PDCCH candidate implicitly corresponds to the PUSCH/PDSCH.

FIG22B is a flow chart illustrating an example method 2200B for identifying resource grants for one or more carriers based on a carrier identification field (CIF) in each DCI message corresponding to a particular aggregation level. Method 2200B may be performed at a multi-carrier capable UE 10. Steps 2210, 2220, 2230, and 2240 of method 2200B are substantially similar to the first four steps performed in method 2200A. At decision step 2250B, the UE determines whether at least one CCE subset candidate at the particular aggregation level corresponds to only one carrier, or in other words, whether there is no overlap for at least one PDCCH candidate at the particular aggregation level. If at least one CCE subset candidate at the particular aggregation level corresponds to only one carrier, at step 2260B, the UE 10 may identify the carrier associated with the CCE subset candidate at the particular aggregation level for the subframe without identifying the CIF. Otherwise, the CIF is included in all DCI control messages at the particular aggregation level sent at the particular subframe. Thus, the process proceeds to step 2270B, where the UA 10 decodes the DCI message corresponding to the particular aggregation level by identifying the CIF of the subframe. At step 2280B, the UA uses the identified CIF to identify the carrier associated with the CCE subset candidate.

FIG22C is a flow chart illustrating an example method 2200C for identifying resource grants for one or more carriers based on a CIF in each DCI message corresponding to all aggregation levels. Method 2200C may be performed at a multi-carrier capable UE 10. Steps 2210, 2220, 2230, and 2240 of method 2200B are substantially similar to the first four steps performed in methods 2200A-B. At decision step 2250C, the UE determines whether at least one CCE subset candidate at any aggregation level corresponds to only one carrier, or in other words, whether there is no overlap for at least one PDCCH candidate at any aggregation level. If at least one CCE subset candidate at any aggregation level corresponds to only one carrier, at step 2260C, the UE may identify the carrier associated with the CCE subset candidate at all aggregation levels for the subframe without identifying any CIF. Otherwise, the CIF is included in all DCI control messages at any aggregation level sent at a particular subframe. Thus, the process proceeds to step 2270C, where the UA 10 decodes the DCI messages at all aggregation levels by identifying the CIF in each DCI message of the subframe. At step 2280C, the UA 10 uses the identified CIF to identify the carrier associated with the CCE subset candidate.

In some embodiments, the inclusion of the CIF can be applied extensively to UA 10-specific search spaces. This approach allows the CIF to be included in DCI control messages only when there is uncertainty about which carrier a PDCCH candidate belongs to. This reduces control channel overhead compared to always including the CIF in DCI control messages and allows search space to be fully shared across carriers that never include the CIF in DCI control messages.

FIG13 illustrates a wireless communication system including an embodiment of a UA 10. The UA 10 may be operable to implement various aspects of the present disclosure, but the present disclosure should not be limited to such implementations. Although illustrated as a mobile phone, the UA 10 may take various forms, including a wireless handset, a pager, a personal digital assistant (PDA), a portable computer, a tablet computer, or a laptop computer. Many suitable devices combine some or all of these functionalities. In some embodiments of the present disclosure, the UA 10 is not a general-purpose computing device such as a portable, laptop, or tablet computer, but rather a special-purpose communication device such as a mobile phone, a wireless handset, a pager, a PDA, or a communication device installed in a vehicle. The UA 10 may also be a device, include a device, or be included in a device having similar capabilities but not being portable. The UA 10 may support specialized activities, such as gaming, inventory control, job control, and/or task management functions, and the like.

The UA 10 includes a display 702. The UA 10 also includes a touch-sensitive surface, a keyboard, or other input keys, referred to as 704, for user input. The keyboard can be a full or reduced alphanumeric keyboard (such as QWERTY, Dvorak, AZERTY, and sequential types) or a traditional numeric keypad with letters associated with a telephone keypad. Input keys can include a scroll wheel, an exit or escape key, a trackball, and other navigation or function keys that can be pressed inward to provide other input functions. The UA 10 can present options for the user to select, controls for the user to actuate, and/or a pointer or other indicator for the user to direct.

The UA 10 may also accept data input from the user, including numbers to dial or various parameter values for configuring the operation of the UA 10. In response to user commands, the UA 10 may also execute one or more software or firmware applications. These applications may configure the UA 10 to perform various customized functions in response to user interactions. Additionally, the UA 10 may be programmed and/or configured over the air, for example, from a wireless base station, a wireless access point, or a peer UA 10.

Among the various applications executable by the UA 10 is a web browser that enables the display 702 to present web pages. The web pages may be obtained via wireless communications with a wireless network access node, a cell tower, a peer UA 10, or any other wireless communication network or system 700. The network 700 is connected to a wired network 708 (e.g., the Internet). Via wireless links and the wired network, the UA 10 has access to information on various servers, such as server 710. The server 710 may provide content that may be presented on the display 702. Alternatively, the UA 10 may access the network 700 with a relay-type or hop-type connection through a peer UA 10 acting as an intermediary.

FIG14 shows a block diagram of a UA 10. Although various known components of a UA 110 are shown, in embodiments, the UA 10 may include a subset of the listed components and/or additional components not listed. The UA 10 includes a digital signal processor (DSP) 802 and a memory 804. As shown, the UA 10 may also include an antenna and front end unit 806, a radio frequency (RF) transceiver 808, an analog baseband processing unit 810, a microphone 812, an earpiece speaker 814, a headset port 816, an input/output interface 818, a removable memory card 820, a universal serial bus (USB) port 822, a short-range wireless communication subsystem 824, an alarm 826, a keypad 828, a liquid crystal display (LCD) (which may include a touch-sensitive surface 830, an LCD controller 832), a charge-coupled device (CCD) camera 834, a camera controller 836, and a global positioning system (GPS) sensor 838. In embodiments, the UA 10 may include another display that does not provide a touch-sensitive screen. In an embodiment, the DSP 802 may communicate directly with the memory 804 without going through the input/output interface 818 .

The DSP 802, or some other form of controller or central processing unit, controls the various components of the UA 10 according to embedded software or firmware stored in the memory 804 or in memory contained within the DSP 802 itself. In addition to the embedded software or firmware, the DSP 802 can execute other applications stored in the memory 804 or available via information carrier media (such as portable data storage media, similar to the removable memory card 820) or available via wired or wireless network communications. The application software can include a compiled set of machine-readable instructions that configure the DSP 802 to provide the desired functionality, or the application software can be high-level software instructions that are processed by an interpreter or compiler to indirectly configure the DSP 802.

An antenna and front end unit 806 may be provided to convert between wireless and electrical signals, enabling the UA 10 to send and receive information from a cellular network or some other available wireless communication network or a peer UA 10. In an embodiment, the antenna and front end unit 806 may include multiple antennas to support beamforming and/or multiple-input, multiple-output (MIMO) operations. As known to those skilled in the art, MIMO operations may provide spatial diversity for overcoming difficult channel conditions and/or increasing channel throughput. The antenna and front end unit 806 may include antenna tuning and/or impedance matching components, an RF power amplifier, and/or a low noise amplifier.

The RF transceiver 808 provides frequency shifting, converting received RF signals to baseband, and converting baseband transmit signals to RF. In some descriptions, a wireless transceiver or RF transceiver may be understood to include other signal processing functions, such as modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions. For clarity, this description separates the description of this signal processing from the RF and/or radio stages and conceptually allocates this signal processing to the analog baseband processing unit 810 and/or DSP 802 or other central processing unit. In some embodiments, the RF transceiver 808, portions of the antenna and front end unit 806, and the analog baseband processing unit 810 may be combined in one or more processing units and/or application-specific integrated circuits (ASICs).

The analog baseband processing unit 810 can provide various analog processing for inputs and outputs, such as analog processing for inputs from a microphone 812 and a headset 816, and analog processing for outputs to earphones 814 and earphones 816. To this end, the analog baseband processing unit 810 can include ports for connecting to a built-in microphone 812 and an earpiece speaker 814, which enables the UA 10 to be used as a cellular phone. The analog baseband processing unit 810 can also include ports for connecting to a headset or other hands-free microphone and speaker configuration. The analog baseband processing unit 810 can provide digital-to-analog conversion in one signal direction and analog-to-digital conversion in the opposite signal direction. In some embodiments, at least some of the functionality of the analog baseband processing unit 810 can be provided by digital processing components, such as the DSP 802 or other central processing unit.

The DSP 802 may perform modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions associated with wireless communications. In one embodiment, for example, in a code division multiple access (CDMA) technology application, the DSP 802 may perform modulation, encoding, interleaving, and spreading for transmitter functions, and despreading, deinterleaving, decoding, and demodulation for receiver functions. In another embodiment, for example, in an orthogonal frequency division multiple access (OFDMA) technology application, the DSP 802 may perform modulation, encoding, interleaving, inverse fast Fourier transform, and cyclic prefix addition for transmitter functions, and cyclic prefix removal, fast Fourier transform, deinterleaving, decoding, and demodulation for receiver functions. In other wireless technology applications, other signal processing functions and combinations of signal processing functions may be performed by the DSP 802.

The DSP 802 can communicate with a wireless network via the analog baseband processing unit 810. In some embodiments, this communication can provide an Internet connection, allowing users to access content on the Internet and send and receive emails or text messages. The input/output interface 818 interconnects the DSP 802 with various memories and interfaces. The memory 804 and the removable memory card 820 can provide software and data to configure the operation of the DSP 802. Among these interfaces can be a USB interface 822 and a short-range wireless communication subsystem 824. The USB interface 822 can be used to charge the UA 10 and can also enable the UA 10 to exchange information with a personal computer or other computer system as a peripheral device. The short-range wireless communication subsystem 824 can include an infrared port, a Bluetooth interface, an IEEE 802.11-compliant wireless interface, or any other short-range wireless communication subsystem that can enable the UA 10 to wirelessly communicate with other nearby mobile devices and/or wireless base stations.

When triggered, the input/output interface 818 can also connect the DSP 802 to the alarm 826 to cause the UA 10 to provide notification to the user by, for example, ringing, playing a melody, or vibrating. The alarm 826 can serve as a mechanism for alerting the user of any of a variety of events (such as an incoming call, a new text message, and an appointment reminder) by silently vibrating or by playing a specific pre-assigned melody assigned to a specific caller.

The keypad 828 is connected to the DSP 802 via the interface 818 to provide a mechanism for the user to make selections, enter information, and otherwise provide input to the UA 10. The keyboard 828 can be a full or reduced alphanumeric keyboard (such as QWERTY, Dvorak, AZERTY, and sequential types) or a traditional numeric keypad with letters associated with a telephone keypad. Input keys can include a scroll wheel, an exit or escape key, a trackball, and other navigation or function keys that can be pressed inward to provide other input functions. Another input mechanism can be an LCD 830, which can include touch screen capabilities and also display text and/or graphics to the user. An LCD controller 832 connects the DSP 802 to the LCD 830.

A CCD camera 834 (if equipped) enables the UA 10 to take digital pictures. The DSP 802 communicates with the CCD camera 834 via a camera controller 836. In alternative embodiments, cameras operating according to technologies other than charge-coupled device cameras may be used. A GPS sensor 838 is connected to the DSP 802 to decode global positioning system signals, thereby enabling the UA 10 to determine its location. Various other peripherals may also be included to provide additional functionality, such as radio and television reception.

FIG15 illustrates a software environment 902 that can be implemented by the DSP 802. The DSP 802 executes operating system drivers 904, which provide a platform on which the rest of the software can run. The operating system drivers 904 provide drivers for the UE hardware with standardized interfaces accessible by application software. The operating system drivers 904 include an application management service ("AMS") 906 that transfers control between applications running on the UA 10. Also shown in FIG18 are a web browser application 908, a media player application 910, and a Java applet 912. The web browser application 908 configures the UA 10 to operate as a web browser, allowing users to enter information into forms and select links to retrieve and view web pages. The media player application 910 configures the UA 10 to retrieve and play audio or audiovisual media. The Java applets 912 configure the UA 10 to provide games, tools, and other functionality. Component 914 may provide the functionality described herein.

The UA 10, access device 120, and other components described above may include processing components capable of executing instructions related to the aforementioned actions. FIG16 illustrates an example of a system 1000 including a processing component 1010 suitable for implementing one or more embodiments disclosed herein. In addition to a processor 1010 (which may be referred to as a central processing unit (CPU or DSP)), the system 1000 may include a network connection device 1020, a random access memory (RAM) 1030, a read-only memory (ROM) 1040, an auxiliary storage 1050, and input/output (I/O) devices 1060. In some cases, some of these components may not be present, or they may be combined in various combinations with each other or with other components not shown in the figure. These components may be located in a single physical entity or in more than one physical entity. Any actions described herein as being taken by the processor 1010 may be performed by the processor 1010 alone or in conjunction with one or more components shown or not shown in the figure.

Processor 1010 executes instructions, codes, computer programs, or scripts that it may access from network connection device 1020, RAM 1030, ROM 1040, or secondary storage 1050 (which may include various disk-based systems, such as hard disks, floppy disks, or optical disks). Although only one processor 1010 is shown, multiple processors may be present. Thus, although instructions may be discussed as being executed by a processor, instructions may be executed simultaneously, serially, or in other ways by one or more processors. Processor 1010 may be implemented as one or more CPU chips.

The network connection device 1020 may be a modem, a modem bank, an Ethernet device, a Universal Serial Bus (USB) interface device, a serial interface, a token ring device, a Fiber Distributed Data Interface (FDDI) device, a Wireless Local Area Network (WLAN) device, a radio frequency transceiver device (such as a Code Division Multiple Access (CDMA) device, a Global System for Mobile Communications (GSM) radio transceiver device, a Worldwide Interoperability for Microwave Access (WiMAX) device), and/or other well-known devices for connecting to a network. These network connection devices 1020 may enable the processor 1010 to communicate with the Internet or one or more communication networks or other networks from which the processor 1010 can receive information or output information.

The network connection device 1020 may also include one or more transceiver components 1025 capable of wirelessly transmitting and/or receiving data in the form of electromagnetic waves (such as radio frequency signals or microwave frequency signals). Alternatively, the data may be transmitted in or on the surface of an electrical conductor, in a coaxial cable, in a waveguide, in an optical medium (such as an optical fiber), or in other media. The transceiver component 1025 may include separate receiving and transmitting units, or a single transceiver. The information transmitted or received by the transceiver component 1025 may include data processed by the processor 1010 or instructions to be executed by the processor 1010. This information may be received from and output to the network in the form of, for example, computer data baseband signals or signals embodied in a carrier wave. The data may be sorted in various sequences required for processing or generating the data or for transmitting or receiving the data. Baseband signals, signals embedded in a carrier wave, or other types of signals currently used or later developed may be referred to as transmission media, and these signals may be generated according to a number of methods well known to those skilled in the art.

RAM 1030 can be used to store volatile data and possibly to store instructions to be executed by processor 1010. ROM 1040 is a non-volatile memory device that typically has a smaller memory capacity than that of secondary storage 1050. ROM 1040 can be used to store instructions and data that may be read during program execution. Access to RAM 1030 and ROM 1040 is generally faster than access to secondary storage 1050. Secondary storage 1050 typically includes one or more disk drives or tape drives and can be used for non-volatile storage of data or as an overflow data storage device if RAM 1030 is not large enough to hold all working data. Secondary storage 1050 can be used to store programs that are loaded into RAM 1030 when such programs are selected for execution.

The I/O devices 1060 may include a liquid crystal display (LCD), a touch screen display, a keyboard, a keypad, switches, a dial, a mouse, a trackball, a voice recognizer, a card reader, a paper tape reader, a printer, a video monitor, or other well-known input devices. Similarly, the transceiver 1025 may be considered a component of the I/O devices 1060 rather than or in addition to the network connectivity devices 1020. Some or all of the I/O devices 1060 may be substantially similar to the various components shown in the previous figures of the UA 10, such as the display 702 and input 704 shown in FIG. 13 .

The following 3rd Generation Partnership Project (3GPP) Technical Specifications (TS) are incorporated herein by reference: TS 36.321, TS 36.331, TS 36.300, TS 36.211, TS 36.212, and TS 36.213.

Although several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples should be considered illustrative rather than restrictive, and the present invention is not intended to be limited to the details given herein. For example, various units or components may be combined or integrated into another system, or specific features may be omitted or not implemented.

In addition, the techniques, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or described as connected or directly connected or communicating with each other may be indirectly connected or communicating through an interface, device, or intermediate component, whether electronically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations may be determined by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

In order to apprise the public of the scope of the present disclosure, the following claims are made.

Claims (26)

1. A method for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by control channel element (CCE) subset candidates, a CCE subset candidate on a carrier is associated with more than one carrier, one of the CCE subset candidates is associated with one carrier, and the carrier used for data transmission and reception is a configuration carrier, the method comprising the steps of: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored. 2. The method of claim 1, wherein the activation signal indicates that the uplink carrier is active and indicates that the corresponding pair of downlink carriers is deactivated, and the step of identifying CCE subset candidates includes: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DAC0 format. 3. The method of claim 1, wherein the activation signal is included in Media Access Control (MAC) signaling. 4. The method of claim 1, wherein the activation signal is included in physical signaling. 5. The method according to claim 3, further comprising: decoding the activation signal. 6. The method of claim 1, wherein the CCE subset candidate is identified based on the index of the corresponding carrier. 7. The method of claim 1, wherein the identified resource permission corresponds to a downlink control information (DCI) message. 8. A user equipment for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by control channel element (CCE) subset candidates, a CCE subset candidate on a carrier is associated with more than one carrier, one of the CCE subset candidates is associated with one carrier, and the carrier for data transmission and reception is a configuration carrier, the user equipment comprising: One or more processors are configured as follows: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored. 9. The user equipment of claim 8, wherein the activation signal indicates that the uplink carrier is active and indicates that the corresponding pair of downlink carriers is deactivated, and identifying CCE subset candidates includes: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DAC0 format. 10. The user equipment of claim 8, wherein the activation signal is included in Media Access Control (MAC) signaling. 11. The user equipment of claim 8, wherein the activation signal is included in physical signaling. 12. The user equipment of claim 11, wherein the one or more processors are further configured to: decode the activation signal. 13. The user equipment of claim 8, wherein the CCE subset candidate is identified based on the index of the corresponding carrier. 14. The user equipment according to claim 8, wherein the identified resource license corresponds to a downlink control information (DCI) message. 15. A network device for transmitting a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by control channel element (CCE) subset candidates, a CCE subset candidate on a carrier is associated with more than one carrier, one of the CCE subset candidates is associated with one carrier, and the carrier for data transmission and reception is a configuration carrier, the network device comprising: The transmitter is configured to transmit activation signals for designated activation and deactivation carriers in a configuration carrier, wherein the activation carrier includes a number of CCE subset candidates to be decoded, and the user equipment ignores the associated CCE subset candidates in the deactivation carrier. 16. The network device of claim 15, wherein the activation signal indicates that the uplink carrier is active and indicates that the corresponding pair of downlink carriers is deactivated, and identifying CCE subset candidates includes: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DAC0 format. 17. The network device of claim 15, wherein the activation signal is included in Media Access Control (MAC) signaling. 18. The network device of claim 15, wherein the activation signal is included in physical signaling. 19. The network device of claim 15, wherein the CCE subset candidate is identified based on the index of the corresponding carrier. 20. The network device of claim 15, wherein the identified resource permission corresponds to a downlink control information (DCI) message. 21. A method for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by a subset of control channel elements (CCEs) candidates, and the carriers used for data transmission and reception are configured carriers, the method comprising the steps of: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored; The steps of indicating that the uplink carrier is active and the corresponding downlink carrier pair is deactivated, and identifying CCE subset candidates, include: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DCI0 format. 22. A method for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by a subset of control channel elements (CCEs) candidates, and the carriers used for data transmission and reception are configured carriers, the method comprising the steps of: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored; The activation signal indicates that the uplink carrier is active and that the corresponding downlink carrier pair is deactivated. 23. A user equipment for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by a subset candidate of control channel elements (CCEs), and the carriers used for data transmission and reception are configured carriers, the user equipment comprising: One or more processors are configured as follows: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored; The activation signal indicates that the uplink carrier is active and that the corresponding pair of downlink carriers is deactivated. Identifying CCE subset candidates includes: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DCI0 format. 24. A user equipment for processing a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein resource grants are specified by a subset of candidate control channel elements (CCEs), and the carriers used for data transmission and reception are configured carriers, the user equipment comprising: One or more processors are configured as follows: Receive activation signals for specified active and deactivation carriers in the configuration carrier; For the active carrier: (i) Identify a certain number of CCE subset candidates to be decoded; and (ii) Decode the identified subset of CCE candidates in a single attempt to identify resource licenses; and For deactivated carriers, the CCE subset candidates associated with the deactivated carriers are ignored; The activation signal indicates that the uplink carrier is active and that the corresponding downlink carrier pair is deactivated. 25. A network device for transmitting a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein the resource grants are specified by a subset candidate of control channel elements (CCEs), and the carriers used for data transmission and reception are configuration carriers, the network device comprising: The transmitter is configured to transmit activation signals for designated activation and deactivation carriers in a configuration carrier, wherein the activation carrier includes a certain number of CCE subset candidates to be decoded, and the user equipment ignores the associated CCE subset candidates in the deactivation carrier; The activation signal indicates that the uplink carrier is active and that the corresponding pair of downlink carriers is deactivated. Identifying CCE subset candidates includes: for the active uplink carrier used for decoding, identifying only candidates associated with the downlink control information DCI0 format. 26. A network device for transmitting a control channel at a user agent (UA) to identify at least one of uplink and downlink resources allocated by resource grants in a multi-carrier communication system, wherein the resource grants are specified by a subset candidate of control channel elements (CCEs), and the carriers used for data transmission and reception are configured carriers, the network device comprising: The transmitter is configured to transmit activation signals for designated activation and deactivation carriers in a configuration carrier, wherein the activation carrier includes a certain number of CCE subset candidates to be decoded, and the user equipment ignores the associated CCE subset candidates in the deactivation carrier; The activation signal indicates that the uplink carrier is active and that the corresponding downlink carrier pair is deactivated.