GB2605445A

GB2605445A - Apparatus, methods, and computer programs

Info

Publication number: GB2605445A
Application number: GB2104735.2A
Authority: GB
Inventors: Deghel Matha; Saliya Jayasinghe Laddu Keeth
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2021-04-01
Filing date: 2021-04-01
Publication date: 2022-10-05
Also published as: GB202104735D0

Abstract

A terminal (e.g. user equipment, UE) is configured with a sequence of redundancy version values (RVs) for redundantly transmitting uplink (UL) data over a physical uplink shared channel (PUSCH), the sequence comprising a first redundancy version value and a second redundancy version value succeeding the first redundancy version value in the sequence. The terminal associates redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, selects a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting the data on the first uplink path, and redundantly transmits the data over the second uplink path using the selected transmission occasion. The terminal may redundantly transmit the data by separately applying the sequence over each of the first and second uplink paths, or by applying the sequence across both the uplink paths. The terminal may be configured with the sequence of redundancy version values using radio resource control (RRC) signalling.

Description

APPARATUS, METHODS, AND COMPUTER PROGRAMS

Field

[0001]The present disclosure relates to apparatus, methods, and computer programs, and in particular but not exclusively to apparatus, methods and computer programs for terminals and network apparatuses.

Background

[0002]A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, access nodes and/or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and/or content data and so on. Content may be multicast or uni-cast to communication devices.

[0003]A user can access the communication system by means of an appropriate communication device or terminal. A communication device of a user is often referred to as user equipment (UE) or user device. The communication device may access a carrier provided by an access node and transmit and/or receive communications on the carrier.

[0004]The communication system and associated devices typically operate in accordance with a required standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and/or parameters which shall be used for the connection are also typically defined. One example of a communications system is UTRAN (30 radio). Another example of an architecture that is known is the long-term evolution (LIE) or the Universal Mobile Telecommunications System (UMTS) radio-access technology. Another example communication system is so called 50 system that allows user equipment (UE) or user device to contact a 50 core via e.g. new radio (NR) access technology or via other access technology such as Untrusted access to 5GC or wireline access technology.

Summary

[0005]According to a first aspect, there is provided an apparatus for a terminal, the apparatus comprising: at least one processor; and at least one memory comprising code that, when executed by the at least one processor, causes the apparatus to: configure the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associate redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; select a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmit said data over the second uplink path using the selected transmission occasion. [0006]The apparatus may be caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0007]The apparatus may be caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0008]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence.

[0009]The apparatus may be further caused to receive configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.

[0010]The apparatus may be caused to select the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.

[0011]The apparatus may be caused to use a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path.

[0012]The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.

[0013]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0014]According to a second aspect, there is provided an apparatus for a network apparatus, the apparatus comprising: at least one processor; and at least one memory comprising code that, when executed by the at least one processor, causes the apparatus to: configure a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; provide at least one uplink path of a first uplink path and a second uplink path from the terminal; select a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receive the data on the at least one uplink path using said selected transmission occasion.

[0015]Configuring the terminal with the sequence of redundancy version values may be performed using Radio Resource Control signalling.

[0016]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0017]According to a third aspect, there is provided an apparatus for a terminal, the apparatus comprising: configuring means for configuring the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associating means for associating redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; selecting means for selecting a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and transmitting means for redundantly transmitting said data over the second uplink path using the selected transmission occasion.

[0018]The transmitting means may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0019]The transmitting means may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0020]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence.

[0021]The apparatus may comprise receiving means for receiving configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.

[0022]The apparatus may comprise selecting means for selecting the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.

[0023]The apparatus may comprise using means for using a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path.

[0024]The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.

[0025]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0026]According to a fourth aspect, there is provided an apparatus for a network apparatus, the apparatus comprising: configuring means for configuring a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; providing means for providing at least one uplink path of a first uplink path and a second uplink path from the terminal; selecting means for selecting a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receiving means for receiving the data on the at least one uplink path using said selected transmission occasion.

[0027]Configuring the terminal with the sequence of redundancy version values may be performed using Radio Resource Control signalling.

[0028]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0029]According to a fifth aspect, there is provided a method for an apparatus for a terminal, the apparatus, the method comprising: configuring the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; for associating redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; selecting a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmitting said data over the second uplink path using the selected transmission occasion.

[0030]The transmitting may comprise redundantly transmitting said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0031]The transmitting may comprise redundantly transmitting said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0032]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence.

[0033]The method may comprise receiving configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.

[0034]The method may comprise selecting the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.

[0035]The method may comprise using a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path.

[0036]The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.

[0037]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0038]According to a sixth aspect, there is provided a method for an apparatus for a network apparatus, the method comprising: configuring a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; providing at least one uplink path of a first uplink path and a second uplink path from the terminal; selecting a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receiving the data on the at least one uplink path using said selected transmission occasion.

[0039]Configuring the terminal with the sequence of redundancy version values may be performed using Radio Resource Control signalling.

[0040]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0041]According to a seventh aspect, there is provided an apparatus for a terminal, the apparatus comprising: configuring circuitry for configuring the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associating circuitry for associating redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; selecting circuitry for selecting a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and transmitting circuitry for redundantly transmitting said data over the second uplink path using the selected transmission occasion.

[0042]The transmitting circuitry may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0043]The transmitting circuitry may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0044]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence.

[0045]The apparatus may comprise receiving means for receiving configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.

[0046]The apparatus may comprise selecting circuitry for selecting the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.

[0047]The apparatus may comprise using circuitry for using a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path.

[0048]The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.

[0049]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0050]According to an eighth aspect, there is provided an apparatus for a network apparatus, the apparatus comprising: configuring circuitry for configuring a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; providing circuitry for providing at least one uplink path of a first uplink path and a second uplink path from the terminal; selecting circuitry for selecting a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receiving circuitry for receiving the data on the at least one uplink path using said selected transmission occasion. [0051]Configuring the terminal with the sequence of redundancy version values may be performed using Radio Resource Control signalling.

[0052]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0053]According to a ninth aspect, there is provided non-transitory computer readable medium comprising program instructions for causing an apparatus for a terminal to perform at least the following: configure the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associate redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; select a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmit said data over the second uplink path using the selected transmission occasion.

[0054]The apparatus may be caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0055]The apparatus may be caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0056]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence.

[0057]The apparatus may be further caused to receive configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.

[0058]The apparatus may be caused to select the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.

[0059]The apparatus may be caused to use a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path. [0060]The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.

[0061]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0062]According to a tenth aspect, non-transitory computer readable medium comprising program instructions for causing an apparatus for a network appartus to perform at least the following: configure a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; provide at least one uplink path of a first uplink path and a second uplink path from the terminal; select a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receive the data on the at least one uplink path using said selected transmission occasion.

[0063]Configuring the terminal with the sequence of redundancy version values may be performed using Radio Resource Control signalling.

[0064]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator.

[0065]According to an eleventh aspect, there is provided a computer program comprising program instructions for causing a computer to perform any method as described above.

[0066]According to a twelfth aspect, there is provided a computer program product stored on a medium that may cause an apparatus to perform any method as described herein.

[0067]According to a thirteenth aspect, there is provided an electronic device that may comprise apparatus as described herein.

[0068]According to a fourteenth aspect, there is provided a chipset that may comprise an apparatus as described herein.

Brief description of Figures

[0069]Examples will now be described, by way of example only, with reference to the accompanying Figures in which: [0070]Figure 1 shows a schematic representation of a 5G system; [0071]Figure 2 shows a schematic representation of a network apparatus; [0072]Figure 3 shows a schematic representation of a user equipment; [0073] Figure 4 shows a schematic representation of a non-volatile memory medium storing instructions which when executed by a processor allow a processor to perform one or more of the steps of the methods of some examples; [0074] Figures 5A and 5B illustrate transmission occasions; [0075] Figures 6 and 7 are flowcharts illustrating potential operations performed by a terminal; [0076] Figure 8 illustrates transmission occasions according to a particular example; [0077] Figure 9 is a flowchart illustrating potential operations performed by a terminal; [0078] Figure 10 illustrates transmission occasions according to a particular example; [0079] Figures 11 and 12 are flowcharts illustrating potential operations performed by apparatuses described herein.

