Timer handling in multiple active grant configurations

Abstract

Systems and methods for determining retransmission configuration(s) are provided herein. Some embodiments relate to configuring one or more timers associated with a configured grant configuration. A network node can configure a wireless device with multiple different configured grant configurations and associated parameters. The wireless device can use a first configured grant configuration to transmit data and a second configured grant configuration to retransmit data.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 62 / 932,242, filed November 7, 2019, the entire contents of which are incorporated herein by reference.

[0002] TECHNICAL FIELD The present disclosure relates generally to wireless communications and wireless communication networks. [Background technology]

[0003] Introduction Standardization bodies such as the 3rd Generation Partnership Project (3GPP) are studying potential solutions for efficient operation of radio communications in new radio (NR) networks. The next generation mobile radio communication system 5G / NR will support a diverse set of use cases and a diverse set of deployment scenarios. The latter includes deployments at both low frequencies (e.g., hundreds of MHz) and very high frequencies (e.g., mm-wave in the tens of GHz range) similar to today's LTE. Besides typical mobile broadband use cases, NR is also being developed to support machine-type communications (MTC), very low latency critical communications (URLCC), sidelink device-to-device (D2D), and other use cases.

[0004] Like LTE, NR uses OFDM (orthogonal frequency division multiplexing) in the downlink (i.e., from a network node, gNB, eNB, or base station, to a user equipment or UE). In the uplink (i.e., from the UE to the gNB), both DFT-spread OFDM and OFDM may be supported.

[0005] In NR, the basic scheduling unit is called a slot. A slot consists of 14 OFDM symbols for a normal cyclic prefix configuration. NR supports many different subcarrier spacing configurations, and for a subcarrier spacing of 30 kHz, the OFDM symbol duration is approximately 33 μs. As an example, a slot with 14 symbols for the same subcarrier spacing (SCS) is 500 μs long (including the cyclic prefix).

[0006] Thus, the basic NR physical resource on an antenna port can be viewed as a time-frequency grid as shown in Figure 1, where resource blocks (RBs) in 14 symbol slots are shown. A resource block corresponds to 12 consecutive subcarriers in the frequency domain. Resource blocks are numbered in the frequency domain starting at 0 from one end of the system bandwidth. Each resource element corresponds to one OFDM subcarrier in one OFDM symbol interval.

[0007] NR also supports flexible bandwidth configuration for different UEs on the same serving cell. In other words, the bandwidth monitored by the UE and used for its control and data channels may be smaller than the carrier bandwidth. One or more bandwidth portion (BWP) configurations for each component carrier may be semi-statically signaled to the UE, where a bandwidth portion consists of a group of contiguous PRBs. Reserved resources may be configured within the bandwidth portion. The bandwidth of the bandwidth portion is equal to or smaller than the maximum bandwidth capability supported by the UE.

[0008] NR targets access to both licensed and unlicensed spectrum. Allowing unlicensed networks, i.e. networks operating in shared spectrum (or unlicensed spectrum), to effectively use available spectrum can be an attractive approach to increase system capacity. Although unlicensed spectrum does not match the quality of the licensed regime, solutions that enable efficient use of unlicensed spectrum as a complement to licensed deployments have the potential to bring value to 3GPP operators and, ultimately, the 3GPP industry as a whole. It is expected that some features in NR will need to be adapted to comply with the special characteristics of unlicensed spectrum, as well as different regulations. Subcarrier spacing of 15 kHz or 30 kHz is the most promising candidate for NR Unlicensed Spectrum (NR-U) OFDM numerology for frequencies below 6 GHz.

[0009] When operating in unlicensed spectrum, many regions around the world require a device to sense the medium as free before transmitting. This operation is often called Listen Before Talk (LBT). There are many variations of LBT, depending on which radio technology the device uses and what type of data the device currently wishes to transmit. Common to all the variations is that sensing is done in a specific channel (e.g., corresponding to a defined carrier frequency) and over a predefined bandwidth. For example, in the 5 GHz band, sensing is done over a 20 MHz channel.

[0010] Many devices are capable of transmitting (and receiving) on ​​a wide bandwidth that includes multiple subbands / channels, e.g., LBT subbands (i.e., frequency portions with a bandwidth equal to the LBT bandwidth). Devices are only allowed to transmit on subbands in which the medium is sensed as free. Also, when multiple subbands are involved, there are different flavors of how sensing should be done.

[0011] In principle, there are two ways in which a device can operate across multiple sub-bands. One way is that the transmitter / receiver bandwidth is changed depending on which sub-band is sensed as free. In this setup, there is only one component carrier (CC) and the multiple sub-bands are treated as a single channel with a larger bandwidth. Another way is that the device operates largely independent processing chains for each channel. Depending on how independent the processing chains are, this option can be called carrier aggregation (CA) or dual connectivity (DC).

[0012] Listen-Before-Talk (LBT) is designed for unlicensed spectrum coexistence with other RATs. In the conventional mechanism, a wireless device applies a clear channel assessment (CCA) check (i.e., channel sensing) before any transmission. The transmitter involves energy detection (ED) over a period of time compared to a certain threshold (ED threshold) to determine if the channel is idle. If the channel is determined to be occupied, the transmitter performs a random backoff within the contention window before the next CCA attempt. To protect ACK transmissions, the transmitter must postpone a period after each busy CCA slot before resuming backoff. Once the transmitter gains access to the channel, it is only allowed to perform transmissions up to a maximum duration (i.e., maximum channel occupation time (MCOT)). For QoS differentiation, channel access priority based on service type was defined. For example, there are four LBT priority classes, which are defined for the differentiation of contention window size (CWS) and MCOT between services.

[0013] In NR-U, both configured and dynamic scheduling may be used.

[0014] Pre-configured Scheduling

[0015] In NR, configured scheduling is used to assign semi-static periodic allocations or grants for UEs. For the uplink, there are two types of configured scheduling schemes, Type 1 and Type 2. For Type 1, configured grants are configured only via RRC signaling. For Type 2, a configuration procedure similar to SPS UL in LTE is specified, i.e., some parameters are preconfigured via RRC signaling and some physical layer parameters are configured via MAC scheduling procedure. The detailed procedure is described in 3GPP TS38.321 V15.4.0. Configured uplink scheduling may also be used in NR unlicensed operation. For NR-U, configured scheduling can improve the channel access probability for PUSCH transmission by avoiding an additional LBT for PDCCH transmission per UL grant, and the UE can acquire the channel for PUSCH transmission using the configured grant after LBT success. In this uplink transmission procedure, only a single LBT procedure is needed compared to three LBT procedures relying on the SR / BSR procedure (e.g., an LBT procedure for SR TX, an LBT procedure for PDCCH for UL grant, and an LBT procedure for PUSCH TX), which can significantly improve the channel access probability for PUSCH transmission.

