Patent Description:
The present disclosure generally relates to wireless communications and wireless communication networks.

Standardization bodies such as Third Generation Partnership Project (3GPP) are studying potential solutions for efficient operation of wireless communication in new radio (NR) networks. The next generation mobile wireless communication system <NUM>/NR will support a diverse set of use cases and a diverse set of deployment scenarios. The later includes deployment at both low frequencies (e.g. <NUM> of MHz), similar to LTE today, and very high frequencies (e.g. mm waves in the tens of GHz). Besides the typical mobile broadband use case, NR is being developed to also support machine type communication (MTC), ultra-low latency critical communications (URLCC), side-link device-to-device (D2D) and other use cases.

Similar to 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 UE to gNB), both DFT-spread OFDM and OFDM can be supported.

In NR, the basic scheduling unit is called a slot. A slot consists of <NUM> OFDM symbols for the normal cyclic prefix configuration. NR supports many different subcarrier spacing configurations and at a subcarrier spacing of <NUM> the OFDM symbol duration is ~<NUM>. As an example, a slot with <NUM> symbols for the same subcarrier-spacing (SCS) is <NUM> long (including cyclic prefixes).

The basic NR physical resource over an antenna port can thus be seen as a time-frequency grid as illustrated in <FIG>, where a resource block (RB) in a <NUM>-symbol slot is shown. A resource block corresponds to <NUM> contiguous subcarriers in the frequency domain. Resource blocks are numbered in the frequency domain, starting at <NUM> from one end of the system bandwidth. Each resource element corresponds to one OFDM subcarrier during one OFDM symbol interval.

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

NR is targeting access to both licensed and unlicensed bands. Allowing unlicensed networks, i.e., networks that operate in shared spectrum (or unlicensed spectrum) to effectively use the available spectrum can be an attractive approach to increase system capacity. Although unlicensed spectrum does not match the qualities of the licensed regime, solutions that allow an efficient use of it as a complement to licensed deployments have the potential to bring value to the 3GPP operators, and, ultimately, to 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 the unlicensed band as well as also different regulations. A subcarrier spacing of <NUM> or <NUM> are the most promising candidates for NR unlicensed spectrum (NR-U) OFDM numerologies for frequencies below <NUM>.

When operating in unlicensed spectrum, many regions in the world require a device to sense the medium as free before transmitting. This operation is often referred to as listen-before-talk (LBT). There are many variations of LBT depending on which radio technology the device uses and which type of data it wants to transmit at the moment. Common for all variations is that the sensing is done in a particular channel (e.g. corresponding to a defined carrier frequency) and over a predefined bandwidth. For example, in the <NUM> band, the sensing is done over <NUM> channels.

Many devices are capable of transmitting (and receiving) over a wide bandwidth including multiple sub-bands/channels, e.g., LBT sub-band (i.e., the frequency part with bandwidth equals to LBT bandwidth). A device is only allowed to transmit on the sub-bands where the medium is sensed as free. Again, there are different flavors of how the sensing should be done when multiple sub-bands are involved.

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

Listen-before-talk (LBT) is designed for unlicensed spectrum co-existence with other RATs. In the conventional mechanism, a radio device applies a clear channel assessment (CCA) check (i.e. channel sensing) before any transmission. The transmitter involves energy detection (ED) over a time period compared to a certain threshold (ED threshold) in order to determine if a channel is idle. In case the channel is determined to be occupied, the transmitter performs a random back-off within a contention window before the next CCA attempt. In order to protect the ACK transmissions, the transmitter must defer a period after each busy CCA slot prior to resuming back-off. As soon as the transmitter has grasped access to a channel, the transmitter is only allowed to perform transmission up to a maximum time duration (namely, the maximum channel occupancy time (MCOT)). For QoS differentiation, a channel access priority based on the service type has been defined. For example, there are four LBT priority classes are defined for differentiation of contention window sizes (CWS) and MCOT between services.

In NR-U, both configured scheduling and dynamic scheduling can be used.

In NR, configured scheduling is used to allocate semi-static periodic assignments or grants for a UE. For uplink, there are two types of configured scheduling schemes: Type <NUM> and Type <NUM>. For Type <NUM>, configured grants are configured via RRC signaling only. For Type <NUM>, similar configuration procedure as SPS UL in LTE was defined, i.e. some parameters are preconfigured via RRC signaling and some physical layer parameters are configured via MAC scheduling procedure. The detailed procedures are explained in 3GPP TS <NUM> V15. The configured uplink scheduling can also be used in NR unlicensed operation. For NR-U, the configured scheduling can improve the channel access probability for PUSCH transmission due to additional LBT for PDCCH transmission per UL grant is avoided and the UE can acquire channel for PUSCH transmission using a configured grant after LBT success. In this uplink transmission procedure, only single LBT procedure is needed as compared to three LBT procedures (e.g. one for SR TX, one for PDCCH for UL grant, and one for PUSCH TX) relying on the SR/BSR procedure. This can significantly improve the channel access probability for PUSCH transmission.

