Method and apparatus for mobile communications

Abstract

Various schemes for dynamic cross-carrier scheduling related to the UE and network device in mobile communications are described. The device can receive a PDCCH on a first CC. The device can receive a PDSCH on the first CC scheduled by the PDCCH. The device can determine a second CC to transmit a PUCCH based on the configuration of the dynamically switched CC. The device can transmit a PUCCH corresponding to the PDSCH on the second CC scheduled by the PDCCH. The device can receive a PDCCH on the second CC. The device can receive a PDSCH on the second CC scheduled by the PDCCH. By utilizing this invention, mobile communications can be performed more effectively.

Description

[0001] Cross-references This invention claims priority to U.S. Provisional Application No. 62 / 924,815, filed October 23, 2019, and U.S. Provisional Application No. 63 / 039,513, filed June 16, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention relates to mobile communications, and more particularly to dynamic cross-carrier scheduling in mobile communications in relation to user equipment (UE) and network devices for improving latency and uplink control information (UCI) transmission. Background Technology

[0003] Unless otherwise indicated, the methods described in this section are not prior art to the claims and are not acknowledged as prior art by virtue of their inclusion in this section.

[0004] In Long Term Evolution (LTE) or New Radio (NR), Hybrid Automatic Repeat reQuest (HARQ) Acknowledgement (ACK) information transmission is introduced to improve transmission reliability and robustness. The UE needs to report HARQ-ACK information in the HARQ-ACK codebook for the corresponding downlink (DL) reception. The HARQ-ACK codebook can be transmitted in a single time slot, indicated by the value of the HARQ feedback timing indicator field in the corresponding Downlink Control Information (DCI) format. This DCI format can also indicate the Physical Uplink Control Channel (PUCCH) resource scheduled for HARQ-ACK information transmission. HARQ-ACK multiplexing can be used to facilitate HARQ-ACK information transmission. Multiple HARQ-ACK responses corresponding to multiple Physical Downlink Shared Channels (PDSCHs) can be accumulated, multiplexed, and transmitted to the network device at once. A single PUCCH resource can be used to carry multiple HARQ-ACK responses for transmission in the same time slot.

[0005] The current framework for transmitting HARQ feedback bits is unsuitable for Ultra-Reliable and Low-Latency Communications (URLLC). URLLC was introduced for emerging applications with high requirements for end-to-end latency and reliability. A typical URLLC requirement is that a 32-byte packet should be transmitted within 1 millisecond of end-to-end latency, with a success rate of 100%. -5 URLLC services are typically sporadic and short-lived, with stringent requirements for low latency and high reliability. For example, control reliability in URLLC is more critical than data reliability, while data reliability can reach as high as 10. -6 Block Error Rate (BLER). Accordingly, allowing only one PUCCH resource in the uplink (UL) slot for HARQ feedback bit transmission increases transmission latency.

[0006] On the other hand, multi-link operation is introduced to increase the system capacity and transmission efficiency of the communication system. Multi-link operation can be implemented through carrier aggregation (CA) or dual connectivity (DC), where additional links can be used to increase the amount of data that can be transferred to or from the UE. A UE can be configured with more than one radio link (e.g., component carrier (CC)) and can connect to more than one network node (e.g., serving cell). Under the CA framework, cross-carrier scheduling is supported to improve transmission efficiency and reduce latency. Cross-carrier scheduling allows the UE to connect to different network nodes to receive downlink data on different carriers. Cross-carrier scheduling can also be used to balance the load of services scheduled on different component carriers. Without cross-carrier scheduling, downlink scheduling assignments on the Physical Downlink Control Channel (PDCCH) are only valid for the component carriers that transmit them. With cross-carrier scheduling, downlink scheduling assignments can be received on component carriers different from the component carriers receiving the PDCCH.

[0007] However, the current NR framework does not support cross-carrier scheduling for UCI transmissions (such as PUCCH). In 3GPP Release-16, PUCCH carriers are semi-statically allocated to individual cells within a PUCCH cell group. In Time Division Duplex (TDD) systems, the uplink / downlink TDD pattern is the bottleneck for URLLC latency. TDD allows uplink and downlink to use the entire spectrum, but in different time slots. Time can be divided into short time slots, some of which can be designated for uplink and others for downlink. This approach supports asymmetric traffic and time-varying uplink and downlink demands. However, since PUCCH can only be scheduled in uplink time slots, in events where more time slots are allocated as downlink time slots in the TDD pattern, the duration between uplink time slots will be excessively long, resulting in excessive latency. The worst-case PUCCH alignment delay depends primarily on the downlink and uplink lengths and may prevent the application of URLLC retransmission. Therefore, it is necessary to introduce cross-carrier scheduling in PUCCH transmission and improve UCI transmission for URLLC.

[0008] Accordingly, reducing alignment delay / latency and improving reliability are important issues for URLLC applications in newly developed wireless communication networks. Therefore, when supporting URLLC, appropriate cross-carrier scheduling mechanisms and UCI transmission improvements are needed to achieve better performance. Summary of the Invention

[0009] The following description is merely illustrative and is not intended to limit the invention in any way. That is, it is provided to introduce the novel and non-obvious technical concepts, highlights, benefits, and advantages described herein. Preferred embodiments will be further described in the Detailed Description section. Therefore, the following description is neither intended to identify the essential features of the claimed subject matter nor to define the scope of the claimed subject matter.

[0010] One object of the present invention is to provide a solution or scheme for solving the problems related to dynamic cross-carrier scheduling in mobile communications for UE and network devices to improve latency and improve UCI transmission.

[0011] A method for mobile communication includes: receiving a physical downlink control channel on a first component carrier by a processor of the device; receiving a physical downlink shared channel on the first component carrier scheduled by the physical downlink control channel by the processor; determining a second component carrier to transmit a physical uplink control channel according to a configuration of dynamically switched component carriers by the processor; transmitting the physical uplink control channel corresponding to the physical downlink shared channel on the second component carrier scheduled by the physical downlink control channel by the processor; receiving the physical downlink control channel on the second component carrier by the processor; and receiving the physical downlink shared channel on the second component carrier scheduled by the physical downlink control channel by the processor.

[0012] By utilizing this invention, mobile communication can be improved.

[0013] It is worth noting that, although the description of the present invention may be in the context of specific radio access technologies, networks, and network topologies (such as Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, 5G), the specific network access technologies, networks, and network topologies described herein may vary. thThe invention is provided in the context of Generation (5G), New Radio (NR), Internet of Things (IoT), and Narrow Band-IoT (NB-IoT), but the concepts, schemes, and any variations or derivatives thereof proposed in this invention may be implemented, for use with, or by other types of radio access technologies, networks, and network topologies. Therefore, the scope of this invention is not limited to the examples described herein. Attached Figure Description