Detailed description

[0080] I n the following, certain aspects are explained with reference to mobile communication devices capable of communication via a wireless cellular system and mobile communication systems serving such mobile communication devices. For brevity and clarity, the following describes such aspects with reference to a 5G wireless communication system. However, it is understood that such aspects are not limited to 5G wireless communication systems, and may, for example, be applied to other wireless communication systems with analogous components (for example, current 6G proposals).

[0081]Before explaining in detail the exemplifying embodiments, certain general principles of a 5G wireless communication system are briefly explained with reference to Figure 1.

[0082] Figure 1 shows a schematic representation of a 5G system (5GS) 100. The 5GS may comprise a user equipment (UE) 102 (which may also be referred to as a communication device or a terminal), a 5G access network (AN) (which may be a 5G Radio Access Network (RAN) or any other type of 5G AN such as a Non-3GPP lnterworking Function (N3IWF) /a Trusted Non3GPP Gateway Function (TNGF) for Untrusted / Trusted Non-3GPP access or Wireline Access Gateway Function (W-AGF) for Wireline access) 104, a 5G core (5GC) 106, one or more application functions (AF) 108 and one or more data networks (DN) 110.

[0083]The 50 RAN may comprise one or more gNodeB (gNB) distributed unit functions connected to one or more gNodeB (gNB) unit functions. The RAN may comprise one or more access nodes.

[0084]The 5GC 106 may comprise one or more Access Management Functions (AMF) 112, one or more Session Management Funcctions (SMF) 114, one or more authentication server functions (AUSF) 116, one or more unified data management (UDM) functions 118, one or more user plane functions (UPF) 120, one or more unified data repository (UDR) functions 122, one or more network repository functions (NRF) 128, and/or one or more network exposure functions (NEF) 124. Although NRF 128 is not depicted with its interfaces, it is understood that this is for clarity reasons and that NRF 128 may have a plurality of interfaces with other network functions.

[0085]The 50C 106 also comprises a network data analytics function (NWDAF) 126. The NWDAF is responsible for providing network analytics information upon request from one or more network functions or apparatus within the network. Network functions can also subscribe to the NWDAF 126 to receive information therefrom. Accordingly, the NWDAF 126 is also configured to receive and store network information from one or more network functions or apparatus within the network. The data collection by the NWDAF 126 may be performed based on at least one subscription to the events provided by the at least one network function.

[0086]3GPP refers to a group of organizations that develop and release different standardized communication protocols. They are currently developing and publishing documents related to Release 16, relating to 50 technology, with Release 17 currently being scheduled for 2022.

[0087]Precoding is a technique that exploits transmit diversity by weighting the information stream. In particular, the transmitter sends coded information to the receiver to achieve pre-knowledge of the channel. This considerably reduces the feedback overhead. This technique may reduce the corrupted effect of the communication channel. According to current 30PP specifications, a UE may be configured in two different modes for Physical Uplink Shared Channel (PUSCH) multi-antenna precoding, namely codebook-based transmission and non-codebook-based transmission.

[0088]For codebook-based transmission in 30PP, the access point provides a UE with a transmit precoding matrix indication in the DCI, which the UE uses the indication to select a PUSCH transmit precoder from the codebook.

[0089]As a particular example, for codebook-based dynamic grant Physical Uplink Shared Channel (PUSCH), the UE determines an SRI (Sounding Reference Signal (SRS) resource indicator) and the Transmit Precoding-Matrix Indicator (TPMI) information (via Precoding information and number of layers) from their corresponding fields in a Downlink Control Information (DCI) signal received by the UE from the network. A Sounding Reference Signal is a signal transmitted on the uplink for allowing the network to estimate the quality of the channel at different frequencies. The SRI therefore may provide uplink beam information for the SRS, and the TPMI provides uplink precoder information.

[0090]For non-codebook-based dynamic grant PUSCH, in contrast to codebookbased mode, the UE determines its precoder and transmission rank based on downlink measurements. However, the UE selection of a precoder (and the number of layers) for each scheduled PUSCH may be modified by the network. This may be modified by the network when multiple SRS resources are configured. The modification may be performed by omitting some columns from the precoder that the UE has selected. This latter step is done by indicating, via an SRI contained in DCI scheduling the PUSCH, a subset of the configured SRS resources.

[0091]Although the above refers to dynamic grants, a network may provide a UE with grants for making uplink transmissions in at least two different ways: configured grants (CO) and dynamic grants (DG).

[0092]Configured grants are grants that are configured in a UE in advance of when they are needed by Radio Resource Control (RRC) signalling (although, as indicated below, they may be activated dynamically). A type of configured grant in LTE is a Semi-Persistent Scheduling (SPS) grant. In contrast, dynamic grants are provided to a UE in real time in a DCI.

[0093] Configured grants in 30PP specifications are labelled as Type 1 and Type 2. When Type 1 is configured or when Type 2 is configured and activated by the network, the UE can autonomously start transmitting uplink data according to the configured periodicity and radio resources.

[0094]Configured grant Type 1 is an uplink grant that is provided by the Radio Resource Control (RRC) level, and stored at the UE as a configured uplink grant. Therefore, Type 1 CO UL is only based on (and released by) the UE's Radio Resource Control (RRC) configuration without any Layer 1 signaling from the network. In other words, once configured, the network does not need to transmit to activate the use of the configured resources.

[0095] Configured grant Type 2 is an uplink grant where the RRC signaling defines some of the transmission/resource parameters such as the periodicity of the configured uplink grant, and a Physical Downlink Control Channel (PDCCH) can either signal and activate the configured uplink grant or deactivate it. Therefore, Type 2 CO UL is based on both RRC configuration and Layer 1 signaling. In other words, the network activates use of the Type 2 configured grants subsequent to the UE being configured.

[0096] In Release 15, only a single configured grant configuration can be active at a time in a Bandwidth part, where a Bandwidth Part (BWP) is a contiguous set of physical resource blocks (PRBs) on a given carrier.

[0097] In Release 16, it has been agreed to support multiple active configured grant configurations at the same time. In particular, the support of up to 12 active configured grant configurations is currently agreed, with separate RRC configuration, activation and deactivation being supported (e.g. both Type 1 and Type 2 configured grants will be supported). Support of joint release for multiple configured grants using a single Downlink Control Information (DCI) signal has also been agreed. Further, it has been agreed that the transmission of a transport block based on the configured grant is associated with a single active configuration, even if the transmission is repeated. [0098]This support of multiple active configured grant configurations has been agreed in response to two main factors. Firstly, the use of multiple configurations being supported simultaneously allows for support of multiple services or traffic types. Secondly, the use of multiple configurations being supported simultaneously may reduce transmission alignment delay and increase reliability.

[0099]According to some 3GPP specifications, a network may be configured to not transmit explicit acknowledgements/negative acknowledgements to a UE with the aim of saving signalling resources in a network. As a result of this, the concept of repetition is used, where a UE repeats an uplink transmission in order to allow the data to be more likely to be received by the network.

[0100]There are currently 2 types of Physical Uplink Shared Channel repetition defined in 3GPP specifications: Type A (which was introduced in Release 15) and Type B (which was introduced in Release 16).

[0101]For Type A repetition, PUSCH repetition via slot aggregation was supported in a semi-static way such that there is no repetition within a slot, and with aggregation (i.e. repetition) factor of 2, 4 or 8. This repetition operation is also referred to as slot-based repetition.

[0102] PUSCH Type A transmissions and receptions may be omitted in certain cases. For example, for PUSCH repetition Type A, a PUSCH transmission in a slot of a multi-slot PUSCH transmission is omitted according to the conditions in the communication protocol (e.g. Clause 9, Clause 11.1 and Clause 11.2A of 3GPP Technical Specification 38.213).