[0016] As described in 3GPP TR38.889, for both Type 1 and Type 2, only the initial Hybrid Automatic Repeat Request (HARQ) transmission is allowed to use configured grants. HARQ retransmissions rely on dynamic grants indicated via the PDCCH addressed to the CS-RNTI.

[0017] In NR Rel-15, it is desirable to introduce feLAA autonomous uplink transmission (AUL) type behavior. However, it is important to realize that the baseline is Type 1 and Type 2 Configured Grants (CGs). Some extensions on top of this baseline may be required to enable the desired behavior. Similar to SPS in LTE, the CG periodicity is RRC configured and specified in the ConfiguredGrantConfig IE. In NR Rel-15, different periodicity values ​​are supported depending on the subcarrier spacing. For example, for 15 and 30 kHz SCS, the following periodicities are supported, expressed in number of OFDM symbols: 15kHz SCS 2, 7 and n*14 OFDM symbols where n∈{1,2,4,5,8,10,16,20,32,40,64,80,128,160,320,640} 30kHz SCS 2, 7 and n*14 OFDM symbols where n∈{1,2,4,5,8,10,16,20,32,40,64,80,128,160,256,320,640,1280}

[0018] For Type 1 configured grants, in addition to the periodicity, the time domain allocation of the PUSCH is configured purely via RRC signaling. timeDomainOffset: Provides the slot offset with respect to SFN 0 timeDomainAllocation: Provides an index into a table of 16 possible combinations of PUSCH mapping type (Type A or Type B), the starting symbol S for the mapping (S = 0, 2, 4, or 8 OFDM symbols in the slot), and the length L of the mapping (L = 4, 6, 8, 10, 12, or 14 OFDM symbols).

[0019] For Type 2 configured grants, the periodicity is configured by the RRC in a similar manner as for Type 1, but the slot offset is dynamically indicated and given by the slot in which the UE receives the DCI activating the Type 2 configured grant. In contrast to Type 1, the time domain allocation of the PUSCH is dynamically indicated by the DCI via the time domain resource allocation field in the same manner as for scheduled (non-CG) PUSCH. This DCI field indexes a table of start symbol and length (SLIV) values. Detailed configuration details of the RRC specification (see, for example, 3GPP TS38.331 v15.6.0) for configured grants are given below:

[0020] ConfiguredGrantConfig Information Element (IE): JPEG0007597807000001.jpg239170

[0021] An autonomous uplink transmission (AUL) mechanism is currently designed based on a configured scheduling scheme to support autonomous retransmission with configured grant. To support autonomous retransmission in uplink with configured grant, the configuration of related retransmission timer(s) and HARQ process(es) needs to be determined. Summary of the Invention

[0022] It is an object of the present disclosure to obviate or mitigate at least one of the disadvantages of the prior art.

[0023] A system and method for determining retransmission setting(s) is provided.

[0024] In a first aspect, a method implemented by a wireless device is provided. The wireless device may comprise an air interface and a processing circuit and be configured to obtain configuration information including a plurality of configured granted (CG) configurations. The wireless device selects data from a logical channel mapped to a first CG configuration for transmission and transmits the selected data using the first CG configuration. In response to determining that a retransmission of the data is required, the wireless device selects a second CG configuration to use for the retransmission, the second CG configuration being different from the first CG configuration. The wireless device retransmits the data using the selected second CG configuration.

[0025] In some embodiments, the configuration information is received from a network node.

[0026] In some embodiments, a logical channel may be mapped to one or more of a plurality of CG configurations, which may share the same Hybrid Automatic Repeat Request (HARQ) process.

[0027] In some embodiments, in response to transmitting the selected data, the wireless device may start one or more timers. A CG timer may be started according to a first CG configuration, the CG timer defining a maximum time period during which the wireless device may trigger an autonomous retransmission. A retransmission timer may be started according to the first CG configuration, the retransmission timer defining a time period after which the wireless device triggers a next retransmission attempt.

[0028] In some embodiments, the retransmission timer may be stopped in response to one of receiving HARQ feedback indicating an acknowledgement (ACK) or negative acknowledgement (NACK), or receiving a grant indicating a new transmission or a retransmission of the transmitted data.

[0029] In some embodiments, determining that a retransmission is required is in response to expiration of a retransmission timer.

[0030] In some embodiments, the second CG setting may be selected according to selecting the earliest time resource that belongs to any of the multiple CG settings.

[0031] In some embodiments, the second CG configuration may be selected according to the first CG configuration and the second CG configuration sharing the same HARQ process.

[0032] In some embodiments, the second CG setting may be selected according to which the second CG setting provides the same transport block size as the transmitted data.

[0033] In some embodiments, the logical channel is not mapped to the selected second CG setting.

[0034] In some embodiments, in response to retransmitting the data, the retransmission timer is restarted according to the second CG setting. In some embodiments, in response to retransmitting the data, the CG timer is not updated.

[0035] In another aspect, a method is provided that is implemented by a network node. The network node may comprise an air interface and a processing circuit and be configured to generate configuration information including a plurality of Configured Granted (CG) configurations. The network node transmits a control message including the configuration information to one or more wireless devices. The network node receives data retransmissions from the wireless devices, where a first CG configuration was used for the initial data transmission and a second CG configuration was used for the retransmission.

[0036] In some embodiments, the first CG configuration and the second CG configuration share the same hybrid automatic repeat request (HARQ) process.

[0037] In some embodiments, each of the multiple CG configurations includes corresponding retransmission timer information.

[0038] In some embodiments, the second CG setting may be selected according to selecting the earliest time resource that belongs to any of the multiple CG settings.

[0039] In some embodiments, the second CG configuration may be selected according to the first CG configuration and the second CG configuration sharing the same HARQ process.

[0040] In some embodiments, the second CG setting may be selected according to which the second CG setting provides the same transport block size as the transmitted data.

[0041] The various aspects and embodiments described herein may be alternatively, optionally, and / or additionally combined with each other.

[0042] Other aspects and features of the present disclosure will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

[0043] Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying figures. [Brief description of the drawings]

[0044] [Figure 1] A diagram showing an example of NR physical resources. [Diagram 2] FIG. 1 illustrates an exemplary wireless network. [Diagram 3] FIG. 1 illustrates an example of signaling in a wireless network. [Figure 4] FIG. 1 is an exemplary signaling diagram. [Diagram 5] 1 is a flowchart illustrating a method that may be implemented in a wireless device. [Figure 6]1 is a flowchart illustrating a method that may be implemented in a network node. [Figure 7] 1 is a block diagram of an example wireless device. [Figure 8] 1 is a block diagram of an example wireless device with modules. [Figure 9] FIG. 2 is a block diagram of an example network node. [Figure 10] FIG. 2 is a block diagram of an example network node with modules. [Figure 11] FIG. 2 is a block diagram of an example virtualized processing node. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] The embodiments described below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the description and recognize applications of these concepts not specifically addressed herein. It is understood that these concepts and applications fall within the scope of the description.