[0014] The accompanying drawings are included to provide a further understanding of the invention, and are incorporated into and constitute a part of this invention. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. It is understood that the drawings are not necessarily to scale, as some components may be shown at dimensions that are not proportional to actual dimensions in a practical implementation, in order to clearly illustrate the concepts of the invention.

[0015] Figure 1 This is a schematic diagram illustrating an exemplary scenario under an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of an exemplary scenario under the scheme of an embodiment of the present invention.

[0017] Figure 3 This is a schematic diagram of an exemplary scenario under the scheme of an embodiment of the present invention.

[0018] Figure 4 This is a schematic diagram of an exemplary scenario under the scheme of an embodiment of the present invention.

[0019] Figure 5 This is a block diagram of an exemplary communication device and an exemplary network device according to embodiments of the present invention.

[0020] Figure 6 This is a flowchart illustrating an exemplary process according to an embodiment of the present invention.

[0021] Figure 7 This is a flowchart illustrating an exemplary process according to an embodiment of the present invention.

[0022] Figure 8 This is a flowchart illustrating an exemplary process according to an embodiment of the present invention. Detailed Implementation

[0023] This invention discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter, which can be implemented in various forms. The invention can be implemented in many different forms and should not be construed as limited to the exemplary embodiments and implementations described herein. Rather, these exemplary embodiments and implementations are provided so that the description of the invention is thorough and complete, and can fully convey the scope of the invention to those skilled in the art. In the following description, well-known features and technical details may be omitted to avoid unnecessarily obscuring the embodiments and implementations of the invention.

[0024] Overview According to embodiments of the present invention, there are various techniques, methods, schemes, and / or solutions related to dynamic cross-carrier scheduling in mobile communications involving UEs and network devices to improve latency. According to the present invention, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described individually below, two or more of these solutions may be implemented in one combination or another combination.

[0025] The current NR framework does not support cross-carrier scheduling for UCI transmissions (such as PUCCH). In 3GPPRelease-16, PUCCH carriers are semi-statically configured to individual cells within a PUCCH cell group. In TDD systems, the uplink / downlink TDD pattern is the bottleneck for URLLC latency. TDD allows uplink and downlink to use the entire spectrum, but in different time slots. Time can be divided into short time slots, some of which can be designated for uplink and others for downlink. This approach supports asymmetric traffic and time-varying uplink and downlink requirements. However, since PUCCH can only be scheduled in uplink time slots, in events where more time slots are allocated as downlink time slots in the TDD pattern, the duration between uplink time slots will be excessively long, resulting in excessive latency. The worst-case PUCCH alignment delay depends primarily on the length of the downlink and uplink and may prevent the application of URLLC retransmissions. Therefore, it is necessary to introduce cross-carrier scheduling in PUCCH transmission and improve UCI transmission in URLLC.

[0026] In view of the above, this invention proposes several schemes related to dynamic cross-carrier scheduling of UE and network devices to improve latency and UCI transmission. The schemes according to the invention support CA systems with TDD carriers, where the TDD carriers have appropriate time offsets between uplink slots on different CCs. The UE can be configured with dynamic cross-carrier scheduling for PUCCH. Dynamic switching of CCs for PUCCH helps reduce latency in CAs with two or more carriers, where these two or more carriers may have different TDD patterns. Furthermore, dynamic cross-carrier scheduling of PDSCH and / or Physical Uplink Shared Channel (PUSCH) can be configured for the UE. Additionally, SRs with Scheduling Request (SR) resources can be configured on each CC within a cell group. The UE can be configured with multiple SR resources on multiple CCs. On the other hand, improvements to the PUCCH format can also be introduced. The current PUCCH formats 1, 3, and 4 can be redesigned to improve reliability and reduce latency. Accordingly, by applying the solution of this invention, the performance of UCI transmission can be improved to reduce alignment delay / latency. Applications with URLLC requirements can benefit from the improvements achieved by this invention.

[0027] Figure 1 An exemplary scenario 100 can be illustrated under the scheme of an embodiment of the present invention. Scenario 100 may include a UE and multiple network nodes, which may be part of a wireless communication network (such as an LTE network, 5G network, NR network, IoT network, or NB-IoT network). Scenario 100 may illustrate an example of dynamic cross-carrier scheduling of PUCCH. The UE may be configured with multiple CCs, such as a first CC (e.g., CC1) and a second CC (e.g., CC2). For uplink / downlink time slots, the first CC and the second CC may have different TDD patterns. For example, for CC1, the ratio of downlink time slots to uplink time slots may be 3:1, and for CC2, it may be 5:1. To reduce alignment delay, the UE may configure dynamic switching of CCs for PUCCH.

[0028] Specifically, the UE can receive the PDCCH on the first CC. The PDCCH can schedule the PDSCH on the first CC. The UE can receive the PDSCH on the first CC scheduled by the PDCCH. Then, the UE can transmit the HARQ-ACK information corresponding to the PDSCH to the network node. Therefore, the PDCCH can also schedule the PUCCH for transmitting HARQ-ACK information. To reduce latency, the PUCCH can be scheduled on different CCs. For example, the nearest uplink time slot for PUCCH transmission can be allocated on the second CC. Therefore, the UE can determine the second CC to transmit the PUCCH according to the configuration of dynamic CC handover. Then, the UE can transmit the PUCCH corresponding to the PDSCH on the second CC scheduled by the PDCCH.

[0029] This invention provides a method for configuring multiple dynamically selectable CC options for a PUCCH carrying HARQ-ACK information. For example, within a cell group, the CCs used for the PUCCH are dynamically selectable. The configuration for dynamically switching CCs can include multiple CCs configured to be used for transmitting the PUCCH. Some limitations can be placed on the number of selectable CCs. For example, only a predetermined number of CCs (e.g., K = 2 CCs) can be used to transmit the PUCCH. The UE can receive a configuration for configuring multiple CCs that can be used to transmit the PUCCH within a cell group (e.g., Radio Resource Control (RRC) configuration). For example, multiple serving cells within a cell group can be appointed for PUCCH transmission (e.g., per PDSCH serving cell (PDSCH-ServingCell) configuration). The PUCCH-Cell field of the PDSCH-ServingCell configuration can be allowed to list up to K elements of the ServCellIndex. The contents of the HARQ-ACK codebook carried by the PUCCH can be independent of the CC (such as CC2) selected for the PUCCH transmission.

