Patent Description:
The present applications claims the Paris Convention priority from European patent application <CIT>.

Latest generation mobile telecommunication systems, such as those based on the 3GPP defined UMTS and Long Term Evolution (LTE) architecture, are able to support a wider range of services than simple voice and messaging services offered by previous generations of mobile telecommunication systems. The demand to deploy such networks is therefore strong and the coverage area of these networks, i.e. geographic locations where access to the networks is possible, is expected to continue to increase rapidly.

Future wireless communications networks will be expected to routinely and efficiently support communications with an ever increasing range of devices associated with a wider range of data traffic profiles and types than existing systems are optimised to support. For example it is expected future wireless communications networks will be expected to efficiently support communications with devices including reduced complexity devices, machine type communication (MTC) devices, high resolution video displays, virtual reality headsets and so on. Some of these different types of devices may be deployed in very large numbers, for example low complexity devices for supporting the "The Internet of Things", and may typically be associated with the transmissions of relatively small amounts of data with relatively high latency tolerance. Other types of device, for example supporting high-definition video streaming, may be associated with transmissions of relatively large amounts of data with relatively low latency tolerance. Other types of device, for example used for autonomous vehicle communications and for other critical applications, may be characterised by data that should be transmitted through the network with low latency and high reliability. A single device type might also be associated with different traffic profiles / characteristics depending on the application(s) it is running. For example, different consideration may apply for efficiently supporting data exchange with a smartphone when it is running a video streaming application (high downlink data) as compared to when it is running an Internet browsing application (sporadic uplink and downlink data) or being used for voice communications by an emergency responder in an emergency scenario (data subject to stringent reliability and latency requirements).

In view of this there is expected to be a desire for future wireless communications networks, for example those which may be referred to as <NUM> or new radio (NR) systems / new radio access technology (RAT) systems, as well as future iterations / releases of existing systems, to efficiently support connectivity for a wide range of devices associated with different applications and different characteristic data traffic profiles and requirements.

One example of a new service is referred to as Ultra Reliable Low Latency Communications (URLLC) services which, as its name suggests, requires that a data unit or packet be communicated with a high reliability and with a low communications delay. Another example of a new service is Enhanced Mobile Broadband (eMBB) services, which are characterised by a high capacity with a requirement to support up to <NUM> Gb/s. URLLC and eMBB type services therefore represent challenging examples for both LTE type communications systems and <NUM>/NR communications systems.

The increasing use of different types of network infrastructure equipment and terminal devices associated with different traffic profiles give rise to new challenges for efficiently handling communications in wireless communications systems that need to be addressed.

Non-patent document "Discussion on the remaining issues of configured grant enhancements" (OPPO) discusses some ambiguities between the RAN1 agreement and Rel. <NUM> specifications in respect of enhancements of configured grant operation.

Preferred embodiments are stipulated in dependent claims.

Embodiments of the present technique can provide a method of operating a communications device configured to transmit data to a wireless communications network via a wireless access interface. The method comprises operating in accordance with a configured grant, CG, mode of operation, the CG mode of operation comprising determining a sequence of instances of uplink communications resources of the wireless access interface and transmitting signals to the wireless communications network in at least one instance of the sequence of instances of uplink communications resources of the wireless access interface, transmitting uplink data to the wireless communications network in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data, and transmitting one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network, each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the one or more transmitted versions of CG-UCI are each repeated a plurality of times during the transmission of the uplink data.

Some further embodiments of the present technique can provide a method of operating a communications device configured to transmit data to a wireless communications network via a wireless access interface. The method comprises operating in accordance with a configured grant, CG, mode of operation, the CG mode of operation comprising determining a sequence of instances of uplink communications resources of the wireless access interface and transmitting signals to the wireless communications network in at least one instance of the sequence of instances of uplink communications resources of the wireless access interface, transmitting uplink data to the wireless communications network in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data, and transmitting one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network, each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the one or more transmitted versions of CG-UCI are each transmitted as two or more separate portions, each of the two or more portions being transmitted within different instances of the two or more instances during the transmission of the uplink data.

Embodiments of the present technique, which, in addition to methods of operating communications devices, relate to methods of operating infrastructure equipment, communications devices and infrastructure equipment, and circuitry for communications devices and infrastructure equipment, allow for more efficient use of radio resources by a communications device.

The network <NUM> includes a plurality of base stations <NUM> connected to a core network <NUM>. Each base station provides a coverage area <NUM> (i.e. a cell) within which data can be communicated to and from communications devices <NUM>. Although each base station <NUM> is shown in <FIG> as a single entity, the skilled person will appreciate that some of the functions of the base station may be carried out by disparate, inter-connected elements, such as antennas (or antennae), remote radio heads, amplifiers, etc. Collectively, one or more base stations may form a radio access network.

Data is transmitted from base stations <NUM> to communications devices <NUM> within their respective coverage areas <NUM> via a radio downlink. Data is transmitted from communications devices <NUM> to the base stations <NUM> via a radio uplink. The core network <NUM> routes data to and from the communications devices <NUM> via the respective base stations <NUM> and provides functions such as authentication, mobility management, charging and so on. Terminal devices may also be referred to as mobile stations, user equipment (UE), user terminal, mobile radio, communications device, and so forth. Services provided by the core network <NUM> may include connectivity to the internet or to external telephony services. The core network <NUM> may further track the location of the communications devices <NUM> so that it can efficiently contact (i.e. page) the communications devices <NUM> for transmitting downlink data towards the communications devices <NUM>.

Base stations, which are an example of network infrastructure equipment, may also be referred to as transceiver stations, nodeBs, e-nodeBs, eNB, g-nodeBs, gNB and so forth. In this regard different terminology is often associated with different generations of wireless telecommunications systems for elements providing broadly comparable functionality. However, certain embodiments of the disclosure may be equally implemented in different generations of wireless telecommunications systems, and for simplicity certain terminology may be used regardless of the underlying network architecture. That is to say, the use of a specific term in relation to certain example implementations is not intended to indicate these implementations are limited to a certain generation of network that may be most associated with that particular terminology.

An example configuration of a wireless communications network which uses some of the terminology proposed for and used in NR and <NUM> is shown in <FIG>. In <FIG> a plurality of transmission and reception points (TRPs) <NUM> are connected to distributed control units (DUs) <NUM>, <NUM> by a connection interface represented as a line <NUM>. Each of the TRPs <NUM> is arranged to transmit and receive signals via a wireless access interface within a radio frequency bandwidth available to the wireless communications network. Thus, within a range for performing radio communications via the wireless access interface, each of the TRPs <NUM>, forms a cell of the wireless communications network as represented by a circle <NUM>. As such, wireless communications devices <NUM> which are within a radio communications range provided by the cells <NUM> can transmit and receive signals to and from the TRPs <NUM> via the wireless access interface. Each of the distributed units <NUM>, <NUM> are connected to a central unit (CU) <NUM> (which may be referred to as a controlling node) via an interface <NUM>. The central unit <NUM> is then connected to the core network <NUM> which may contain all other functions required to transmit data for communicating to and from the wireless communications devices and the core network <NUM> may be connected to other networks <NUM>.

The TRPs <NUM> of <FIG> may in part have a corresponding functionality to a base station or eNodeB of an LTE network. Similarly, the communications devices <NUM> may have a functionality corresponding to the UE devices <NUM> known for operation with an LTE network. It will be appreciated therefore that operational aspects of a new RAT network (for example in relation to specific communication protocols and physical channels for communicating between different elements) may be different to those known from LTE or other known mobile telecommunications standards. However, it will also be appreciated that each of the core network component, base stations and communications devices of a new RAT network will be functionally similar to, respectively, the core network component, base stations and communications devices of an LTE wireless communications network.

In terms of broad top-level functionality, the core network <NUM> connected to the new RAT telecommunications system represented in <FIG> may be broadly considered to correspond with the core network <NUM> represented in <FIG>, and the respective central units <NUM> and their associated distributed units / TRPs <NUM> may be broadly considered to provide functionality corresponding to the base stations <NUM> of <FIG>. The term network infrastructure equipment / access node may be used to encompass these elements and more conventional base station type elements of wireless telecommunications systems. Depending on the application at hand the responsibility for scheduling transmissions which are scheduled on the radio interface between the respective distributed units and the communications devices may lie with the controlling node / central unit and / or the distributed units / TRPs. A communications device <NUM> is represented in <FIG> within the coverage area of the first communication cell <NUM>. This communications device <NUM> may thus exchange signalling with the first central unit <NUM> in the first communication cell <NUM> via one of the distributed units <NUM> associated with the first communication cell <NUM>.