[0046] In the following description, numerous specific details are set forth. However, it should be understood that the embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of the description. Those skilled in the art will be able to use the included description to implement the appropriate functionality without undue experimentation.

[0047] References herein to "one embodiment," "an embodiment," "exemplary embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described with respect to an embodiment, it is submitted that it is within the knowledge of one of ordinary skill in the art to implement such feature, structure, or characteristic with respect to other embodiments, whether or not explicitly described.

[0048] In some embodiments, the non-limiting term "user equipment" (UE) is used, which may refer to any type of wireless device capable of communicating with a network node and / or another UE in a cellular or mobile or wireless communication system. Examples of UEs are target devices, device-to-device (D2D) UEs, machine-type UEs, as well as UEs capable of machine-to-machine (M2M) communication, personal digital assistants, tablets, mobile terminals, smartphones, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, ProSe UEs, V2V UEs, V2X UEs, MTC UEs, eMTC UEs, FeMTC UEs, UE Cat0, UE Cat M1, narrowband IoT (NB-IoT) UEs, UE Cat NB1, etc. Exemplary embodiments of UEs are described in more detail herein with respect to FIG. 7.

[0049] In some embodiments, the non-limiting term "network node" is used, and "network node" may correspond to any type of radio access node (or radio network node) or any network node that can communicate with a UE and / or another network node in a cellular or mobile or wireless communication system. Examples of network nodes are Node B, MeNB, SeNB, network nodes belonging to MCG or SCG, base station (BS), MSR radio access node such as Multi-Standard Radio (MSR) BS, eNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlled relay, base transceiver station (BTS), access point (AP), transmission point, transmitting node, RRU, RRH, node in distributed antenna system (DAS), core network node (e.g. MSC, MME, etc.), O&M, OSS, self-organizing network (SON), positioning node (e.g. E-SMLC), MDT, test equipment, etc. Exemplary embodiments of network nodes are described in more detail below with respect to FIG. 9.

[0050] In some embodiments, the term "Radio Access Technology" (RAT) refers to any RAT, e.g., UTRA, E-UTRA, Narrowband Internet of Things (NB-IoT), WiFi, Bluetooth, Next Generation RAT (NR), 4G, 5G, etc. Either the first node and the second node may be capable of supporting a single RAT or multiple RATs.

[0051] As used herein, the term "wireless node" may be used to denote a wireless device or a network node.

[0052] In some embodiments, a UE may be configured to operate in carrier aggregation (CA), which implies aggregation of two or more carriers in at least one of a downlink (DL) direction and an uplink (UL) direction. With CA, a UE may have multiple serving cells, and the term "serving" herein means that a UE is configured with a corresponding serving cell and may receive data from and / or transmit data to a network node on the serving cell, e.g., on either a PCell or an SCell. Data is transmitted or received via a physical channel, e.g., PDSCH in DL, PUSCH in UL, etc. A component carrier (CC) is also interchangeably referred to as a carrier or aggregated carrier, and a PCC or SCC is configured in the UE by a network node using higher layer signaling, e.g., by sending an RRC configuration message to the UE. A configured CC is used by a network node to serve a UE on the serving cell of the configured CC (e.g., on a PCell, PSCell, SCell, etc.). The configured CC is also used by the UE to perform one or more radio measurements (eg, RSRP, RSRQ, etc.) on a cell operating on the CC, eg, a PCell, SCell, or PSCell, and on neighboring cells.

[0053] In some embodiments, the UE may also operate in dual connectivity (DC) or multi-connectivity (MC). Multi-carrier or multi-carrier operation may be either CA, DC, MC, etc. The term "multi-carrier" may also be referred to interchangeably as band combining.

[0054] The term "radio measurement" as used herein may refer to any measurement performed on a radio signal. Radio measurements may be absolute or relative. Radio measurements may be, for example, intra-frequency, inter-frequency, CA, etc. Radio measurements may be unidirectional (e.g., in either direction on DL or UL, or on the sidelink) or bidirectional (e.g., RTT, Rx-Tx, etc.). Some examples of radio measurements: timing measurements (e.g., propagation delay, TOA, timing advance, RTT, RSTD, Rx-Tx, etc.), angle measurements (e.g., angle of arrival), power-based or channel quality measurements (e.g., path loss, received signal power, RSRP, received signal quality, RSRQ, SINR, SNR, interference power, total interference plus noise, RSSI, noise power, CSI, CQI, PMI, etc.), cell detection or cell identification, RLM, SI reading, etc. Measurements may be performed on one or multiple links in each direction and may be based on, for example, RSTD or relative RSRP, or on signals from different transmission points of the same (shared) cell.

[0055] The term "signaling" as used herein may include either higher layer signaling (e.g., via RRC, etc.), lower layer signaling (e.g., via physical control or broadcast channels), or a combination thereof. Signaling may be implicit or explicit. Signaling may further be unicast, multicast, or broadcast. Signaling may also be direct to another node or via a third node.

[0056] The term "time resource" as used herein may correspond to any type of physical or radio resource expressed in terms of a length of time. Examples of time resources include symbols, time slots, subframes, radio frames, TTIs, interleaving times, etc. The term "frequency resource" may refer to a subband, subcarrier, carrier frequency, frequency band within a channel bandwidth. The term "time and frequency resource" may refer to any combination of time and frequency resources.

[0057] Some examples of UE operations include UE radio measurements (see the term "radio measurements" above), two-way measurements with UE transmissions, cell detection or identification, beam detection or identification, system information reading, channel reception and decoding, any UE operation or UE activity involving at least reception of one or more radio signals and / or channels, cell change or (re)selection, beam change or (re)selection, mobility related operations, measurement related operations, radio resource management (RRM) related operations, positioning procedures, timing related procedures, timing adjustment related procedures, UE location tracking procedures, time tracking related procedures, synchronization related procedures, MDT-like procedures, measurement collection related procedures, CA related procedures, serving cell activation / deactivation, CC configuration / deconfiguration, and the like.

[0058] It should be noted that the description provided herein focuses on 3GPP cellular communication systems, and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used, however, the concepts disclosed herein are not limited to 3GPP systems.

[0059] It should be noted that in the description herein, reference may be made to the term "cell." However, it is important to note that, particularly with respect to 5G NR concepts, a beam may be used in place of a cell, and thus the concepts described herein are equally applicable to both cells and beams.

[0060] 2 illustrates an example of a wireless network 100 that may be used for wireless communication. The wireless network 100 includes wireless devices, such as UEs 110A-110B, and network nodes, such as radio access nodes 120A-120B (e.g., eNBs, gNBs, etc.), connected to one or more core network nodes 130 via an interconnection network 125. The network 100 may use any suitable deployment scenario. The UEs 110 within the coverage area 115 may each be capable of communicating directly with the radio access nodes 120 over the air interface. In some embodiments, the UEs 110 may also be capable of communicating with each other via D2D communication.