[0030] Configuration for dynamically switching CCs can include physical (PHY) layer signaling. In one example, this configuration could include a data field that allows selection of a CC from multiple distinct CCs for PUCCH transmission. A new field could be introduced for explicit selection among K distinct CCs. In another example, the configuration could include an indication of the earliest uplink slot / subslot on multiple CCs. The earliest uplink slot / subslot on any CC can be selected. This behavior can be configured via a HARQ process, signaled via a special K1 index / value, or by sending one bit in any other available manner. In yet another example, the configuration could include a data field for selecting CCs and slots / subslots. CCs and slots / subslots can be selected using the same field K1, which counts the boundaries of the slot / subslot across all CCs that can be selected for PUCCH transmission. Optionally, the slot / sub-slot count can be incremented in events where the slot / sub-slot following this boundary contains uplink symbols or flexible downlink / uplink symbols. The reference point for the K1 offset can be the end of the PDSCH or the end of the N1UE processing timeline.

[0031] Some constraints / rules may exist for the above configuration. For example, different CCs can use different parameter sets (numerology) or slot / sub-slot partitioning configurations. Although this may affect the range of offsets that the K1 field can handle, the number of CCs used for PUCCH transmission is not limited. All of the above features (such as dynamic cross-carrier scheduling for PUCCH) can be enabled for each HARQ process. Optionally, it is possible to support the formation of HARQ cell groups within the same cell group to allow the simultaneous construction of multiple HARQ-ACK codebooks. In this case, the proposed behavior can apply to HARQ cell groups rather than cell groups. PHY layer signaling methods can be introduced to select HARQ cell groups.

[0032] In some implementations, dynamic cross-carrier scheduling of the PUCCH can be configured based on different Radio Network Temporary Identity (RNTI) fields (e.g., Cell RNTI, Modulation and Coding Scheme RNTI, MCS RNTI, etc.), search spaces, or different DCI formats / sizes, where dynamic cross-carrier scheduling of the PUCCH dynamically indicates the carriers used to carry the PUCCH. In another implementation, any other DCI field can be used to indicate the component carriers used to carry the PUCCH. In yet another implementation, a UE-specific DCI or Group Common-DCI (GC-DCI) can be used to signal the component carriers carrying the PUCCH.

[0033] In some implementations, restrictions can be placed on the dynamic cross-carrier scheduling of PUCCH. For example, a set of carriers used to carry dynamically scheduled PUCCH can be contained within a PUCCH group or a cell group. Carriers used for dynamic cross-carrier scheduling can span PUCCH groups and / or cell groups. A group of M carriers (e.g., a PUCCH group, cell group, or a newly defined cell group) can be mapped to a specific group of N carriers capable of carrying PUCCH. Dynamic cross-carrier scheduling of PUCCH can be allowed between the M carriers and the N associated carriers capable of carrying PUCCH. If a carrier indicator field is added to the DCI used for PUCCH carrier indication, the size of the bit-field can be determined by ceiling (log2(N)). In another implementation, each carrier in the group of M carriers can be configured with an associated group of N carriers capable of carrying dynamic PUCCH. This group of N carriers can be a subgroup of the group of M carriers. Alternatively, the group of M carriers and the group of N carriers can overlap or be completely disjoint. A group of M carriers (e.g., a PUCCH group, a cell group, or a newly defined cell group) can be configured with semi-static or dynamic cross-carrier scheduling of PUCCH by a network node (e.g., a gNB). The above-mentioned restriction on carrier subsets can also be applied to any method of cross-carrier indication (e.g., explicit indications such as DCI or search space, or implicit indications such as the earliest available PUCCH).

[0034] In some implementations, UE capability reporting can be performed for dynamic cross-carrier scheduling of PUCCHs. Specifically, supporting dynamic cross-carrier scheduling of PUCCHs can be defined as a UE capability. In events where a UE is capable of supporting dynamic cross-carrier scheduling of PUCCHs, the UE can be configured to report to the network node. The UE can report the number or maximum number of groups (e.g., PUCCH groups, cell groups, or newly defined cell groups) for which it can support dynamic cross-carrier scheduling of PUCCHs. In events where a UE is capable of supporting dynamic cross-carrier scheduling of PUCCHs, the UE can also report its capability for each group (e.g., PUCCH groups, cell groups, or newly defined cell groups). In another implementation, the UE can report the number of PUCCH groups for which it can support dynamic cross-carrier scheduling. In another implementation, the UE can report the number of PUCCH groups for which it can support semi-static cross-carrier scheduling and / or dynamic cross-carrier scheduling. In yet another implementation, a specific number of CCs can be defined for dynamic cross-carrier scheduling, and the UE can report the number it can support. In addition, the UE can report the number N of carriers it can support for dynamic cross-carrier scheduling of PUCCH for each group (such as a PUCCH group, cell group, or a newly defined cell group). If the UE can support dynamic cross-carrier scheduling of PUCCH, the UE can report this for each carrier. The UE can report the total number or maximum number of carriers it can support for dynamic cross-carrier scheduling of PUCCH.

[0035] In some implementations, the Priority (PRI) field and / or other fields similar to K1 can be padded with 0s to align the DCI size, allowing dynamic selection of the carrier carrying the PUCCH without changing the DCI size (e.g., similar to the case of different priorities). This specific DCI size alignment can be enabled when dynamic cross-carrier PUCCH is enabled. When dynamic cross-carrier transmission of PUCCH is enabled, multiple high-priority HARQ-ACK codebooks can be built simultaneously in a PUCCH group or cell group.

[0036] In some implementations, certain restrictions can be placed on the configuration of dynamic cross-carrier scheduling for PUCCH. For example, dynamic carrier selection for PUCCH transmission can be limited to at least one of the following: a PUCCH carrying HARQ-ACK, a PUCCH carrying a high-priority HARQ-ACK codebook, a high-priority SR, and high-priority Channel State Information (CSI). Semi-static PUCCHs can be configured for low-priority HARQs. Dynamic PUCCH selection can be configured for high-priority HARQs. In another example, a group (e.g., a PUCCH group, cell group, or a newly defined cell group) can be configured with dynamic carrier selection for PUCCHs for high-priority HARQ-ACK. In another example, a group (e.g., a PUCCH group, cell group, or a newly defined cell group) can be configured with static carrier selection for PUCCHs for low-priority HARQ-ACK. In yet another example, support for dynamic carrier selection for PUCCH transmission can be limited to carriers that support sub-slot-based HARQ-ACK feedback processes. In another example, for a group of carriers, PUCCH groups, or cell groups where some carriers support sub-slot-based HARQ-ACK feedback but some carriers support slot-based HARQ-ACK feedback, dynamic carrier selection that supports PUCCH transmission may not be allowed.