It will further be appreciated that <FIG> represents merely one example of a proposed architecture for a new RAT based telecommunications system in which approaches in accordance with the principles described herein may be adopted, and the functionality disclosed herein may also be applied in respect of wireless telecommunications systems having different architectures.

Thus, certain embodiments of the disclosure as discussed herein may be implemented in wireless telecommunication systems / networks according to various different architectures, such as the example architectures shown in <FIG> and <FIG>. It will thus be appreciated the specific wireless telecommunications architecture in any given implementation is not of primary significance to the principles described herein. In this regard, certain embodiments of the disclosure may be described generally in the context of communications between network infrastructure equipment / access nodes and a communications device, wherein the specific nature of the network infrastructure equipment / access node and the communications device will depend on the network infrastructure for the implementation at hand. For example, in some scenarios the network infrastructure equipment / access node may comprise a base station, such as an LTE-type base station <NUM> as shown in <FIG> which is adapted to provide functionality in accordance with the principles described herein, and in other examples the network infrastructure equipment may comprise a control unit / controlling node <NUM> and / or a TRP <NUM> of the kind shown in <FIG> which is adapted to provide functionality in accordance with the principles described herein.

A more detailed diagram of some of the components of the network shown in <FIG> is provided by <FIG>. In <FIG>, a TRP <NUM> as shown in <FIG> comprises, as a simplified representation, a wireless transmitter <NUM>, a wireless receiver <NUM> and a controller or controlling processor <NUM> which may operate to control the transmitter <NUM> and the wireless receiver <NUM> to transmit and receive radio signals to one or more UEs <NUM> within a cell <NUM> formed by the TRP <NUM>. As shown in <FIG>, an example UE <NUM> is shown to include a corresponding transmitter <NUM>, a receiver <NUM> and a controller <NUM> which is configured to control the transmitter <NUM> and the receiver <NUM> to transmit signals representing uplink data to the wireless communications network via the wireless access interface formed by the TRP <NUM> and to receive downlink data as signals transmitted by the transmitter <NUM> and received by the receiver <NUM> in accordance with the conventional operation.

The transmitters <NUM>, <NUM> and the receivers <NUM>, <NUM> (as well as other transmitters, receivers and transceivers described in relation to examples and embodiments of the present disclosure) may include radio frequency filters and amplifiers as well as signal processing components and devices in order to transmit and receive radio signals in accordance for example with the <NUM>/NR standard. The controllers <NUM>, <NUM> (as well as other controllers described in relation to examples and embodiments of the present disclosure) may be, for example, a microprocessor, a CPU, or a dedicated chipset, etc., configured to carry out instructions which are stored on a computer readable medium, such as a non-volatile memory. The processing steps described herein may be carried out by, for example, a microprocessor in conjunction with a random access memory, operating according to instructions stored on a computer readable medium. The transmitters, the receivers and the controllers are schematically shown in <FIG> as separate elements for ease of representation. However, it will be appreciated that the functionality of these elements can be provided in various different ways, for example using one or more suitably programmed programmable computer(s), or one or more suitably configured application-specific integrated circuit(s) / circuitry / chip(s) / chipset(s). As will be appreciated the infrastructure equipment / TRP / base station as well as the UE / communications device will in general comprise various other elements associated with its operating functionality.

As shown in <FIG>, the TRP <NUM> also includes a network interface <NUM> which connects to the DU <NUM> via a physical interface <NUM>. The network interface <NUM> therefore provides a communication link for data and signalling traffic from the TRP <NUM> via the DU <NUM> and the CU <NUM> to the core network <NUM>.

The interface <NUM> between the DU <NUM> and the CU <NUM> is known as the F1 interface which can be a physical or a logical interface. The F1 interface <NUM> between CU and DU may operate in accordance with specifications 3GPP TS <NUM> and 3GPP TS <NUM>, and may be formed from a fibre optic or other wired or wireless high bandwidth connection. In one example the connection <NUM> from the TRP <NUM> to the DU <NUM> is via fibre optic. The connection between a TRP <NUM> and the core network <NUM> can be generally referred to as a backhaul, which comprises the interface <NUM> from the network interface <NUM> of the TRP10 to the DU <NUM> and the F1 interface <NUM> from the DU <NUM> to the CU <NUM>.

Systems incorporating NR technology are expected to support different services (or types of services), which may be characterised by different requirements for latency, data rate and/or reliability. For example, Enhanced Mobile Broadband (eMBB) services are characterised by high capacity with a requirement to support up to <NUM> Gb/s. A requirement for Ultra Reliable and Low Latency Communications (URLLC) services is that one transmission of a <NUM> byte packet is required to be transmitted from the radio protocol layer <NUM>/<NUM> SDU ingress point to the radio protocol layer <NUM>/<NUM> SDU egress point of the radio interface within <NUM> with a reliability of <NUM> - <NUM>-<NUM> (<NUM> %) or higher (<NUM>%) [<NUM>]. Massive Machine Type Communications (mMTC) is another example of a service which may be supported by NR-based communications networks. In addition, systems may be expected to support further enhancements related to Industrial Internet of Things (IIoT) in order to support services with new requirements of high availability, high reliability, low latency, and in some cases, high-accuracy positioning.

Enhanced URLLC (eURLLC) [<NUM>][<NUM>] specifies features that require high reliability and low latency, such as factory automation, transport industry, electrical power distribution, etc. It should be appreciated that the Uplink Control Information (UCI) for URLLC and eMBB will have different requirements. Hence, one of the current objectives of eURLLC is to enhance the UCI to support URLLC, where the aim is to allow more frequent UCI to be transmitted, such as the transmission of more Hybrid Automatic Repeat Request Acknowledgement (HARQ-ACK) feedback per slot, and to support multiple HARQ-ACK codebooks for different traffic services. Solutions identified to accommodate more frequent UCI without interrupting the high-priority and low-latency data transmissions using Physical Uplink Shared Channels (PUSCHs) can comprise the multiplexing of UCI onto PUSCH repetitions.

Another such service incorporating NR technology is <NUM> NR in Unlicensed Spectrum (NR-U) [<NUM>], which enable devices to make use of shared and unlicensed spectrum bandwidth. Such features as Listen Before Talk (LBT), as specified by [<NUM>], may be incorporated into the NR frame structure for NR-U operation in unlicensed bands. One of the objectives of eURLLC, as laid out in [<NUM>], is to harmonise Configured Grant (CG) PUSCH operations in eURLLC and NR-U.

In the following paragraphs, an explanation is provided of current proposals for accessing communications from an unlicensed frequency band. In an unlicensed band, two or more systems may operate to communicate using the same communications resources. As a result, transmissions from different systems can interfere with each other especially when for example, each of the different systems are configured according to different technical standards, for example Wi-Fi and <NUM>. Of course, transmissions from systems operating in accordance with the same standard may also cause interference. As such, there is a regulatory requirement to use an LBT protocol for each transmitter operating in an unlicensed band to reduce interferences among different systems (either operating according to the same or different technical standards as one another) sharing that band. In LBT, a device that wishes to transmit a packet will firstly sense the band for any energy levels above a threshold to determine if any other device is transmitting, i.e. it listens, and if there is no detected transmission, the device will then transmit its packet. Otherwise, if the device senses a transmission from another device it will back-off and try again at a later time.

In NR-U the channel access can be Dynamic (also known as Load Based Equipment) or Semi-Static (also known as Frame Based Equipment). The dynamic channel access schemes consist of one or more Clear Channel Assessment (CCA) phases in a Contention Window followed by a Channel Occupancy Time (COT) phase as shown <FIG>. LBT is performed during the CCA phase by an NR-U device (e.g. gNB or UE) that wishes to perform a transmission. According to the CCA phase, the NR-U device listens to one or more of CCA slots and if no other transmission is detected (i.e. energy level is determined to be below a threshold for the duration of the one or more CCA slots) after the CCA phase, the NR-U device moves into the COT phase where it can transmit its packet in the COT resources. In Dynamic Channel Access (DCA) the CCA and COT phases can be of different length between different systems whilst in Semi-static Channel Access, the CCA and COT phases have fixed time windows and are synchronised for all systems sharing the band. Further details on channel access in NR-U may be found in co-pending European patent application with application number <CIT> [<NUM>].