[0103] For Type B repetition, cross-slot-boundary and cross-downlink-symbols scheduling are allowed in order to reduce latency without sacrificing reliability. This is also referred to as a multi-segment transmission. In essence, for Type B repetition, a transmission of a transport block can be performed over multiple (adjacent) transmission slots. In contrast, Type A has a fixed allocation within slots and a transport block is not transmitted across multiple transmission slots. The related Release 16 objective for Type B repetition was to allow specification of PUSCH enhancements for both dynamic-grant based PUSCH and configured-grant based PUSCH and to, for a transport block, allow one dynamic uplink grant and/or one configured grant to schedule two or more PUSCH repetitions in one slot or across a slot boundary in consecutive available slots.

[0104] PUSCH Type B transmissions and receptions may be omitted in certain cases. For example, for PUSCH repetition Type B, an actual repetition with a single symbol is omitted except for the case of when the length of each nominal repetition equals 1 (see more below). In addition, an actual repetition is omitted according to the conditions in the operating communication protocol (e.g. see Clause 9, Clause 11.1 and Clause 11.2A of 3GPP Technical Specification 38.213).

[0105]Further, for PUSCH repetition Type B carrying semi-persistent CSI report(s) without a corresponding Physical Downlink Control Channel (PDCCH) after being activated on PUSCH by a CSI request field on a DCI, if the first nominal repetition is not the same as the first actual repetition, the first nominal repetition is omitted; otherwise, the first nominal repetition is omitted according to the conditions in the operating communication protocol (e.g. see Clause 9, Clause 11.1 and Clause 11.2A of 3GPP Technical Specification 38.213).

[0106]For PUSCH repetition Type B, when a data transmission may be repeated may be determined, at least in part, using a time domain resource assignment (TDRA) field in the DCI or the TDRA parameter in a configured grant, which indicates the resource for the first "nominal" repetition. A "nominal" repetition relates to at least one transmission opportunity, although it is understood that no transmission may occur when no uplink data has been received by the transmitter in advance of this nominal repetition. In particular, a time resource allocation is defined by S (starting symbol), L is the length of each nominal repetition, and K symbolizes the number of nominal repetitions. The TDRA field in the DCI may indicate one of the entries in a TDRA table in order to define/provide these values.

[0107]One nominal repetition may be segmented into one or more actual repetitions around semi-static downlink symbols and dynamically indicated / semi-statically configured invalid uplink symbols and/or at the slot boundary. For dynamic grant, the actual repetitions are transmitted and there should not be conflict between the transmitted symbols and the dynamic downlink/flexible symbols (indicated by dynamic Slot Format Indicator (SFI) in the DCI).

[0108]For configured grant, whether the actual repetition of the uplink transmission is transmitted or not follows the principles outlined in Release 15. In particular, the uplink repetition is not transmitted if it conflicts with any dynamic downlink/flexible symbols. Moreover, the uplink repetition is not transmitted if it conflicts with any semi-static flexible symbol if dynamic SFI is configured but not received.

[0109]The uplink configured-grant resource(s) can, for example, define a bundle of one or more PUSCH transmission occasions that repeats in time based on some periodicity determined by the configured grant configuration. When a transmission occasion in a bundle is used, it is referred to as a repetition (or transmission). Transmitting the transport block on a resource associated with a configured grant configuration may comprise transmitting a set of repetitions that each use a transmission occasion in the bundle and comprise the transport block. The set may comprise one or more repetition.

[0110]. Another parameter impacting a PUSCH transmission/repetition is the redundancy version (RV). A redundancy version defines the starting position of a circular buffer from which coded bits are selected to transmit from. There may be, for example, four different starting points, and the initial starting point is indicated to the UE in order to decode the coded bits. In current 30PP specifications, there are 4 different redundancy versions defined, which are labelled as RVO, RV1, RV2, and RV3. For dynamic-grant PUSCH with repetition Type B, the RV for the first repetition is provided by the Downlink Control Information, and then RV is cycled across the actual repetitions following the sequence of {0,2,3,1}.

[0111]The higher layer parameter repK-RV defines the redundancy version sequence (a.k.a. the RV pattern) to be applied to the repetition transmissions. There are currently 4 redundancy versions defined (labelled as RVO, RV1, RV2 and RV3, as discussed above) and these may be applied in predefined sequences.

[0112]New Radio introduced a non-uniform separation of Redundancy Versions (RVs) compared to LTE, where New Radio RVs did not always start at 0, 25%, 50%, 75% (unlike RVO -RV3 in LTE). Instead, in New Radio, the RV starting points depend on the low density parity check (LDPC) base graph and are defined as below, Starting position of different redundancy versions, k, Where, Nth is defined to dimension the circular buffer size for a code block, and Zc is the used sub-metric dimension of the LDPC encoding.

[0113]It is understood that the following can be achieved based on the Releasel 5 New Radio LDPC design.

