Patent Description:
Existing technologies such as multi-antenna, repetition/slot aggregation, low modulation and coding scheme (MCS), and hybrid automatic repeat request (HARQ) procedures have been considered as possible ways to enhance reliability or diversity. However, these approaches are conventionally performed within a single carrier. Drawbacks of single carrier implementations include:.

Carrier domain can be exploited for flexible and efficient resource sharing for data duplication. This can be performed across frequency division duplex (FDD) carriers, time division duplex (TDD) carriers, unlicensed carriers, high frequency/low frequency carriers. Two existing frameworks for carrier domain resource sharing, where multiple carriers are used for communication between the network and a UE, include dual-connectivity and carrier aggregation.

In the dual-connectivity framework, there is a different media access control (MAC) entity for each carrier group. Transport block (TB) scheduling for a UE is performed independently on the each carrier group. The carrier aggregation framework has one MAC entity for all carriers, but TBs are still scheduled separately/independently on the multiple carriers. The carrier aggregation framework may be used to enhance data rate. With the carrier aggregation framework, the MAC entity schedules independent HARQ processes on each carrier.

Data duplication at the packet data convergence protocol (PDCP) layer can be performed to produce multiple TBs from one TB for transmission on separate carriers, but the multiple TBs then pass through the separate MAC entities (for dual-connectivity) or a single MAC entity (carrier aggregation) and are scheduled independently in both cases. The UE treats the received TBs independently. TB retransmissions are scheduled on the same carrier as original data TB transmissions.

The protocol stack for legacy carrier aggregation is depicted in <FIG>, and is based on single MAC with separate HARQ entities per component carrier. A HARQ entity is the combination of the HARQ transmit/receive buffers of the associated HARQ processes handled by the HARQ entity, and their corresponding HARQ state machines.

If the same TB (more generally the same TB or different redundancy versions of the same TB) is repeated in another component carrier, the UE needs to identify that to be the case. The protocol stack in <FIG> includes a radio link control (RLC) layer <NUM>, MAC layer <NUM>, and physical (PHY) layer <NUM>. The RLC layer <NUM> includes multiple RLC entities <NUM>,<NUM>,<NUM> that receive TBs from the PDCP layer (not shown). In the MAC layer <NUM>, multiplexing <NUM> takes place, and then separate HARQ entities <NUM>,<NUM> generate TBs for each of two component carriers CC1, CC2 in the PHY layer <NUM>.

In some systems, transmissions are performed on component carriers in unlicensed spectrum, e.g., in New Radio (NR)-Unlicensed (NR-U) using CA,DC, or stand-alone (SA) modes). In such systems, the gnodeB (gNB)/UE may not be able to gain medium access on the original band to perform the HARQ retransmission for several slots or subframes due to the failure of the regulatory-required listen-before-talk (LBT) procedure. Furthermore, wide-band transmissions, e.g., carrier-wide transmissions, are desired in NR-U to shorten the channel occupancy time and to decrease the power spectral density, whereas LBT failure can be caused by a full or partial occupancy of the LBT bandwidth by the coexisting nodes/systems. In a meeting paper, <NPL>, a method of UL transmission without grant is disclosed wherein repetitions for a transport block are transmitted using resources and wherein the transport block is mapped to a time/frequency domain resource and wherein a used HARQ process ID is associated with the configured time/frequency/code resource. In a meeting paper, <NPL>, a method of repetitions of UL transmission without grant is disclosed. In a meeting paper, <NPL>, multiple grant free resource configurations for grant free transmission are disclosed.

With asynchronous HARQ, a retransmission might not occur for several slots or subframes due to a blocked or lost acknowledgement (ACK)/negative acknowledgement (NACK) feedback transmission as a result of LBT failure or persistent collisions with the transmissions of hidden nodes on that unlicensed component carrier.

Moreover, the receiving end RLC layer will not request a retransmission of the associated SDU from the sending end RLC layer unless a subsequent SDU has been received and a reordering timer has been started and elapsed. The sending end RLC then triggers the retransmission of the SDU and new associated TBs are created and scheduled at the MAC entity, possibly on a different component carrier.

Significant delays and throughput reduction can be incurred with such a design in unlicensed spectrum. There is a need for efficient LBT-resilient mechanisms for performing the HARQ retransmissions and transmission of the associated ACK/NACK feedback on a PUCCH in unlicensed spectrum.

Example embodiments provide systems and methods for reliable transmission over a network resource. The word "invention" as used in the present description refers to the inventive concept as understood by the applicant at the time of filing the patent application. The scope of protection is defined in the appended claims. All following occurrences of the word "embodiment(s)", if referring to feature combinations different from those defined by the independent claims, refer to examples which were originally disclosed but which do not represent embodiments of the presently claimed invention; these examples are still shown for illustrative purposes only.

The making and using of the disclosed embodiments are discussed in detail below. It should be appreciated, however, that the present disclosure provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the embodiments, and do not limit the scope of the disclosure.

This application describes solutions where UE receives an assignment comprising an indication when same transport block is duplicated or transmitted in more than one carrier. The UE can be semi-statically configured for data duplication mode. The assignment can be semi-statically provided to the UE such as configured ID of shared HARQ process across a carrier group or a subset of carrier group. Alternatively, the assignment can be provided to the UE as a combination of semi-static and dynamic signaling. In particular, indication can be provided in one or more of the scheduling downlink control information (DCIs) that schedule same transport block in different carriers. When provided in scheduling DCI, the indication may comprise one or more fields such as a flag for differentiation between duplication or independent scheduling, HARQ process ID of the other carrier(s) where data is duplicated, carrier index of the carrier(s) where data is duplicated. The indication may be provided in one or both of the scheduling DCIs in primary and secondary component carriers. Semi-static signaling may notify the UE which set of carriers can be used for data duplication or which set of HARQ process IDs can be used for duplication or what is the mapping between a HARQ process ID in one carrier to another HARQ process ID in a different carrier if data duplication is indicated. In another example, prior semi-static configuration may not be necessary, and duplication is indicated by dynamic signaling only, i.e., in the form of explicit and/or implicit indication in a DCI. Furthermore, a common HARQ feedback can be generated by the UE, if the UE is able to combine the packets and if the UE is configured for this process. The common HARQ feedback can be transmitted in the primary component carrier (PCC) and/or a secondary component carrier (SCC) uplink configured/indicated resource. Common HARQ feedback generation may require soft buffer data/log-likelihood ratio (LLR) sharing at the receiver.