In NR-U a device can be an initiating device or a responding device. The initiating device acquires the COT by performing CCA and typically it initiates a first transmission, e.g. a gNB transmitting an uplink grant. The responding device receives the transmission from the initiating device and responds with a transmission to the initiating device, e.g. a UE receiving an uplink grant and transmitting the corresponding PUSCH. As will be appreciated a UE can also be an initiating device, for example when it is transmitting a Configured Grant (CG) PUSCH, and the gNB can be a responding device.

There are two types of Dynamic Channel Access (DCA), which are referred to as Type <NUM> and Type <NUM>. In a Type <NUM> DCA, a counter N is generated as a random number between <NUM> and CWp, where a Contention Window size CWp is set between CWmin,p and CWmax,p. The duration of the COT and the values {CWmin,p, CWmax,p} depend on the value p, which is the Channel Access Priority Class (CAPC) of the transmission. The CAPC may be determined, for example, by a QoS of the transmitting packet. A Type <NUM> DCA is performed by an initiating device, and once the COT is acquired, one or more responding devices can use Type <NUM> DCA for their transmissions within the COT. Type <NUM> DCA may require a short CCA or no CCA prior to transmission if the gap between one transmission of two devices is less than a predefined value, such as, for example, <NUM>. If the gap is greater than this predefined value such as <NUM>, then the responding device needs to perform Type <NUM> DCA.

<FIG> provides an illustration of frequency against time for transmission in an unlicensed band. As shown for the example of <FIG>, an example of a Type <NUM> DCA transmission and an example of a Type <NUM> DCA transmission are shown. According to the example shown in <FIG>, at time t<NUM>, the gNB wishes to send an uplink grant, UG#<NUM>, to the UE to schedule PUSCH#<NUM>. The gNB performs a Type <NUM> DCA starting with a Contention Window with four CCAs <NUM>, so that for this example the random number N = <NUM>, and detects no energy during this Contention Window <NUM>, thereby acquiring the COT <NUM> between time t<NUM> to t<NUM>. The gNB then transmits UG#<NUM> to the UE scheduling a PUSCH#<NUM> at time t<NUM> as represented by arrow <NUM>. The UE receiving the uplink grant UG#<NUM> then can use Type <NUM> DCA if the gap between UG#<NUM> and the start of its PUSCH#<NUM> transmission, between time t<NUM> and t<NUM> is below a threshold, otherwise the UE will have to perform a Type <NUM> DCA. This is to say, if the granted PUSCH#<NUM> is less than a threshold time from the gNB's transmission of the uplink grant UG#<NUM> or other gNB transmissions, then the UE is not required to make a contention itself for the resources on the unlicensed band by transmitting in the CCA and then COT according to the Type <NUM> DCA.

There are three types of Type <NUM> DCA, as shown in <FIG>, which are defined with respect to a length of the gap <NUM> between transmission <NUM> by a first device (initiating device) and transmission <NUM> by a second device (responding device) within a COT, and are therefore defined by whether the second responding device needs to perform a CCA. These types are:.

A COT can be shared by multiple devices; i.e. a gNB can initiate the COT which it can then share with one or more UE. For example, a gNB can initiate a COT, and then can transmit an UL Grant to a UE, and the UE can then use this COT to transmit the PUSCH. A device using a COT initiated by another device may not need to perform CCA, or may need to perform just a short CCA. Those skilled in the art would appreciate that a UE can also initiate a COT.

As is well understood by those skilled in the art, a UE uses a Physical Uplink Shared Channel (PUSCH) for uplink data transmission. The PUSCH resources used for the transmission of the PUSCH can be scheduled by a gNB using a Dynamic Grant (DG) or a Configured Grant (CG).

In a Dynamic Grant PUSCH (DG-PUSCH), the UE typically sends a Scheduling Request (SR) to the gNB when uplink data arrives at its buffer. In response to receiving the SR, the gNB would then send an Uplink Grant, e.g. via Downlink Control Information (DCI) using DCI Format 0_0, 0_1 or 0_2, carried by a Physical Downlink Control Channel (PDCCH) to the UE where this Uplink Grant schedules resources for a PUSCH. The UE then uses the scheduled PUSCH (i.e. DG-PUSCH) to transmit its uplink data.

It is observed that the use of DG-PUSCHs introduces latency, since the UE needs to initiate an SR and has to wait for an Uplink Grant before it is scheduled PUSCH resources. For regular and periodic traffic, DG-PUSCH would lead to multiple SR and Uplink Grants being sent which is not an efficient use of resources. Hence, recognising the drawbacks of DG-PUSCH, Configured Grant PUSCH (CG-PUSCH) is introduced in NR. In CG-PUSCH, the UE is pre-configured using Radio Resource Control (RRC) configuration periodic PUSCH resources, such that the UE can transmit its uplink data in any of these regularly occurring CG-PUSCH resources without the need to request it with an SR. There are two types of CG-PUSCH:.

In the time domain, a CG-PUSCH consists of a periodicity PCG, repetitions K = {<NUM>, <NUM>, <NUM>, <NUM>}, duration L of the PUSCH and starting symbol offset relative to slot boundary S of the PUSCH. An example is shown in <FIG>, where the CG-PUSCH has a periodicity PCG=<NUM> symbols (or <NUM> slots), repetition of K=<NUM>, duration of L=<NUM> symbols and a starting symbol S=<NUM> symbols from the start of slot boundary. The CG-PUSCH consists of Transmission Occasions (TO), where a TO is an opportunity for the UE to transmit uplink data. It should be noted here that the UE does not need to use a TO, i.e. a CG-PUSCH resource, if it has no uplink data to transmit. For example, in Slot n, the UE does not have any uplink data and so it does not transmit anything in the TOs for that CG period but in the next CG Period starting in Slot n+<NUM>, the UE has uplink data and therefore uses the TOs in that CG Period to transmit four repetitions of the uplink data.

The first TO in a CG Period is associated with Redundancy Version RV=<NUM>. If repetition K><NUM>, then each TO in the CG Period is associated with an RRC configured RV pattern, where the RV pattern can be {<NUM>, <NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>} or {<NUM>, <NUM>, <NUM>, <NUM>}. The RV pattern is configured in RRC parameter repK-RV. For example, in <FIG>, the RV pattern = {<NUM>, <NUM>, <NUM>, <NUM>}. The first PUSCH transmission in a CG Period must always start with RV=<NUM>. For repetition K=<NUM>, the RV pattern is cycled after the fourth repetition; i.e. the RV pattern restarts after the fourth repetition. For example, in <FIG>, the RV pattern = {<NUM>, <NUM>, <NUM>, <NUM>} and K=<NUM> repetitions. Here the UE cycles the RV at the fifth repetition, where the RV pattern is restarted at the fifth TO of the CG period in Slot n+<NUM>.

Since HARQ is used for PUSCH transmission, each PUSCH is associated with a HARQ Process Number (HPN) where there are <NUM> HARQ processes, i.e. HPN = <NUM> to <NUM>. In DG-PUSCH, the HPN is indicated in the UL Grant. For CG-PUSCH, since there is no UL Grant, each CG period is associated with an HPN and is dependent upon the starting symbol OCG (in units of symbols) of the first TO in a CG period relative to SFN=<NUM>, the periodicity PCG (in units of symbols) and the number of HARQ processes NHARQ configured for the CG-PUSCH [<NUM>] (i.e. the gNB can configured less than <NUM> HARQ processes for a CG-PUSCH), i.e.: <MAT>.

Where <MAT> is the Floor function and OCG is relative to the first symbol of the first slot of the radio frame with SFN=<NUM>.

Retransmission of a CG-PUSCH is scheduled using an UL Grant. That is, a DG-PUSCH is used for the retransmission of a CG-PUSCH that is not decoded successfully at the gNB. If the UE does not receive an UL Grant for the retransmission of a CG-PUSCH within a pre-configured timer TCG-ACK, the UE will consider that the CG-PUSCH has been received successfully.

Since the first CG-PUSCH transmission must use a TO with RV=<NUM>, if the UE misses that TO, it may not be able to transmit any PUSCH in that CG Period. For example, referring back to <FIG>, if the uplink data arrives at the UE buffer in Slot n+<NUM>, then the UE may only be ready to transmit a PUSCH in Slot n+<NUM> but the TO in Slot n+<NUM> corresponds to RV=<NUM> and so the UE cannot start its PUSCH transmission. It then has to wait till the next CG Period in Slot n+<NUM> for a TO with RV=<NUM> to start its transmission. This introduces latency for the PUSCH transmission, which may not meet the stringent latency requirement in URLLC.