[0114]First, Redundancy Versions RVO and RV3 are self-decodable (with RVO being better than RV3 as a result of it having lower latency) compared to RV2 and RV1. This may be achieved even at higher code rates (above 0.9). Therefore, RVO is commonly 664 _ z, 504 _ LOPC graph 1 base LDPC b graph 2 [5 6W, 664 _ [25N,,, 504 _ used to indicate an initial/start transmission of the series of redundant transmissions/repetitions.

[0115]Redundancy Version sequence {0,3,0,31 therefore provides more selfdecodable Redundancy Versions than Redundancy Version sequence {0,2,3,1}, while having IR (incremental redundancy) gain over Redundancy Version sequence {0,0,0,0}. The decoding can start whenever the received PUSCH transmission occasion is associated with the Redundancy Version is 0 or 3.

[0116] Self-decodability of a signal means you can decode that signal independently (i.e. without always relaying on combining mechanisms). Having a better selfdecodability allows decoding as soon as the Redundancy Version(s) are received compared to waiting for remaining Redundancy Version reception, which is beneficial for latency reduction.

[0117]Second, Redundancy Version sequence {0, 2, 3, 1} may achieve the best performance when all Redundancy Versions are soft combined at the receiver. For any Redundancy Version sequence (and especially for {0,2,3,1} as it relies mainly on soft combining), if the decoding waits for multiple Redundancy Versions to be received, the performance gains are at the cost of latency.

[0118]Third, Redundancy Version sequence {0, 0, 0, 0} does not providing any IR gain but support similar latency advantages as {0, 3, 0, 31.

[0119]Based on this information on RV values and RV sequences, the following considers Transport Block repetition for uplink transmissions of both Types A and B PUSCH repetition with a configured grant. This is currently defined for a single Transmission-Reception point in 3GPP TS 38.214.

[0120] First, Type A repetition is considered.

[0121] In this case, when the RV sequence parameter repK-RV is not provided in the related R RC configuration (i.e. configuredGrantConfig), and cg-Retransmission Timer is not provided, the redundancy version for uplink transmissions with a configured grant is set to 0. When the RV sequence parameter repK-RV is provided in the configuredGrantConfig and cg-Retransmission Timer is not provided, for the nth transmission occasion among K repetitions, n=1, 2, ..., K, the transmission occasion is associated with (mod(n-1,4)+1)th value in the configured RV sequence. When a configured grant configuration is configured with startingFromRVO set to 'off', the initial transmission of a transport block may only start at the first transmission occasion of the K repetitions. Otherwise, the initial transmission of a transport block may start at: the first transmission occasion of the K repetitions when the configured RV sequence is {0,2,3,1}, any of the transmission occasions of the K repetitions that are associated with RV=0 when the configured RV sequence is {0,3,0,3}, or any of the transmission occasions of the K repetitions when the configured RV sequence is {0,0,0,0}, except the last transmission occasion when Ka8.

[0122]Second, Type B repetition is considered with reference to nominal repetitions and actual repetitions. A nominal repetition may be considered to be a defined set of transmission resources and/or parameters that are usable for a transmission, while an actual transmission may be considered to be a used portion of the nominal transmission during which a repetition and/or transmission is performed. The actual time domain resources may therefore be smaller than the nominal durations, and may comprise more than one actual repetition (depending on the invalid symbols between uplink transmission resources).

[0123]For PUSCH transmissions with a Type 1 or Type 2 configured grant, the nominal repetitions and the actual repetitions are determined according to the procedures for PUSCH repetition Type B (e.g. defined in 3GPP TS 38.214). In this case, the higher-layer configured RV sequence parameter repK-RV defines the redundancy version pattern to be applied to the repetitions. When repK-RV is not provided in the configuredGrantConfig, the redundancy version for each actual repetition with a configured grant is set to 0. Otherwise, for the nth transmission occasion among all the actual repetitions (including the actual repetitions that are omitted) of the K nominal repetitions, the transmission occasion is associated with (mod(n-1,4)+1)th value in the configured RV sequence. Additionally, when a configured grant configuration is configured with startingFromRVO set to 'off', the initial transmission of a transport block may only start at the first transmission occasion of the actual repetitions. Otherwise, the initial transmission of a transport block may start at the first transmission occasion of the actual repetitions if the configured RV sequence is {0,2,3,1}, any of the transmission occasions of the actual repetitions that are associated with RV=0 if the configured RV sequence is {0,3,0,3}, any of the transmission occasions of the actual repetitions if the configured RV sequence is 10,0,0,01, except the actual repetitions within the last nominal repetition when 1<8.

[0124]The above described mechanisms all relate to the case in which redundant/repeated transmissions are provided upstream to a single Transmission-Reception Point (TRP). However, multi-TRP deployment may be applied in Release 17. One of the key objectives for the development for this new release is to identify and specify features to improve reliability and robustness for channels other than Physical Downlink Shared Channel (PDSCH) using multi-TRP and/or multiple-antenna panel, with Re1.16 reliability features as the baseline. These other channels may be, for example, the Physical Downlink Control Channel (PDCCH), the Physical Uplink Shared Channel (PUSCH), and the Physical Uplink Control Channel (PUCCH). [0125]As can be seen from the following agreements, the support for multi-TRP PUSCH repetition operation in future 3GPP releases has been agreed. Under such an operation, a transport block is repeated (e.g. in a Time Division Multiplexed manner) towards different TRPs. In such a case, up to two SRIs may be indicated.

[0126]It should be noted that although SRI is predominantly referred to in the following, SRI is merely one parameter for distinguishing between multiple/different uplink paths, and that the presently described mechanisms may be applied to other uplink paths and their metrics. For example, an SRI may also refer to an uplink beam, an uplink Transmission Configuration Indicator (TCI) state, joint ICI state, spatial filter, etc. [0127]Several agreements have already been reached in 3GPP discussion groups in relation to Multi-TRP PUSCH reliability enhancement. For example, it has been agreed that Time Division Multiplexed PUSCH repetition scheme(s) based on Re1-16 PUSCH repetition Type A and Type B will be supported. PUSCH transmission without repetition as a potential candidate Multi-TRP was for future study.

[0128]A further agreement relating to single DCI based Multi-TRP PUSCH repetition schemes is that it will support codebook based PUSCH transmission with following enhancements.

[0129]First, the Multi-TRP scheme will support the indication of two SRIs to indicate two different uplink paths. This may be effected by modifying/enhancing the SRI field.

Alternatively, the SRI field may be left alone (i.e. new changes) but with the indication being provided in another way.

[0130]Second, the Multi-TRP scheme will support the indication of two Transmit Precoding-Matrix Indicator (TPMIs) for the different uplink paths. In this case, the same number of layers may be applied for both TPMIs if two TPMIs are indicated, with the number of SRS ports between two TRPs being the same. It is for future study how these two TPMIs will be indicated (e.g. one TPMI field or two TPMI fields in the DCI). [0131]Third, the maximum number of SRS resource sets may be increased to two. The configuration details of each SRS resource set (e.g., number of SRS resources in a resource set) to a UE is for future study.

[0132]Another agreement for single DCI-based M-TRP PUSCH repetition Type B supports the following RV mapping. In this mapping, the DCI indicates the first RV for the first PUSCH actual repetition, and the RV pattern (0 2 3 1) is applied separately to PUSCH actual repetitions of different TRPs with a possibility of configuring an RV offset for the starting RV for the first actual repetition towards the second TRP.

[0133]Another agreement for single DCI based M-TRP PUSCH repetition Type B supports using at least nominal repetitions to map beams. How exactly this is to be performed is for future study.

[0134]For Dynamic Grant single DCI based Multi-TRP PUSCH repetition Type B, the DCI indicates the first RV for the first PUSCH actual repetition, and the RV pattern (0 2 3 1) is applied separately to PUSCH actual repetitions of different TRPs with a possibility of configuring an RV offset for the starting RV for the first actual repetition towards the second TRP.

[0135]However, the above operation, which is defined for Dynamic Grant, cannot be adopted for the Configured Grant case as it uses the DCI to schedule the Multi-TRP PUSCH repetition scheme while such a DCI is not provided for the Configured Grant PUSCH scheme.

[0136]As explained above, in the existing configured-grant PUSCH operation, which was conceived for the single TRP case, the initial transmission of a transport block can start only at a certain transmission occasion(s) with a given redundancy version value (namely, value 0). Depending on the redundancy version sequence(s) (i.e. pattern(s)), this can result in discarding PUSCH repetitions/opportunities, leading to reduced diversity and potential impact on the PUSCH reliability. On the other hand, redundancy version sequences with only one or two 0 values have better incremental redundancy gain compared to when the sequence consists of only 0 values.

[0137] This is exacerbated for the multi-TRP case and Frequency Range 2 (FR2 -a frequency range defined by 50 specifications), which, as illustrated above, is likely to become a bigger issue in future 3GPP releases. This is because in these cases, in addition to having some PUSCH repetitions discarded, the link towards a TRP may be blocked. To ensure enough opportunities for the configured-grant PUSCH repetitions under such scenarios, the operation related to redundancy version sequence(s)/value and where the initial transmission of a transport block can start should be carefully designed.

[0138]This is illustrated with respect to Figures 5A and 5B.

[0139]Figure 5A shows a configured grant configuration having a Redundancy Version (RV) sequency {0,3,0,3) and an offset of 0. In this Figure, RVO is shown as lined while RV3 is shown as spotted. The arrows above each transmission occasion indicates an SRI for that transmission occasion, where the same direction indicates the same SRI. Initially a first RVO PUSCH transmission occasion is available on (or associated to) SRI 0 (i.e. on uplink beam 0) before a PUSCH RVO transmission occasion is available on (or associated to) SRI 1 (i.e. on uplink beam 1). Subsequently, an RV3 PUSCH transmission occasion is available on (or associated with) SRI 0, before a PUSCH RV3transmission occasion is available on (or associated to) SRI 1. A transport block is received from the Medium Access Control (MAC) layer for transmission on the uplink at a time instant such that the repeated transmission of this transport block cannot start on a PUSCH transmission occasion before the second occasion.

[0140] In this case, based on the existing RV related operation defined for a single TRP (e.g. SRI / uplink beam) and discussed above, the PUSCH transmission occasion with RV3 and SRI 0 cannot be used as PUSCH repetition if there hasn't already been a PUSCH repetition with RVO transmitted towards the same TRP (i.e. using the same SRI / uplink beam). Therefore the third PUSCH occasion, which is with RV3 and is associated with SRI 0, cannot be used as PUSCH repetition since there hasn't been a PUSCH repetition with RVO transmitted with SRI 0. Instead, the repetition was on SRI 1, and so the PUSCH repetition occurs on the second RV3 transmission occasion. Consequently, only the second and fourth PUSCH transmission occasions may be used as PUSCH repetitions (denoted PUSCH Rep#0 and Rep#1, respectively, in the figure) for the transport block repetition/transmission operation.

[0141]Figure 5B illustrates another example problem.

[0142]Figure 5B shows a configured grant configuration having a Redundancy Version (RV) sequency {0,3,0,3) and an offset of 0. In this Figure, RVO is shown as lined while RV3 is shown as spotted. The arrows above each transmission occasion indicates an SRI for that transmission occasion, where the same direction indicates the same SRI. Initially a first RVO PUSCH transmission occasion is available on (or associated to) SRI 0 (i.e. on uplink beam 0) before a first RV3 PUSCH transmission occasion is available on SRI 1 (i.e. on uplink beam 1). Subsequently, an RV3 PUSCH transmission occasion is available on SRI 0, before a PUSCH RVO PUSCH transmission occasion is available on (or associated to) SRI 1. A transport block is received from the MAC layer for transmission on the uplink at a time instant such that the repeated transmission of this transport block cannot start on a PUSCH transmission occasion before the second occasion.

[0143] In this case, based on the existing RV related operation defined for a single TRP (e.g. a single SRI / uplink beam) and discussed above, a PUSCH occasion with RV3 cannot be used as PUSCH repetition if there hasn't been a PUSCH repetition transmitted with RVO towards the same TRP (e.g. using the same SRI / uplink beam). Therefore, the third PUSCH occasion, which is with RV3 and is associated with SRI 0, cannot be used as PUSCH repetition since there hasn't been a PUSCH repetition with RVO transmitted with SRI 0. Similarly, the second PUSCH occasion, which is with RV3 and associated with SRI 1, cannot be used as PUSCH repetition since there hasn't been a PUSCH repetition with RVO transmitted using SRI 1. Consequently, only the last/fourth PUSCH transmission occasion may be used as PUSCH repetition (denoted PUSCH Rep#0 in the figure) for the transport block repetition/transmission operation.

[0144]Based on this, the following focuses on how to design and enhance the operation related to redundancy version sequence(s)/value for the multi-TRP configured grant PUSCH repetition operation -in such a way to have more PUSCH occasions that can be used as PUSCH repetitions.

[0145]The following considers two options for the use of redundancy version (RV) sequence(s) under multi-TRP configured grant PUSCH repetition operation.

[0146] In the first option (i.e. Option 1), it is assumed that for the multi-TRP configured grant PUSCH repetition operation, one redundancy version sequence is configured (and indicated) and applied separately for PUSCH repetitions using two different SRIs (or, equivalently, towards different TRPs). This option may also include configuring an offset for the starting redundancy version corresponding to the second SRI (or, equivalently, second TRP).

[0147] In the second option (i.e. Option 2), a single redundancy version sequence is configured and applied across two (different) SRIs (or, equivalently, TRPs).

[0148] In both of these options, rules are provided that allow the UE to determine available PUSCH transmission occasions depending on RV sequence/values for multi-TRP configured-grant PUSCH repetition operation, in such a way to create more available occasions and thus allowing more PUSCH repetitions.

[0149] In particular, for multi-TRP configured grant PUSCH repetition, the operation related to RV sequence(s) is defined based on a specific configuration and/or indication. The specific configuration and/or indication may be based on at least one of the following ways.

[0150]For both of the described option, for the multi-TRP configured grant PUSCH repetition of a transport block where two SRIs are provided, at least one of the following mechanisms may be configured for the UE.

[0151]As a first example, a PUSCH transmission occasion with a first RV value can be used as a first PUSCH repetition using one SRI (or, equivalently, towards one TRP) when an earlier PUSCH repetition with a second RV value is transmitted using the other SRI (or, equivalently, towards the other TRP) where the second RV value is precedent to the first RV value in configured RV sequence (i.e. pattern).

[0152]The first RV value may be derived based on RV sequence and the configured RV offset for starting RV corresponding to the one SRI.

[0153]The first RV value(s) may contain more than one value which also include RVO. [0154]For the next/remaining at least one PUSCH transmission occasion corresponding to the one SRI, if any, considering that there has been a first PUSCH repetition using this SRI, the UE may be allowed to use these PUSCH transmission occasions for PUSCH repetitions regardless of the corresponding RV value(s). As another example, an (additional) condition or rule may be defined when a PUSCH transmission occasion from these occasions is with a first preconfigured RV value (e.g. RV 1) (of the configured RV sequence), this occasion can be used as a PUSCH repetition using the SRI when an earlier PUSCH repetition with a second preconfigured RV value or with any RV value is transmitted using the same SRI. [0155]As a second example, which may be used alternatively or additionally to the first example, a PUSCH transmission occasion with a first RV value may be used as a first PUSCH repetition using one SRI (or, equivalently, towards one TRP) when a PUSCH repetition with a second RV value will be transmitted using the other SRI (or, equivalently, towards the other TRP) and/or using the same SRI (or, equivalently, towards the same TRP) where the second RV value is precedent to the first RV value in configured RV sequence.

[0156]At least one (additional) condition or rule may be defined. For example, the PUSCH occasion corresponding to the one SRI may be immediately before the PUSCH repetition with the second RV value that will be transmitted using the other SRI. If not, the proposed operation/rule may not be applicable. In an example, the PUSCH occasion corresponding to the one SRI should be at most a (configured) number of PUSCH occasions/repetitions from the PUSCH repetition with the second RV value that will be transmitted using the other SRI. If not, the proposed operation/rule may not be applicable.

[0157]For the next/remaining at least one PUSCH transmission occasion corresponding to the one SRI, if any, considering that there has been a first PUSCH repetition using this SRI, the UE may be allowed to use these PUSCH transmission occasions for PUSCH repetitions regardless of the corresponding RV value(s).

[0158]Another condition or rule may be defined as follows. When a PUSCH transmission occasion from these occasions is with a preconfigured RV value (e.g. RV 1), this occasion can be used as a PUSCH repetition using the one SRI if an earlier PUSCH repetition with a preconfigured RV value or with any RV value is transmitted using the same SRI. The first RV value may have similar variants as those listed under the Case 1 above.

[0159]The above proposed operations may be configured via RRC per configured-grant configuration or per group of configured-grant configurations.

[0160]The DCI (such as the activation DCI used for activating a configured-grant configuration), Medium Access Control Control Element, or even RRC may be used to e.g. enable/disable the proposed operations.

[0161]When the mechanism is enabled, the proposed operation/rule above may be applicable.

[0162]When the mechanism is disabled, only a PUSCH transmission occasion with RV 0 can be used as a first PUSCH repetition using one SRI (or, equivalently, towards one TRP), regardless of whether or which PUSCH repetitions (and their corresponding RV values) are transmitted using the other SRI (or, equivalently, towards the other TRP).

[0163]Under the second option, for the multi-TRP configured grant PUSCH repetition of a transport block, the following rule may be defined/configured for the UE. Legacy operation related to redundancy version may be used across the two (different) SRIs or TRPs. As a specific example, only a PUSCH transmission occasion with RV 0 can be used as a first PUSCH repetition. The UE then uses the remaining PUSCH transmission occasions as PUSCH repetitions considering the configured RV sequence and SRI/beam mapping.

[0164]The proposed operation may be applied for both PUSCH repetition Type A and Type B. For PUSCH repetition Type B, the term 'repetition' should be replaced by 'actual repetition' as the redundancy version sequence is applied on the actual repetitions (which are obtained after segmentation of nominal PUSCH repetitions, if any).

[0165]The proposed operations may be applied on the PUSCH repetitions considering/including the repetitions that are omitted/cancelled. Alternatively, the proposed operations may be applied on the PUSCH repetitions without considering/including the repetitions that are omitted/cancelled. Further, the RV mapping may account for the omitted/cancelled PUSCH repetitions. Alternatively, the RV mapping may be done without considering the omitted/cancelled PUSCH repetitions.

[0166]A PUSCH transmission occasion with RV 0 may always be used as a PUSCH repetition (including a first PUSCH repetition) using any SRI (or, equivalently, towards any TRP).

[0167]It is understood that although the term "SRI" is used throughout, a similar mechanism may be applied when the SRI is swapped with a reference to an uplink beam, an uplink TCI state, joint ICI state, common TO state, spatial filter, spatial relation information, a Transmission-Reception Point link, etc. [0168]The UE may be configured or indicated to start the multi-TRP configured-grant PUSCH repetition operation with a certain SRI (or, equivalently, towards a certain TRP).

[0169]Figure 6 illustrates example features of a UE performing at least one of the mechanisms described herein, and particularly with reference to "Option 1" identified above.

[0170]At 601, the UE is configured for uplink transmissions.

[0171]At least part of this configuration may be for multi-TRP configured grant PUSCH repetition operation. In this case, one RV sequence may be configured and applied separately for PUSCH repetitions using two different SRls. The configuration may comprise at least one RV related rule. The configuration may cause the UE to, for a next/remaining at least one PUSCH transmission occasion corresponding to an SRI, if there has been a first PUSCH repetition using this SRI, then the UE is allowed to use these PUSCH transmission occasions for PUSCH repetitions.

[0172]At 602, the UE determines to apply multi-TRP PUSCH repetition for a transport block where two SRIs are configured and/or indicated.

[0173]At 603, the UE determines an earliest PUSCH transmission condition with RV 0 where a transport block can be transmitted, regardless of its corresponding SRI; the corresponding SRI is referred to as 'the other' SRI, and the remaining SRI is referred to as 'the one' SRI. This PUSCH transmission occasion is designated (and used) as a first PUSCH repetition.

[0174]At 604, the UE determines whether there is a next PUSCH transmission occasion corresponding to 'the other' SRI.

[0175] If the determination of 604 is in the positive, the UE proceeds to 605. At 605, the UE uses this PUSCH transmission occasion and the remaining PUSCH transmission occasions corresponding to 'the other' SRI as PUSCH repetitions. [0176] If the determination of 604 is in the negative, the UE proceeds to 606. At 606, the UE determines whether the RV of this PUSCH transmission occasion matches with the configuration rule related to RV.

[0177] If the determination to 606 is in the positive, the UE proceeds to 607. At 607, the UE uses this PUSCH transmission occasion and the remaining PUSCH transmission occasions corresponding to 'the one' SRI as PUSCH repetitions.

[0178] If the determination to 606 is in the negative, the UE returns to 604. [0179]Figure 7 is a flowchart illustrating potential operations of the UE that may be performed. This may be performed in relation to Option 1, described above.

[0180]At 701 the UE is configured.

[0181]The UE may be configured with one RV sequence for multi-TRP configured grant PUSCH repetition operation. The RV sequence may be configured and applied separately for PUSCH repetitions using two different SRls.

[0182]The UE may be configured with a PUSCH transmission occasion with any RV value that can be used as a first PUSCH repetition using one SRI if an earlier PUSCH when an earlier PUSCJ repetition with RV 0 is transmitted using the other SRI.

[0183]The UE may be configured to, for the next/remaining at least one PUSCH transmission occasion corresponding to the one SRI, when there has been a first PUSCH repetition using this SRI, the UE may be allowed to use these PUSCH transmission occasions for PUSCH repetitions.

[0184]At 702, the UE determines to apply a multi-TRP PUSCH repetition for a transport block where two SRIs are configured and/or indicated.

[0185] At 703, the UE determines an earliest USCH transmission occasion with RV 0, regardless of its corresponding SRI (i.e. the other SRI), where the transport block can be transmitted; the corresponding SRI is referred to as the other' SRI, and the remaining SRI is referred to as 'the one' SRI. The UE may use this determined PUSCH transmission occasion as a first PUSCH repetition.

[0186] At 704, the determines whether the next PUSCH transmission corresponds to the other SRI.

[0187] If 704 is determined in the negative, the UE proceeds to 705. At 705, the UE uses this PUSCH transmission occasion as PUSCH repetition using 'the one' SRI. [0188] It 704 is determined in the positive, the UE proceeds to 706. At 706, the UE uses this PUSCH transmission occasion as a first PUSCH repetition using this 'other' SRI.

[0189] Regardless of whether the UE proceeds to 705 or 706, the also UE returns to 704.

[0190] Figure 8 illustrates an example of the proposed operation for the multi-TRP configured grant PUSCH repetition (Type A) for the case in which the configured grant configuration is configured with four PUSCH transmission occasions. In other words, in the present case, the maximum number of PUSCH repetitions is four. In addition, in this example, the RV sequence {0,3,0,3} is configured and applied separately for PUSCH repetitions using two different SRls. Also, offset 0 is configured for the starting redundancy version corresponding to the second SRI (i.e. SRI 1). The UE may also be configured such that a PUSCH transmission occasion with any RV value can be used as a first PUSCH repetition using one SRI when an earlier PUSCH repetition with a RV value 0 is transmitted using the other SRI. In addition, for the next/remaining at least one PUSCH transmission occasion corresponding to the one SRI, if any, when there has been a first PUSCH repetition using this SRI, the UE is allowed to use these PUSCH transmission occasions for PUSCH repetitions.

[0191]In this example of Figure 8, RVO is shown as lined while RV3 is shown as spotted. The arrows above each transmission occasion indicates an SRI for that transmission occasion, where the same direction indicates the same SRI. In addition, the first and third PUSCH occasions are associated with SRI 0 and the second and fourth PUSCH occasions are associated with SRI 1. Based on the configured RV sequence (and offset), where this sequence is applied separately for each SRI, the first and third PUSCH occasions are associated/mapped to RVO and RV3, respectively. And the second and fourth PUSCH occasions are associated/mapped to RVO and RV3, respectively.

[0192]Consequently, Figure 8 shows that, with a transport block arriving from the UE between the first and second RVO PUSCH transmission occasions, the first PUSCH transmission occasion cannot be used for the transmission/repetition of the Transport Block. Since the second PUSCH occasion is with RV 0, then the UE may use this occasion and the next occasion(s) which are mapped to the same SRI (i.e. SRI 1) as PUSCH repetitions. This corresponds to PUSCH Rep#0 and PUSCH Rep#2 in the figure.

[0193]Moreover, although the third PUSCH occasion is with RV 3 and corresponds to an SRI for which there has not yet been a PUSCH repetition transmitted yet, based on the configured operation at the UE, the third transmission occasion can also be used as a (first) PUSCH repetition using SRI 0 since there has been a PUSCH repetition with RV 0 transmitted using the other SRI (i.e. SRI 1). This corresponds to PUSCH Rep#1 in the figure.

[0194]Figure 9 is a flow chart illustrating example operations for the UE. This flow chart may also apply in respect of Option 1, discussed above.

[0195]At 901, the UE is configured for multi-TRP configured grant PUSCH repetition operation.

[0196]The configuration may comprise an RV sequence that is configured and applied separately for PUSCH repetitions using two different SRls.

[0197]The UE may be configured so that a PUSCH transmission occasion with RV 3 can be used as a first PUSCH repetition using one SRI when a PUSCH repetition with RV 0 will be transmitted using the other SRI.

[0198]The PUSCH occasion corresponding to the one SRI may be immediately before the PUSCH with RV 0 that will be transmitted using the other SRI. Otherwise, this operation is not applied.

[0199]For the next/remaining at least one PUSCH transmission occasion corresponding to any SRI when there has been a first PUSCH repetition using this SRI, the UE is allowed to use these PUSCH transmission occasions for PUSCH repetitions.

[0200]At 902, the UE determines to apply multi-TRP PUSCH repetition for a transport block, where two SRIs are configured and/or indicated.

[0201]At 903, the UE determines the earliest PUSCH transmission occasion with RV 0, regardless of its corresponding SRI where the transport block may be transmitted. [0202]At 904, the UE determines whether this PUSCH transmission occasion corresponding to one SRI is with RV3 and whether the PUSCH repetition with RVO will be transmitted using the other SRI immediately in the next PUSCH occasion. [0203]When both of the questions of 904 are determined in the affirmative, the UE moves to 905.

[0204]At 905, the UE determines that this PUSCH transmission may be used as a first PUSCH repetition using the one SRI.

[0205]At 906, the UE determines that the next PUSCH transmission occasion may be used as a first PUSCH repetition using the other SRI.

[0206]At 907, the UE determines that the remaining PUSCH transmission occasions (if any) can be used as PUSCH repetitions, regardless of the corresponding SRI. [0207]When at least one of the questions of 904 is determined in the negative, the UE moves to 908.

[0208]At 908, the UE determines if this PUSCH transmission occasion is with RV 0. [0209]When the determination of 908 is in the affirmative, the UE proceeds to 909. [0210]At 909, the UE determines that this PUSCH transmission occasion is used as a first PUSCH repetition using the one SRI.

[0211]At 910, the UE determines that the configured rules cannot be applied anymore. [0212]At 911, the UE uses any remaining PUSCH transmission occasions corresponding to the one SRI as PUSCH repetitions.

[0213]When the determination of 908 is in the negative, the UE proceeds to 912. [0214]At 912, the UE determines to skip this PUSCH transmission occasion.

[0215]At 913, the UE determines to consider the next PUSCH transmission occasion, and returns to 904 to do so.

[0216]Figure 10 illustrates an example of the proposed operation for the multi-TRP configured grant PUSCH repetition where PUSCH repetition Type B. This example relates to a configured grant configuration with an RV sequence of {0,3,2,1} and offset 0. Note that, instead of {0,3,2,1}, the RV sequence {0,2,3,1} may also be used here. [0217] In Figure 10, RVO is shown as lined, RV2 is white and RV3 is shown as spotted. The arrows above each transmission occasion indicates an SRI for that transmission occasion, where the same direction indicates the same SRI. Figure 10 shows that a transport block is received from the MAC during a first RVO that is configured for SRI 0.

[0218]The represented PUSCH occasions (aka repetitions, for which the UE has not yet decided whether they can be used for a transport block transmission/repetition) correspond to actual PUSCH repetitions. In other words, what is shown is the result of segmentation of nominal PUSCH repetitions. As seen in Figure 10, there may be up to five actual PUSCH repetitions that can be transmitted, depending (at least partially) on when the transport block arrives for transmittal. The first two PUSCH occasions / actual repetitions (representing two PUSCH occasions for which the UE has not yet determined whether they can be used for transmitting data) are associated with SRI 0 and the last three actual repetitions (representing three PUSCH occasions, for which the UE has not yet determined whether they can be used for transmitting data) are associated with SRI 1. Based on the configured RV sequence (and offset), where this sequence is applied separately for each SRI, the first and second actual repetitions / transmission occasions are associated with RVO and RV3, respectively. And the third, fourth and fifth actual repetitions / transmission occasions are associated with RVO, RV3, RV2, respectively.

[0219]Further, in this example, the following rule/operation relating to redundancy version is configured: A PUSCH transmission occasion with an RV value different than 0 can be used as a first PUSCH repetition using one SRI if a PUSCH repetition with a redundancy version value 0 will be transmitted using the other SRI in the next PUSCH transmission occasion.

[0220]Therefore, as can be seen in Figure 10, with this transport block/data arrival time, the first PUSCH transmission occasion cannot be used for the transmission of the transport block. Further, although the second PUSCH occasion is with RV 3 and corresponds to an SRI for which there hasn't yet been a PUSCH repetition transmitted, based on the configured operation/rule mentioned above, the second transmission occasion can be used as a first PUSCH repetition using SRI 0 since there will be a PUSCH repetition with RV 0 transmitted using the other SRI (i.e. SRI 1) in the next transmission opportunity. Hence, based on all the above, the transport block is transmitted/repeated on the second, the third, the fourth and the fifth actual repetitions. This is shown as Rep#0, Rep#1, Rep#2, and Rep#3 in the Figure 10.

[0221]For the case with a given total number of PUSCH repetitions and where a fixed/configured number of PUSCH repetitions cannot be achieved using one SRI and/or using the other SRI, the UE may be configured to skip (e.g. not transmit on) the corresponding PUSCH repetitions/occasions. For example, if the total number of PUSCH repetitions is greater than or equal to 8, and depending on a scenario in which the UE would only have the last two PUSCH transmission occasions available, the UE may be configured to skip these repetitions/occasions -and potentially wait until next available bundle of PUSCH transmission occasions if possible/feasible.

[0222]By using various rules/conditions for the operation related to redundancy version sequence(s)/value for the multi-TRP configured grant PUSCH repetition scheme/operation, the present mechanisms provide for increased diversity (especially the spatial diversity) and flexibility by making more PUSCH occasions available for multi-TRP configured grant PUSCH repetition. This is valuable for ensuring the reliability (and latency) requirements for critical services, especially in FR2.

[0223]Figures 11 and 12 are flowcharts illustrating potential operations that may be performed be apparatuses performing at least part of the above-described examples. [0224]In the following, a starting transmission occasion for making a redundant transmission (e.g. transmitting a repetition) is selected for a second uplink path in dependence on a transmission occasion used for a redundant transmission on a first uplink path. This selected transmission occasion allows for reduced latency and wasted resources relative to currently known mechanisms for selecting such transmission occasions. The previous examples (e.g. of Figures 6 to 10) are more specific examples of how the following mechanism may be implemented in different situations.

[0225]Figure 11 relates to operations that may be performed by an apparatus for a terminal.

[0226]At 1101, the apparatus configures the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel. The sequence comprises a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence.

[0227]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence. For example, the second redundancy value may immediately succeed the first redundancy value in the sequence.

[0228]The sequence may comprise a redundancy version value designated as being an initial value. This initial value may be determined in dependence on an offset from a defined start point, and/or in dependence on an operating communication protocol. The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions. For example, the first redundancy version value may correspond to the redundancy version value designated as being an initial value, where the designation is determined in dependence on signalling received from a network apparatus (including a signalled offset).

[0229]The configuring of the sequence may be performed in dependence on receipt of signalling received from a network apparatus. This signalling may be Radio Resource Control signalling.

[0230]At 1102, the apparatus associates redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path. The transmission occasions are configured occasions during which redundant transmissions are allowed to be made. It is understood that the terminal may transmit on none of these transmission occasions, at least one of these transmission occasions, and/or all of these transmission occasions, in dependence on what data the terminal has to transmit at any particular instance.

[0231]At 1103, the apparatus selects a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path.

[0232]The data may be a transport block. The transport block may be received from a Medium Access Control layer of the terminal.

[0233]The apparatus may select the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path. The first offset may be received from the network apparatus via RRC signalling.

[0234]At 1104, the apparatus redundantly transmits said data over the second uplink path using the selected transmission occasion.

[0235]The apparatus may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.

[0236]The apparatus may redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.

[0237]The apparatus may use a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path. The second offset may be signalled to the apparatus from the network apparatus using RRC signalling. [0238]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator. The first uplink path may correspond to a first uplink beam and the second uplink path may correspond to a second uplink beam. The other examples of uplink paths mentioned above may also be used as first uplink paths and second uplink paths.

[0239]The first uplink path may be to the network apparatus. The second uplink path may be to the network apparatus. The first and second uplink paths may be to the network apparatus. At least one of the first and second uplink paths may be to different network apparatuses.

[0240]Figure 12 is a flow chart illustrating potential operations that may be performed by an apparatus for a network apparatus. The network apparatus may be a radio access network network apparatus, such as an access point. The network apparatus may interact with the terminal of Figure 11.

[0241]At 1201, the apparatus configures a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel. The sequence comprises a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence.

[0242]The first redundancy version value may be immediately adjacent the second redundancy version value in the sequence. For example, the second redundancy value may immediately succeed the first redundancy value in the sequence.

[0243]The sequence may comprise a redundancy version value designated as being an initial value. This initial value may be determined in dependence on an offset from a defined start point, and/or in dependence on an operating communication protocol. The first redundancy version value may be an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions. For example, the first redundancy version value may correspond to the redundancy version value designated as being an initial value, where the designation is determined in dependence on signalling transmitted by the network apparatus (including a signalled offset).

[0244]The configuring of the sequence may be performed by transmitting signalling from the network apparatus. This signalling may be Radio Resource Control signalling. [0245]At 1202, the apparatus provides at least one uplink path of a first uplink path and a second uplink path from the terminal. For example, the apparatus may provide configured resources for at least one of the first uplink path and the second uplink path from the terminal.

[0246]At 1203, the apparatus selects a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path. The transmission occasions are configured occasions during which redundant transmissions are allowed to be made.

[0247]At 1204, the apparatus receives the data on the at least one uplink path using said selected transmission occasion. The received data may be a transport block.

[0248]The first uplink path may be associated with a first sounding reference signal resource indicator and the second uplink path may be associated with a second sounding reference signal resource indicator. The first uplink path may correspond to a first uplink beam and the second uplink path may correspond to a second uplink beam. The other examples of uplink paths mentioned above may also be used as first uplink paths and second uplink paths.

[0249]The first uplink path may be to the network apparatus. The second uplink path may be to the network apparatus. The first and second uplink paths may be to the network apparatus. At least one of the first and second uplink paths may be to different network apparatuses.

[0250] Figure 2 shows an example of a control apparatus for a communication system, for example to be coupled to and/or for controlling a station of an access system, such as a RAN node, e.g. a base station, gNB, a central unit of a cloud architecture or a node of a core network such as an MME or S-GW, a scheduling entity such as a spectrum management entity, or a server or host, for example an apparatus hosting an NRF, NWDAF, AMF, SMF, UDM/UDR etc. The control apparatus may be integrated with or external to a node or module of a core network or RAN. In some embodiments, base stations comprise a separate control apparatus unit or module. In other embodiments, the control apparatus can be another network element such as a radio network controller or a spectrum controller. The control apparatus 200 can be arranged to provide control on communications in the service area of the system. The apparatus 200 comprises at least one memory 201, at least one data processing unit 202, 203 and an input/output interface 204. Via the interface the control apparatus can be coupled to a receiver and a transmitter of the apparatus. The receiver and/or the transmitter may be implemented as a radio front end or a remote radio head. For example the control apparatus 200 or processor 201 can be configured to execute an appropriate software code to provide the control functions.

[0251] A possible wireless communication device will now be described in more detail with reference to Figure 3 showing a schematic, partially sectioned view of a communication device 300. Such a communication device is often referred to as user equipment (UE) or terminal. An appropriate mobile communication device may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a mobile station (MS) or mobile device such as a mobile phone or what is known as a 'smart phone', a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), personal data assistant (FDA) or a tablet provided with wireless communication capabilities, or any combinations of these or the like. A mobile communication device may provide, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and so on. Users may thus be offered and provided numerous services via their communication devices. Non-limiting examples of these services comprise two-way or multi-way calls, data communication or multimedia services or simply an access to a data communications network system, such as the Internet. Users may also be provided broadcast or multicast data. Non-limiting examples of the content comprise downloads, television and radio programs, videos, advertisements, various alerts and other information.

[0252]A wireless communication device may be for example a mobile device, that is, a device not fixed to a particular location, or it may be a stationary device. The wireless device may need human interaction for communication, or may not need human interaction for communication. In the present teachings the terms UE or "user" are used to refer to any type of wireless communication device.

[0253]The wireless device 300 may receive signals over an air or radio interface 307 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In Figure 3 transceiver apparatus is designated schematically by block 306. The transceiver apparatus 306 may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the wireless device.

[0254]A wireless device is typically provided with at least one data processing entity 301, at least one memory 302 and other possible components 303 for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 704. The user may control the operation of the wireless device by means of a suitable user interface such as key pad 305, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 308, a speaker and a microphone can be also provided. Furthermore, a wireless communication device may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto.

[0255]Figure 4 shows a schematic representation of non-volatile memory media 400a (e.g. computer disc (CD) or digital versatile disc (DVD)) and 400b (e.g. universal serial bus (USB) memory stick) storing instructions and/or parameters 402 which when executed by a processor allow the processor to perform one or more of the steps of the methods of Figure 11 and/or Figure 12.

[0256]The embodiments may thus vary within the scope of the attached claims. In general, some embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although embodiments are not limited thereto. While various embodiments may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0257]The embodiments may be implemented by computer software stored in a memory and executable by at least one data processor of the involved entities or by hardware, or by a combination of software and hardware. Further in this regard it should be noted that any procedures, e.g., as in Figure 11 and/or Figure 12, may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD.

[0258]The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (AStudy ItemC), gate level circuits and processors based on multi-core processor architecture, as non-limiting examples.

[0259]Alternatively or additionally some embodiments may be implemented using circuitry. The circuitry may be configured to perform one or more of the functions and/or method steps previously described. That circuitry may be provided in the base station and/or in the communications device.

[0260]As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analogue and/or digital circuitry); (b) combinations of hardware circuits and software, such as: (i) a combination of analogue and/or digital hardware circuit(s) with software/firmware and (H) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as the communications device or base station to perform the various functions previously described; and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0261]This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example integrated device.

[0262]The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of some embodiments. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings will still fall within the scope as defined in the appended claims.

Claims

Claims 1) An apparatus for a terminal, the apparatus comprising: at least one processor; and at least one memory comprising code that, when executed by the at least one processor, causes the apparatus to: configure the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associate redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; select a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmit said data over the second uplink path using the selected transmission occasion.
2) An apparatus as claimed in claim 1, wherein the apparatus is caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by separately applying said sequence over each of the first and second uplink paths.
3) An apparatus as claimed in claim 1, wherein the apparatus is caused to redundantly transmit said data using the sequence over a first uplink path and a second uplink path by applying said sequence across both of the first and second uplink paths.
4) An apparatus as claimed in any preceding claim, wherein the first redundancy version value is immediately adjacent the second redundancy version value in the sequence.
5) An apparatus as claimed in any preceding claim, wherein the apparatus is further caused to receive configuration information for said configuring the terminal with the sequence of redundancy version values via Radio Resource Control signalling.
6) An apparatus as claimed in any preceding claim, wherein the apparatus is further caused to select the second redundancy version value using a first offset and an initial redundancy version value used for an initial redundant transmission of said data on the first uplink path.
7) An apparatus as claimed in claim 6, wherein the apparatus is further caused to use a second offset to select an initial redundancy version value for the first redundant transmission on the first uplink path.
8) An apparatus as claimed in any preceding claim, wherein the first redundancy version value is an initial redundancy version value in the sequence for an initial transmission of said redundant transmissions.
9) An apparatus for a network apparatus, the apparatus comprising: at least one processor; and at least one memory comprising code that, when executed by the at least one processor, causes the apparatus to: configure a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; provide at least one uplink path of a first uplink path and a second uplink path from the terminal; select a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receive the data on the at least one uplink path using said selected transmission occasion.
10)An apparatus as claimed in any claim 9, wherein configuring the terminal with the sequence of redundancy version values is performed using Radio Resource Control signalling.
11)An apparatus as claimed in any preceding claim, wherein the first uplink path is associated with a first sounding reference signal resource indicator and the second uplink path is associated with a second sounding reference signal resource indicator.
12)A method for a terminal, the method comprising: configuring the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associating redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; selecting a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmitting said data over the second uplink path using the selected transmission occasion.
13)A method for a network apparatus, the method comprising: configuring a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; providing at least one uplink path of a first uplink path and a second uplink path from the terminal; selecting a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receiving the data on the at least one uplink path using said selected transmission occasion.
14)A computer program product that, when run on an apparatus for a terminal, causes the apparatus to perform: configuring the terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; associating redundancy version values in the sequence with transmission occasions on each of a first uplink path and a second uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; selecting a transmission occasion associated with the second redundancy version value on the second uplink path for an initial redundant transmission of data on the second uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path; and redundantly transmitting said data over the second uplink path using the selected transmission occasion.
15)A computer program product that, when run on an apparatus for a terminal, causes the apparatus to perform: configuring a terminal with a sequence of redundancy version values for redundantly transmitting uplink data over a physical uplink shared channel, the sequence comprising a first redundancy version value and a second redundancy version value, wherein the second redundancy version value succeeds the first redundancy version value in the sequence; providing at least one uplink path of a first uplink path and a second uplink path from the terminal; selecting a transmission occasion associated with the second redundancy version value for receiving an initial redundant data transmission from the terminal on one of the at least one uplink path when a transmission occasion associated with the first redundancy version value has been or will be used for redundantly transmitting said data on the first uplink path, the transmission occasions being configured occasions during which redundant transmissions are allowed to be made; and receiving the data on the at least one uplink path using said selected transmission occasion.