[0061] As an example, the UE 110 may communicate with the radio access node 120A over the air interface. That is, the UE 110 may transmit wireless signals to and / or receive wireless signals from the radio access node 120A. The wireless signals may include voice traffic, data traffic, control signals, and / or any other suitable information. In some embodiments, an area of ​​wireless signal coverage 115 associated with the radio access node 120 may be referred to as a cell.

[0062] Interconnection network 125 may refer to any interconnection system capable of transmitting audio, video, signals, data, messages, etc., or any combination of the foregoing. Interconnection network 125 may include all or a portion of any other suitable communications links, including a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), the Internet, a local, regional, or global communications or computer network such as a wired or wireless network, a corporate intranet, or a combination thereof.

[0063] In some embodiments, the network node 130 may be a core network node 130 that manages the establishment of communication sessions for the UE 110 and various other functions. Examples of the core network node 130 may include a mobile switching center (MSC), an MME, a serving gateway (SGW), a packet data network gateway (PGW), an operation and maintenance (O&M), an operation support system (OSS), a SON, a positioning node (e.g., an enhanced serving mobile location center (E-SMLC)), an MDT node, etc. The UE 110 may exchange some signals with the core network node using a non-access stratum layer. In non-access stratum signaling, signals between the UE 110 and the core network node 130 may be passed transparently through the radio access network. In some embodiments, the radio access node 120 may interface with one or more network nodes 130 over a node-to-node interface.

[0064] In some embodiments, the radio access node 120 may be a "distributed" radio access node in the sense that the radio access node 120 components and their associated functions may be separated into two main units (or sub-radio network nodes), sometimes referred to as a central unit (CU) and a distributed unit (DU). Different distributed radio network node architectures are possible. For example, in some architectures, the DU may be connected to the CU via a dedicated wired or wireless link (e.g., fiber optic cable), while in other architectures, the DU may be connected to the CU via a transport network. Also, how the various functions of the radio access node 120 are separated between the CU(s) and the DU(s) may vary depending on the architecture chosen.

[0065] 3 illustrates an example of signaling in wireless network 100. As shown, the wireless interface generally enables UE 110 and radio access node 120 to exchange signals and messages in both the downlink direction (from radio access node 120 to UE 110) and the uplink direction (from UE 110 to radio access node 120).

[0066] The air interface between the wireless device 110 and the radio access node 120 generally enables the UE 110 to access various applications or services provided by one or more servers 140 (also referred to as application servers or host computers) located in the external network(s) 135. The connectivity between the UE 110 and the server 140, enabled at least in part by the air interface between the UE 110 and the radio access node 120, may be described as an “over-the-top” (OTT) or “application layer” connection. In such cases, the UE 110 and the server 140 are configured to exchange data and / or signaling via an OTT connection using the radio access network 100, the core network 125, and possibly one or more intermediate networks (e.g., transport networks, not shown). The OTT connection may be transparent in the sense that participating communication devices or nodes through which the OTT connection passes (e.g., the radio access node 120, one or more core network nodes 130, etc.) may be unaware of the actual OTT connection that those communication devices or nodes enable and support. For example, the radio access node 120 may not be or need not be informed about the previous handling (e.g., routing) of an incoming downlink communication involving data originating from the server 140 to be forwarded or transmitted to the UE 110. Similarly, the radio access node 120 may not be or need not be aware of the subsequent handling of an outgoing uplink communication originating from the UE 110 and destined for the server 140.

[0067] As previously described, autonomous uplink transmission (AUL) is developed to support autonomous retransmission using configured grant (CG). To support autonomous retransmission in the uplink using configured grant, new timers may be configured to protect the HARQ procedure so that the retransmission can use the same HARQ process for the retransmission as for the initial transmission.

[0068] When a configured grant is not sent due to an LBT failure, it is assumed that the configured grant timer is not started / restarted. PDU overwriting should be avoided.

[0069] The CG timer is not started / restarted when a UL LBT fails on a PUSCH transmission for a grant received over a PDCCH addressed to the CS-RNTI that schedules a retransmission for a configured grant.

[0070] The CG timer is not started / restarted when the UL LBT fails on a PUSCH transmission for an UL grant received by a PDCCH addressed to a C-RNTI indicating the same HARQ process configured for the configured uplink grant.

[0071] Retransmission of a transport block (TB) using configured grant resources is not conventionally allowed when an initial transmission or a retransmission of the TB was previously performed using dynamically scheduled resources.

[0072] If a TB was previously transmitted for a configured grant, a new retransmission timer "CG retransmission timer" may be introduced for automatic retransmission for a configured grant (eg, timer expiration=HARQ NACK).

[0073] The new retransmission timer may be started when a TB is actually transmitted for a configured grant and stopped upon receipt of a HARQ feedback (DFI) or a dynamic grant for the HARQ process.

[0074] Legacy CG timers and behavior may be maintained to prevent configured grants from overriding TBs scheduled by dynamic grants, i.e., legacy CG timers and behavior are (re)started upon reception of the PDCCH and upon transmission on the PUSCH of the dynamic grant.

[0075] In the case of AUL, the serving gNB can also schedule a retransmission for the UE when a previous transmission using a configured grant fails.

[0076] Please note the following about configured grants:

[0077] - When the CG timer expires, the UE should stop the CGR if the CG retransmission timer (CGRT) is still running.

[0078] - upon receiving a CG activation command, stop the CG retransmission timers for the HARQ processes configured for CG.

[0079] - There is no special handling for HARQ processes shared between configured and dynamic grants (i.e. according to the licensed specification).

[0080] - HARQ process ID selection is based on UE implementation. Ongoing retransmissions for a HARQ process should be prioritized.

[0081] - For NR-U, multiple active CG configurations may be enabled, a single logical channel (LCH) may be mapped to multiple CG configurations, and multiple LCHs may be mapped to a single CG configuration.

[0082] Based on the above, the following can be observed:

[0083] - If the UE supports autonomous HARQ retransmission for a TB using a configured grant, the UE may use a CG timer (i.e., a CG retransmission timer is configured) to limit the maximum retransmission attempt for a TB using a configured grant.

[0084] A UE may be configured with multiple active CG configurations.

[0085] - The mapping relationship between LCHs and CG configurations may be one-to-many or many-to-many.

[0086] As explained above, a UE may be configured with multiple active CG configurations and an LCH may be mapped to multiple CG configurations. For each CG configuration, there may be several HARQ processes in the allocated HARQ process pool. There may also be separate CG timer and CG retransmission timer settings associated with each CG configuration. Note two potential issues that must be addressed to support multiple active CG configurations.

[0087] Question 1: Can HARQ processes be shared between two CG configurations?

[0088] Question 2: Can TB retransmissions be performed across multiple CG configurations?