[0037] In another example, dynamic carrier selection can allow only carriers with the same parameter set for PUCCH transmission. In another example, dynamic carrier selection can allow only certain PUCCH formats (e.g., only short PUCCH formats) for PUCCH transmission. In yet another example, when dynamic carrier selection for PUCCH transmission is enabled, a default PUCCH carrier can be defined. The default PUCCH carrier can be used as a fallback when there is a conflict between a PUCCH and another high-priority transmission. When a PUCCH scheduled via dynamic carrier selection conflicts with a high-priority PUSCH, the PUCCH and PUSCH can be multiplexed in events where the PUCCH carries a high-priority HARQ / SR. When a PUCCH scheduled via dynamic carrier selection conflicts with a high-priority PUSCH, the PUCCH transmission can fall back to the default PUCCH carrier in events where the PUCCH carries a low-priority HARQ / SR. In yet another example, dynamic carrier selection can allow only HARQ-ACK codebook type 1 or type 2 for PUCCH transmission.

[0038] In some implementations, in the event that a PUCCH transmission is dropped due to a collision, a network node may request the same PUCCH transmission on another specific carrier.

[0039] Additionally, a PUCCH resource determination with dynamic carrier selection can be proposed for PUCCH transmission. Combining all the following proposals regarding K1, when dynamic carrier selection for PUCCH transmission using explicit or implicit carrier indication is supported between carriers with different parameter sets and / or uplink sub-slot partitioning (including slot-based configurations), the required UE processing time between the end of PDSCH reception (e.g., Sub-Carrier Spacing (SCS) is u1) and the start of PUCCH transmission (e.g., SCS is u2) can be determined by max(T1, T2). T1 = N1_1 x S1, where N1_1 is the UE processing time for a single parameter set with SCS u1, and S1 is the symbol duration with SCS u1. T2 = N1_2 x S2, where N1_2 is the UE processing time for a single parameter set with SCS u2, and S2 is the symbol duration with SCS u2. When the target carrier is implicitly selected by rules, max(T1, T2) can be evaluated individually for each assumed target carrier.

[0040] In some implementations, when dynamic carrier selection for PUCCH transmission using explicit or implicit carrier indication is supported between carriers with different parameter sets and / or uplink sub-slot divisions (including slot-based configurations), K1 can apply a common unit to a set of carriers that allow cross-carrier scheduling. Conveniently, K1 can be the shortest sub-slot length configured in the CC, represented by the parameter set of the CC and the highest SCS in the configured or active Bandwidth Part (BWP). In another implementation, K1 can apply a flexible unit specific to each carrier pair that may participate in cross-carrier scheduling and their roles. Conveniently, K1 can be evaluated by trying all hypothetical CCs for the PUCCH and using a two-dimensional (2D) table, where the 2D table can define the unit of K1 for each ordered pair of CCs (e.g., first CC: PDCCH, second CC: PUCCH). In another implementation, K1 can apply the unit configured for the indicated target carrier for the PUCCH.

[0041] On the other hand, for TDD systems, the worst-case PDSCH / PUSCH alignment delay can depend primarily on the downlink and uplink lengths, and may prohibit the application of URLLC retransmission. Therefore, to reduce alignment delay, a CA system with TDD carriers can be adopted, where the TDD carriers have appropriate time offsets between uplink time slots of different CCs, and dynamic cross-carrier scheduling of PDSCH / PUSCH can be introduced. Figure 2An exemplary scenario 200 can be illustrated under the scheme of an embodiment of the present invention. Scenario 200 may include a UE and multiple network nodes, which may be part of a wireless communication network (such as an LTE network, 5G network, NR network, IoT network, or NB-IoT network). Scenario 200 may illustrate an example of dynamic cross-carrier scheduling of PDSCH and / or PUSCH. The UE may be configured with multiple CCs, such as a first CC (e.g., CC1) and a second CC (e.g., CC2). For uplink / downlink time slots, the first CC and the second CC may have different TDD patterns. For example, CC1 and CC2 may have opposite downlink / uplink time slot distributions. To reduce alignment delay, the UE may be configured to dynamically switch the CCs used for PDSCH and / or PUSCH.

[0042] Specifically, the UE can receive a first PDCCH for scheduling PDSCH on a first CC. The first PDCCH can schedule PDSCH on the first CC. The UE can receive PDSCH on the first CC scheduled by the first PDCCH. The UE can also receive a second PDCCH for scheduling PUSCH on the first CC. To reduce latency, PUSCH can be scheduled on a different CC (such as the second CC) with the closest uplink time slot. Therefore, the UE can determine the second CC to transmit PUSCH based on the configuration of dynamic CC handover. Then, the UE can transmit PUSCH on the second CC scheduled by the second PDCCH.

[0043] Similarly, the second CC can also schedule PUSCH / PUCCH on different CCs (such as the first CC) and can monitor multiple carriers for PDCCH. Figure 2 As shown, the UE can receive a first PDCCH on the second CC to schedule a PDSCH. The first PDCCH can schedule a PDSCH on the second CC. The UE can receive a PDSCH on the second CC scheduled by the first PDCCH. The UE can also receive a second PDCCH on the second CC for scheduling a PUSCH. To reduce latency, the PUSCH can be scheduled on different CCs (such as the first CC) with the closest uplink time slots. Therefore, the UE can determine the first CC to transmit the PUSCH based on the configuration of dynamic CC handover. Then, the UE can transmit the PUSCH on the first CC scheduled by the second PDCCH.

[0044] In some implementations, dynamic cross-carrier scheduling can also be applied to PDSCH. The UE can receive the PDCCH used for scheduling PDSCH on a first CC. The first PDCCH can schedule PDSCH on a different CC (e.g., a second CC). The UE can determine whether to receive PDSCH on the second CC based on the configuration of dynamic CC handover. The UE can receive PDSCH on the second CC scheduled by the PDCCH.

[0045] This invention provides a method for configuring multiple dynamically selectable CC options, on which scheduling information for PDSCH / PUSCH can be transmitted. For example, the number of selectable CCs can be limited. In another example, the aforementioned behavior can be enabled only when a physical indication of URLLC or high-priority traffic is detected from the PDSCH or the resources allocated for the PDSCH. In yet another example, PDCCH monitoring can be limited to each monitoring event on a single carrier or a set of monitoring events on a CC. When multiple CCs include downlink and monitoring events, priority rules can be used (e.g., the primary cell within a cell group can have higher priority). Multiple CCs can be configured with different sets of parameters.