In order to improve reliability, PUSCH is transmitted using repetitions, as has been mentioned above. For CG-PUSCH, if the uplink data does not arrive before the first TO of a CG Period, the UE may not be able to transmit the required number of repetitions, even if there are multiple TOs with RV=<NUM> within that CG Period. For example, in <FIG>, a CG-PUSCH is configured with K=<NUM> repetitions and an RV pattern {<NUM>, <NUM>, <NUM>, <NUM>} thereby allowing two TOs where the first PUSCH transmissions can start (i.e. the first and third TOs). Uplink data arrives at the UE buffer at the end of Slot n, thereby missing the first TO of the CG Period. Since the UE has to start its PUSCH transmission in a TO with RV=<NUM>, the PUSCH is transmitted in Slot n+<NUM>, i.e. the closest TO with RV=<NUM>. However, there are only two TOs left in that CG Period and so the UE is only able to transmit two out of the targeted four repetitions. The reduced PUSCH repetition transmissions may not meet the strict reliability requirement for URLLC.

Recognising the drawbacks of Rel-<NUM> CG-PUSCH, multi CG-PUSCH was introduced for Rel-<NUM> eURLLC, where a UE can be configured with up to <NUM> CG-PUSCH where each CG-PUSCH can be independently configured. A configuration can be made such that different CG-PUSCHs start at different times so that a UE has multiple opportunities to transmit its PUSCH. For example, in <FIG>, a UE is configured with four CG-PUSCHs, labelled as CG#<NUM>, CG#<NUM>, CG#<NUM> and CG#<NUM> and each with repetition K=<NUM>. These CG-PUSCHs are configured such that they start within one slot offset of one another. At Slot n+<NUM>, uplink data arrives at the UE's buffer and the possible TOs that the UE can use to start its PUSCH transmissions are the third TO (Slot n+<NUM>) of CG#<NUM>, the first TO (Slot n+<NUM>) of CG#<NUM> and the first TO (Slot n+<NUM>) of CG#<NUM>. In order to ensure K=<NUM> repetitions, the UE can use CG#<NUM> or CG#<NUM> but since CG#<NUM> offers the lowest latency, the UE selects CG#<NUM> for its PUSCH transmissions thereby ensuring K=<NUM> repetitions and minimising latency. It would be appreciated by those skilled in the art that the staggering of multiple CG-PUSCH resources as shown in <FIG> is just one possible configuration to ensure K repetitions are sent with minimum latency. The gNB is free to configure other arrangements as each CG-PUSCH can be individually configured.

For Type <NUM> CG-PUSCH, a CG-PUSCH can be individually activated using the four-bit HPN field in an UL Grant. For deactivation, one or more CG-PUSCHs can be indicated for deactivation using the <NUM> states in the HPN field, where each state can be configured to indicate a combination of CG-PUSCHs for deactivation.

In Rel-<NUM>, slot based PUSCH repetition, known as PUSCH Aggregation, is introduced to improve the reliability of the PUSCH transmission. An example is shown in <FIG>, where a Type B PUSCH of four symbols duration, i.e. L=<NUM>, which starts with two symbols offset from the slot boundary, is repeated four times, i.e. K=<NUM>, using PUSCH Aggregation starting from slot n to slot n+<NUM>. The number of repetitions for PUSCH Aggregation is RRC configured.

In PUSCH Aggregation i.e. the slot based PUSCH repetition, where the PUSCH duration is less than a slot, time gaps between repetitions are observed. For the example in <FIG>, the PUSCH is repeated at the slot level leaving a gap of <NUM> symbols between successive repetitions. Such gaps introduce latency and therefore are not acceptable for URLLC. Recognising this, in Rel-<NUM> eURLLC, Enhanced Type B PUSCH Repetition (e-Type B PUSCH) is introduced where the PUSCH repetitions are repeated back-to-back, thereby minimising latency whilst improving reliability. An example is shown in <FIG>, where a four symbol duration PUSCH, L=<NUM>, with two symbols offset from the slot boundary, is repeated four times, i.e. KN=<NUM>, using Rel-<NUM> PUSCH Repetition. Here, there are no gaps between each repetition, thereby completing the entire repetitions within <NUM> symbols as compared to <NUM> symbols (four slots) when using PUSCH Aggregation. Enhanced Type B PUSCH repetition is supported in DG-PUSCH and CG-PUSCH for Rel-<NUM> eURLLC. In DG-PUSCH, the number of repetitions is indicated in the UL Grant, whilst for CG-PUSCH, the repetition number is RRC configured in the parameter repK.

Since e-Type B PUSCH can start at any symbol within a slot, some of its repetitions may cross a slot boundary, or may collide with an invalid Orthogonal Frequency Division Multiplexing (OFDM) symbol, e.g. a Downlink symbol, and these PUSCHs are segmented. A PUSCH repetition that is scheduled e.g. by an UL Grant or configured for a CG-PUSCH, is known as a nominal repetition. If segmentation occurs on a nominal PUSCH and it is segmented into two or more PUSCH segments, these segments are called actual repetitions KA, i.e. these actual repetitions are PUSCH repetitions that are actually transmitted, which can therefore be larger than the number of nominal repetitions, i.e. the scheduled number of repetitions. The PUSCH duration L and nominal repetition number KN that are scheduled by an UL Grant or configured for a CG-PUSCH gives the absolute total duration of the PUSCH transmission; that is KN×L is the duration of the entire PUSCH transmission and so any parts of the PUSCH transmission that collide with invalid OFDM symbols are dropped. <FIG> shows two examples of PUSCH segmentation. At time t<NUM>, a PUSCH <NUM> with KN=<NUM>, L=<NUM> is transmitted, where the third nominal PUSCH repetition crosses the slot boundary at time t<NUM>. Consequently, the third nominal PUSCH repetition is segmented into two PUSCH repetitions and therefore the actual number of repetitions KA=<NUM>. At time t<NUM>, another PUSCH <NUM> with KN=<NUM>, L=<NUM>, is transmitted, where the first nominal PUSCH repetition collides with <NUM> DL (or invalid) symbols between time t<NUM> and t<NUM>. Consequently, the first nominal PUSCH repetition is segmented into two PUSCH repetitions and therefore the actual number of repetitions KA=<NUM>. Since KN×L = <NUM> OFDM symbols, is the total duration of the PUSCH transmission <NUM>, the two PUSCH symbols that collide with the DL (or invalid) symbols between time t<NUM> and t<NUM> are therefore dropped.

In Rel-<NUM>, there are no priority levels at the Physical Layer, and when two UL transmissions collide, their information is multiplexed and transmitted using a single channel. The possible collisions are those between a Physical Uplink Control Channel (PUCCH) and another PUCCH and between a PUCCH and a PUSCH. It should be noted that priority levels are defined for the MAC layer in Rel-<NUM>, where there are <NUM> priority levels.

A UE can be configured to provide eMBB and URLLC services. Since eMBB and URLLC have different latency requirements, their uplink transmissions may collide. For example, after an eMBB uplink transmission has been scheduled, an urgent URLLC packet may arrive, which would need to be scheduled immediately and so its transmissions may collide with the eMBB transmission. In order to handle such intra-UE collisions with different latency and reliability requirements, two priority levels at the Physical Layer were introduced in Rel-<NUM> for uplink transmissions, i.e. PUCCH and PUSCH. In Rel-<NUM> intra-UE prioritisation is used; that is, when two UL transmissions with different Physical Layer priority levels (L1 priority) collide, the UE will drop the lower priority transmission. If both UL transmissions have the same L1 priorities, then the UE may reuse Rel-<NUM> procedures (i.e. the UL transmissions are multiplexed and transmitted using a single channel). For CG-PUSCH, the L1 priority is RRC configured for each CG-PUSCH in the RRC parameter phy-PriorityIndex-r16.