Although the discussion focuses on carriers and carrier groups, a carrier is an example of a network resource and a carrier group is an example of a group of network resources. In general, a network resource is a resource of the network that is usable in the transmission of information. A network resource may be characterized as being a member one or more domains, where the domains include the time domain, the frequency domain, the code domain, a spatial domain, and so forth. Examples of network resources include time resources, frequency resources, code resources, spatial resources, time-frequency resources, carriers, component carriers, bandwidth parts, and so on.

As used herein, repetition of a transport block implies subsequent transmission of a transport block after initial transmission but before HARQ feedback, if any. Retransmission implies a subsequent transmission of a transport block after initial transmission is not correctly received. Below, data duplication is used in the context when the same transport block, or different redundancy versions of the same transport block, is transmitted over multiple carriers. Duplication may happen at the same or different time, in the form of a repetition or retransmission. The UE may or may not be able to do HARQ combining of the copies of a transport block transmitted over different carriers, depending on the hardware capability of the UE and/or timing of the transmissions in different carriers and/or indicated HARQ feedback timing.

In a first set of methods, HARQ process are shared across two or more carriers in a carrier group, and these shared HARQ process are pre-configured, for example, semi-statically using radio resource control (RRC) signaling on a per UE basis. Once the configuration is performed/notified to the UE, additional signalling (such as dynamic signalling in a DCI), on a per transmission basis, is not required to inform a UE of which HARQ Processes are shared and/or which component carriers are sharing on or more HARQ Process IDs.

This method depends on configuring/associating a pool of HARQ process across carriers. Rather than having independent HARQ Process per carrier, a pool of K HARQ process are common across all carriers or across all carriers in a carrier group. With this approach, multiple HARQ entities share a pool of HARQ process. The pool of HARQ process may include all HARQ process, or a subset of all the HARQ processes.

A UE receiving indication of a given HARQ process ID from more than one carrier in the pool concludes that a same transmission or transport block is scheduled across the carriers for which indication is received. In some embodiments, indication of assignment of a HARQ process ID to a transmission or transport block may be provided in a scheduling DCI or physical downlink control channel (PDCCH). When PDCCH scheduling over different carriers in a group indicates a common HARQ process ID in the same slot/symbol(s)/interval or within a pre-configured/pre-defined period/duration of slots/symbols/intervals, the configured UE concludes that transmission of same packet is scheduled across the carriers.

A UE can be RRC configured with the association of a pool of HARQ process IDs and corresponding CC indices of component carriers that are to use the common pool of HARQ processes.

This approach is suitable for a UE that does not require a large number of HARQ processes supported across component carriers. The number of available HARQ processes does not scale with the number of component carriers, in the sense that adding a component carrier that uses a common set of HARQ processes with another component carrier or carriers does not increase the number of available HARQ processes.

An example protocol stack is shown in <FIG>, which differs from <FIG> in that the MAC layer includes HARQ entities <NUM>,<NUM> for component carriers CC1,CC2 respectively that are part of a group of HARQ entities <NUM> that shares HARQ processes across component carriers. Note that HARQ entities that share HARQ processes may share soft buffer information.

<FIG> shows a specific example of shared HARQ process, in which there are <NUM> HARQ process with HARQ ID <NUM>,. , HARQ ID <NUM>, that are shared between four component carriers CC1,. ,CC4 configured for a UE.

A first example of TB transmission is indicated at <NUM>, in which four TBs with different HARQ Process IDs are transmitted on the four carriers. These are independent TB transmissions.

A second example of TB transmission is indicated at <NUM>, in which two TBs with the same HARQ ID <NUM> are transmitted on two carriers CC1,CC2. These are the same TB or redundancy versions of the same TB. An independent TB is transmitted on CC3.

A third example of TB transmission is indicated at <NUM>, in which three TBs with the same HARQ ID <NUM> are transmitted on three carriers CC1,CC2,CC3. These are the same TB or redundancy versions of the same TB.

In a variant of method 1A, some HARQ process are shared across a set of component carriers, and other process are independently used in each component carrier.

An example protocol stack is shown in <FIG>, which differs from <FIG> in that the MAC layer includes a separate HARQ entity <NUM>,<NUM> for each component carrier, but there is cooperation between the two HARQ entities <NUM>,<NUM> as indicated at <NUM>, across component carriers.

In mathematical terms, where the maximum number of HARQ process per component carrier is K >= <NUM>, P HARQ processes are shared across the component carriers, where P < K. Duplication across component carriers uses the pool of P HARQ processes only. Which HARQ process are shared can be RRC configured for a UE.

An example is shown in <FIG> which shows <NUM> HARQ processes per cell. Of these, HARQ process with HARQ ID <NUM>,. , HARQ ID <NUM> are independent for each of four component carriers CC1,. , CC4, and HARQ ID <NUM>,. , HARQ ID <NUM> are shared across the four component carriers.

A first example of TB transmission is indicated at <NUM>, in which four TBs with different HARQ Process IDs belonging to the set of independent HARQ Process are transmitted on the four carriers. These are independent TB transmissions.

A second example of TB transmission is indicated at <NUM>, in which two TBs with the same HARQ ID <NUM> are transmitted on two carriers CC1,CC2. Because HARQ ID <NUM> is a shared process, these TBs are are duplicates in that one TB is a duplicate (i.e. repetition or retransmission, same or different redundancy version) of the other TB. An independent TB is transmitted on CC3.

In a variant of the above-described embodiments, HARQ process are shared across a subset of the component carriers in a carrier group. All of the HARQ process may be shared across the subset of component carriers (as per the example of <FIG>) or a subset of the HARQ Process may be shared across the subset of component carriers (as per the example of <FIG>).