[0089] For a UE with multiple active CG configurations, the above issues should be addressed to allow the CG-based transmission to function properly.

[0090] Some embodiments described herein are directed towards mechanisms for handling timers (e.g., CG timers and / or CG retransmission timers) when a UE is configured with multiple active CG configurations, and how HARQ processes should be assigned to different CG configurations.

[0091] Some embodiments are described in the context of NR unlicensed spectrum (NR-U), but are not limited to NR-U scenarios. The embodiments may also be applicable to other unlicensed operation scenarios, such as LTE LAA / eLAA / feLAA / MulteFire. The embodiments may also be applicable to licensed spectrum scenarios.

[0092] The notation "ConfiguredGrantTimer" (CGT) is used herein to denote a timer defined to control the maximum time period for retransmission attempts of a TB using a configured grant. "CGretransmissionTimer" (CGRT) is used to denote a timer for triggering UE autonomous retransmission of a TB using a configured grant. It will be appreciated that the embodiments are not limited by the timer names, which are used for illustrative purposes only.

[0093] In the first embodiment, when multiple active CG configurations are configured in a UE, each LCH may be mapped to zero, one, or multiple CG configurations.

[0094] At a CG opportunity in the CG configuration (i.e., with a configured grant), if CG resources should be used for a new transmission, the UE selects data from one or more LCHs from the set of LCHs mapped to the CG configuration to build a TB. If the CG configuration is not restricted to some LCHs, the UE can select data from any LCH to build a TB. The UE starts the CG timer and the CG retransmission timer for the associated HARQ process immediately after the TB is attempted to be transmitted at the PHY layer. The timers are set to the value(s) configured in the CG configuration.

[0095] In a second embodiment, if the UE does not receive HARQ feedback until the CG retransmission timer expires after the TB is transmitted, the UE may perform a retransmission for the TB using the configured grant. The UE may take at least one of the following options to select the configured resource for retransmission:

[0096] Option 1: The UE selects configured resources in the same CG configuration used for the initial transmission (ie, retransmissions are restricted to within the same configuration in which the initial transmission is performed).

[0097] Option 2a: The UE selects a configured resource, which belongs to the set of CG configurations that comes earliest in time and is enabled for the TB to transmit. In other words, according to the mapping relationship between the LCH and the CG configuration, the LCH multiplexed / mapped to the TB can use the configured resource.

[0098] Option 2b: The UE selects a configured resource, which comes earliest in time and belongs to any of the multiple CG configurations configured for the UE. According to the mapping relationship between the LCH and the CG configuration, there may be at least one LCH that is multiplexed into the TB and is not allowed to use the configured resource. In this case, the mapping relationship may be applicable only to the initial transmission.

[0099] Option 3: For any of the above options, the UE selects the configured resources not according to when the grant is available, instead, the UE selects the configured resources according to other conditions, such as:

[0100] - Select the resource that can achieve the highest transmission reliability, or

[0101] - Select the resource with the shortest PUSCH duration.

[0102] For the above options, the UE may select resources by considering several conditions in parallel.

[0103] For the above options, the selected resources provide a TB of the same size as the initial TB.

[0104] For the above options, the selected resource may provide a different size (smaller or larger) than the initial TB, and the UE may need to perform rate matching to accommodate the new (different) size.

[0105] For the above options, the TB can be retransmitted using the same HARQ process using the selected configured resource. The UE can select the configured resource in the CG configuration that has the same HARQ process ID configured.

[0106] For the above options, using the selected configured resources, the TB may be retransmitted using a different HARQ process. If the HARQ processes for the retransmission are different, the UE may have two alternatives for handling the retransmission.

[0107] Alternative 1: The UE can drop the current TB and trigger a higher layer retransmission.

[0108] Alternative 2: The UE can copy the TB from the first HARQ process to the second HARQ process, and then the UE drops the TB in the first HARQ process.

[0109] In the third embodiment, when the TB is attempted to be retransmitted using the selected CG resource in the CG configuration, the UE restarts the CG retransmission timer. The UE may have two options for setting the retransmission timer value.

[0110] Option 1: Set the timer value configured in the selected CG configuration for retransmission.

[0111] Option 2: Set to the timer value configured in the CG configuration used for the initial transmission of the TB.

[0112] In a fourth embodiment, when a TB is attempted to be retransmitted using a selected CG resource in the CG configuration, the UE may have two options for handling the CG timer (and may be independent of whether the LBT operation is successful or failed).

[0113] Option 1: The CG timer is kept running without updates or interruptions.

[0114] Option 2: The CG timer is restarted and set to a timer value, which is set at the selected CG setting for TB retransmission, subtracted by the elapsed time period since the initial TB transmission.

[0115] In a fifth embodiment, for a UE with multiple active CG configurations configured, each CG is configured with a separate set of HARQ processes.

[0116] In a sixth embodiment, for a UE with multiple active CG configurations configured, the UE is allowed to share the same HARQ process between the CG configurations, which may provide better configuration flexibility.

[0117] In the seventh embodiment, for a UE configured with multiple active CG configurations, the sets of CG configurations that are mapped to the same set of LCHs can share the same HARQ process. In other words, two CG configurations that are mapped to different sets of LCHs can be configured with different HARQ processes.

[0118] 4 is an example signaling diagram. An access node, such as gNB 120, may generate parameters for a control / configuration message, such as an RRC and / or MAC message (step 201). In some embodiments, the control information may include CG configuration information, including scheduling / grant parameters. The message may indicate one or more time / frequency resources available for DL ​​or UL transmission. For example, the control message may indicate the number and / or duration of slots during which resources are not available. The resources may correspond to transport blocks, resource blocks (e.g., PRBs) and / or resource block ranges.

[0119] The access node 120 sends a configured control message to the wireless device 110 (step 202). The wireless device 110 may determine the CG resource(s) according to the received control message (step 203).

[0120] The wireless device 110 may then attempt to transmit the data in accordance with the determined CG resource(s) (step 204). Following the transmission, the wireless device 110 may determine whether a retransmission is required and determine associated retransmission settings and / or parameters (step 205). The wireless device 110 may then retransmit the data in accordance with the retransmission settings (step 206).

[0121] 5 is a flowchart illustrating a method that may be implemented in a wireless device, such as the UE 110 described herein. The method may include:

[0122] Step 300: Obtaining configuration information. The configuration information may be received via a control message, such as RRC and / or MAC signaling. The control message may be received from a network node, such as the gNB 120. The configuration information may include an indication of availability of time / frequency resource(s) for UL and / or DL ​​transmission, such as scheduling / grant configuration. The wireless device may be configured with one or more CG configurations according to the obtained configuration information.

[0123] Step 310: Selecting data for transmission according to the configuration information. When a CG resource is to be used for a new transmission, the wireless device selects data for transmission (e.g., to generate a TB). The data may be selected from an LCH associated with one (or more) of the (one or more) CG configurations. The LCH may be mapped to one or more of the CG configurations.