Since LBT is required for a transmission, the UE may not be able to access a CG-PUSCH Transmission Occasion (TO), especially one that is associated with RV=<NUM>. Hence, recognising this, in Rel-<NUM> NR-U, the TO is increased in each CG Period by extending the CG Period to cg-nrofSlots-r16 (<NUM> to <NUM>) slots, where each slot contains cg-nrofPUSCH-InSlot-r16 (<NUM> to <NUM>) consecutive CG-PUSCHs. The parameters cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16 are RRC configured per CG-PUSCH. The UE can start a PUSCH transmission in any of these CG-PUSCHs resources within the CG Period, instead of being limited to specific TOs with RV=<NUM> in the legacy system as described above. Hence, effectively in each CG Period, the UE is provided with cg-nrofSlots-r16 × cg-nrofPUSCH-InSlot-r16 Flexible TOs, and so the UE has multiple opportunities for LBT attempts to transmit its PUSCH. It should be noted that in 3GPP these TOs are called multi CG-PUSCH, but to avoid confusing these with Rel-<NUM> eURLLC Multi CG-PUSCH as described above, these TOs are referred to herein as Flexible TOs (F-TO). An example is shown in <FIG>, where PCG=<NUM> symbols (<NUM> slots), S=<NUM> symbols, L=<NUM> symbols, cg-nrofSlots-r16=<NUM> and cg-nrofPUSCH-InSlot-r16=<NUM>, which gives <NUM> Flexible TOs per CG Period. At the end of Slot n, UL data arrives at the UE buffer and the UE attempts to transmit it in the next F-TO, i.e. TO#<NUM> in Slot n+<NUM>. However, the UE here in the example shown in <FIG> fails the LBT process and so it attempts another LBT on TO#<NUM>, in which case it is successful. The UE then transmits two PUSCH using TO#<NUM> and TO#<NUM> in Slot n+<NUM> (which could be for different TBs or HPN). At the end of Slot n+<NUM>, further UL data arrives at the UE's buffer and it attempts LBT on the next F-TO, i.e. TO#<NUM> in Slot n+<NUM> and is successful, thereby transmitting the PUSCH in this slot.

For a CG-PUSCH transmission, the UE may need to perform the CCA and initiate a COT. The UE can share the COT with the gNB, for example to allow the gNB to send feedback signals for its CG-PUSCH transmissions. The DL resources within the COT for the gNB are indicated by the UE in a CG-UCI. Here, the UE indicates an index to an entry in a lookup table containing the slot offset ODL where the DL transmission can start, and the duration in slots LDL of the DL transmission. The lookup table is RRC configured with configurable CDL entries and they are signalled in the cg-COT-SharingList-r16 parameter. One of the entries in this lookup table indicates "No Sharing". The slot offset ODL is relative to the end of the slot containing the CG-UCI indicating the COT Sharing DL resources. An example of a "cg-COT-SharingList-r16" configuration with CDL=<NUM> entries as shown in Table I.

<FIG> illustrates an example operation using the example configuration of Table I. Here, we label the offsets and DL resources according to their indices; i.e. ODL1, ODL2 and ODL3 are offsets for indices <NUM>, <NUM> and <NUM> respectively. Similarly, DL#<NUM>, DL#<NUM> and DL#<NUM> are DL resources for indices <NUM>, <NUM> and <NUM> respectively, with duration LDL1, LDL2 and LDL3 respectively. Resource for index <NUM> is not shown since it indicates "No Sharing". In <FIG>, the UE has a CG Period with four F-TOs (i.e. cg-nrofSlots-r16=<NUM> and cg-nrofPUSCH-InSlot-r16=<NUM>), the UE manages to acquire TO#<NUM> for its PUSCH transmission and thereby acquiring a COT that is seven slots long. In the PUSCH transmission, the UE multiplexes CG-UCI containing COT Sharing Information where it indicates one of the three available DL resources that the gNB can use for HARQ-ACK feedback for its PUSCH transmission. Since the CG-UCI is in Slot n+<NUM>, the slot offsets ODL1, ODL2 and ODL3 are relative to the end of Slot n+<NUM>.

In Rel-<NUM> and Rel-<NUM> eURLLC, the HPN and RV of each CG-PUSCH transmission is fixed for each TO and known to the gNB. However, since Flexible TOs are used in Rel-<NUM> NR-U, where the UE can use any of the TOs for a first PUSCH transmission, and where different TBs (i.e. with different HPNs) can be transmitted in a CG Period, the gNB needs to know the HPN and the RV of each of these CG-PUSCHs. In order to provide this information to the gNB, CG Uplink Control Information (CG-UCI) is introduced for Rel-<NUM> NR-U which consists of the following fields [<NUM>]:.

The CG-UCI is multiplexed into the CG-PUSCH transmission.

In Rel-<NUM> and Rel-<NUM> eURLLC, an implicit HARQ-ACK feedback is used for CG-PUSCH, where a NACK is implicitly indicated with an UL Grant scheduling a retransmission for the CG-PUSCH, and the timer TCG-ACK is used to implicitly indicate an ACK.

For Rel-<NUM> NR-U, an explicit HARQ-ACK is used for CG-PUSCH, which is carried by Downlink Feedback Information (DFI). The DFI is carried by the PDCCH and it contains a <NUM>-bit bitmap indicating the ACK/NACK for each HPN where "<NUM>" indicates ACK and "<NUM>" indicates NACK. The HARQ-ACK feedbacks in the DFI are applicable not only for CG-PUSCHs but also for DG-PUSCHs that are transmitted at least TDFI-Delay symbols prior to the start of the DFI. TDFI-Delay is RRC configured in parameter cg-minDFI-Delay-r16. An example is shown in <FIG>, where a CG Period consists of four F-TOs and the UE transmits PUSCH on TO#<NUM>, TO#<NUM> and TO#<NUM> with HPN=<NUM>, HPN=<NUM> and HPN=<NUM> respectively. The TDFI-Delay = <NUM> symbols and in this example the DFI can only feedback HARQ-ACKs for TO#<NUM> and TO#<NUM>, which are indicated in the first and eleventh positions respectively in the DFI bitmap according to their HPN (these are indicated as bold and underlined in <FIG>). Since TO#<NUM> ends with fewer than TDFI-Delay symbols before the start of the DFI, the HARQ-ACK for TO#<NUM> is not represented in the DFI and is indicated as "<NUM>" regardless of whether it is an ACK or NACK.

The DFI does not indicate any uplink resource for the UE, and so the retransmission of a CG-PUSCH is transmitted using another CG-PUSCH resource. The gNB determines that a CG-PUSCH is a retransmission using the NDI and HPN fields of the CG-UCI. The UE can also decide on the RV of the retransmission (or the first transmission) since it can be indicated in the CG-UCI.

The transmission of the DFI is not guaranteed since the gNB has to perform LBT especially for the scenario where the DFI is not transmitted within the UE initiated COT. A retransmission timer TCG-ReTx is introduced for Rel-<NUM> NR-U, which is started after a CG-PUSCH transmission. If this retransmission timer expires without the UE receiving an explicit HARQ-ACK (i.e. a DFI) from the gNB, the UE will retransmit that CG-PUSCH.

In Rel-<NUM> NR-U, the CG-UCI is transmitted in each PUSCH repetition, where the CG-UCI indicates the HPN, RV, NDI and COT Sharing Information. In URLLC, PUSCH repetitions are introduced to improve reliability of the data transmission. Since CG-UCI may carry different RV information in each PUSCH repetition, the CG-UCI cannot benefit from any combining gain from these repetitions, and therefore may not have sufficient reliability to meet URLLC requirements.

The CG-UCI needs to be decoded correctly in order to be able to decode the PUSCH, since the CG-UCI signals some of the parameters that are needed for PUSCH decoding (e.g. the CG-UCI indicates the RV applied to the PUSCH transmission, i.e. indicates which set of parity and systematic bits is contained within the PUSCH). Hence, if the CG-UCI is not reliable, the PUSCH that is associated with the CG-UCI is also not reliable and the URLLC latency and reliability requirements may not be met. Embodiments of the present technique propose ways in which the reliability of CG-UCI can be increased in order, for example, to meet the latency and reliability requirements of URLLC. Embodiments of the present technique seek to ensure that the CG-UCI reliability is improved such that the CG-UCI is not the weakest link with respect to the reliability of the PUSCH.

<FIG> shows a part schematic, part message flow diagram representation of a wireless communications network comprising a communications device <NUM> and an infrastructure equipment <NUM> in accordance with at least some embodiments of the present technique. The communications device <NUM> is configured to transmit data to or receive data from the wireless communications network, for example, to and from the infrastructure equipment <NUM>, via a wireless access interface provided by the wireless communications network. Specifically, the communications device <NUM> may be configured to transmit data (for example, Ultra Reliable Low Latency Communications (URLLC) data) to the wireless communications network (e.g. to the infrastructure equipment <NUM>) via the wireless access interface. The communications device <NUM> and the infrastructure equipment <NUM> each comprise a transceiver (or transceiver circuitry) <NUM>, <NUM>, and a controller (or controller circuitry) <NUM>, <NUM>. Each of the controllers <NUM>, <NUM> may be, for example, a microprocessor, a CPU, or a dedicated chipset, etc..