Mathematically, this can be expressed as follows:.

A specific example is shown in <FIG> where there are K = <NUM> HARQ process, P = <NUM> shared HARQ Process, N = <NUM> component carriers, and M = <NUM> component carriers that use the shared HARQ Process IDs.

A first example of TB transmission is indicated at <NUM>, in which two TBs with the same HARQ ID <NUM> are transmitted on two carriers CC1,CC2. Because HARQ ID <NUM> correspond to a shared process between CC1 and CC2, these transmissions are the same TB or different redundancy versions of the same TB. An independent TB is transmitted on CC3 using HARQ ID <NUM>, and another independent TB is transmitted on CC4 also using HARQ ID <NUM>.

A second example of TB transmission is indicated at <NUM>, in which three TBs with the same HARQ ID <NUM> are transmitted on three carriers CC1,CC2,CC3. Because HARQ ID <NUM> correspond to a shared process between CC1 and CC2, the two transmissions on those carriers are the same TB or redundancy versions of the same TB. An independent TB is transmitted on CC3 using the same HARQ ID <NUM>.

For the embodiments of <FIG>,<FIG>,<FIG>, configuration may be performed semi-statically, for example using radio resource control (RRC) signaling. This can involve signaling one or more of the following:.

Once the configuration is performed, additional signalling, on a per transmission basis, is not required to inform a UE of which HARQ Process are shared and/or which component carriers are sharing one or more HARQ Process. In some embodiments, a dynamic indication (for example in a DCI) is used to indicate which CCs of the pre-configured sharing carrier group are currently carrying duplications of the same TB.

In a second set of methods, HARQ process IDs are mapped, on a per transmission basis, across two or more carriers in a carrier group, and this is indicated to a UE in downlink control information (DCI) transmissions that schedule the TB transmissions using the shared HARQ Process. In some embodiments, as detailed below, DCI signaling indicates when the same or different HARQ process ID across different carriers are used for transmission of the same transport block or packet. In other words, HARQ process IDs in different carriers do not have to be the same for the same packet transmission/duplication/repetition/retransmission in the case of DCI based signaling. For the examples described below, DCI signaling can be conveyed in a scheduling DCI, for example PDCCH carrying a grant.

In some embodiments, the DCI-based approach is a unified DCI solution which can support both data duplication and legacy TB scheduling in a carrier aggregation framework. These embodiments will be described in the context of two component carriers referred to herein as a PCC and a SCC but the approach can be generalized to any two or more component carriers generally on a single cell or multiple cells.

In this embodiment, separate HARQ processes are implemented for the two carriers. Consistent with a legacy carrier aggregation, in some embodiments, a default configuration is used, in which there is no shared HARQ processing. In other words, two TBs transmitted on the two carriers are independent, irrespective of the HARQ process IDs used on the two carriers which may be the same or different.

<FIG> shows an example of scheduling for two component carriers: DCI <NUM><NUM> indicates transmission scheduling for the PCC <NUM>, and DCI <NUM><NUM> indicates transmission scheduling for the SCC <NUM>. HARQ Process IDs in DCI <NUM> and DCI <NUM> are independently mapped or correlated, with a relationship between the two DCIs indicated using a flag in a new field, as detailed below. The HARQ IDs for duplicate TB transmissions may be the same or different, and the same HARQ ID used on two CCs may relate to duplicate or independent TBs.

To achieve independent scheduling, DCI <NUM> and DCI <NUM> schedule independent TBs on the two carriers. To achieve data duplication, DCI <NUM> and DCI <NUM> schedule the same TB on the two carriers. One or more fields in one or both DCI <NUM> and DCI <NUM> are used to indicate whether data duplication is used or not. Various examples are described below.

Note that DCI <NUM> can be received in the primary component carrier or a secondary component carrier. If DCI <NUM> is received in PCC and its scheduled PDSCH and PUCCH is in SCC as shown in <FIG>, DCI <NUM> would then be called a cross-carrier scheduling DCI. If DCI <NUM> is received in SCC and its scheduled PDSCH and PUCCH is in SCC, then it would be called a self-scheduling DCI.

To configure data duplication across carriers, a UE needs to identify when a TB is duplicated across carriers. One or more of the two DCIs, i.e., self-scheduling DCI of PC, i.e., DCI <NUM>, and self/cross-scheduling DCI of SC (e.g., DCI <NUM> is a cross-scheduling DCI), include an indication that informs the UE of whether data duplication is taking place or not. The indication may comprise one or more fields in one or both of the DCIs. Indication notifies whether signaled HARQ processes carry same or different data in the carriers for which scheduling DCIs are received.

In a specific example, DCI <NUM> includes a flag (or other indication) that indicates whether data duplication is taking place or not. With this approach, the same DCI format can be used for both independent scheduling or data duplication. For example:.

In some embodiments, a single-bit flag can indicate the data duplication between the two DCIs (transmitted simultaneously or with a time gap) only in the absence of any other concurrent DCIs for the same RNTI/UE as depicted in <FIG> and <FIG>, described below. In the more general case, a single-bit flag might not be sufficient. Example methods of addressing this are provided below.

<FIG> shows an example set of DCI fields for DCI <NUM> indicated at <NUM>. The fields include a carrier indicator, HARQ Process ID, and the above-discussed flag. More generally, the DCI may include different and/or additional fields (usually including scheduling information such as resource allocation), and the indicator field may be a flag or a field having a different structure.

With this embodiment, the UE may follow HARQ timing indicated in DCI <NUM> or DCI <NUM>. Independent or same bundling or repetition numbers can be configured/indicated for the TB transmissions in different carriers.

Some prior association may or may not be configured in advance, or semi-statically. A specific relationship between HARQ Process IDs for the two carriers for data duplication purposes may be configured. For example, there may be a configuration that maps HARQ Process ID in DCI <NUM> to HARQ Process ID in DCI <NUM> or vice versa for data duplication purposes when the flag = <NUM> (or more generally, when data duplication is indicated).