As described in 3GPP TR <NUM>, for both Type <NUM> and Type <NUM>, only the initial Hybrid Automatic Repeat Request (HARQ) transmission is allowed to use configured grant. A HARQ retransmission relies on dynamic grant which is indicated via PDCCH addressed to CS-RNTI.

In NR Rel-<NUM>, it is desirable to introduce feLAA Autonomous Uplink Transmission (AUL) type behavior. However, it is important to recognize that the baseline is Type1 and Type2 configured grants (CG). Some enhancements may be needed over and above this baseline to enable the desired behavior. Similar to SPS in LTE, the CG periodicity is RRC configured and is specified in the ConfiguredGrantConfig IE. Different periodicity values are supported in NR Rel-<NUM> depending on the subcarrier spacing. For example, for <NUM> and <NUM> SCS, the following periodicities are supported, expressed in a number of OFDM symbols:.

For Type1 configured grants, in addition to the periodicity, the time domain allocation of PUSCH is configured purely via RRC signaling:.

For the case of Type2 configured grants, the periodicity is configured by RRC in the same way as for Type1, but the slot offset is dynamically indicated and is given by the slot in which the UE receives the DCI that activates the Type2 configured grant. In contrast to Type1, the time domain allocation of PUSCH is indicated dynamically by DCI via the time domain resource assignment field in the same way as for scheduled (non-CG) PUSCH. This DCI field indexes a table of start symbol and length (SLIV) values. The detailed configuration details of the RRC specification (see for example 3GPP TS <NUM> v <NUM>. <NUM>) for configured grant is illustrated as below.

Autonomous Uplink Transmission (AUL) mechanisms are currently designed based on the configured scheduling scheme to support autonomous retransmission using a configured grant. To support autonomous retransmission in uplink using a configured grant, the configuration of the associated re-transmission timer(s) and HARQ process(es) need to be determined.

<CIT> discloses techniques and apparatuses for enhancing uplink grant-free transmissions and/or downlink semi-persistent scheduling (SPS) transmissions for uplink ultra-reliable low latency communications (URLLC). One technique includes receiving a first configuration for a first grant-free communication and a second configuration for at least one second grant-free communication. Grant-free communications are performed based on at least one of the first configuration or the second configuration.

<NPL>), proposes that for deprioritized MAC PDU on CG resource, the UE should be allowed to retransmit the deprioritized MAC PDU using the same HARQ process on the earliest available CG resource.

<CIT> discloses a technique for SPS transmission selection. A message received by a wireless device comprises first configuration parameters of a first SPS, and second configuration parameters of a second SPS. The wireless device receives a first downlink control information (DCI) indicating activation of the first SPS. The first SPS allocates resources in transmission time intervals (TTIs) comprising a first TTI. The wireless device receives a second DCI indicating activation of the second SPS and transmits second transport block(s), TB(s), based on the second DCI and the second configuration parameters. The wireless device receives a negative acknowledgement for a scheduled retransmission of the second TB(s) in the first TTI. The wireless device selects TB(s) for transmission in the first TTI, one of: a scheduled transmission of first TB(s) corresponding to the first SPS, or the scheduled retransmission of the second TB(s). The selected TB(s) are transmitted in the first TTI.

<NPL>), discusses procedural aspects of transmission on configured grants in unlicensed spectrum, including HARQ operation and CAPC selection.

<NPL>), proposes the following options on which actions to take if a configuredGrantTimer is running when a bandwidth part (BWP) switch is started: <NUM>) Stop the timer <NUM>) Keep the timer running <NUM>) Stop and restart the timer with the new value (if exists) <NUM>) Stop and restart the timer with the old value <NUM>) Suspend the timer during the BWP switch and resume it after the BWP switch. It is further proposed that a UE stops a transmission of repetitions when it detects a BWP switch (i.e. when the BWP is started).

<NPL>), proposes that autonomous uplink in NR-U uses the configuredGrantTimer for controlling maximum AUL retransmissions attempts for an associated HARQ process, and that the corresponding HARQ process shall not be autonomously retransmitted after the expiry of the configuredGrantTimer.

<NPL>), discloses a discussion on the following issues: terminologies, text proposal on support of HARQ feedback via DFI, coexistence handling between scheduled grant (SG) and configured grant (CG), configuration and deconfiguration of AUL with configured grant, MAC PDU overwritten, and support of multiple active CG configurations.