[0046] On the other hand, for TDD systems, the worst-case SR alignment delay can depend primarily on the downlink and uplink lengths and may prohibit the application of URLLC retransmission. Therefore, to reduce alignment delay, a CA system with TDD carriers can be adopted, where the CCs of the TDD carriers have appropriate time offsets and can support the configuration of SRs with SR resources on each CC within a cell group. Figure 3 An exemplary scenario 300 can be illustrated under the scheme of an embodiment of the present invention. Scenario 300 may include a UE and multiple network nodes, which may be part of a wireless communication network (such as an LTE network, 5G network, NR network, IoT network, or NB-IoT network). Scenario 300 may illustrate an example of multiple SR resources configured on multiple CCs. The UE may be configured with multiple CCs, such as a first CC (e.g., CC1) and a second CC (e.g., CC2). For uplink / downlink time slots, the first CC and the second CC may have different TDD patterns. For example, for CC1, the ratio of downlink time slots to uplink time slots may be 3:1, and for CC2, it may be 5:1. To reduce alignment delay, the UE may be configured with multiple SR resources distributed across each CC. For example, at least one SR resource may be configured on each CC within a cell group.

[0047] Specifically, the UE can receive a configuration that can configure multiple SR resources on multiple CCs. This configuration may include logical channel configuration, scheduling request configuration, scheduling request resource configuration, PUCCH configuration, or PUCCH resource configuration. When the UE attempts to initiate an SR process, it can determine one SR resource from the multiple SR resources on multiple CCs to transmit the SR. For example, the UE can determine the earliest SR resource on multiple CCs to transmit the SR. The UE can then transmit the SR on the determined SR resource. An SR can have multiple SR resources (e.g., PUCCH, period, and offset), and these multiple SR resources can be operated using a common prohibition timer. SR resources allocated to the same SR can reside on different CCs and uplink BWPs within a cell group.

[0048] To further improve PUCCH transmission to reduce latency and / or increase the reliability of HARQ feedback, some improvements to the PUCCH format can also be introduced. Figure 4 An exemplary scenario 400 can be illustrated under the scheme of an embodiment of the present invention. Scenario 400 may include a UE and multiple network nodes, which may be part of a wireless communication network (such as an LTE network, 5G network, NR network, IoT network, or NB-IoT network). The conventional PUCCH format 1 in 3GPP Release-15 contains 4 symbols and begins after the N1 UE processing timeline. Therefore, the PUCCH transmission delay may include N1 + alignment + PUCCH duration. To reduce latency, some improvements to the PUCCH format can be proposed. The UE can be configured to support formats with 2, 3, 4, or other symbol lengths. The length of the PUCCH format can be determined by a length of M+N, where N demodulation reference signal (DMRS) symbols are followed by a mixture of M long ACK and DMRS symbols.

[0049] Specifically, the UE can be configured to determine the PUCCH format for transmitting HARQ-ACK information. The UE can transmit the PUCCH format using the length of two or three Orthogonal Frequency Division Multiplexing (OFDM) symbols. For example, the PUCCH format may include two or three symbols. Therefore, the PUCCH duration can be reduced to improve latency. Furthermore, the UE can shuffle the PUCCH symbols by starting the PUCCH format with at least one (e.g., one or more) DMRS symbols. The UE can arrange the PUCCH format by following multiple DMRS symbols with at least one HARQ-ACK information symbol. For example, the PUCCH format may begin with one DMRS symbol followed by one HARQ-ACK data symbol. In another example, the PUCCH format may begin with two DMRS symbols followed by one HARQ-ACK data symbol. The UE can then transmit a PUCCH format with an improved format. The PUCCH format may include at least one of PUCCH format 1, PUCCH format 3, and PUCCH format 4.

[0050] On the other hand, to further reduce latency, the UE can be configured to support DMRS that overlaps with the N1 UE processing timeline. Typically, PUCCH transmissions may only be scheduled after the end of the N1 UE processing timeline, measured from the last symbol of the PDSCH transmission. However, using the novel format proposed in this invention, when a PUCCH resource is identified, transmission of pre-calculated DMRS symbols (potentially overlapping with the decoding of the PDSCH transmission) can begin. Identifying a PUCCH resource means that the DCI of subsequent scheduled PUCCHs cannot override the current transmission. Therefore, the UE can overlap at least one DMRS symbol (e.g., one or two DMRS symbols) with the N1 UE processing timeline. In other words, the UE can transmit DMRS symbols during the N1 UE processing time to save time. A portion of the N1 UE processing time can be used simultaneously for transmitting DMRS symbols. The UE can begin transmitting HARQ-ACK data immediately after the N1 UE processing time. Therefore, the overall PUCCH transmission latency (e.g., N1 + alignment + PUCCH duration) can be reduced.

[0051] In some implementations, the UE can be configured to support two cyclic delay diversity (CDD) events on two transmit antennas. The UE can transmit the PUCCH format on both transmit antennas via CDD. The cyclic delay amount is predefined or configured, and therefore can be applied in a way that is opaque to network nodes. In another implementation, to support frequency hopping using the aforementioned new PUCCH format, this invention proposes establishing associations between DMRS and UCI symbols transmitted on the same frequency on discontinuous symbols. The UE can be configured to support DMRS and ACK symbols occurring at non-adjacent times on the same frequency hopping. The UE can transmit DMRS symbols and HARQ-ACK information on discontinuous OFDM symbols.

[0052] Exemplary Implementation Figure 5 Block diagram 500 illustrates an exemplary communication device 510 and an exemplary network device 520 according to embodiments of the present invention. The communication device 510 and the network device 520 can perform various functions to implement schemes, techniques, processes, and methods related to dynamic cross-carrier scheduling to improve latency and UCI transmission in wireless communication described in this invention, including the scenarios / schemes described above and the processes 600, 700, and 800 described below.

[0053] Communication device 510 may be part of an electronic device, which may be a UE (User Equipment), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, communication device 510 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device (such as a tablet, laptop, or notebook computer). Communication device 510 may also be part of a machine-type device, which may be an IoT, NB-IoT, or IIoT device, such as a fixed or static device, a home device, a wired communication device, or a computing device. For example, communication device 510 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, communication device 510 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. Communication device 510 may include... Figure 5 At least some of the components shown, such as processor 512. Communication device 510 may also include one or more other components unrelated to the proposed solution (e.g., external power supply, display device, and / or user interface device), therefore, for the sake of brevity, such components of communication device 510 are not... Figure 5 It is shown in the image and will not be described below.