In some embodiments, specific UEs can be configured by RRC signaling to support the feature.

In a specific example, if HARQ ID i and HARD ID j are received on separate component carriers with the flag set to duplication mode, {i, j} € {<NUM>,.

In some embodiments, DCI <NUM> and DCI <NUM> can be received in the same scheduling period, for example the same transmit time interval (TTI). In another embodiment, DCI <NUM> may precede DCI <NUM> by n time units, where n may be a configurable value that can be set, for example by an RRC or DCI or MAC control element (CE). The time units can be symbols or slots.

DCI <NUM> and DCI <NUM> can be of the same or different size.

In some embodiments, DCI <NUM> is a compact DCI that contains at least one of a field indicating a component carrier, HARQ process ID and a field indicating data duplication. In this case, the rest of the fields, such as resource allocation, are either pre-configured or the same as/inherited from DCI <NUM>.

In some embodiments, DCI <NUM> includes a bandwidth part (BWP) index. A BWP may or may not be indicated in DCI <NUM>.

If a UE is configured for data duplication over a carrier group, the UE can monitor for a subsequent DCI scheduling the same TB within the activity period (n time units referred to above).

<FIG> shows an example of DCI-based cross-carrier scheduling. DCI <NUM> is transmitted to schedule on the PC. DCI <NUM> is transmitted to schedule a duplicate transmission on the SC. DCI <NUM> can be transmitted, and received, simultaneously with DCI <NUM>, or later.

Three examples are shown in <FIG>. In the first example <NUM>, a DCI is transmitted on the PCC with HARQ ID <NUM>, and a DCI is transmitted on the SCC with HARQ ID <NUM>, and flag = <NUM>, meaning no duplication. The scheduled TBs are treated as two different TBs, consistent with legacy transmission.

In the second example <NUM>, a DCI is transmitted on the PCC with HARQ ID <NUM>, and a DCI is transmitted on the SCC with HARQ ID <NUM>, and flag = <NUM>, meaning duplication. These scheduled TBs are treated as two copies (or redundancy versions) of the same TB.

In the third example <NUM>, a DCI is transmitted on the PCC with HARQ ID <NUM>, and a DCI is transmitted on the SCC with HARQ ID <NUM> within n time units of the DCI on the PC, and flag = <NUM>, meaning duplication. The scheduled TBs are treated as two copies (or redundancy versions) of the same TB.

There can be an ambiguity as to which TB is being duplicated if multiple TBs are scheduled within the window when the indicator is set to indicate duplication. An example is shown in <FIG>. In this example, initial transmissions on PCC are made with HARQ IDs <NUM> and <NUM>. Within the activity period, transmissions on the SCC with HARQ IDs <NUM> and <NUM>, flag =<NUM>, are repetitions in respect of the initial transmissions. It is not clear which repetition corresponds to which initial transmission.

In some embodiments, to address the possible ambiguity, the PCC DCI also includes an indicator such as a flag that indicates duplication. Then, two DCIs indicating duplication indicate they are scheduling the same TB if they are transmitted within the activity period. If more than one TB needs data duplication within an activity period, a single bit flag may not be sufficient to avoid ambiguity. In some embodiments, additional bits in the indicator can be used to convey which packets are duplications of which packets.

In some embodiments, a predetermined mapping is used. For example, Odd ID in SCC DCI can be configured to be mapped to Odd ID in PCC DCI, or vice versa. For example:.

In some embodiments, a mapping rule can be established as:
<NUM> - <NUM> → 2n - <NUM>, <NUM> + <NUM> → 2n+<NUM>, <NUM> + <NUM> → 2n.

In the example above, <NUM>+<NUM> maps to 2n because <NUM> was skipped and not used for duplication. Hence, the UE may assume active odd processes with flag <NUM> in SCC map to the active odd processes in order in the PCC.

In some embodiments, a fallback behavior is configured whereby if a UE misses one DCI (e.g., PCC DCI), the UE will send ACK/NACK independently for the SCC transmission. Combination of the multiple transmissions by the UE is not possible in this case.

Alternatively, there can be a pre-configured association between HARQ processes of the HARQ entities of the PCC and SCC. For example:.

If process j<NUM> is scheduled in SCC with flag= <NUM>, the UE knows that process j<NUM> corresponds to one of processes {i<NUM>, i<NUM>,. , iKm} which is scheduled in PCC when or before the DCI for j<NUM> is received. The mapping procedure can be semi-statically indicated to the UE or obtained by the UE from a configured look-up table.

Mapping might not be unique for HARQ processes, for efficiency. In this case it is up to the network implementation to make sure scheduled HARQ processes do not conflict when data duplication is indicated.

In this example, a flag or other indication in one or more of the scheduling DCIs is included. A DCI format can be used for this purpose. HARQ process mapping configuration across carriers and/or which carriers are used for duplication can be semi-statically indicated to the UE.

In another example, there may not be any prior association or mapping configuration of HARQ process and/or carrier group. One or more of scheduling DCIs in PCC and SCC(s) may include one or more of: carrier indices of the other carrier(s) where DCI for duplication or same packet transmission is received, HARQ indices which are used in the DCIs sent over other carriers participating in duplication. This indication may be in addition to the carrier index and HARQ process ID indication in the DCI for a given carrier.

In these embodiments, one DCI received in a component carrier schedules duplicate TBs over multiple carriers. In one example, one HARQ Process ID and one HARQ timing is indicated. Alternatively, separate HARQ Process ID and same or different HARQ timing is indicated for indicated carriers. This DCI format can be received in the PC. The BWP in the SCC may be associated with for the PCC. In this case, the UE gets duplicate versions of a TB over multiple carriers. Optionally, a Carrier Indicator for SCC can be included in the DCI. Optionally, a BWP indicator for SCC or PCC or both is included in the DCI. Other regular fields can be included as usual, including fields such as MCS, Resource allocation, multi-antenna indication. Those regular fields can be common for transmission over multiple carriers, or can be different and explicitly indicated for different carriers. There can be one set of parameters for both BWPs or separate sets of parameters for each BWP. The same or different numerologies can be employed for the two transmissions.

For example, in some embodiments, separate resource allocation fields are included for the two component carriers. Resource allocation could be different for the two component carriers depending on the available RB indices per carrier. Also, in some embodiments, separate MCS fields are included for the two component carriers. The MCS may differ for the two component carriers due to the different channel quality across the carriers.

An example is shown in <FIG> which shows a single DCI <NUM> that schedules duplicate TBs over a PCC <NUM> and an SCC <NUM>. <FIG> shows an example where there are associated BWPs in the SCC and the PC.

The DCI format examples discussed above can be received in UE specific search space or common search space.

For any of the embodiments described herein, a UE may combine duplications of a TB received over different carriers. For repetition, log likelihood ratios (LLRs) of transmissions received over different carriers can be added before feeding to the decoder. In this case, HARQ feedback may be generated once. Combining duplications may involve the HARQ entities of the group of carriers sharing soft buffers of the HARQ entities. In another embodiment, selection combining is performed. Alternatively, the UE does not combine duplications of a TB received over different carriers, and sends ACK/NACK for each transmission.

An example UE side implementation is depicted in <FIG>. Shown are two LLRs produced for TBs received on the SCC <NUM> and PCC <NUM> respectively. These can be combined at <NUM> before being passed to the decoder <NUM>. Alternatively, the LLRs are passed separately to the decoder <NUM> where they are decoded separately.

HARQ feedback generated for carrier aggregation with the same HARQ process shared across multiple carriers may require a modified HARQ codebook generation. A UE may generate a common HARQ feedback after combining the duplications across the carriers. In some embodiments, a HARQ codebook is defined which specifies HARQ feedback for one or more of the embodiments described herein. The size of HARQ codebook can be decided by:.

<FIG> shows an example, where a UE may have different types of traffic transmission ongoing, such as enhanced mobile broadband (eMBB) and ultra reliable low latency communications (URLLC). eMBB transmission can be code block group (CBG)-based and URLLC transmission can be TB-based. In this example, each eMBB transmission is configured with up to two CBGs for feedback. DAI (N, i) indicates ith feedback in the codebook where there are N total feedbacks combined in the message. For example, DAI (<NUM>,<NUM>) and DAI (<NUM>,<NUM>), each have two sub-fields within the ACK/NACK message for corresponding downlink transmission, each sub-field accounting for a CBG. DAI (<NUM>,<NUM>) is common for CC3 and CC4 because the UE is configured to have a common HARQ feedback for the same TB transmission over CC3 and CC4. Mapping of the DAIs to the fields may be arranged in the order of the CC index.

Referring now to <FIG>, shown is a block diagram of a system for transmission over unlicensed spectrum, using auxiliary HARQ Processes for multi-carrier operations, in accordance with an embodiment of the invention. Auxiliary HARQ processes may also be referred to as switched HARQ processes. Auxiliary and switched HARQ processes may be used interchangeably.

On the transmit side, there is a transmit RLC <NUM>, transmit MAC <NUM> (including MAC scheduler) that implements a respective HARQ entity <NUM>,<NUM>,<NUM> for each of three component carriers <NUM>,<NUM>,<NUM>. At the receiver side, there is a receive MAC <NUM> that implements a respective HARQ entity <NUM>,<NUM>,<NUM> for each of the three component carriers <NUM>,<NUM>,<NUM>, and a receive RLC <NUM>.

In operation, initial transmissions are made using one component carriers, and using the associated HARQ entity, with a HARQ process ID. If no positive acknowledgement (ACK) has been received from the receiver within an expected window of time after the transmission, a retransmission is initiated using the same component carrier and HARQ process ID.

Because LBT is used before transmissions, a retransmission may or may not be transmitted depending on the availability of the channel. A transmission that is not transmitted is said to be blocked. The transmitter MAC <NUM> monitors (for example using a timer) the blocking time during which a retransmission of a HARQ process (HARQ ID i) that was initiated on a component carrier (CCx) is being blocked. As an alternative to using a timer, a count of the number of retransmission attempts can be made, with a certain number of retransmission attempts functioning as a trigger for activating an auxiliary HARQ process, as detailed below.

In a specific example, a timer at the transmitter MAC <NUM> is started at the instant at which the HARQ feedback of process i is due on CCx. In this case, the timer also accounts for the pre-defined window of time within which the HARQ feedback is expected. In another embodiment, the timer can be started once the corresponding negative acknowledgement (NACK) has been received or the corresponding HARQ feedback is overdue. In the case of the HARQ feedback being overdue, the timer accounts as well for the blocking delay of the feedback at the receiving end.

The timer at the transmitter MAC <NUM> is specific to the UE's HARQ process i on CCx if the transmitter resets once the retransmission attempt is successful or after the timer expires (or reaches a higher-layer configured maximum). Alternatively, the timer can be specific to the HARQ entity such that the timer's value can be accumulated from the associated set of HARQ processes until the timer expires (or reaches a greater higher-layer configured maximum), and then a set of auxiliary HARQ processes are activated concurrently as a group event.

Upon expiry of the timer, the transmitter MAC activates an auxiliary HARQ process on a different component carrier CCy and schedules and then transmits a retransmission using the auxiliary HARQ process. In some embodiments, for a given CCx, another component carrier CCy for auxiliary retransmission is chosen in advance. In other embodiments, CCy is dynamically selected from a carrier or cell group that the receiver has been configured to use.

The receiver MAC <NUM> can also monitor the excess retransmission delay time beyond a HARQ round trip time (RTT) timer value that has been pre-configured through higher-layer signaling such as RRC.

The RTT timer at the receiver MAC <NUM> can be initialized at the instant at which the HARQ RTT timer elapses from the last (re)transmission of HARQ process i on CCx. The timer can be reset upon receiving the retransmission of HARQ process i.

Similar to the transmitter side timer, the timer at the receiver MAC is either specific to the UE's HARQ process i on CCx or the HARQ entity on CCx.

Once the timer value in the receiver exceeds a pre-configured parameter (e.g. HARQReTxMaxDelay), the receiver MAC <NUM> can trigger the receive HARQ to change to the auxiliary HARQ process and indicate the change to the transmitter, for example through control signaling over a more reliable (e.g., licensed) CC.

Referring again to <FIG>, in a specific example, a TB transmission is taking place using HARQ ID <NUM> on CC1 <NUM>. A retransmission is attempted, using the same HARQ ID and component carrier. After the retransmission is blocked for the duration of a timer (Dmax), the Transmit MAC <NUM> activates a transmit auxiliary HARQ process on a different component carrier. In the example illustrated, the auxiliary HARQ process is initiated with HARQ ID <NUM> on CC2 <NUM>. The auxiliary HARQ process is scheduled and activated on CC2. Correspondingly, in the receiver activates a receive auxiliary HARQ process to receive the retransmission on CC2.

In a specific example, retransmissions of the TB associated with the active HARQ process (HARQ ID i) on CCx can be changed by the transmitter to the first idle HARQ process j on a component carrier. Note that different component carriers may be associated with the same or different cells/transmission/receiving point (TRP).

In some embodiments, to reduce the overhead associated with indicating the HARQ process ID to be activated on CCy, a subset of such 'auxiliary' HARQ process IDs can be defined using a semi-statically configured mapping table or rule. If the first auxiliary HARQ process ID in the subset is busy, then the second auxiliary HARQ process ID in the subset is selected, and can be indicated to the receiver using fewer bits than would be required to select from an entire set of HARQ process IDs. Alternatively, the auxiliary HARQ process ID is pre-configured for a given HARQ process on CCx. For grant-free transmissions, such as grant-free uplink transmissions, this can be a one-to-many mapping, with the transmitter responsible for selecting an available one of the mapped HARQ processes. For scheduled uplink and downlink transmissions, this can be a one-to-many mapping, with the scheduler responsible for selecting an available one of the mapped HARQ processes. Alternatively, the auxiliary HARQ process ID (optionally along with the carrier index of CCy) may be signaled in a DCI.

In some embodiments, there is a default mode of operation that is used if no auxiliary HARQ process is available, in which retransmissions/repetitions are performed using the same component carrier as an original transmission.

Once the receiver detects the change in the component carrier used for retransmissions, the corresponding idle auxiliary HARQ process is activated on CCy along with its receive FEC buffer.

Referring to <FIG>, shown is another view of the system of <FIG>, showing additional steps that may be implemented following successful TB decoding in the receiver. The receive side RLC <NUM> collects a successfully decoded TB at <NUM> (from either process i or its activated auxiliary process(es)) and updates its receive window.

An indication <NUM> to free up the main and associated auxiliary process(es) and clear their FEC buffers is provided to respective HARQ entities directly or through the MAC or through the receiver RLC sub-layer. A decode success indication (e.g. ACK) <NUM> is transmitted back to the receiver. In some embodiments this can be sent on any of the component carriers involved.

Upon receiving a decode success indication, the transmit side RLC <NUM> updates its PDU transmit window, and generates an indication <NUM> to free up all associated processes and clear their circular transmit buffers, which is provided to respective HARQ entities. Alternatively, the HARQ entity for which a success indication has been received can signal the remaining HARQ entities through the transmit MAC to clear their respective transmit buffers.

In some embodiments, one or more of the methods described herein applied to New Radio - unlicensed (NR-U) uplink grant based retransmissions in respect of initial uplink grant based transmissions, where the uplink grant of retransmission and granted uplink resource can be in different component carrier from the initial transmission.

In some embodiments, the UE is configured to inform the network (for example by informing a gNB) of its capability to soft-combine TBs received across multiple CCs. Based on this information, the network can then decide on the redundancy version to use with auxiliary HARQ retransmission. For example, for transmission to a UE that is not capable of such soft-combining, the retransmission can be a complete retransmission of the original TB. For example, for transmission to a UE that is not capable of such soft-combining, the retransmission can be a complete independent retransmission of the original TB.

In some embodiments, the network transmits a configuration of auxiliary HARQ Processes/Mapping Rule. For example, a gNB may semi-statically configure the UEs with the auxiliary HARQ processes through higher layer signaling, e.g., RRC. The mapping rule can be signaled as a lookup table or parameters of a pre-determined formulae/arithmetic procedure.

In some embodiments, the mapping rule is a lookup table. An example is shown in <FIG> which maps a main HARQ ID i to the pre-configured auxiliary HARQ Process IDs j. The example shown in <FIG> also shows the mapping of main HARQ ID i to the pre-configured auxiliary HARQ Process IDs k and l. As used herein, a main HARQ ID and an original HARQ ID are interchangeable.

In some embodiments, wherein a pre-determined formula/arithmetic procedure is employed, an index offset and/or a cyclic shift is used to calculate the auxiliary HARQ Process ID. The cyclic shift register can hold the HARQ ID i in n binary bits concatenated with a predefined number of bits that are started with zeros or the carrier indication field (CIF) bits of CCx. The index offset is applied to the cyclic shift register to avoid corner cases such as all zeros or all ones HARQ ID i. An all zeros or all ones HARQ ID i is a situation where a value representing HARD ID i is represented in the shift register as all binary zeros or all binary ones. An example is shown in <FIG>. In some embodiments, a one-to-many mapping rule involves applying a number of binary ID shifts, each binary ID shift having an associated index that can be used to communicate a specific binary ID shift in dynamic signalling. In some embodiments, both the index offset, and the number of binary ID shifts are used in combination.

In some embodiments one or more parameters are signaled, which are applied to a formula. An example is shown in <FIG>. In <FIG>, the resource identifier CIF of CCx is used in concatenation with the n bits of the HARQ ID of the HARQ Process i. Other techniques may be used to combine the resource identifier CIF and the HARQ ID, such as addition, subtraction, multiplication, and so on.

If the network needs to retransmit HARQ process i on CCx but its LBT before the retransmission fails on CCx or a BWP thereof, after receiving a NACK or not receiving any feedback for a preset duration, a DCI for the retransmission takes place on CCy or a BWP thereof instead of CCx using one of the following methods depending on whether a mapping rule or formula is pre-configured and whether the DCI is cross-carrier scheduling or self-scheduling.

The DCI comprises indications of one or more of:.

Same new data indicator (NDI) as original (non-toggled).

Format A1: The DCI comprises indications of one or more of:.

Using the indicated CCy and switched HARQ ID i, the UE can to obtain the pair (CCx, Aux-HARQ ID j). As a validation of the received DCI, UE can check if obtained CCx had the HARQ ID i among its associated processes. This is in addition to the same TB size as original and the non-toggled NDI field w. t that of the original DCI scheduled process i.

Format A2: The DCI comprises indications of one or more of:.

Using the indicated CCx, which is not the CC ID being scheduled unlike legacy cross-carrier scheduling DCI formats, and the auxiliary HARQ ID j, the UE can to obtain the pair (CCy, HARQ ID i). As a validation of the received DCI, UE can check if obtained HARQ ID i is among the associated processes of CCx. This is in addition to the same TB size as original and the non-toggled NDI field w. t that of the original DCI scheduled process i.

Format B <NUM>: The DCI comprises indications of one or more of:.

Using the self-carrier index of CCy and switched HARQ ID i, the UE can to obtain the pair (CCx, Aux-HARQ ID j). In some embodiments, Format B1 can imply that j=i for simplicity As a validation of the received DCI, UE can check if obtained CCx had the HARQ ID i among its associated processes. This is in addition to the same TB size as original and the non-toggled NDI filed w. t that of the original DCI scheduled process i.

Format B2: The DCI comprises indications of one or more of:.

Using the scheduled CCy and the auxiliary HARQ ID j, the UE can to obtain the pair (CCx, HARQ ID i). In some embodiments, Format B2 can imply that i=j for simplicity. As a validation of the received DCI, UE can check if obtained HARQ ID i is among the associated processes of CCx. This is in addition to the same TB size as original and the non-toggled NDI filed w. t that of the original DCI scheduled process i.

In some embodiments, downlink assignments for subsequent retransmissions of the same TB on CCy follow normal procedure indicating the auxiliary HARQ ID.

<FIG> illustrates a flow diagram of example operations occurring in an access node operating in accordance with the example embodiments presented herein.

Operations begin with the access node sending an assignment of a transmission with HARQ Process ID i (block <NUM>). The transmission may be of a transmission block in a first network resource. Examples of network resources include time resources, frequency resources, time-frequency resources, code resources, carriers, component carriers, cells, or BWPs. The access node sends an assignment of a transmission with HARQ Process ID j (block <NUM>). The transmission may be of a transmission block in a second network resource. The access node detects an indication that the HARQ Process ID i and the HARQ Process ID j map to the same transmission block (block <NUM>). As an example, the access node detects that the indication indicates independent scheduling or data duplication in different HARQ Process IDs. As another example, the access node detects expiration of a RTT timer (either a transmit RTT timer for situations when the access node is transmitting or a receive RTT timer for situations when the access node is receiving) as the indication. The access node communicates the transmission associated with either of the HARQ Process IDs (block <NUM>). As used in this disclosure, communication applies to transmitting the transmission, receiving the transmission, or both transmitting and receiving the transmission.

<FIG> illustrates a flow diagram of example operations occurring in a UE operating in accordance with the example embodiments presented herein.

Operations begin with the UE receiving an assignment of a transmission with HARQ Process ID i (block <NUM>). The transmission may be of a transmission block in a first network resource. The UE receives an assignment of a transmission with HARQ Process ID j (block <NUM>). The transmission may be of a transmission block in a second network resource. The UE detects an indication that the HARQ Process ID i and the HARQ Process ID j map to the same transmission block (block <NUM>). As an example, the UE detects that the indication indicates independent scheduling or data duplication in different HARQ Process IDs. As another example, the UE detects expiration of a RTT timer (either a transmit RTT timer for situations when the UE is transmitting or a receive RTT timer for situations when the UE is receiving) as the indication. The UE communicates the transmission associated with either of the HARQ Process IDs (block <NUM>).

<FIG> illustrates a flow diagram of example operations occurring in an access node transmitting when a network resource becomes blocked.

Operations begin with the access node sending an assignment of a transmission with HARQ Process ID i (block <NUM>). The transmission may be of a transmission block in a first network resource. The access node sends an assignment of a transmission with HARQ Process ID j (block <NUM>). The transmission may be of a transmission block in a second network resource. The access node transmits the transmission on network resource X that is associated with HARQ Process ID i (block <NUM>). The access node performs a check to determine if feedback associated with HARQ Process ID i is blocked (block <NUM>). As an example, the feedback associated with HARQ Process ID i is blocked if the access node does not receive the feedback before expiration of a transmit RTT associated with the HARQ Process ID i. If the feedback is not blocked, the access node returns to continue checking.

If the feedback is blocked, the access node determines the HARQ Process ID j (block <NUM>). As an example, the access node determines the HARQ Process ID j utilizing a lookup table, such as shown in <FIG>. As another example, the access node determines the HARQ Process ID j using a pre-determined formula/arithmetic procedure with or without parameters, such as shown in <FIG> and <FIG>. The access node transmits on resource Y that is associated with HARQ Process ID j (block <NUM>).

<FIG> illustrates a flow diagram of example operations occurring in a UE receiving when a network resource becomes blocked.

Operations begin with the UE receiving an assignment of a transmission with HARQ Process ID i (block <NUM>). The transmission may be of a transmission block in a first network resource. The UE receives an assignment of a transmission with HARQ Process ID j (block <NUM>). The transmission may be of a transmission block in a second network resource. The UE receives the transmission on resource X that is associated with HARQ Process ID i (block <NUM>). The UE performs a check to determine if a retransmission is needed (block <NUM>). As an example, if the UE is unable to successfully decode the transmission, a retransmission is needed. If a retransmission is not needed, operations complete.

If a retransmission is needed, the UE transmits a NACK and performs a check to determine if resource X is blocked (block <NUM>). As an example, the resource X is blocked if a retransmission of the transmission is not received before expiration of a receive RTT associated with the HARQ Process ID i. If the resource X is not blocked, the UE returns to continue checking. If the resource X is blocked, the UE determines the HARQ Process ID j (block <NUM>). As an example, the UE determines the HARQ Process ID j utilizing a lookup table, such as shown in <FIG>. As another example, the UE determines the HARQ Process ID j using a pre-determined formula/arithmetic procedure with or without parameters, such as shown in <FIG> and <FIG>. The UE receives on resource Y that is associated with HARQ Process ID j (block <NUM>).

<FIG> illustrates an example communication system <NUM>. In general, the system <NUM> enables multiple wireless or wired users to transmit and receive data and other content. The system <NUM> may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

In this example, the communication system <NUM> includes electronic devices (ED) 1710a-1710c, radio access networks (RANs) 1720a-1720b, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>. While certain numbers of these components or elements are shown in <FIG>, any number of these components or elements may be included in the system <NUM>.

The EDs 1710a-1710c are configured to operate or communicate in the system <NUM>. For example, the EDs 1710a-1710c are configured to transmit or receive via wireless or wired communication channels. Each ED 1710a-1710c represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device.

The RANs 1720a-1720b here include base stations 1770a-1770b, respectively. Each base station 1770a-1770b is configured to wirelessly interface with one or more of the EDs 1710a-1710c to enable access to the core network <NUM>, the PSTN <NUM>, the Internet <NUM>, or the other networks <NUM>. For example, the base stations 1770a-1770b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNodeB), a Next Generation (NG) NodeB (gNB), a Home NodeB, a Home eNodeB, a site controller, an access point (AP), or a wireless router. The EDs 1710a-1710c are configured to interface and communicate with the Internet <NUM> and may access the core network <NUM>, the PSTN <NUM>, or the other networks <NUM>.