As shown in the example of <FIG>, the transceiver circuitry <NUM> and the controller circuitry <NUM> of the communications device <NUM> are configured in combination, to operate <NUM> in accordance with a configured grant (CG) mode of operation, the CG mode of operation comprising the communications device <NUM> being configured to determine <NUM> (e.g. via an activation indication or other such command received from the wireless communications network, such as from infrastructure equipment <NUM>) a sequence of instances of uplink communications resources of the wireless access interface, and to transmit <NUM> signals to the wireless communications network (for example, to the infrastructure equipment <NUM>) in at least one instance of the sequence of instances of uplink communications resources of the wireless access interface, to transmit <NUM> uplink data, to the wireless communications network (for example, to the infrastructure equipment <NUM>), in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data (where each instance may comprise one or more repetitions of the same PUSCH), and to transmit <NUM> one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network (for example, from the infrastructure equipment <NUM>), each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the communications device <NUM> is configured to transmit <NUM>, <NUM> the uplink data and the CG-UCI such that the one or more transmitted <NUM> versions of CG-UCI are each repeated a plurality of times during the transmission <NUM> of the uplink data. Here, CG-UCI may be understood as UCI that relates to the CG mode of operation, but which doesn't exclusively carry information that relates to CG; for example, as described above, the CG-UCI may also carry COT sharing information.

In at least some embodiments, the uplink data transmission may be a URLLC data transmission, and wherein the information indicated by the one or more indicators of the CG-UCI is specific to URLLC transmissions. However, those skilled in the art would appreciate that embodiments of the present technique could be equally applied to transmissions other than URLLC transmissions, for example eMBB transmissions or unlicensed band transmissions (NR-U), and so the one or more new indicators in the CG-UCI may equally be used for the transmission of data related to services other than URLLC.

In at least some embodiments, each of the plurality of versions of CG-UCI indicate different control information, and wherein each of the plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface associated with a version of the CG-UCI are associated with the same control information indicated by that version of the CG-UCI. Here, the control information may comprise one of a plurality of redundancy versions (RVs).

Essentially, such embodiments of the present technique as illustrated by the example of <FIG> propose that a PUSCH may be repeated consecutively for a number of repetitions within a longer set of PUSCH repetitions. The reliability of the CG-UCI coding may then be increased within that number of consecutive repetitions by repeating the CG-UCI within those PUSCH repetitions. It is necessary to repeat the CG-UCI within PUSCH repetitions having the same characteristics (e.g. RV), because there would otherwise be no benefit to the repetitions; CG-UCIs indicating different RVs or the like would not be combinable at the receiver (e.g. gNB) in order to increase the reliability of the CG-UCI. While RVs are described herein as the information within the CG-UCI that changes between PUSCH repetitions and thus requires repetition of CG-UCI within PUSCH repetitions, those skilled in the art would appreciate that this could be any field(s) within the CG-UCI other than (or in addition to) RV.

In at least some arrangements of embodiments of the present technique, the CG-UCI information may be repeated for XUCIREP units of physical resource. The PUSCH that is associated with the CG-UCI has the same characteristic (where the "characteristic" includes HPN, RV, NDI and COT Sharing Information) for those XUCIREP repetitions.

For example, the CG-UCI is repeated for XUCIREP slots and the PUSCH is also repeated for those XUCIREP slots. In an example implementation as shown in <FIG>, XUCIREP =<NUM> for a PUSCH with K=<NUM> repetitions, although those skilled in the art would appreciate that XUCIREP could be greater than <NUM> and indeed this may increase reliability of the CG-UCI but at the cost of increased overhead and latency. For example, the <NUM>st and <NUM>nd repetitions use RV=<NUM>, <NUM>d and <NUM>th repetitions use RV=<NUM>, <NUM>th and <NUM>th repetitions use RV=<NUM> and <NUM>th and <NUM>th repetitions use RV=<NUM>.

In some arrangements of embodiments of the present technique, the unit of physical resource is a timeslot. In other words, the one or more transmitted versions of CG-UCI are each repeated one or more times within a plurality of time-divided slots of the wireless access interface, wherein each of the time-divided slots contains one of the two or more instances carrying the repetitions of the uplink data. This mode of operation is shown in <FIG>.

In some other arrangements of embodiments of the present technique, the unit of physical resource is a sub-slot. In other words, the one or more transmitted versions of CG-UCI are each repeated one or more times within a plurality of time-divided sub-slots of the wireless access interface, wherein each of the time-divided sub-slots contains one of the two or more instances carrying the repetitions of the uplink data. In such arrangements, the PUSCH occupies a sub-slot, where the sub-slot can for example have a duration of <NUM> OFDM symbols, and the CG-UCI occupies OFDM symbols within the sub-slot. This mode of operation is similar to the arrangements described above with respect to <FIG>; the difference being that the time axis is enumerated in units of sub-slot rather than in units of slot.

It will be evident from <FIG> that the gNB needs to receive and buffer multiple timeslots before it is able to decode the PUSCH. For example, with reference to <FIG>, the gNB needs to buffer the first timeslot and the second timeslot before it is able to decode the CG-UCI and hence decode the PUSCH. i.e. in order to process the PUSCH repetition RV0 (repeated across slots A and B), the gNB needs to receive the CG-UCI in both slots A and B (and combine the CG-UCI in slots A and B). Once it has received the CG-UCI that is repeated across slots A and B, the gNB can determine that RV0 had been used to encode the PUSCH in slots A and B and hence perform physical channel processing of the PUSCH that is repeated across slots A and B. Hence, in this example, the gNB can start physical channel processing of the PUSCH received in slots A and B at time TB. The gNB will have had to buffer the PUSCH across slots A and B until TB, after which the gNB would know how to perform physical channel processing of the buffered PUSCH. Here, it should be noted that physical channel processing entails functions such as determining which parity and systematic bits are contained in the PUSCH and the interleaver pattern applied to the PUSCH physical channel bits.

In some other arrangements of embodiments of the present technique, the unit of physical resource is a Transmission Occasion. In other words, the one or more transmitted versions of CG-UCI are each repeated one or more times within one or more of the sequence of instances of uplink communications resources of the wireless access interface.

The gNB buffering requirement described above can be averted if the repetitions of the CG-UCI are staggered with respect to the PUSCH to which they refer, as illustrated in <FIG> shows:.

Thus, as is shown by the example of <FIG>, at least one CG-UCI repetition of at least one of the transmitted versions of CG-UCI is included earlier in time during the transmission of the uplink data than an earliest of the two or more instances associated with the at least one of the transmitted versions of CG-UCI.

The CG-UCI repetitions can occur within the first repetition of a set of PUSCH repetitions that are all encoded with the same RV. In this case, the gNB can reliably repetition decode the CG-UCI within the first PUSCH repetition and then repetition decode the following PUSCH repetitions that are all encoded with the same RV. In other words, all CG-UCI repetitions of at least one of the transmitted versions of CG-UCI are included in an earliest of the two or more instances associated with the at least one of the transmitted versions of CG-UCI. An example of such arrangements is shown in <FIG> shows:.

In some arrangements of embodiments of the present technique, the CG-UCI repetitions occur within the central portion of a PUSCH repetition when the RV changes (as shown in <FIG>). In other words, all CG-UCI repetitions of the at least one of the transmitted versions of CG-UCI are located substantially in the middle of the earliest of the two or more instances associated with the at least one of the transmitted versions of CG-UCI.

<FIG> shows CG-UCI repetitions being repeated within the middle of a PUSCH repetition, but a those skilled in the art would appreciate that the CG-UCI repetitions could alternatively be located within other parts of the PUSCH repetition. An example is shown in <FIG>, where the CG-UCI repetitions are located in the start and end symbols (OFDM symbols or SC-FDMA symbols) of a slot containing a PUSCH repetition.