It is an object of the present disclosure to obviate or mitigate at least one disadvantage of the prior art.

There are provided systems and methods for determining retransmission configuration(s). According to aspects of the present disclosure, a method performed by a wireless device, a wireless device, a method performed by a network node, and a network node are provided according to the independent claims. Preferred embodiments are recited in the dependent claims.

In a first aspect there is provided a method performed by a wireless device according to claim <NUM>. In another aspect, there is provided a wireless device according to claim <NUM>.

In another aspect there is provided a method performed by a network node according to claim <NUM>. In another aspect, there is provided a network node according to claim <NUM>.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the attached Figures, wherein:.

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

In the following description, numerous specific details are set forth. However, it is understood that 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 the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In some embodiments, the non-limiting term "user equipment" (UE) is used and it can refer to any type of wireless device which can communicate with a network node and/or with another UE in a cellular or mobile or wireless communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, personal digital assistant, tablet, mobile terminal, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, ProSe UE, V2V UE, V2X UE, MTC UE, eMTC UE, FeMTC UE, UE Cat <NUM>, UE Cat M1, narrow band IoT (NB-IoT) UE, UE Cat NB <NUM>, etc. Example embodiments of a UE are described in more detail herein with respect to <FIG>.

In some embodiments, the non-limiting term "network node" is used and it can correspond to any type of radio access node (or radio network node) or any network node, which can communicate with a UE and/or with another network node in a cellular or mobile or wireless communication system. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to MCG or SCG, base station (BS), multi-standard radio (MSR) radio access node such as MSR BS, eNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, RRU, RRH, nodes 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. Example embodiments of a network node are described in more detail below with respect to <FIG>.

In some embodiments, the term "radio access technology" (RAT) refers to any RAT e.g. UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR), <NUM>, <NUM>, etc. Any of the first and the second nodes may be capable of supporting a single or multiple RATs.

The term "radio node" used herein can be used to denote a wireless device or a network node.

In some embodiments, a UE can be configured to operate in carrier aggregation (CA) implying aggregation of two or more carriers in at least one of downlink (DL) and uplink (UL) directions. With CA, a UE can have multiple serving cells, wherein the term 'serving' herein means that the UE is configured with the corresponding serving cell and may receive from and/or transmit data to the network node on the serving cell e.g. on PCell or any of the SCells. The data is transmitted or received via physical channels e.g. PDSCH in DL, PUSCH in UL, etc. A component carrier (CC) also interchangeably called as carrier or aggregated carrier, PCC or SCC is configured at the UE by the network node using higher layer signaling e.g. by sending RRC configuration message to the UE. The configured CC is used by the network node for serving the UE on the serving cell (e.g. on PCell, PSCell, SCell, etc.) of the configured CC. The configured CC is also used by the UE for performing one or more radio measurements (e.g. RSRP, RSRQ, etc.) on the cells operating on the CC, e.g. PCell, SCell or PSCell and neighboring cells.

In some embodiments, a UE can also operate in dual connectivity (DC) or multi-connectivity (MC). The multicarrier or multicarrier operation can be any of CA, DC, MC, etc. The term "multicarrier" can also be interchangeably called a band combination.

The term "radio measurement" used herein may refer to any measurement performed on radio signals. Radio measurements can be absolute or relative. Radio measurements can be e.g. intra-frequency, inter-frequency, CA, etc. Radio measurements can be unidirectional (e.g., DL or UL or in either direction on a 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. The measurement may be performed on one or more links in each direction, e.g., RSTD or relative RSRP or based on signals from different transmission points of the same (shared) cell.

The term "signaling" used herein may comprise any of: high-layer signaling (e.g., via RRC or a like), lower-layer signaling (e.g., via a physical control channel or a broadcast channel), or a combination thereof. The signaling may be implicit or explicit. The signaling may further be unicast, multicast or broadcast. The signaling may also be directly to another node or via a third node.

The term "time resource" used herein may correspond to any type of physical resource or radio resource expressed in terms of length of time. Examples of time resources include: symbol, time slot, sub-frame, radio frame, TTI, interleaving time, etc. The term "frequency resource" may refer to sub-band within a channel bandwidth, subcarrier, carrier frequency, frequency band. The term "time and frequency resources" may refer to any combination of time and frequency resources.

Some examples of UE operation include: UE radio measurement (see the term "radio measurement" above), bidirectional measurement with UE transmitting, cell detection or identification, beam detection or identification, system information reading, channel receiving and decoding, any UE operation or activity involving at least receiving of one or more radio signals and/or channels, cell change or (re)selection, beam change or (re)selection, a mobility-related operation, a measurement-related operation, a radio resource management (RRM)-related operation, a positioning procedure, a timing related procedure, a timing adjustment related procedure, UE location tracking procedure, time tracking related procedure, synchronization related procedure, MDT-like procedure, measurement collection related procedure, a CA-related procedure, serving cell activation/deactivation, CC configuration/de-configuration, etc..

Note that, in the description herein, reference may be made to the term "cell". However, particularly with respect to <NUM> NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

<FIG> illustrates an example of a wireless network <NUM> that can be used for wireless communications. Wireless network <NUM> 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 <NUM> via an interconnecting network <NUM>. The network <NUM> can use any suitable deployment scenarios. UEs <NUM> within coverage area <NUM> can each be capable of communicating directly with radio access nodes <NUM> over a wireless interface. In some embodiments, UEs <NUM> can also be capable of communicating with each other via D2D communication.

As an example, UE 110A can communicate with radio access node 120A over a wireless interface. That is, UE 110A can transmit wireless signals to and/or receive wireless signals from radio access node 120A. The wireless signals can contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage <NUM> associated with a radio access node <NUM> can be referred to as a cell.

The interconnecting network <NUM> can refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, etc., or any combination of the preceding. The interconnecting network <NUM> can include all or a portion of 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), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