In the embodiment shown in <FIG>, the base station 1770a forms part of the RAN 1720a, which may include other base stations, elements, or devices. Also, the base station 1770b forms part of the RAN 1720b, which may include other base stations, elements, or devices. Each base station 1770a-1770b operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a "cell. " In some embodiments, multiple-input multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

The base stations 1770a-1770b communicate with one or more of the EDs 1710a-1710c over one or more air interfaces <NUM> using wireless communication links. The air interfaces <NUM> may utilize any suitable radio access technology.

It is contemplated that the system <NUM> may use multiple channel access functionality, including such schemes as described above. In particular embodiments, the base stations and EDs implement <NUM> New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may be utilized.

The RANs 1720a-1720b are in communication with the core network <NUM> to provide the EDs 1710a-1710c with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs 1720a-1720b or the core network <NUM> may be in direct or indirect communication with one or more other RANs (not shown). The core network <NUM> may also serve as a gateway access for other networks (such as the PSTN <NUM>, the Internet <NUM>, and the other networks <NUM>). In addition, some or all of the EDs 1710a-1710c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet <NUM>.

The ED <NUM> also includes at least one transceiver <NUM>. The transceiver <NUM> is configured to modulate data or other content for transmission by at least one antenna or NIC (Network Interface Controller) <NUM>. The transceiver <NUM> is also configured to demodulate data or other content received by the at least one antenna <NUM>. Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission or processing signals received wirelessly or by wire. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers <NUM> could be used in the ED <NUM>, and one or multiple antennas <NUM> could be used in the ED <NUM>. Although shown as a single functional unit, a transceiver <NUM> could also be implemented using at least one transmitter and at least one separate receiver.