[0054] Network device 520 may be part of an electronic device, which may be a network node such as a base station, small cell, router, or gateway. For example, network device 520 may be implemented in an evolved Node B (eNB) in LTE, LTE-Advanced, or LTE-Enhanced networks, or a next-generation Node B (gNB) in 5G, NR, NR-U, IoT, NB-IoT, or IIoT networks. Alternatively, network device 520 may be implemented as one or more IC chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more RISC processors, or CISC processors. Network device 520 may include... Figure 5 At least some of the components shown, such as processor 522. Network device 520 may also include one or more other components unrelated to the proposed solution (e.g., external power supply, display device, and / or user interface device), therefore, for the sake of brevity, such components of network device 520 are not... Figure 5 It is shown in the image and will not be described below.

[0055] On the one hand, each processor 512 and processor 522 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the present invention may use the singular term "processor" to refer to processor 512 and processor 522, according to the present invention, each processor 512 and processor 522 may include multiple processors in some embodiments and a single processor in other embodiments. On the other hand, each processor 512 and processor 522 may be implemented as hardware (and firmware, optional) with electronic components, wherein the electronic components include, but are not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, which may be configured and arranged to achieve a specific purpose according to the present invention. In other words, in at least some embodiments, each processor 512 and processor 522 may be a dedicated machine specifically designed, arranged, and configured to perform specific tasks (including power reduction) according to various embodiments of the present invention in devices (e.g., represented by communication device 510) and networks (e.g., represented by network device 520).

[0056] In some embodiments, the communication device 510 may also include a transceiver 516, which may be coupled to the processor 512 and is capable of wirelessly transmitting and receiving data. In some embodiments, the communication device 510 may also include a storage medium 514, which may be coupled to the processor 512 and can be accessed by the processor 512 to store data. In some embodiments, the network device 520 may also include a transceiver 526, which may be coupled to the processor 522 and is capable of wirelessly transmitting and receiving data. In some embodiments, the network device 520 may also include a storage medium 524, which may be coupled to the processor 522 and can be accessed by the processor 522 to store data. Accordingly, the communication device 510 and the network device 520 may wirelessly communicate with each other via transceiver 516 and transceiver 526, respectively. To aid in better understanding, the following descriptions of the operation, functions, and capabilities of the communication device 510 and network device 520 are provided in the context of a mobile communication environment, in which the communication device 510 may be implemented in or as a communication device or UE, and the network device 520 may be implemented in or as a network node of a communication network.

[0057] In some implementations, processor 512 can receive PDCCH on a first CC via transceiver 516. PDCCH can schedule PDSCH on the first CC. Processor 512 can receive PDSCH on the first CC scheduled by PDCCH via transceiver 516. Then, processor 512 can transmit HARQ-ACK information corresponding to the PDSCH to the network node. Therefore, PDCCH can also schedule PUCCH for transmitting HARQ-ACK information. To reduce latency, PUCCH can be scheduled on different CCs. For example, the nearest uplink time slot for PUCCH transmission can be allocated on a second CC. Therefore, processor 512 can determine the second CC to transmit PUCCH based on the configuration of dynamic CC switching. Then, processor 512 can transmit the PUCCH corresponding to the PDSCH on the second CC scheduled by PDCCH via transceiver 516.

[0058] In some implementations, processor 512 may receive via transceiver 516 configurations (e.g., RRC configurations) for configuring multiple CCs within a cell group that can be used to transmit PUCCH. Processor 512 may also receive configurations for dynamically switching CCs via PHY layer signaling.

[0059] In some implementations, in an event where the UE is able to support dynamic cross-carrier scheduling of PUCCH, the processor 512 may be configured to report to the network device 520. The processor 512 may report the number or maximum number of groups (e.g., PUCCH groups, cell groups, or newly defined cell groups) in which it is able to support dynamic cross-carrier scheduling of PUCCH. In an event where the UE is able to support dynamic cross-carrier scheduling of PUCCH, the processor 512 may also report its capability for each group (e.g., PUCCH groups, cell groups, or newly defined cell groups).

[0060] In some implementations, processor 512 may report the number of PUCCH groups it can support for dynamic cross-carrier scheduling. In another implementation, processor 512 may report the number of PUCCH groups it can support for semi-static cross-carrier scheduling and / or dynamic cross-carrier scheduling. In yet another implementation, a specific number of CCs may be defined for dynamic cross-carrier scheduling, and processor 512 may report the number it can support.

[0061] In some implementations, processor 512 may report the number N of carriers that it can support dynamic cross-carrier scheduling of PUCCH for each group (such as a PUCCH group, cell group, or a newly defined cell group). If the UE can support dynamic cross-carrier scheduling of PUCCH, processor 512 may report for each carrier. Processor 512 may report the total number or maximum number of carriers that it can support dynamic cross-carrier scheduling of PUCCH.

[0062] In some implementations, processor 512 may receive a first PDCCH for scheduling PDSCH on a first CC via transceiver 516. The first PDCCH can schedule PDSCH on the first CC. Processor 512 may receive the PDSCH on the first CC scheduled by the first PDCCH via transceiver 516. Processor 512 may also receive a second PDCCH for scheduling PUSCH on the first CC via transceiver 516. To reduce latency, PUSCH can be scheduled on a different CC (e.g., a second CC) with the closest uplink time slot. Therefore, processor 512 can determine the second CC to transmit PUSCH based on the configuration of dynamically switching CCs. Then, processor 512 can transmit PUSCH on the second CC scheduled by the second PDCCH via transceiver 516.

[0063] In some implementations, processor 512 may receive a first PDCCH on a second CC via transceiver 516 to schedule PDSCH. The first PDCCH may schedule PDSCH on the second CC. Processor 512 may receive PDSCH on the second CC scheduled by the first PDCCH via transceiver 516. Processor 512 may also receive a second PDCCH on the second CC for scheduling PUSCH via transceiver 516. To reduce latency, PUSCH may be scheduled on different CCs (e.g., the first CC) with the closest uplink time slots. Therefore, processor 512 may determine the first CC to transmit PUSCH based on the configuration of dynamically switching CCs. Then, processor 512 may transmit PUSCH on the first CC scheduled by the second PDCCH via transceiver 516.

[0064] In some implementations, processor 512 may receive a PDCCH for scheduling PDSCH on a first CC via transceiver 516. The first PDCCH may schedule PDSCH on a different CC (e.g., a second CC). Processor 512 may determine on the second CC to receive PDSCH based on the configuration of dynamically switching CCs. Processor 512 may receive PDSCH on the second CC scheduled by the PDCCH via transceiver 516.