[0124] Step 320: Transmitting data The wireless device may attempt to transmit the selected data on the resources of the corresponding CG configuration.

[0125] Step 330: Determining whether a retransmission is required.

[0126] In some embodiments, at the time of the initial transmission, the wireless device may start one or more timers, such as a CG timer and / or a CG retransmission timer described herein. The timers may be set to a value(s) according to the CG configuration used for the initial transmission.

[0127] In some embodiments, determining that a retransmission is required may be in response to expiration of a retransmission timer, which may be stopped in response to one or more of receiving HARQ feedback indicating an acknowledgment (ACK) or negative acknowledgment (NACK), receiving a grant indicating a new transmission or retransmission of the initially transmitted data, or expiration of the timer itself.

[0128] In some embodiments, if the wireless device does not receive HARQ feedback before expiration of the timer, it is determined that a retransmission is required.

[0129] The wireless device may further determine parameters / settings to use for the retransmission. This may include selecting CG resources to use for the retransmission. In some embodiments, the wireless device may select resources in the same CG setting as the initial transmission. In some embodiments, the wireless device may select resources in a different CG setting than the initial transmission. In some embodiments, the wireless device may select resources that belong to any CG setting associated with the LCH and / or the wireless device. In some embodiments, the wireless device may select the earliest time resource that belongs to the CG setting. The resources may be selected further based on other conditions described herein.

[0130] In some embodiments, the wireless device may determine a HARQ process for the retransmission. The HARQ process may be the same HARQ process as the initial transmission, or a second, different HARQ process. In some embodiments, the wireless device may be configured with a separate HARQ process for each CG configuration. In some embodiments, the wireless device may share HARQ processes between CG configurations. In some embodiments, the wireless device may share HARQ processes between CG configurations associated with the same LCH(s).

[0131] Step 340: Retransmitting the data. The wireless device may attempt to retransmit the data according to the determined retransmission CG setting.

[0132] In some embodiments, upon retransmission, the wireless device may decide to start (or re-start) one or more timers, such as a CG timer and / or a retransmission timer. In some embodiments, the timer value(s) may be set according to the CG configuration(s) used for the transmission and / or retransmission. In some embodiments, the timer value(s) may be set according to the time period between the initial transmission and the retransmission. In some embodiments, the CG timer is not updated following the retransmission, and the retransmission timer may be restarted according to the CG configuration used for the retransmission.

[0133] It will be appreciated that one or more of the above steps may be performed simultaneously and / or in different orders. Also, steps shown in dashed lines are optional and may be omitted in some embodiments.

[0134] 6 is a flowchart illustrating a method that may be implemented in a network node, such as a gNB 120, as described herein. The method may include:

[0135] Step 400: Generate a control message, which may include one or more of generating / setting / modifying / adding parameters or other information in the control message, such as an RRC and / or MAC message. The control message may include one or more CG settings for a wireless device, such as the UE 110.

[0136] Step 410: Transmit the generated control message. The control message may be transmitted to one or more wireless devices.

[0137] Step 420: The network node optionally receives a data transmission and / or a retransmission according to the configuration information. In some embodiments, the network node may receive a data retransmission from the wireless device, where a first CG configuration was used for the initial data transmission and a second CG configuration was used for the retransmission.

[0138] It will be appreciated that one or more of the above steps may be performed simultaneously and / or in different orders. Also, steps shown in dashed lines are optional and may be omitted in some embodiments.

[0139] Some embodiments described herein may enable improved configuration flexibility for handling configured resources. Some embodiments provide improved utilization of configured resources, including taking into account QoS requirements of different services that may share the same configured resource(s).

[0140] 7 is a block diagram of an exemplary wireless device, UE 110, according to some embodiments. The UE 110 includes a transceiver 510, a processor 520, and a memory 530. In some embodiments, the transceiver 510 facilitates transmitting wireless signals to and receiving wireless signals from the radio access node 120 (e.g., via a transmitter (Tx)(s), a receiver (Rx)(s) and an antenna(s)). The processor 520 executes instructions for providing some or all of the functionality described above as provided by the UE, and the memory 530 stores instructions executed by the processor 520. In some embodiments, the processor 520 and the memory 530 form a processing circuit.

[0141] The processor 520 may include any suitable combination of hardware for executing instructions and manipulating data to implement some or all of the described functions of a wireless device, such as the functions of the UE 110 described above. In some embodiments, the processor 520 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), and / or other logic.

[0142] The memory 530 is generally operable to store instructions, such as applications including one or more of computer programs, software, logic, rules, algorithms, codes, tables, etc., and / or other instructions that can be executed by the processor 520. Examples of the memory 530 include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., compact discs (CDs) or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory computer-readable and / or computer-executable memory devices that store information, data, and / or instructions that can be used by the processor 520 of the UE 110.

[0143] Other embodiments of the UE 110 may include additional components other than those shown in FIG. 7 that may be responsible for providing some aspects of the functionality of the wireless device, including any of the functionality described above and / or any additional functionality (including any functionality necessary to support the solutions described above). By way of example only, the UE 110 may include input devices and circuits, output devices, and one or more synchronization units or circuits that may be part of the processor 520. The input devices include mechanisms for the entry of data into the UE 110. For example, the input devices may include input mechanisms such as microphones, input elements, displays, etc. The output devices may include mechanisms for outputting data in audio, video, and / or hardcopy formats. For example, the output devices may include speakers, displays, etc.

[0144] In some embodiments, the wireless device UE 110 may comprise a set of modules configured to implement the functions of the wireless device described above. With reference to FIG. 8, in some embodiments, the wireless device 110 may comprise a control module 550 for receiving and interpreting control / configuration information and a transceiver module 560 for transmitting and retransmitting data transmissions according to the configuration information.

[0145] It will be appreciated that the various modules may be implemented as a combination of hardware and software, e.g., the processor, memory, and transceiver(s) of the UE 110 shown in Figure 7. Some embodiments may also include additional modules to support additional and / or optional functionality.

[0146] FIG. 9 is a block diagram of an exemplary network node, such as the radio access node 120, according to some embodiments. The network node 120 may include one or more of a transceiver 610, a processor 620, a memory 630, and a network interface 640. In some embodiments, the transceiver 610 facilitates transmitting wireless signals to and receiving wireless signals from a wireless device, such as the UE 110 (e.g., via a transmitter (Tx)(s), a receiver (Rx)(s), and an antenna(s)). The processor 620 executes instructions for providing some or all of the functionality described above as provided by the radio access node 120, and the memory 630 stores instructions executed by the processor 620. In some embodiments, the processor 620 and the memory 630 form a processing circuit. The network interface 640 may communicate signals to back-end network components, such as a gateway, a switch, a router, the Internet, a public switched telephone network (PSTN), a core network node, or a radio network controller.