In some embodiments, the network node <NUM> can be a core network node <NUM>, managing the establishment of communication sessions and other various other functionalities for UEs <NUM>. Examples of core network node <NUM> can include mobile switching center (MSC), MME, serving gateway (SGW), packet data network gateway (PGW), operation and maintenance (O&M), operations support system (OSS), SON, positioning node (e.g., Enhanced Serving Mobile Location Center, E-SMLC), MDT node, etc. UEs <NUM> can exchange certain signals with the core network node using the non-access stratum layer. In non-access stratum signaling, signals between UEs <NUM> and the core network node <NUM> can be transparently passed through the radio access network. In some embodiments, radio access nodes <NUM> can interface with one or more network nodes <NUM> over an internode interface.

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

<FIG> illustrates an example of signaling in wireless network <NUM>. As illustrated, the radio interface generally enables the UE <NUM> and the radio access node <NUM> to exchange signals and messages in both a downlink direction (from the radio access node <NUM> to the UE <NUM>) and in an uplink direction (from the UE <NUM> to the radio access node <NUM>).

The radio interface between the wireless device <NUM> and the radio access node <NUM> typically enables the UE <NUM> to access various applications or services provided by one or more servers <NUM> (also referred to as application server or host computer) located in an external network(s) <NUM>. The connectivity between the UE <NUM> and the server <NUM>, enabled at least in part by the radio interface between the UE <NUM> and the radio access node <NUM>, can be described as an "over-the-top" (OTT) or "application layer" connection. In such cases, the UE <NUM> and the server <NUM> are configured to exchange data and/or signaling via the OTT connection, using the radio access network <NUM>, the core network <NUM>, and possibly one or more intermediate networks (e.g. a transport network, not shown). The OTT connection may be transparent in the sense that the participating communication devices or nodes (e.g., the radio access node <NUM>, one or more core network nodes <NUM>, etc.) through which the OTT connection passes may be unaware of the actual OTT connection they enable and support. For example, the radio access node <NUM> may not or need not be informed about the previous handling (e.g., routing) of an incoming downlink communication with data originating from the server <NUM> to be forwarded or transmitted to the UE <NUM>. Similarly, the radio access node <NUM> may not or need not be aware of the subsequent handling of an outgoing uplink communication originating from the UE <NUM> towards the server <NUM>.

As previously discussed, Autonomous Uplink Transmission (AUL) is being developed to support autonomous retransmission using a configured grant (CG). To support autonomous retransmission in uplink using a configured grant, a new timer can be configured to protect the HARQ procedure so that the retransmission can use the same HARQ process for retransmission as for the initial transmission.

It is assumed that the configured grant timer is not started/restarted when configured grant is not transmitted due to LBT failure. PDU overwrite should be avoided.

The CG timer is not started/restarted when UL LBT fails on PUSCH transmission for grant received by PDCCH addressed to CS-RNTI scheduling retransmission for configured grant.

The CG timer is not started/restarted when the UL LBT fails on PUSCH transmission for UL grant received by PDCCH addressed to C-RNTI, which indicates the same HARQ process configured for configured uplink grant.

Retransmissions of a Transport Block (TB) using configured grant resources, when initial transmission or a retransmission of the TB was previously done using dynamically scheduled resources is conventionally not allowed.

