Patent Description:
It is known to schedule resources between a mobile terminal and a base station in a communication system.

<NPL> relates to preconfigured uplink resources involving multiple UEs sharing a data resource (by assignment from dedicated RRC signalling) while using unique UE-specific DMRS sequences (also assigned by dedicated RRC).

The CFS PUR scheme proposed includes a mechanism to allow sending information to a particular UE in response to an initial PUR transmission (e.g. HARQ-ACK, RRC response, grant for retransmission, etc) which can be achieved by assigning a dedicated RNTI to each UE, for example.

After a UE transmits data to the eNB on a PUR resource, it may wait for a response from the eNB within a certain window of time. Depending on the response the UE may either (i) perform a HARQ retransmission using the same resources and DMRS and scrambling sequences as the first time, (ii) receive a new dedicated grant for retransmission, (iii) perform a fallback.

The following summary is merely intended to be an example. The summary is not intended to limit the scope of the claims.

In accordance with an aspect, a method includes receiving an assignment of contention based shared preconfigured uplink resources via radio resource control signaling; receiving an assignment of a common radio network temporary identifier for monitoring downlink control information indicating a negative acknowledgement for contention based shared transmission, and a dedicated radio network temporary identifier for monitoring downlink control information indicating an acknowledgement of transmission of uplink data; transmitting the uplink data during a contention based shared preconfigured uplink resource transmission using a physical uplink shared channel allocated for the contention based shared preconfigured uplink resource transmission; in response to the downlink control information indicating the negative acknowledgement and uplink grants for multiple physical uplink shared channel resources, retransmitting the uplink data on a selected one of the received uplink grants for multiple physical uplink shared channel resources; and in response to the downlink control information indicating the acknowledgment, not retransmitting the uplink data.

In accordance with an aspect, a method includes configuring an assignment of contention based shared preconfigured uplink resources via radio resource control signaling for multiple user equipments; attempting to decode the contention based shared preconfigured uplink resources; in response to detecting a collision between transmissions within the contention based shared preconfigured uplink resources, transmitting the downlink control information indicating a negative acknowledgement with a common radio network temporary identifier and uplink grants for multiple physical uplink shared channel resource allocations for retransmission, and decoding the multiple physical uplink shared channel resource allocations; and in response to the transmitted uplink data being successfully decoded from at least one of the multiple user equipments within the assigned contention based shared resources, transmitting the downlink control information indicating an acknowledgement with a dedicated radio network temporary identifier.

In accordance with an aspect, an apparatus includes means for receiving an assignment of contention based shared preconfigured uplink resources via radio resource control signaling; means for receiving an assignment of a common radio network temporary identifier for monitoring downlink control information indicating a negative acknowledgement for contention based shared transmission, and a dedicated radio network temporary identifier for monitoring downlink control information indicating an acknowledgement of transmission of uplink data; means for transmitting the uplink data during a contention based shared preconfigured uplink resource transmission using a physical uplink shared channel allocated for the contention based shared preconfigured uplink resource transmission; means for, in response to the downlink control information indicating the negative acknowledgement and uplink grants for multiple physical uplink shared channel resources, retransmitting the uplink data on a selected one of the received uplink grants for multiple physical uplink shared channel resources; and means for, in response to the downlink control information indicating the acknowledgment, not retransmitting the uplink data.

In accordance with an aspect, an apparatus includes means for configuring an assignment of contention based shared preconfigured uplink resources via radio resource control signaling for multiple user equipments; means for attempting to decode the contention based shared preconfigured uplink resources; means for, in response to detecting a collision between transmissions within the contention based shared preconfigured uplink resources, transmitting the downlink control information indicating a negative acknowledgement with a common radio network temporary identifier and uplink grants for multiple physical uplink shared channel resource allocations for retransmission, and decoding the multiple physical uplink shared channel resource allocations; and means for, in response to the transmitted uplink data being successfully decoded from at least one of the multiple user equipments within the assigned contention based shared resources, transmitting the downlink control information indicating an acknowledgement with a dedicated radio network temporary identifier.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting example in which the examples may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element(s) <NUM> are illustrated. In the example of <FIG>, the user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless device that can access the wireless network <NUM>. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> in this example is a base station that provides access by wireless devices such as the UE <NUM> to the wireless network <NUM>. The RAN node <NUM> may be, for example, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM> may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (such as, for example, the network element (s) <NUM>). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting radio resource control (RRC), SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, e.g., as part of a RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, e.g., under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