[0147] The processor 620 may include any suitable combination of hardware for executing instructions and manipulating data to perform some or all of the described functions of the radio access node 120, such as those described above. In some embodiments, the processor 620 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), and / or other logic.

[0148] Memory 630 is generally operable to store instructions, such as applications including one or more of computer programs, software, logic, rules, algorithms, codes, tables, etc., and / or other instructions capable of being executed by processor 620. Examples of memory 630 include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disks), removable storage media (e.g., compact discs (CDs) or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory computer-readable and / or computer-executable memory devices that store information.

[0149] In some embodiments, network interface 640 may refer to any suitable device communicatively coupled to processor 620 and operable to receive input for node 120, send output from node 120, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the foregoing. Network interface 640 may include appropriate hardware (e.g., ports, modems, network interface cards, etc.) and software, including protocol conversion and data processing capabilities, to communicate over a network.

[0150] Other embodiments of network node 120 may include additional components other than those shown in Figure 9 that may be responsible for providing some aspects of the node's functionality, including any of the functionality described above and / or any additional functionality (including any functionality necessary to support the solutions described above). Various different types of network nodes may include components that have the same physical hardware but are configured (e.g., via programming) to support different radio access technologies, or may represent partially or completely different physical components.

[0151] Processors, interfaces, and memories similar to those described with respect to Figure 9 may be included in other network nodes (such as the UE 110, the core network node 130, etc.) that may or may not optionally include a radio interface (such as the transceiver described in Figure 9).

[0152] In some embodiments, the network node 120 may comprise a series of modules configured to implement the network node functionality described above. With reference to Figure 10, in some embodiments, the network node 120 may comprise a control module 650 for generating and transmitting control / configuration information and a transceiver module 660 for receiving data transmissions / retransmissions in accordance with the configuration information.

[0153] It will be appreciated that the various modules may be implemented as a combination of hardware and software, e.g., the processor, memory and transceiver(s) of the network node 120 shown in Figure 9. Some embodiments may also include additional modules to support additional and / or optional functionality.

[0154] 11, some network nodes in a wireless communication network 100 (e.g., UE 110, radio access node 120, core network node 130, etc.) may be partially or even fully virtualized. As a virtualized entity, some or all of the functionality of a given network node is implemented as one or more Virtual Network Functions (VNFs) running in a Virtual Machine (VM) typically hosted on a general-purpose processing node 700 (or server).

[0155] The processing node 700 generally comprises a hardware infrastructure 702 that supports a virtualization environment 704 .

[0156] The hardware infrastructure 702 generally comprises processing circuitry 706, memory 708, and communication interface(s) 710.

[0157] The processing circuitry 706 generally provides overall control of the hardware infrastructure 702 of the virtualized processing node 700. As such, the processing circuitry 706 is generally responsible for various functions of the hardware infrastructure 702, either directly or indirectly via one or more other components of the processing node 700 (e.g., sending or receiving messages via the communication interface 710). The processing circuitry 706 is also responsible for enabling, supporting, and managing the virtualized environment 704 in which the various VNFs are run. The processing circuitry 706 may include any suitable combination of hardware for enabling the hardware infrastructure 702 of the virtualized processing node 700 to perform its functions.

[0158] In some embodiments, the processing circuit 706 may comprise at least one processor 712 and at least one memory 714. Examples of the processor 712 include, but are not limited to, a central processing unit (CPU), a graphical processing unit (GPU), and other forms of processing units. Examples of the memory 714 include, but are not limited to, a random access memory (RAM) and a read-only memory (ROM). When the processing circuit 706 comprises a memory 714, the memory 714 is generally configured to store instructions or code executable by the processor 712, and possibly operational data. The processor 712 is then configured to execute the stored instructions and possibly create, transform, or otherwise manipulate data to enable the hardware infrastructure 702 of the virtualized processing node 700 to perform its functions.

[0159] Additionally or alternatively, in some embodiments, the processing circuitry 706 may comprise or further comprise one or more application specific integrated circuits (ASICs), one or more complex programmable logic devices (CPLDs), one or more field programmable gate arrays (FPGAs), or other forms of application specific and / or programmable circuitry. When the processing circuitry 706 comprises application specific and / or programmable circuitry (e.g., ASICs, FPGAs), the hardware infrastructure 702 of the virtualized processing node 700 may perform its functions without the need for instructions or code, as the necessary instructions may already be hardwired or preprogrammed into the processing circuitry 706. As can be appreciated, the processing circuitry 706 may comprise a combination of processor(s) 712, memory(s) 714, and other application specific and / or programmable circuitry.

[0160] The communication interface(s) 710 enable the virtualized processing node 700 to send messages to and receive messages from other network nodes (e.g., radio network nodes, other core network nodes, servers, etc.). In that sense, the communication interface 710 generally comprises the necessary hardware and software to process messages received from the processing circuit 706 to be sent by the virtualized processing node 700 into a format suitable for the underlying transport network, and conversely, to process messages received from other network nodes on the underlying transport network into a format suitable for the processing circuit 706. Thus, the communication interface 710 may comprise appropriate hardware (e.g., ports, modems, network interfaces, cards, etc.), such as the transport network interface(s) 716, and software, including protocol conversion and data processing capabilities, to communicate with other network nodes.

[0161] The virtualization environment 704 is enabled by instructions or code stored in memory 708 and / or memory 714. The virtualization environment 704 generally comprises a virtualization layer 718 (also referred to as a hypervisor), at least one virtual machine 720, and at least one VNF 722. The functionality of the processing node 700 may be implemented by one or more VNFs 722.

[0162] Some embodiments may be expressed as a software product stored on a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having computer-readable program code embodied in the medium). The machine-readable medium may be any suitable tangible medium, including magnetic, optical, or electrical storage media, including diskettes, compact disk read-only memory (CD-ROM), digital versatile disk read-only memory (DVD-ROM) memory devices (volatile or non-volatile), or similar storage mechanisms. The machine-readable medium may include various sets of instructions, code sequences, configuration information, or other data that, when executed, cause a processing circuit (e.g., a processor) to perform steps in a method according to one or more embodiments. Those skilled in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with the circuit to perform the described tasks.

[0163] The above described embodiments are intended to be examples only, and alterations, modifications and variations of the particular embodiments may be realized by those skilled in the art without departing from the scope of the description.