A new retransmission timer can be introduced for automatic retransmission (e.g. timer expiry = HARQ NACK) on a configured grant for the case of the TB previously being transmitted on a configured grant, "CG retransmission timer".

The new retransmission timer is started when the TB is actually transmitted on the configured grant and stopped upon reception of HARQ feedback (DFI) or dynamic grant for the HARQ process.

The legacy CG timer and behaviour can be maintained for preventing the configured grant overriding the TB scheduled by dynamic grant, i.e. it is (re)started upon reception of the PDCCH as well as transmission on the PUSCH of dynamic grant.

For AUL, the serving gNB can also schedule retransmission for a UE when previous transmission using a configured grant fails.

Based on the above, it is observed that:.

As discussed above, a UE is configured with multiple active CG configurations and a LCH can be mapped to multiple CG configurations. For each CG configuration, there can be a number of HARQ processes in the HARQ process pool assigned. There are also a separate CG timer and CG retransmission timer setting associated with each CG configuration. Two potential issues to be addressed in order to support multiple active CG configurations are noted.

For a UE configured with multiple active CG configurations, in order to make the functions of CG based transmissions to work properly, the above issues should be addressed.

Some embodiments described herein are directed towards mechanisms for handling the timers (e.g. CG timer and/or CG retransmission timer) in the case where a UE is configured with multiple active CG configurations, and how to allocate HARQ processes to different CG configurations.

Some embodiments will be described in the context of NR unlicensed spectrum (NR-U) but are not limited to NR-U scenarios. They can also be applicable to other unlicensed operation scenarios such as LTE LAA/eLAA/feLAA/MulteFire. They can also be applicable to licensed spectrum scenarios.

The notation of "ConfiguredGrantTimer" (CGT) will be used herein to represent the timer which is defined for controlling the maximum time period for retransmission attempts of a TB using a configured grant. "CGretransmissionTimer" (CGRT) will be used to represent the timer for triggering a UE's 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 descriptive purposes only.

In a first embodiment, when a UE is configured with multiple active CG configurations, each LCH can be mapped to zero, one, or multiple CG configurations.

At a CG occasion (i.e., with a configured grant) in a CG configuration, if the CG resource is to be used for a new transmission, the UE selects data from one or more LCH from the set of LCHs which are mapped to the CG configuration to build the TB. If the CG configuration is not restricted to certain LCHs, the UE can select data from any LCHs to build the TB. The UE starts the CG timer and 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.

In a second embodiment, after the TB has been transmitted, if the UE does not receive HARQ feedback until the CG retransmission timer is expired, the UE can perform a retransmission for the TB using a configured grant. The UE may take at least one of the below options to select a configured resource for the retransmission.

Option <NUM>: The UE chooses a configured resource in the same CG configuration which is used for the initial transmission (i.e. retransmissions are restricted within the same configuration where the initial transmission is performed).

Option 2a: The UE chooses a configured resource which comes earliest in the time and belongs to a set of CG configurations which the TB is allowed to transmit. In other words, according to the mapping relation between LCHs and CG configurations, the LCHs that have been multiplexed/mapped into the TB can use the configured resource.

Option 2b: The UE chooses a configured resource which comes earliest in time and belongs to any of the multiple CG configurations which have been configured for the UE. According to the mapping relation between LCHs and CG configurations, there may be at least one LCH which has been multiplexed into the TB and is not allowed to use the configured resource. In this case, the mapping relation can be only applicable to the initial transmission.

Option <NUM>: For any of the above options, the UE chooses a configured resource not according to what time the grant becomes available, instead, the UE chooses a configured resource according to other condition, such as:.

For any above option, the UE can select the resource considering several conditions in parallel.

For any above option, the selected resource shall provide same size TB as the initial TB.

For any above option, the selected resource can provide a different size (smaller or larger) than the initial TB. The UE may need to perform rate matching to fit the new (different) size.

For any above option, using the selected configured resource, the TB may be retransmitted using a same HARQ process. The UE may choose a configured resource in a CG configuration on which the same HARQ process ID is configured.

For any above option, using the selected configured resource, the TB may be retransmitted using a different HARQ process. In case the HARQ process is different for a retransmission, the UE may have two alternatives to handle the retransmission.

Alternative <NUM>: The UE can drop the current TB and trigger an upper layer retransmission.

Alternative <NUM>: The UE can copy the TB from the first HARQ process to the second HARQ process. After that, the UE drops the TB in the first HARQ process.

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

Option <NUM>: Set to the timer value configured in the selected CG configuration for retransmission.

Option <NUM>: Set to the timer value configured in the CG configuration which was used for the initial transmission of the TB.

In a fourth embodiment, when the TB is attempted to be retransmitted using a selected CG resource in a CG configuration, the UE may have two options to handle the CG timer (may also be regardless of if the LBT operation is successful or failed).