The RAN node <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the DU <NUM>.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

It is noted that description herein indicates that "cells" perform functions, but it should be clear that equipment which forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM> degree area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three <NUM> degree cells per carrier and two carriers, then the base station has a total of <NUM> cells.

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(S)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element (s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to the network element <NUM>. The link <NUM> may be implemented as, e.g., an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more operations.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, network element(s) <NUM>, and other functions as described herein.

Examples described herein relate to Preconfigured Uplink Resource (PUR) for NR or LTE. The examples provide a scheme to enable contention based shared PUR for NR or LTE and the fallback mechanisms for contention resolution. In particular, the examples suggest need-based additional resource grants for UE failing the initial attempt if the gNB or eNB detects collision so as to reduce UEs failing in contention resolution. The examples may be adapted to <NUM> or <NUM> standards.

The examples relate to PUR for NR or LTE. A feature for NR-light is PUR, or grant-free uplink transmission. The UE may be configured with idle-mode or inactive-mode PUR while in RRC connected mode.

In LTE, only dedicated PUR in idle mode is supported. Dedicated PUR works well for cases where the data traffic is periodic, but is not well suited for bursty or aperiodic traffic.

Sharing of PUR resources may be one feature to allow multiple IoT devices which have bursty traffic to make reports while remaining in an idle or inactive state which saves the UE power consumption. However, if PUR resources are no longer dedicated to a single UE there needs to be a contention resolution process. In particular if a UE uses any contention based shared PUR resources but is unsuccessful then a fallback method needs to be defined.

Features provided by the examples described herein is how to enable transmission in contention based shared PUR for NR or LTE.

The examples described herein include a proposed scheme to support transmission in contention based shared preconfigured uplink resource (CBS PUR) for NR-Light devices and the fallback mechanisms needed for the contention resolution.

The examples described herein indicate that for the first transmission, the base station (e.g., gNB for <NUM> NR or eNB for LTE) allocates a single PUR for multiple UE to access. In case the base station (e.g., eNB or gNB) detects collision, in the next possible scheduling period it indicates via DCI more PUSCH resources for the competing UE to split between them to avoid retransmission failure. This mechanism of allocating multiple grants in retransmission to reduce the impact of collision is an aspect.

For example, in case of more than one UE attempting for allocated resources for CBS PUR, instead of failing them in contention resolution and all of them attempting via RACH or EDT in this case, the examples suggest, for the UE failing the initial attempt, providing the UE with second dynamic additional CBS-PUR resources for the UE to succeed in subsequent transmissions. The additional resource allocation described is based on need, instead of overbooking more occasions for CBS PUR or dedicated PUR. The number of additional resource allocation is configurable.

In Rel-<NUM>, NR-Light (also referred to as NR-based IoT or NR-Light) addresses use cases that may not be met by NR eMBB, URLLC or eMTC/NB-IoT. NR-Light supports the following requirements:.

Specifically, NR-Light addresses the following objectives and use cases -.

A feature for NR-Light is transmission in Preconfigured Uplink Resource (PUR), or grant-free uplink transmission. The UE may be configured with idle-mode or inactive-mode PUR while in RRC connected mode prior to moving to the idle or inactive mode. <FIG> is a diagram <NUM> illustrating preconfigured uplink resources <NUM>, <NUM>, and <NUM>.

In addition, eMTC and NB-IoT may also continue to see further improvements in Rel-<NUM>. Thus, contention based shared PUR may also be supported in LTE.

As part of the Rel-<NUM> enhancements of eMTC and NB-IoT (work items RP-<NUM> and RP-<NUM>), one of the objectives of both WIs is -.

In LTE, only dedicated preconfigured uplink resource (PUR) in idle mode is supported. Dedicated means that a unique or dedicated time-frequency resource is reserved for each UE configured with PUR. This also means that PUR transmission is contention-free as only one UE is allocated the time/frequency resources.

In Rel-<NUM>, NR-Light (also referred to as NR-based IoT or NR-Light) addresses use cases that cannot be met by NR eMBB, URLLC or eMTC/NB-IoT. One goal of NR-Light is to support Industrial IoT deployment using low-cost, low-complexity devices with long battery life. To provide support for low-cost preconfigured uplink resources (PURs) may be introduced. Dedicated PUR works well for cases where the data traffic is periodic, but is not well suited for bursty or aperiodic traffic.

Sharing of PUR resources could be one feature to allow multiple IoT devices which have bursty traffic to make reports while remaining in an idle or inactive state which saves the UE power consumption. However, if PURs are no longer dedicated to a single UE multiple UE may simultaneously access a PUR for which there may be a contention resolution process. In particular if a UE tries to use any contention based PUR resources but is unsuccessful then a fallback method needs to be defined.

The examples described herein implement a scheme to enable contention based shared PUR for NR and the fallback mechanisms for contention resolution.

Support for contention free shared preconfigured resources (CFS PUR) has been discussed in 3GPP [<NPL>. The concept of contention-based resources is also described for example in the non-orthogonal multiple access (NOMA) area. However, there is no description of contention based shared PUR for NR or on mechanisms for contention resolution.

The examples provided herein describe a scheme to enable contention based shared preconfigured uplink resource (CBS PUR) for NR-Light devices.

In case of simple CBS PUR mechanism, the following steps are involved in the uplink data transmission.

The above fallback mechanism may result in delay in completing the CBS PUR transmission. If the UE uses EDT or RACH transmission it may also increase the energy usage for the aperiodic emergency uplink transmissions.

In the examples described herein, the failure scenario for CBS-PUR transmission is improved with dynamic allocation of multiple resources for CBS-PUR retransmission with possibility for reduced collision.

Steps of the described examples are provided below. The UE is assigned with CBS-PURs via dedicated RRC signaling. During CBS PUR transmission, UE sends the uplink data using the PUSCH allocated for CBS PUR transmission. The UE is assigned with common RNTI for receiving DCI indicating or containing the NACK for CBS transmission in addition to the UE specific RNTI assigned for monitoring ACK. In case the gNB is able to decode the transmission from any UE in the CBS resources, it sends DCI indicating or containing ACK and scrambled with the UE-specific RNTI. The UE that is able to decode this DCI then determines that its transmission in the CBS PUR was successfully received by the gNB. In case the gNB is not able to decode any of the UE on the CBS resources, the gNB may send DCI containing or indicating NACK and scrambled with the common RNTI. The UE monitoring the NACK may use a fallback procedure for retransmission.

In one embodiment, in case the gNB is not able to decode any of the UE on the CBS resources but the received signal level is higher than a predefined or preconfigured threshold, it indicates a potential collision scenario. In this case the gNB sends DCI containing or indicating NACK and uplink grants for multiple PUSCH resources. These multiple grants are also for CBS PUSCH access for the UE which competed for access over the first CBS PUSCH resources.

In one embodiment, the NACK is implicit and given by the common RNTI. That is, UE detecting a DCI scrambled with the common RNTI may interpret this as NACK. This DCI may itself contain an uplink grant. The number of PUSCH resources may be signaled via higher-layer signaling. The gNB may determine the number of PUSCH resources based on the received signal level or on the number of detected reference signals. In one embodiment, the gNB may determine the number of PUSCH resources based on historical trends. For example, over time the gNB may learn the transmission probability for a particular group of UEs and use this information to determine the PUSCH resources needed.

In one embodiment, the DCI may indicate a delayed grant of the multiple PUSCH resources. In this case, UEs may monitor PDCCH candidate locations before the granted multiple PUSCH resources for DCI scrambled by the dedicated RNTI for an uplink PUSCH grant. If the gNB is able to detect specific reference signals, it may first provide dedicated grants to the corresponding UEs. UEs that did not receive a dedicated grant may then attempt to use the grant of multiple PUSCH resources.

In one embodiment, in case the UE receives the DCI with common RNTI, the UE randomly selects one of the multiple PUSCH resources for retransmission of PUSCH transmissions. As there are likely to be more PUSCH resources for distributing the competing UE to retransmit their PUSCH, the probability of successful completion of PUSCH transmission for all the competing UE may be higher.

In one embodiment, the gNB may send two DCIs where the first DCI scrambled with the dedicated RNTI contains ACK for the UE whose transmission it was able to decode successfully and the second DCI scrambled with the common RNTI contains NACK for all other UEs. In case the gNB detects one of the UE successfully on the PUSCH but deduces based on the total interference /signal level or the presence of other reference signal(s), the possibility of other competing UE(s), the gNB may also send NACK using common RNTI for other UE which failed the CBS access for retransmission of the PUSCH. The second DCI indicating NACK may then include allocation of multiple PUSCH resources for retransmission when the gNB determines that there may have been failed PUSCH transmissions. The UE monitors two DCIs - first DCI scrambled with dedicated RNTI for ACK and a second DCI scrambled with common RNTI for NACK. In case a UE receives ACK in the first DCI, it ignores the second DCI. In case a UE does not receive an ACK in the first DCI and receives a NACK in the second DCI, it decodes the second DCI to determine allocation of resources for retransmission. In this case also the UE which did not succeed in the CBS-PUR attempt can retransmit using these resources.

The UE attempting the PUSCH over the CBS-PUR transmission checks in two predetermined (e.g., fixed in the specification) or preconfigured (e.g., through RRC) PDCCH candidate locations for valid DCI with dedicated RNTI and common RNTI. This is to check whether the PUSCH is received at gNB or not and also whether gNB is assigning another CBS-PUR for retransmission or not. If none of the above is received, the UE may fall back to RACH or EDT transmission.

In case if the UE did not receive DCI with either common RNTI or its dedicated RNTI, it can send common preamble assigned to the CBS PUR to indicate the resources required for PUSCH retransmission. Prior to fallback to EDT, the UE can send this common preamble so that the eNB or gNB can assign TBS and resources configured for CBS-PUR instead of using EDT configuration which may not be suitable for the amount of data configured for CBS-PUR access.

<FIG> is a diagram <NUM> illustrating example steps of the described method. In <FIG>, several UEs (UE1, UE2, and UE3) are competing for access over the first CBS PUSCH resources. In case if the UE did not receive DCI with either common RNTI or its dedicated RNTI, it can send common preamble assigned to the CBS PUR <NUM> to indicate the resources required for PUSCH retransmission.

Benefits of the examples described herein include enabling completion of CBS-PUR transmission for multiple UE without the UE falling back to EDT or RACH mechanism. With the help of multiple CBS-PUR resources allocated dynamically via DCI, the collision probability for CBS-PUR retransmission reduces and the overall performance for CBS-PUR transmission improves. Dynamic CBS-PUR resource allocation for retransmission from failed UE may be beneficial if a higher number of UEs are mapped to the CBS-PUR but only few of them are expected to access the CBS-PUR resources at any given instance of the CBS-PUR.

The examples described herein provide a method where the network sends NACK indicating multiple PUSCH resources for CBS retransmission in case collision is detected in the initial transmission to enable the retransmission with reduced collision probability. The examples described herein provide a method where UE attempting CBS PUR transmission monitoring common RNTI for retransmission in case of collision and also dedicated RNTI to receive HARQ-ACK and further higher layer transmission towards single UE. The examples described herein provide a method where the UE monitors for two predetermined or preconfigured PDCCH for dedicated RNTI reception and common RNTI reception. The dedicated RNTI reception may be for an acknowledgement, and the common RNTI reception may be for the negative acknowledgement. The examples described herein provide a method for a UE indicating non reception of DCI via common and dedicated RNTI via common preamble assigned for CBS to enable the ENB or gNB to send DCI with multiple CBS PUSCH resources for CBS retransmission. The examples described herein provide a method for configuration of CBS PUR retransmission with multiple resources and also the number of PUSCH allocation for retransmissions via high-layer signaling, including dedicated or common RRC signaling.

The message sequence diagram for the CBS PUR transmission procedure as per the described examples is illustrated by <FIG> and <FIG>.

<FIG> illustrates the scenario <NUM> where the base station <NUM> (e.g., gNB or eNB) detects collision on the CBS PUSCH and sends NACK with multiple PUSCH resource for retransmission with reduced collision. At <NUM>, there is configuration of CBS-PUR resources between the UE <NUM> and base station <NUM>. In other words, at <NUM> there is configuration of common-RNTI for retransmission and the number of PUSCH resource for CBS retransmission. At <NUM>, the UE <NUM> performs uplink transmission (CBS-PUSCH). At <NUM>, the base station <NUM> transmits DCI (NACK, Multiple CBS-PUSCH Allocation) via a common-RNTI. At <NUM>, the UE <NUM> selects one of the PUSCH randomly based on the UE-ID. At <NUM>, the UE performs PUSCH-Retransmission on selected PUSCH from the multiple grants.

<FIG> illustrates scenario <NUM> where the base station <NUM> (e.g., gNB or eNB) does not detect collision but there was at least one UE (such as UE <NUM>) which attempted CBS PUR and did not succeed. This may happen in case if the base station detection mechanism does not detect the collision accurately. In this case the UEs that failed CBS transmission send a common preamble to trigger resource allocation for retransmission. At <NUM>, there is configuration of CBS-PUR resources between the UE <NUM> and base station <NUM>. In other words, at <NUM> there is configuration of common-RNTI for retransmission and the number of PUSCH resource for CBS retransmission. At <NUM>, the UE <NUM> does not receive either ACK via dedicated RNTI or NACK via common RNTI. At <NUM>, the UE <NUM> transmits a common preamble. At <NUM>, the UE <NUM> receives from the base station <NUM> DCI (multiple grants for CBS transmission). At <NUM>, the UE <NUM> selects one of the PUSCH randomly based on the UE-ID. At <NUM>, the UE <NUM> performs PUSCH-Retransmission on selected PUSCH from the multiple grants.

The examples described herein may be provided in Rel-<NUM> standards in the NR IoT / NR-Light area, and/or may require standardization of required signaling in 3GPP.

Claim 1:
A method (<NUM>) comprising:
receiving (<NUM>) an assignment of contention based shared preconfigured uplink resources via radio resource control signaling;
receiving (<NUM>) an assignment of a common radio network temporary identifier for monitoring downlink control information indicating a negative acknowledgement for contention based shared transmission, and a dedicated radio network temporary identifier for monitoring downlink control information indicating an acknowledgement of transmission of uplink data;
transmitting (<NUM>) the uplink data during a contention based shared preconfigured uplink resource transmission using a physical uplink shared channel allocated for the contention based shared preconfigured uplink resource transmission;
in response to the downlink control information indicating the negative acknowledgement and uplink grants for multiple physical uplink shared channel resources, retransmitting (<NUM>) the uplink data on a selected (<NUM>) one of the received uplink grants for multiple physical uplink shared channel resources; and
in response to the downlink control information indicating the acknowledgment, not retransmitting the uplink data.