[0164] Glossary The specification may include one or more of the following abbreviations: 3GPP 3rd Generation Partnership Project ACK Acknowledgement AP Access point ARQ Automatic Repeat Request BS base station BSC Base Station Controller BSR Buffer Status Reporting BTS Base Transceiver Station CA Carrier Aggregation CC Component Carrier CCCH SDU Common Control Channel SDU CG Pre-configured Grant CGI Cell Global Identifier CN Core Network CQI Channel Quality Information CSI Channel State Information CU Central Unit DAS Distributed Antenna System DC Dual Connectivity DCCH Dedicated Control Channel DCI Downlink Control Information DL Downlink DMRS demodulation reference signal DU Distributed Unit eMBB Enhanced Mobile Broadband eNB E-UTRAN Node B or Evolved Node B ePDCCH Enhanced Physical Downlink Control Channel E-SMLC Evolved Serving Mobile Location Center E-UTRA (Extended UTRA) E-UTRAN (Extended UTRAN) FDM frequency division multiplexing HARQ Hybrid Automatic Repeat Request HO Handover IAB Wireless Access Backhaul Integrated Transmission IoT Internet of Things LCH Logical Channel LTE Long-Term Evolution M2M Machine to Machine MAC Media Access Control MBMS Multimedia Broadcast Multicast Service MCG Master Cell Group MDT Drive Test Minimization MeNB Master eNodeB MME Mobility Management Entity MSC Mobile Switching Center MSR Multi-Standard Radio MTC Machine Type Communication NACK Negative acknowledgment NDI Next Data Indicator NR new radio O&M operation and maintenance OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OSS Operation Support System PCC Primary Component Carrier P-CCPCH Primary Common Control Physical Channel PCell Primary Cell PCG Primary Cell Group PCH Paging Channel PCI Physical Cell Identification PDCCH Physical Downlink Control Channel PDCP Packet Data Convergence Protocol PDSCH Physical Downlink Shared Channel PDU Protocol Data Unit PGW Packet Gateway PHICH Physical HARQ Indication Channel PMI Precoder Matrix Indicator ProSe Proximity Services PSC Primary Serving Cell PSCell Primary SCell PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RAT Radio Access Technology RB Resource Block RF Radio Frequency RLC Radio Link Control RLM Radio Link Management RNC Radio Network Controller RRC Radio Resource Control RRH Remote Radio Head RRM Radio Resource Management RRU Remote Radio Unit RSRP reference signal received power RSRQ Reference signal reception quality RSSI Received Signal Strength Indicator RSTD reference signal time difference RTT Round Trip Time SCC Secondary Component Carrier SCell Secondary Cell SCG Secondary Cell Group SCH Synchronization Channel SDU Service Data Unit SeNB Secondary eNodeB SGW Serving Gateway SI System Information SIB System Information Block SINR Signal to Interference and Noise Ratio SNR Signal to Noise Ratio SPS Semi-persistent Scheduling SON Self-organizing Network SR Scheduling Request SRS Sounding Reference Signal SSC Secondary Serving Cell TB Transport Block TTI Transmission Time Interval Tx transmitter UE User Equipment UL Uplink URLLC Ultra-reliable low latency communication UTRA Universal Terrestrial Radio Access UTRAN Universal Terrestrial Radio Access Network V2V Vehicle-to-Vehicle V2X Vehicle-to-everything WLAN Wireless Local Area Network

Claims

1. 1. A method implemented by a wireless device, comprising: Obtaining configuration information including a plurality of configured grant (CG) configurations; selecting data from a logical channel mapped to a first CG configuration for transmission; Transmitting the selected data using the first CG setting; and initiating a retransmission timer in response to transmitting the selected data according to the first CG configuration, the retransmission timer defining a time period until the wireless device triggers a next retransmission attempt; determining that a retransmission is required; selecting a second CG configuration to use for the retransmission, the second CG configuration being different from the first CG configuration; retransmitting the selected data using the selected second CG setting; and initiating the retransmission timer in accordance with the second CG configuration in response to retransmitting the selected data; Including, The same hybrid automatic repeat request (HARQ) process is set in two or more CG configurations among the plurality of CG configurations. method.

2. The method of claim 1 , wherein the configuration information is received from a network node.

3. The method of claim 1 , wherein the logical channel is mapped to one or more of the plurality of CG configurations.

4. 2. The method of claim 1, further comprising: in response to transmitting the selected data, starting a CG timer according to the first CG configuration, the CG timer defining a maximum time period during which the wireless device may trigger an autonomous retransmission.

5. Receipt of HARQ feedback indicating an acknowledgement (ACK) or a negative acknowledgement (NACK); or receiving a grant indicating a new transmission or a retransmission of the transmitted data; 2. The method of claim 1, further comprising: stopping the retransmission timer in response to one of:

6. 2. The method of claim 1, wherein determining that a retransmission is required is in response to expiration of the retransmission timer.

7. The method of claim 1 , wherein the second CG configuration is selected according to selecting an earliest time resource that belongs to any of the plurality of CG configurations.

8. The method of claim 1 , wherein the second CG configuration is selected according to that the first CG configuration and the second CG configuration share a same HARQ process.

9. The method of claim 1 , wherein the second CG configuration is selected according to the second CG configuration providing the same transport block size as the transmitted data.

10. 5. The method of claim 4, wherein in response to retransmitting the selected data, a timer value of the CG timer is not set.

11. A wireless device comprising a wireless interface and a processing circuit, Obtaining configuration information including a plurality of configured grant (CG) configurations; selecting data from a logical channel mapped to a first CG configuration for transmission; Transmitting the selected data using the first CG setting; and initiating a retransmission timer in response to transmitting the selected data according to the first CG configuration, the retransmission timer defining a time period until the wireless device triggers a next retransmission attempt; determining that a retransmission is required; selecting a second CG configuration to use for the retransmission, the second CG configuration being different from the first CG configuration; retransmitting the selected data using the selected second CG setting; and initiating the retransmission timer in accordance with the second CG configuration in response to retransmitting the selected data; It is set to do A wireless device, wherein the same hybrid automatic repeat request (HARQ) process is set for two or more CG configurations among the plurality of CG configurations.

12. The wireless device of claim 11 , wherein the configuration information is received from a network node.

13. The wireless device of claim 11 , wherein the logical channel is mapped to one or more of the plurality of CG configurations.

14. 12. The wireless device of claim 11, further configured to, in response to transmitting the selected data, start a CG timer according to the first CG configuration, the CG timer defining a maximum period of time during which the wireless device can trigger autonomous retransmission.

15. Receipt of HARQ feedback indicating an acknowledgement (ACK) or a negative acknowledgement (NACK); or receiving a grant indicating a new transmission or a retransmission of the transmitted data; 12. The wireless device of claim 11, further configured to stop the retransmission timer in response to one of:

16. 12. The wireless device of claim 11, wherein the determining that a retransmission is required is in response to expiration of the retransmission timer.

17. The wireless device of claim 11 , wherein the second CG configuration is selected according to selecting an earliest time resource that belongs to any of the plurality of CG configurations.

18. The wireless device of claim 11 , wherein the second CG configuration is selected according to the first CG configuration and the second CG configuration sharing a same HARQ process.

19. The wireless device of claim 11 , wherein the second CG configuration is selected according to the second CG configuration providing a same transport block size as the transmitted data.

20. 15. The wireless device of claim 14, wherein in response to retransmitting the selected data, a timer value of the CG timer is not set.

Images