Option <NUM>: The CG timer is kept running without any update or interruption.

Option <NUM>: The CG timer is restarted and set to the timer value, which is configured in the selected CG configuration for retransmission of the TB and subtracted by the elapsed time period since the initial TB transmission.

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

In a sixth embodiment, for a UE configured with multiple active CG configurations, the UE is allowed to share the same HARQ processes between CG configurations, which can give better configuration flexibility.

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

<FIG> is an example signaling diagram. An access node, such as gNB <NUM>, generates parameters for a control/configuration message, such as an RRC and/or a MAC message (step <NUM>). The control information includes CG configuration information including scheduling/grant parameters. The message can indicate one or more time/frequency resources available for DL or UL transmission. For example, the control message can indicate a number of slots and/or duration for which resources are not available. The resources can correspond to transport blocks, resources blocks (e.g. PRB) and/or a resource block range.

Access node <NUM> transmits the configured control message to the wireless device <NUM> (step <NUM>). Wireless device <NUM> can determine CG resource(s) in accordance with the received control message (step <NUM>).

Wireless device <NUM> can then attempt to transmit data (step <NUM>) in accordance with the determined CG resource(s). Following transmission, wireless device <NUM> determines if a re-transmission is required and determines the associated re-transmission configuration and/or parameters (step <NUM>). The wireless device <NUM> then re-transmits the data (step <NUM>) in accordance with the re-transmission configuration.

<FIG> is a flow chart illustrating a method which is performed in a wireless device, such as UE <NUM> as described herein. The method includes:.

Step <NUM>: Obtaining configuration information. The configuration information is received via a control message, such RRC and/or MAC signaling. The control message can be received from a network node, such as gNB <NUM>. The configuration information can include an indication of availability of time/frequency resource(s) for UL and/or DL transmission, such as scheduling/grant configuration. The wireless device is configured with one or more CG configurations in accordance with the obtained configuration information.

Step <NUM>: Selecting data for transmission in accordance with 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 is selected from a LCH associated with one (or more) of the CG configuration(s). The LCH is mapped to one of more of the CG configurations.

Step <NUM>: Transmitting the data. The wireless device can attempt to transmit the selected data on the resource of the corresponding CG configuration and, in response to transmitting the selected data, starts a retransmission timer in accordance with the corresponding CG configuration, wherein the retransmission timer defines a time period after which the wireless device triggers a next retransmission attempt.

Step <NUM>: Determining if retransmission is required.

Upon initial transmission, the wireless device starts more timers, such as the CG timer and the CG retransmission timer as have been described herein. The timers are set to a value(s) according to the CG configuration used for the initial transmission.

In some embodiments, determining that the retransmission is required can be in response to an expiration of the retransmission timer. The retransmission timer can be stopped in response to one or more of: receiving HARQ feedback indicating an acknowledgement (ACK) or negative acknowledgment (NACK); receiving a grant indicating a new transmission or retransmission for the initially transmitted data; or expiration of the timer itself.

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

The wireless device further determines the parameters/configuration to use for the re-transmission. This includes selecting a CG resource to use for re-transmission. In some examples, the wireless device can select a resource in the same CG configuration as the initial transmission. According to the first aspect described herein, the wireless device selects a resource in a different CG configuration as the initial transmission. In some embodiments, the wireless device can select a resource belonging to any CG configuration associated with the LCH and/or the wireless device. In some embodiments, the wireless device can select an earliest time resource belonging to a CG configuration. The resource can be selected further based on other conditions as described herein.

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

Step <NUM>: Re-transmitting the data. The wireless device can attempt to retransmit the data in accordance with the determined retransmission CG configuration.

Upon re-transmission, the wireless device restarts the retransmission timer in accordance with the determined retransmission CG configuration that is different from the CG configuration of the initial transmission. In particular, upon re-transmission, the wireless device determines to start (or restart) more timers, such as the CG timer and the retransmission timer. Further, the timer value(s) is set in accordance with the CG configuration(s) used for transmission and/or retransmission. In some embodiments, the timer value(s) can be set in accordance with a time period between the initial transmission and the re-transmission. Specfically, the CG timer is not updated following retransmission while the retransmission timer is restarted in accordance with the CG configuration used for the retransmission.

It will be appreciated that one or more of the above steps can be performed simultaneously and/or in a different order. Also, steps illustrated in dashed lines are optional and can be omitted in some embodiments.

<FIG> is a flow chart illustrating a method which is performed in a network node, such as gNB <NUM> as described herein. The method includes:.