[0065] In some implementations, processor 512 may receive configuration via transceiver 516, which may configure multiple SR resources on multiple CCs. When processor 512 attempts to initiate an SR process, it may determine one SR resource from the multiple SR resources on the multiple CCs to transmit the SR. For example, processor 512 may determine the earliest SR resource on the multiple CCs to transmit the SR. Then, processor 512 may transmit the SR on the determined SR resource via transceiver 516.

[0066] In some implementations, processor 512 can be configured to determine the PUCCH format for transmitting HARQ-ACK information. Processor 512 can transmit the PUCCH format using a length of two or three OFDM symbols. Furthermore, processor 512 can shuffle the PUCCH symbols by starting the PUCCH format with at least one (e.g., one or more) DMRS symbols. Processor 512 can arrange the PUCCH format by following at least one HARQ-ACK information symbol after multiple DMRS symbols. Processor 512 can then transmit the PUCCH format with an improved format via transceiver 516. The PUCCH format may include at least one of PUCCH format 1, PUCCH format 3, and PUCCH format 4.

[0067] In some implementations, processor 512 may overlap at least one DMRS symbol (e.g., one or two DMRS symbols) with the N1 processing timeline. Alternatively, processor 512 may transmit DMRS symbols during the N1 processing time to save time. A portion of the N1 processing time may be used simultaneously for transmitting DMRS symbols. Processor 512 may begin transmitting HARQ-ACK data immediately after the N1 processing time via transceiver 516.

[0068] Indicative processing Figure 6 An exemplary process 600 according to an embodiment of the present invention is illustrated. Process 600 may be an exemplary implementation of the above-described scenario / scheme, which is partially or wholly related to dynamic cross-carrier scheduling to improve latency in the present invention. Process 600 may represent one aspect of the features of communication device 510. Process 600 may include one or more operations, actions, or functions illustrated by one or more blocks 610, 620, 630, and 640. Although illustrated as separate blocks, the various blocks of process 600 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 600 may be arranged according to Figure 6The process 600 can be executed in the order shown, or it can be executed in a different order. Process 600 can be implemented by communication device 510, any suitable UE, or machine-type device. Process 600 is described below in the context of communication device 510, but this is merely illustrative and not limiting. Process 600 may begin at block 610.

[0069] At 610, processing 600 may include: the processor 512 of device 510 receiving the PDCCH on the first CC. Processing 600 can proceed from 610 to 620.

[0070] At 620, processing 600 may include: processor 512 receiving PDSCH on the first CC scheduled by PDCCH. Processing 600 can proceed from 620 to 630.

[0071] At 630, processing 600 may include: processor 512 determining a second CC to transmit the PUCCH based on the configuration of dynamically switching CCs. Processing 600 can proceed from 630 to 640.

[0072] At 640, processing 600 may include: processor 512 may transmit the PUCCH corresponding to PDSCH on the second CC scheduled by PDCCH.

[0073] In some implementations, the configuration may include multiple CCs configured to transmit the PUCCH.

[0074] In some implementations, process 600 may include: processor 512 receiving configuration for configuring multiple CCs within a cell group that can be used to transmit PUCCH.

[0075] In some implementations, the content carried by the PUCCH is unrelated to the determined second CC.

[0076] In some implementations, this configuration may include physical layer signaling.

[0077] In some implementations, the configuration may include a data field that can be used to select one CC from a plurality of different CCs to transmit the PUCCH.

[0078] In some implementations, the configuration may include an indication that can be used to indicate the earliest uplink sub-slot on multiple CCs.

[0079] In some implementations, the configuration may include data fields for selecting CC and sub-slots.

[0080] In some implementations, the first CC and the second CC may include different parameter sets or sub-slot partitioning configurations.

[0081] In some implementations, process 600 may include: processor 512 determining a second CC to transmit PUSCH based on the configuration of dynamically switching CCs. Process 600 may also include: processor 512 transmitting PUSCH on the second CC scheduled by the PDCCH.

[0082] In some implementations, process 600 may include: processor 512 receiving a PDCCH on a second CC. Process 600 may also include: processor 512 receiving a PDSCH on the second CC scheduled by the PDCCH. Process 600 may also include: processor 512 determining a first CC to transmit a PUCCH based on the configuration of dynamically switching CCs. Process 600 may also include: processor 512 transmitting a PUCCH corresponding to the PDSCH on the first CC scheduled by the PDCCH.

[0083] In some implementations, process 600 may include: processor 512 determining, based on the configuration of dynamically switching CCs, to receive PDSCH on the second CC. Process 600 may also include: processor 512 receiving PDSCH on the second CC scheduled by the PDCCH.

[0084] Figure 7 An exemplary process 700 according to an embodiment of the present invention is illustrated. Process 700 may be an exemplary implementation of the above-described scenario / solution, which is partially or wholly related to the improvement of UCI transmission in the present invention. Process 700 may represent one aspect of the features of communication device 510. Process 700 may include one or more operations, actions, or functions illustrated by one or more blocks 710, 720, 730, and 740. Although illustrated as separate blocks, the various blocks of process 700 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 700 may be arranged according to Figure 7 The process can be executed in the order shown, or it can be executed in a different order. Process 700 can be implemented by communication device 510, any suitable UE, or machine-type device. Process 700 is described below in the context of communication device 510, but this is merely illustrative and not limiting. Process 700 may begin at block 710.

[0085] At 710, processing 700 may include: processor 512 of device 510 receiving configuration, which can be used to configure multiple SR resources on multiple CCs. Processing 700 can proceed from 710 to 720.

[0086] At 720, process 700 may include: processor 512 initiating the SR process. Process 700 can proceed from 720 to 730.

[0087] At 730, processing 700 may include: processor 512 determining an SR resource from multiple SR resources on multiple CCs to transfer the SR. Processing 700 can proceed from 730 to 740.

[0088] In 740, processing 700 may include: processor 512 transferring SR on the determined SR resource.

[0089] In some implementations, process 700 may include: processor 512 determining the earliest SR resource on a plurality of CCs to transmit the SR.

[0090] In some implementations, the configuration may include at least one SR resource on each CC within a cell group.

[0091] Figure 8 An exemplary process 800 according to an embodiment of the present invention is illustrated. Process 800 may be an exemplary implementation of the above-described scenario / solution, which is partially or wholly related to the improved PUCCH format in the present invention. Process 800 may represent one aspect of the features of communication device 510. Process 800 may include one or more operations, actions, or functions illustrated by one or more blocks 810, 820, 830, and 840. Although illustrated as separate blocks, the various blocks of process 800 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 800 may be arranged according to Figure 8 The process 800 can be executed in the order shown, or it can be executed in a different order. Process 800 can be implemented by communication device 510, any suitable UE, or machine-type device. Process 800 is described below in the context of communication device 510, but this is merely illustrative and not limiting. Process 800 may begin at block 810.