In some other arrangements of embodiments of the present technique, the CG-UCI repetitions occur within the first and last symbols (OFDM or SC-FDMA) of a PUSCH repetition when the RV changes (as shown in <FIG>). In other words, all CG-UCI repetitions of the at least one of the transmitted versions of CG-UCI are located substantially in at least one end of the earliest of the two or more instances associated with the at least one of the transmitted versions of CG-UCI.

In some other arrangements of embodiments of the present technique, the PUSCH is transmitted together with a CG-UCI within a restricted number of OFDM or SC-FDMA symbols and an additional CG-UCI is transmitted within other OFDM or SC-FDMA symbols. In other words, a first CG-UCI repetition of the at least one of the transmitted versions of CG-UCI is located within the earliest one of the two or more instances associated with the at least one of the transmitted versions of CG-UCI, and a second CG-UCI repetition of the at least one of the transmitted versions of CG-UCI is located subsequently in time to the earliest one of the two or more instances associated with the at least one of the transmitted versions of CG-UCI (i.e. outside of the CG-PUSCH resources, for example, directly afterwards). For example, the gNB configures the UE with a <NUM> OFDM symbol PUSCH that contains within it a <NUM> OFDM symbol CG-UCI, where the <NUM> OFDM symbols start at the first OFDM symbol of the slot. This arrangement can be configured using existing Rel-<NUM> PUSCH configuration signaling. The UE is further configured with a CG-UCI transmission within the last two OFDM symbols, where this CG-UCI carries identical control information to that contained within the previously configured CG-UCI. The gNB can hence combine the two CG-UCI. This example has the benefit of minimizing specification changes and simplifies implementation.

In an alternative example, the repeated CG-UCI may be transmitted earlier than the earliest one of the two or more instances associated with the at least one of the transmitted versions of CG-UCI. In other words, a first CG-UCI repetition of the at least one of the transmitted versions of CG-UCI is located within the earliest one of the two or more instances associated with the at least one of the transmitted versions of CG-UCI, and a second CG-UCI repetition of the at least one of the transmitted versions of CG-UCI is located earlier in time than the earliest one of the two or more instances associated with the at least one of the transmitted versions of CG-UCI. For example, the gNB configures the UE with a <NUM> OFDM symbol PUSCH that contains within it a <NUM> OFDM symbol CG-UCI, where the <NUM> OFDM symbols start at the <NUM>rd OFDM symbol of the slot. This arrangement can be configured using existing Rel-<NUM> PUSCH configuration signaling. The UE is further configured with a CG-UCI transmission within the first two OFDM symbols, where this CG-UCI carries identical control information to that contained within the previously configured CG-UCI. The gNB can hence combine the two CG-UCI.

Generally, in such arrangements of embodiments of the present technique as described above with respect to <FIG>, the CG-UCI repetitions occur within some known positions within a PUSCH repetition in which the RV changes. In other words, all CG-UCI repetitions of all of the one or more transmitted versions of CG-UCI are located in a position of the earliest of the two or more instances associated with the at least one of the transmitted versions of CG-UCI known to the wireless communications network.

In some arrangements of embodiments of the present technique, the CG-UCI repetitions can occur within the first PUSCH repetition (or first few repetitions) and subsequent PUSCH repetitions do not carry CG-UCI or carry fewer information bits within the CG-UCI. In other words, all CG-UCI repetitions of all of the transmitted versions of CG-UCI are included in an earliest of the two or more instances.

Such arrangements allow the gNB to benefit from the repetition decoding gain of the CG-UCI and don't require the gNB to buffer PUSCHs. <FIG> shows an example of operation of such arrangements, where the CG-UCI for all PUSCH repetitions are sent within the first two slots of a PUSCH that is <NUM> timeslots in length. Since the gNB receives the CG-UCI early, it can repetition decode the CG-UCI before buffering the associated PUSCH. <FIG> shows:.

An alternative arrangement of embodiments of the present technique is shown in <FIG> shows that a cluster of repeated CG-UCI may be transmitted at the start of a set of PUSCH repetitions and a second cluster is sent at a later time within the set of PUSCH repetitions. In other words, all CG-UCI repetitions of one or more of the transmitted versions of CG-UCI are included in an earliest of the two or more instances, and all CG-UCI repetitions of the others of the transmitted versions of CG-UCI are included in at least one later instance of the two or more instances. This arrangement avoids the situation where one of the PUSCH redundancy versions is significantly adversely affected, for example due to channel fading during the transmission of that PUSCH redundancy version.

While the above-described arrangements of embodiments of the present technique have described and demonstrated how the reliability of CG-UCI can be increased when a PUSCH is repeated through repetition of the CG-UCI, it is necessary for the UE to know where the boundaries of the new CG-UCI should be within the PUSCH repetitions. It is proposed that the CG-UCI is repeated in known PUSCH repetitions or follows a predefined order. In other words, the one or more transmitted versions of CG-UCI are each repeated one or more times within at least one of the two or more instances, the at least one of the two or more instances being known to the wireless communications network. Alternatively (or in addition), the one or more transmitted versions of CG-UCI are each repeated one or more times within at least one of the two or more instances in accordance with a predefined pattern, the predefined pattern being known to the wireless communications network.

An implementation of the said known PUSCH repetition or predefined order is that the CG-UCI is repeated in two consecutive PUSCH repetitions starting from the first PUSCH repetition; e.g. if PUSCH has <NUM> repetitions, the <NUM>st and <NUM>nd repetitions have the same CG-UCI and the <NUM>m and <NUM>th repetitions have the same CG-UCI, but the CG-UCI in the <NUM>rd and <NUM>th repetitions may be different to that in the <NUM>st & <NUM>nd repetition. Here the gNB can then combine the CG-UCI in the <NUM>st & <NUM>nd repetition and the <NUM>rd with the <NUM>th repetition. An example of the predefined order is that every odd numbered repetition has the same CG-UCI.

The said predefined order or known PUSCH repetition where CG-UCI is repeated can be RRC configured, signalled in an activation DCI or fixed in the specifications. That is, the at least one of the two or more instances and/or the predefined pattern are configured by Radio Resource Control, RRC, signalling received by the communications device from the wireless communications network. Alternatively (or in addition), the at least one of the two or more instances and/or the predefined pattern are indicated in Downlink Control Information, DCI, received by the communications device from the wireless communications network, the DCI indicating that the sequence of instances of uplink communications resources of the wireless access interface are active and may be used by the communications device to transmit signals to the wireless communications network. Alternatively (or in addition), the at least one of the two or more instances and/or the predefined pattern are predetermined and known to both the communications device and the infrastructure equipment.

As shown in the example of <FIG>, the transceiver circuitry <NUM> and the controller circuitry <NUM> of the communications device <NUM> are configured in combination, to operate <NUM> in accordance with a configured grant (CG) mode of operation, the CG mode of operation comprising the communications device <NUM> being configured to determine <NUM> (e.g. via an activation indication or other such command received from the wireless communications network, such as from infrastructure equipment <NUM>) a sequence of instances of uplink communications resources of the wireless access interface, and to transmit <NUM> signals to the wireless communications network (for example, to the infrastructure equipment <NUM>) in at least one instance of the sequence of instances of uplink communications resources of the wireless access interface, to transmit <NUM> uplink data, to the wireless communications network (for example, from the infrastructure equipment <NUM>), in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data (where each instance may comprise one or more repetitions of the same PUSCH), and to transmit <NUM> one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network (for example, from the infrastructure equipment <NUM>), each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the communications device <NUM> is configured to transmit <NUM>, <NUM> the uplink data and the CG-UCI such that the one or more transmitted versions of CG-UCI are each transmitted <NUM> as two or more separate portions, each of the two or more portions being transmitted <NUM> within different instances of the two or more instances during the transmission <NUM> of the uplink data.

Essentially, such embodiments of the present technique as illustrated by the example of <FIG> propose that a PUSCH may be repeated consecutively for a number of repetitions within a longer set of PUSCH repetitions. The reliability of the CG-UCI coding may then be increased within that number of consecutive repetitions by decreasing the number of bits within the CG-UCI through including portions of the CG-UCI in different places within the repetitions, thus reducing the code rate of the CG-UCI.

In such embodiments of the present technique, when repetitions are applied (or more specifically, when more than a threshold number of repetitions are applied), the CG-UCI may be sub-divided (or partitioned, or segmented) and transmitted within separate PUSCH repetitions. The sub-divided CG-UCI are hence compact UCI compared to the original CG-UCI.