Step <NUM>: Generate a control message. This includes one or more of generating/configuring/modifying/adding parameters or other information in a control message, such as a RRC and/or MAC message. The control message includes one or more CG configurations for a wireless device, such as UE <NUM>.

Step <NUM>: Transmit the generated control message. The control message can be transmitted to one or more wireless devices.

Step <NUM>: The network node receives a data transmissionin accordance with the configuration information. The network node receives a data retransmission from a wireless device, wherein a first CG configuration was used for an initial data transmission and a second CG configuration was used for the retransmission and wherein the first CG configuration includes a first value for setting a retransmission timer, wherein the retransmission timer defines a time period after which the wireless device triggers a next retransmission attempt, and the second CG configuration includes a second value for setting the retransmission timer.

Some embodiments described herein can allow for improved configuration flexibility for handling configured resource. Some embodiments provide for improved utilization of configured resources, including considering QoS requirements of different services that may share the same configured resource(s).

<FIG> is a block diagram of an example wireless device, UE <NUM>, in accordance with certain embodiments. UE <NUM> includes a transceiver <NUM>, processor <NUM>, and memory <NUM>. In some embodiments, the transceiver <NUM> facilitates transmitting wireless signals to and receiving wireless signals from radio access node <NUM> (e.g., via transmitter(s) (Tx), receiver(s) (Rx) and antenna(s)). The processor <NUM> executes instructions to provide some or all of the functionalities described above as being provided by UE, and the memory <NUM> stores the instructions executed by the processor <NUM>. In some embodiments, the processor <NUM> and the memory <NUM> form processing circuitry.

The processor <NUM> can include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of a wireless device, such as the functions of UE <NUM> described above. In some embodiments, the processor <NUM> 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.

The memory <NUM> is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor <NUM>. Examples of memory <NUM> include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or 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 may be used by the processor <NUM> of UE <NUM>.

Other embodiments of UE <NUM> may include additional components beyond those shown in <FIG> that may be responsible for providing certain aspects of the wireless device's functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solution described above). As just one example, UE <NUM> may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor <NUM>. Input devices include mechanisms for entry of data into UE <NUM>. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc..

In some embodiments, the wireless device UE <NUM> may comprise a series of modules configured to implement the functionalities of the wireless device described above. Referring to <FIG>, in some embodiments, the wireless device <NUM> may comprise a control module <NUM> for receiving and interpreting control/configuration information and a transceiver module <NUM> for transmitting and re-transmitting data transmissions in accordance with the configuration information.

It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory and transceiver(s) of UE <NUM> shown in <FIG>. Some embodiments may also include additional modules to support additional and/or optional functionalities.

<FIG> is a block diagram of an exemplary network node, such as radio access node <NUM>, in accordance with certain embodiments. Network node <NUM> may include one or more of a transceiver <NUM>, processor <NUM>, memory <NUM>, and network interface <NUM>. In some embodiments, the transceiver <NUM> facilitates transmitting wireless signals to and receiving wireless signals from wireless devices, such as UE <NUM> (e.g., via transmitter(s) (Tx), receiver(s) (Rx), and antenna(s)). The processor <NUM> executes instructions to provide some or all of the functionalities described above as being provided by a radio access node <NUM>, the memory <NUM> stores the instructions executed by the processor <NUM>. In some embodiments, the processor <NUM> and the memory <NUM> form processing circuitry. The network interface <NUM> can communicate signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers, etc..

The processor <NUM> can include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of radio access node <NUM>, such as those described above. In some embodiments, the processor <NUM> 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.

The memory <NUM> is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor <NUM>. Examples of memory <NUM> include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

In some embodiments, the network interface <NUM> is communicatively coupled to the processor <NUM> and may refer to any suitable device operable to receive input for node <NUM>, send output from node <NUM>, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface <NUM> may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of network node <NUM> can include additional components beyond those shown in <FIG> that may be responsible for providing certain aspects of the node's functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

Processors, interfaces, and memory similar to those described with respect to <FIG> may be included in other network nodes (such as UE <NUM>, core network node <NUM>, etc.). Other network nodes may optionally include or not include a wireless interface (such as the transceiver described in <FIG>).

In some embodiments, the network node <NUM>, may comprise a series of modules configured to implement the functionalities of the network node described above. Referring to <FIG>, in some embodiments, the network node <NUM> can comprise a control module <NUM> for generating and transmitting control/configuration information and a transceiver module <NUM> for receiving data transmissions/re-transmissions in accordance with the configuration information.

It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory and transceiver(s) of network node <NUM> shown in <FIG>. Some embodiments may also include additional modules to support additional and/or optional functionalities.