[0092] At 810, processing 800 may include: processor 512 of device 510 determining the PUCCH format to transmit HARQ-ACK information. Processing 800 can proceed from 810 to 820.

[0093] In 820, processing 800 may include: processor 512 transmitting PUCCH format using a length of two or three OFDM symbols. Processing 800 can be extended from 820 to 830.

[0094] In 830, processing 800 may include: processor 512 starting the PUCCH format with at least one DMRS symbol. Processing 800 can proceed from 830 to 840.

[0095] In 840, processing 800 may include: processor 512 transmitting PUCCH format. The PUCCH format may include at least one of PUCCH format 1, PUCCH format 3, and PUCCH format 4.

[0096] In some implementations, processing 800 may include: processor 512 overlapping at least one DMRS symbol with the UE processing timeline.

[0097] In some implementations, the process 800 may include: processor 512 arranging the PUCCH format by following at least one HARQ-ACK message after a plurality of DMRS symbols.

[0098] In some implementations, process 800 may include: processor 512 transmitting DMRS symbols and HARQ-ACK information on non-contiguous OFDM symbols.

[0099] In some implementations, process 800 may include: processor 512 transmitting PUCCH format via CDD on two transmit antennas.

[0100] Additional notes The subject matter described in this invention sometimes illustrates different components contained in or connected to different other components. It should be understood that the architectures described in this way are merely exemplary, and other architectures capable of achieving the same functionality can actually be implemented. Conceptually, the arrangement of any components that achieve the same function is effectively “associated” to achieve the desired function. Therefore, regardless of the architecture or intermediate components, any two components combined herein to achieve a particular function can be considered “associated” with each other to achieve the desired function. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operability and coupling include, but are not limited to, physically matchable and / or physically interactive components and / or wirelessly interactive and / or logically interactive components.

[0101] Furthermore, regarding the use of virtually any plural and / or singular terms in this invention, those skilled in the art can appropriately transform plurals into singulars and / or singulars into plurals depending on the context and / or application. For clarity, various singular / plural substitutions are explicitly described in this invention.

[0102] Furthermore, those skilled in the art should understand that, in general, the terminology used in this invention, especially in the claims (compared to the body of the claims), is typically intended as “open-ended” terms. For example, the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” and the term “including” should be interpreted as “including but not limited to,” etc. Those skilled in the art should also understand that if there is an intent to refer to a specific number of claim statements, that intent will be explicitly stated in the claims, and if such a statement is absent, then such an intent does not exist. For example, to aid understanding, a claim may include the use of the introductory phrases “at least one” and “one or more” to introduce a claim statement. However, the use of such phrases should not be construed as implying that introducing a claim statement with the indefinite article “a” or “an” limits any particular claim containing that introduced claim statement to an embodiment containing only one of those statements, even when the same claim includes the introductory phrases “one or more” or “at least one” and such indefinite articles as “a” or “an” (e.g., “a” and / or “an” should be interpreted as “at least one” or “one or more”); this also applies to the use of definite articles introducing claim statements. Furthermore, even when the specific number of claims to which the claims are introduced is explicitly stated, those skilled in the art should recognize that such statements should be interpreted as indicating at least the number stated (e.g., the statement "two claims" without other modifiers means at least two claims or two or more claims). Additionally, in instances where the customary usage of phrases like "at least one of A, B, and C" is used, such a construction is generally intended to express the meaning of the customary usage as understood by those skilled in the art; for example, "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or systems having A, B, and C, etc. In instances where the customary usage of phrases like "at least one of A, B, or C" is used, such a construction is generally intended to express the meaning of the customary usage as understood by those skilled in the art; for example, "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B, A and C, B and C, and / or systems having A, B, and C, etc. Those skilled in the art will also understand that virtually any transition words and / or phrases presenting two or more options, whether in the specification, claims, or drawings, should be understood to include the possibility of one, either, or both. For example, the term "A or B" should be understood to include the possibility of "A" or "B" or "A and B".

[0103] It should be understood from the foregoing statements that various embodiments of the invention have been described for illustrative purposes, and various modifications may be made without departing from the scope and spirit of the invention. Accordingly, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit of protection are indicated by the claims.

Claims

1. A method for mobile communication, comprising: The device's processor receives the physical downlink control channel on the first component carrier; The processor receives the physical downlink shared channel on the first component carrier scheduled by the physical downlink control channel; The processor determines the second component carrier to transmit the physical uplink control channel based on the configuration of the dynamically switched component carriers. The processor transmits the physical uplink control channel corresponding to the physical downlink shared channel on the second component carrier scheduled by the physical downlink control channel; The processor receives the physical downlink control channel on the second component carrier; as well as The processor receives the physical downlink shared channel on the second component carrier scheduled by the physical downlink control channel.

2. The method for mobile communication as described in claim 1, characterized in that, The configuration includes multiple component carriers configured to transmit the physical uplink control channel.

3. The method for mobile communication as described in claim 1, characterized in that, Also includes: The processor receives a configuration for configuring multiple component carriers within the cell group that can be used to transmit the physical uplink control channel.

4. The method for mobile communication as described in claim 1, characterized in that, The content carried by the physical uplink control channel is unrelated to the determined second component carrier.

5. The method for mobile communication as described in claim 1, characterized in that, The configuration includes physical layer signaling.

6. The method for mobile communication as described in claim 1, characterized in that, The configuration includes a data field used to select one component carrier from a plurality of different component carriers to transmit the physical uplink control channel.

7. The method for mobile communication as described in claim 1, characterized in that, The configuration includes an indication that indicates the earliest uplink sub-slot on multiple component carriers.

8. The method for mobile communication as described in claim 1, characterized in that, The configuration includes data fields used to select component carriers and sub-slots.

9. The method for mobile communication as described in claim 1, characterized in that, The first component carrier and the second component carrier include different parameter sets or sub-slot partitioning configurations.

10. The method for mobile communication as claimed in claim 1, characterized in that, Also includes: The processor determines the second component carrier to transmit the physical uplink shared channel based on the configuration of dynamically switching component carriers; as well as The processor transmits the physical uplink shared channel on the second component carrier scheduled by the physical downlink control channel.

11. The method for mobile communication as claimed in claim 1, characterized in that, Also includes: The processor determines, based on the configuration of dynamically switching component carriers, to receive the physical downlink shared channel on the second component carrier; as well as The processor receives the physical downlink shared channel on the second component carrier scheduled by the physical downlink control channel.

12. An apparatus for mobile communication, comprising: A processor configured to perform the method for mobile communication as described in any one of claims 1-11.

Images