In an example, the CG-UCI consists of {HPN, RV, NDI, COT sharing information}. At a low number of PUSCH repetitions, these information fields are transmitted within a single CG-UCI and within a single PUSCH. At a larger number of repetitions (e.g. when the number of PUSCH repetitions is higher than a threshold), the information bits are split into two CG-UCI:.

The split CG-UCI are then transmitted within different PUSCH repetitions. An example is shown in <FIG> (it should be noted here that the time extent of the CG-UCI is exaggerated in <FIG> for ease of understanding). <FIG> shows the following:.

Those skilled in the art would appreciate that since the number of information bits per CG-UCI has been reduced, while the number of physical bits used to transmit the CG-UCI remains the same, the reliability of the uplink control information is increased (i.e. CG-UCI1, which contains half the number of information bits as CG-UCI, transmitted without repetition, is expected to have the same reliability as / similar reliability to CG-UCI with two repetitions. In both cases, the effective code rate is the same).

It should be appreciated that, with respect to the embodiments of the present technique as described with respect to <FIG> and <FIG>, different aspects of the CG-UCI can be updated / changed at different times. For example, the RV can be updated in slot A or slot C while the COT sharing information can be updated at slot B or slot D.

Those skilled in the art would appreciate that operation of a UE (or communications device) as described with respect to <FIG> and <FIG> could be combined with the operation of a UE as described with respect to <FIG>; that is a UE may transmit repetitions of portions of CG-UCI within PUSCH repetitions comprising uplink data. Those skilled in the art would understand that any embodiment or example as disclosed herein with respect either to the embodiments described by way of <FIG> or to the embodiments described by way of <FIG> and <FIG> is able to be combined with any other.

While the above-described arrangements of embodiments of the present technique have described and demonstrated how the reliability of CG-UCI can be increased when a PUSCH is repeated through segmentation of the CG-UCI, it is necessary for the UE to know where the boundaries of the new CG-UCI should be within the PUSCH repetitions. It is proposed that the first sub-divided portion of a CG-UCI is transmitted in known PUSCH repetitions or follows a predefined order. In other words, the different instances of the two or more instances containing the two or more separate portions are known to the wireless communications network. Alternatively (or in addition), the two or more separate portions are transmitted within the different instances of the two or more instances in accordance with a predefined pattern, the predefined pattern being known to the wireless communications network.

For example, an implementation of the said known PUSCH repetition or predefined order is that CG-UCI1 is transmitted in the <NUM>st PUSCH repetition and CG-UCI2 is transmitted in the <NUM>nd PUSCH repetition. The <NUM>rd PUSCH repetition contains a CG-UCI1, where this CG-UCI1 may have different contents to the CG-UCI1 in the <NUM>st PUSCH repetition and the <NUM>th repetition contains a CG-UCI2, where this CG-UCI2 may have different contents to the CG-UCI2 in the <NUM>nd PUSCH repetition. An example of the predefined order is that odd numbered PUSCH repetitions carry CG-UCI1 and odd numbered PUSCH repetitions carry CG-UCI2.

The said predefined order or known PUSCH repetition where CG-UCI is repeated can be RRC configured, signalled in an activation DCI or fixed in the specifications. That is, the different instances of the two or more instances and/or the predefined pattern are configured by Radio Resource Control, RRC, signalling received by the communications device from the wireless communications network. Alternatively (or in addition), the different instances of the two or more instances and/or the predefined pattern are indicated in Downlink Control Information, DCI, received by the communications device from the wireless communications network, the DCI indicating that the sequence of instances of uplink communications resources of the wireless access interface are active and may be used by the communications device to transmit signals to the wireless communications network. Alternatively (or in addition), the different instances of the two or more instances and/or the predefined pattern are predetermined and known to both the communications device and the infrastructure equipment.

<FIG> shows a flow diagram illustrating a first example process of communications in a communications system in accordance with embodiments of the present technique. The process shown by <FIG> is a method of operating a communications device configured to transmit data to a wireless communications network (e.g. to an infrastructure equipment) via a wireless access interface.

The method begins in step S11. The method comprises, in step S12, operating in accordance with a configured grant (CG) mode of operation. In step S13, the process comprises transmitting uplink data to the wireless communications network in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data. In step S14, the method comprises transmitting one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network, each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the one or more transmitted versions of CG-UCI are each repeated a plurality of times during the transmission of the uplink data. The process ends in step S15.

<FIG> shows a flow diagram illustrating a second example process of communications in a communications system in accordance with embodiments of the present technique. The process shown by <FIG> specifies more in-depth operation of a communications device operating in accordance with a configured grant (CG) mode of operation such as the CG mode of operation as referred to in step S12 of the method illustrated by <FIG>.

The method begins in step S21. The method comprises, in step S22, determining a sequence of instances of uplink communications resources of a wireless access interface (e.g. through reception of an activation (or other) indication or a command defining such a sequence from a wireless communications network, for example from an infrastructure equipment of the wireless communications network). In step S23, the method comprises transmitting signals to the wireless communications network in at least one instance of the sequence of instances of uplink communications resources of the wireless access interface. The process ends in step S24.

<FIG> shows a flow diagram illustrating a third example process of communications in a communications system in accordance with embodiments of the present technique. The process shown by <FIG> is a method of operating a communications device configured to transmit data to a wireless communications network (e.g. to an infrastructure equipment) via a wireless access interface.

The method begins in step S31. The method comprises, in step S32, operating in accordance with a configured grant (CG) mode of operation (again, here, <FIG> specifies more in-depth details of a communications device operating in accordance with a configured grant (CG) mode of operation such as the CG mode of operation as referred to here in step S32 of the method illustrated by <FIG>). In step S33, the process comprises transmitting uplink data to the wireless communications network in two or more instances of the sequence of instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data. In step S34, the method comprises transmitting one or more of a plurality of versions of uplink control information, CG-UCI, to the wireless communications network, each version of CG-UCI being associated with a plurality of instances of the sequence of instances of uplink communications resources of the wireless access interface. Here, the one or more transmitted versions of CG-UCI are each transmitted as two or more separate portions, each of the two or more portions being transmitted within different instances of the two or more instances during the transmission of the uplink data. The process ends in step S35.

Those skilled in the art would appreciate that the methods shown by <FIG>, and <FIG> may be adapted in accordance with embodiments of the present technique. For example, other intermediate steps may be included in either or both of these methods, or the steps may be performed in any logical order.

Though embodiments of the present technique have been described largely by way of the example communications system shown in <FIG> and <FIG>, and described with respect to the examples in <FIG> and <FIG>, it would be clear to those skilled in the art that they could be equally applied to other systems to those described herein.

Whilst embodiments of the present technique have been largely described with respect to uplink CG resources, and uplink control information relating to such resources, those skilled in the art would appreciate that embodiments of the present technique could be correspondingly applied to any kind of resources in the uplink, downlink, or sidelink. For example, downlink control information (DCI) may be transmitted in accordance with repetitions or segmentation as herein-described within PDSCH repetitions in the downlink within semi-persistent scheduling (SPS) resources or the like where such DCI may change between PDSCH repetitions. Such applications of the described embodiments, with respect to uplink downlink, and sidelink communications, are within the scope of the present disclosure.

Those skilled in the art would further appreciate that such infrastructure equipment and/or communications devices as herein defined may be further defined in accordance with the various arrangements and embodiments discussed in the preceding paragraphs. It would be further appreciated by those skilled in the art that such infrastructure equipment and communications devices as herein defined and described may form part of communications systems other than those defined by the present disclosure.

Claim 1:
A method of operating a communications device (<NUM>) configured to transmit data to a wireless communications network via a wireless access interface, the method comprising
operating (<NUM>) in accordance with a configured grant, CG, mode of operation, the CG mode of operation comprising determining (<NUM>) a sequence of time instances of uplink communications resources of the wireless access interface and transmitting (<NUM>) signals to the wireless communications network in at least one instance of the sequence of time instances of uplink communications resources of the wireless access interface,
transmitting (<NUM>) uplink data to the wireless communications network in two or more instances of the sequence of time instances of uplink communications resources of the wireless access interface as a plurality of repetitions of the uplink data, and
transmitting (<NUM>) one or more of a plurality of versions of uplink control information, CG-UCI, associated with the uplink data to the wireless communications network, each version of CG-UCI being associated with a plurality of instances of the sequence of time instances of uplink communications resources of the wireless access interface,
wherein the one or more transmitted versions of CG-UCI are each repeated a plurality of times during the transmission of the uplink data.