Turning now to <FIG>, some network nodes (e.g. UEs <NUM>, radio access nodes <NUM>, core network nodes <NUM>, etc.) in the wireless communication network <NUM> may be partially or even entirely virtualized. As a virtualized entity, some or all the functions of a given network node are implemented as one or more virtual network functions (VNFs) running in virtual machines (VMs) hosted on a typically generic processing node <NUM> (or server).

Processing node <NUM> generally comprises a hardware infrastructure <NUM> supporting a virtualization environment <NUM>.

The hardware infrastructure <NUM> generally comprises processing circuitry <NUM>, a memory <NUM>, and communication interface(s) <NUM>.

Processing circuitry <NUM> typically provides overall control of the hardware infrastructure <NUM> of the virtualized processing node <NUM>. Hence, processing circuitry <NUM> is generally responsible for the various functions of the hardware infrastructure <NUM> either directly or indirectly via one or more other components of the processing node <NUM> (e.g. sending or receiving messages via the communication interface <NUM>). The processing circuitry <NUM> is also responsible for enabling, supporting and managing the virtualization environment <NUM> in which the various VNFs are run. The processing circuitry <NUM> may include any suitable combination of hardware to enable the hardware infrastructure <NUM> of the virtualized processing node <NUM> to perform its functions.

In some embodiments, the processing circuitry <NUM> may comprise at least one processor <NUM> and at least one memory <NUM>. Examples of processor <NUM> include, but are not limited to, a central processing unit (CPU), a graphical processing unit (GPU), and other forms of processing unit. Examples of memory <NUM> include, but are not limited to, Random Access Memory (RAM) and Read Only Memory (ROM). When processing circuitry <NUM> comprises memory <NUM>, memory <NUM> is generally configured to store instructions or codes executable by processor <NUM>, and possibly operational data. Processor <NUM> is then configured to execute the stored instructions and possibly create, transform, or otherwise manipulate data to enable the hardware infrastructure <NUM> of the virtualized processing node <NUM> to perform its functions.

Additionally, or alternatively, in some embodiments, the processing circuity <NUM> may comprise, or further comprise, one or more application-specific integrated circuits (ASICs), one or more complex programmable logic device (CPLDs), one or more field-programmable gate arrays (FPGAs), or other forms of application-specific and/or programmable circuitry. When the processing circuitry <NUM> comprises application-specific and/or programmable circuitry (e.g., ASICs, FPGAs), the hardware infrastructure <NUM> of the virtualized processing node <NUM> may perform its functions without the need for instructions or codes as the necessary instructions may already be hardwired or preprogrammed into processing circuitry <NUM>. Understandably, processing circuitry <NUM> may comprise a combination of processor(s) <NUM>, memory(ies) <NUM>, and other application-specific and/or programmable circuitry.

The communication interface(s) <NUM> enable the virtualized processing node <NUM> 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 <NUM> generally comprises the necessary hardware and software to process messages received from the processing circuitry <NUM> to be sent by the virtualized processing node <NUM> into a format appropriate for the underlying transport network and, conversely, to process messages received from other network nodes over the underlying transport network into a format appropriate for the processing circuitry <NUM>. Hence, communication interface <NUM> may comprise appropriate hardware, such as transport network interface(s) <NUM> (e.g., port, modem, network interface card, etc.), and software, including protocol conversion and data processing capabilities, to communicate with other network nodes.

The virtualization environment <NUM> is enabled by instructions or codes stored on memory <NUM> and/or memory <NUM>. The virtualization environment <NUM> generally comprises a virtualization layer <NUM> (also referred to as a hypervisor), at least one virtual machine <NUM>, and at least one VNF <NUM>. The functions of the processing node <NUM> may be implemented by one or more VNFs <NUM>.

Some embodiments may be represented as a software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause processing circuitry (e.g. a processor) to perform steps in a method according to one or more embodiments. Those of ordinary skill 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 circuitry to perform the described tasks.

The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the appended claims.

Claim 1:
A method performed by a wireless device (<NUM>), comprising:
obtaining (<NUM>) configuration information including a plurality of configured granted, CG, configurations;
selecting (<NUM>) data from a logical channel mapped to a first CG configuration for transmission;
transmitting (<NUM>) the selected data using the first CG configuration and, in response to transmitting the selected data, starting a retransmission timer in accordance with the first CG configuration, wherein the retransmission timer defines a time period after which the wireless device triggers a next retransmission attempt;
determining (<NUM>) that a retransmission is required;
selecting a second CG configuration to use for the retransmission, the second CG configuration being different than the first CG configuration;
in response to retransmitting the data, restarting the retransmission timer in accordance with the second CG configuration; and
retransmitting (<NUM>) the data using the selected second CG configuration.