The ED <NUM> further includes one or more input/output devices <NUM> or interfaces (such as a wired interface to the Internet <NUM>). The input/output devices <NUM> facilitate interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

In addition, the ED <NUM> includes at least one memory <NUM>. The memory <NUM> stores instructions and data used, generated, or collected by the ED <NUM>. For example, the memory <NUM> could store software or firmware instructions executed by the processing unit(s) <NUM> and data used to reduce or eliminate interference in incoming signals. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.

Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver <NUM> further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver <NUM>, a transmitter and a receiver could be separate components. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna <NUM> is shown here as being coupled to the transceiver <NUM>, one or more antennas <NUM> could be coupled to the transceiver(s) <NUM>, allowing separate antennas <NUM> to be coupled to the transmitter and the receiver if equipped as separate components. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Each input/output device <NUM> facilitates interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving/providing information from a user, including network interface communications.

<FIG> is a block diagram of a computing system <NUM> that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system <NUM> includes a processing unit <NUM>. The processing unit includes a central processing unit (CPU) <NUM>, memory <NUM>, and may further include a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> connected to a bus <NUM>.

The video adapter <NUM> and the I/O interface <NUM> provide interfaces to couple external input and output devices to the processing unit <NUM>. As illustrated, examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and a mouse, keyboard, or printer <NUM> coupled to the I/O interface <NUM>. Other devices may be coupled to the processing unit <NUM>, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

Claim 1:
A method, performed by a user equipment, UE, the method comprising:
receiving (<NUM>), from an access node, a first assignment for a first transmission with a first hybrid automatic repeat request, HARQ, process identifier, ID, in a first network resource being a first component carrier;
receiving (<NUM>), from the access node, a second assignment for a second transmission with a second HARQ process ID in a second network resource being a second component carrier,
wherein the first network resource and the second network resource are associated with different transmission/receiving points, TRPs,
wherein the receiving the first assignment and the second assignment comprises:
receiving the first assignment and the second assignment in two different pieces of downlink control information, DCI, indicating respectively the first HARQ process ID and the second HARQ process ID; or
receiving the first assignment and the second assignment in a single DCI indicating the first HARQ process ID, wherein the first HARQ process ID and the second HARQ process ID are the same;
detecting (<NUM>) an indication including a semi-static configuration indicating that the first transmission and the second transmission map to a same transport block, TB; and
communicating (<NUM>) at least one transmission of the first transmission in the first network resource and the second transmission in the second network resource.