Patent Description:
The present invention claims the Paris Convention priority of European patent application number <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. The contribution 3GPP TSG RAN WG1 #<NUM> R1-<NUM>, titled "UCI enhancements for URLLC", by Fujitsi, XP51728034, relates to collision handling of UCI piggyback on PUSCH with different priorities.

Embodiments of the present technique can provide a method of operating a communications device in a wireless communications network. The method comprises receiving, determining that the communications device should transmit at least two uplink signals to the wireless communications network, wherein the uplink signals are each to be transmitted in a set of uplink resources of a wireless access interface, determining that the set of uplink radio resources in which a first of the uplink signals should be transmitted at least partially overlaps the set of uplink radio resources in which a second of the uplink signals should be transmitted, wherein the first uplink signal has a different one of a plurality of physical layer priority levels to the second uplink signal, and detecting an indication of whether the first uplink signal and the second uplink signal should be multiplexed. If the indication indicates that the first uplink signal and the second uplink signal should be multiplexed, the method further comprises multiplexing the first uplink signal and the second uplink signal into a third uplink signal, and transmitting the third uplink signal. If the indication indicates that the first uplink signal and the second uplink signal should not be multiplexed, the method further comprises transmitting only the one of the first uplink signal and the second uplink signal that has a higher physical layer priority level. 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>, <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 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. The requirements for Ultra Reliable and Low Latency Communications (URLLC) services are for a reliability of <NUM> - <NUM>-<NUM> (<NUM> %) or higher for 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>% to <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>] 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 Physical Uplink Control Channels (PUCCHs) carrying Hybrid Automatic Repeat Request Acknowledgement (HARQ-ACK) feedback per slot, and to support multiple HARQ-ACK codebooks for different traffic services. Another objective, detailed in [<NUM>], is to further enhance the eURLLC feature by introducing intra-UE multiplexing of uplink transmissions with different Physical Layer priority levels.

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 a PUCCH colliding with a PUSCH, or a PUCCH colliding with another PUCCH. It would be appreciated by those skilled in the art that although there are no priority levels defined in Rel-<NUM> for the Physical Layer, priority levels are defined for the Medium Access Control (MAC) Layer in Rel-<NUM>, where there are <NUM> priority levels.

The PUCCH carries Uplink Control Information (UCI), such as HARQ-ACK feedback for PDSCH, Scheduling Requests (SRs) and Channel State Information (CSI). There are <NUM> PUCCH formats, namely Format <NUM>, <NUM>, <NUM>, <NUM> & <NUM>. PUCCH Format <NUM> carries up to <NUM> HARQ-ACK bits and a positive SR. PUCCH Format <NUM> carries up to <NUM> bits of information which can be either <NUM> HARQ-ACK bits or <NUM> HARQ-ACK & <NUM> SR bit. PUCCH Formats <NUM>, <NUM> & <NUM> can carry more than <NUM> bits, which can consist of HARQ-ACK, SRs and CSI. It should be noted that HARQ-ACK is a term of art used to describe HARQ feedback for a PDSCH, where despite the name the feedback itself can be either a positive acknowledgement (termed "ACK") or a negative acknowledgement (termed "NACK").

A HARQ-ACK feedback is transmitted to the gNB, in response to Physical Downlink Shared Channel (PDSCH) scheduling, to inform the gNB whether the UE has successfully decoded the PDSCH or not. For a PDSCH ending in slot n, the corresponding PUCCH carrying the HARQ-ACK is transmitted in slot n+K<NUM>, where the value of K<NUM> is indicated in the field "PDSCH-to-HARQ_ feedback timing indicator" of the DL Grant (carried by Downlink Control Information (DCI) Format 1_0 or DCI Format 1_1). The PUCCH resource used is indicated in the "PUCCH Resource Indicator" (PRI) field of the DL Grant.

Multiple (different) PDSCHs can point to the same slot for transmissions of their respective HARQ-ACKs and the bits of these HARQ-ACKs (in the same slot) are then multiplexed by the UE into a single PUCCH, where the PUCCH resource is determined by the DL Grant scheduling the last PDSCH. Hence, a PUCCH can contain multiple HARQ-ACKs for multiple PDSCHs. An example is shown in <FIG>, in which three DL Grants are transmitted to the UE via DCI#<NUM>, DCI#<NUM> and DCI#<NUM> in slot n, n+<NUM> and n+<NUM> respectively. DCI#<NUM>, DCI#<NUM> and DCI#<NUM> schedule PDSCH#<NUM>, PDSCH#<NUM> and PDSCH#<NUM> respectively. DCI#<NUM>, DCI#<NUM> and DCI#<NUM> further indicate K<NUM>=<NUM>, K<NUM>=<NUM> and K<NUM>=<NUM> respectively. Since the K<NUM> values indicate that the HARQ-ACK feedbacks for PDSCH#<NUM>, PDSCH#<NUM> and PDSCH#<NUM> are all transmitted in slot n+<NUM>, the UE multiplexes all three of these HARQ-ACKs into a single PUCCH. The PUCCH Multiplexing Window is a time window during which PDSCHs can be multiplexed into that single PUCCH, where this PUCCH Multiplexing Window depends on the range of K<NUM> values. In the example shown by <FIG>, the PUCCH Multiplexing Window is from Slot n to Slot n+<NUM>, which means the max K<NUM> value is <NUM> slots.

The PUCCH resource is determined based on the DL Grant scheduling the last PDSCH in the PUCCH Multiplexing Window, since the UE only knows the total number of HARQ-ACK bits after the last PDSCH is received. Additionally, the UE follows the PUCCH Resource Indicator (PRI) in the DL Grant of the last PDSCH to determine which PUCCH resource within a PUCCH resource set to use. In the example in in <FIG>, since PDSCH#<NUM> is the last PDSCH to be scheduled with corresponding PUCCH in slot n+<NUM>, the HARQ-ACKs for all these PDSCHs with corresponding PUCCH in that slot are multiplexed together using PUCCH#<NUM>, which is associated with PDSCH#<NUM>.

When a PUCCH carrying a positive SR (i.e. SR is triggered) collides with another PUCCH carrying a HARQ-ACK, the multiplexing of SR & HARQ-ACK depends on the PUCCH format used. This is summarised in Table I below. It should be noted that for Scenario <NUM> in Table I below, a positive SR is not transmitted.

CSI reports can be configured to be periodic, aperiodic or semi-persistent. Periodic CSI is transmitted using PUCCH, where the CSI report is sent periodically. Aperiodic CSI is transmitted using PUSCH and is triggered by a CSI Request field in the UL Grant, where only a single CSI report is sent. In semi-persistent CSI, the CSI report is sent periodically once it is activated by lower layers and is stopped when deactivated by lower layers. Semi-persistent CSI can be configured to transmit on PUSCH or PUCCH, where semi-persistent CSI on PUSCH is activated & deactivated by DCI whilst semi-persistent on PUCCH is activated & deactivated by MAC Control Element (CE).

In Rel-<NUM>, when a PUCCH carrying CSI collides with another PUCCH carrying HARQ-ACK with or without SR, the UE multiplexes the CSI & HARQ-ACK/SR if the RRC parameter "simultaneousHARQ-ACK-CSI" is set to TRUE. Otherwise the UE drops the CSI. This parameter is part of the PUCCH configuration and hence is applicable to all PUCCH transmissions in the UE. The PUCCH resource used to transmit the multiplexed UCI (CSI & HARQ-ACK/SR) is selected from all the overlapping PUCCHs.

In Rel-<NUM>, when UCI carried by PUCCH (or CSI carried by PUSCH) collides with PUSCH carrying data, the UCI bits and data bits are multiplexed and transmitted on the PUSCH. The multiplexing is done by piggybacking the UCI onto the PUSCH resource, i.e. some of the allocated PUSCH resources are used to carry the UCI, which will reduce the resources for the PUSCH data. The HARQ-ACK bits are multiplexed first, and are followed by CSI bits. The number of resources (i.e. Resource Elements) that can be used is determined by two parameters, an offset βPUSCH and a scaling factor α. The βPUSCH offset is signalled by the DCI carrying the UL Grant for the PUSCH using the "beta_offset indicator" field, which indicates one of four configured βPUSCH offset values. These four βPUSCH offset values are selected from a table which is defined in [<NUM>], where the minimum value is <NUM>, i.e. βPUSCH ≥ <NUM>. The scaling factor α = {<NUM>, <NUM>, <NUM>, <NUM>} is RRC configured, and this scaling factor sets the maximum number of REs (Resource Elements) as a percentage of the number of PUSCH REs that can be used for UCI.

The multiplexing procedure is summarised in the flow chart in <FIG>. When a PUCCH & PUSCH collide, which is determined in step S501, the UE calculates in step S503 the number of HARQ-ACK bits OACK and the number of CRC bits LACK. This is then multiplied by the βPUSCH indicated in the UL Grant (and determined by the UE in step S502) to determine the total bits required to carry these HARQ-ACKs. The βPUSCH offset is effectively the level of redundancies used for the HARQ-ACKs information. The UE then calculates in step S504 the number of modulated symbols QACK (where the modulation used depends on the scheduled PUSCH) and hence the number of REs (Resource Element) required. The UE then determines the maximum allowed PUSCH REs that can be used for UCI by multiplying the scaling factor α with the number of PUSCH REs MPUSCH. The UE checks in step S505 that QACK does not exceed this maximum REs and if it does (i.e. QACK > α MPUSCH) then the actual number of REs that can be used, as is determined by the UE in step S506, Q'ACK = α MPUSCH. Otherwise the actual number of REs is the calculated number of REs, i.e. Q'ACK = QACK, and is determined so by the UE in step S507. The UE then piggybacks the Q'ACK HARQ-ACK modulated symbols to the PUSCH where puncturing is used in step S509 for OACK ≤ <NUM> bits (which the UE checks in step S508), otherwise the PUSCH data symbols are rate matched in step S510 around Q'ACK symbols.

This process is then repeated for the CSI, i.e. UE calculates in step S511 the number of CSI bits OCSI and its CRC LCSI and multiply it with the offset βPUSCH. The UE determines in step S512 the number of modulated symbols QCSI and hence the number of REs required to carry the CSI. The UE then checks in step S513 that QCSI does not exceed the remaining PUSCH REs (α MPUSCH - Q'ACK), and if it does (i.e. QCSI > a MPUSCH - Q'ACK) then the actual number of REs for CSI Q'CSI takes up the remaining PUSCH REs in step S514, i.e. Q'CSI = α MPUSCH - Q'ACK. Otherwise, as determined by the UE in step S515, Q'CSI is the calculated number of CSI REs, i.e. Q'CSI = QCSI. For CSI, only rate matching is used, i.e. the PUSCH data is rate matched in step S516 around the Q'CSI modulated symbols. It should be noted that the CSI UCI may consists of two types, i.e. Type <NUM> CSI and Type <NUM> CSI, the multiplexing process is performed on Type <NUM> CSI first followed by Type <NUM> CSI. The process then ends in step S517.

The UCI-onto-PUSCH multiplexing prioritises HARQ-ACK bits followed by Type <NUM> CSI and finally Type <NUM> CSI. It should be noted that if there are not sufficient REs in the PUSCH, then part of the CSI bits are multiplexed, and if there are no REs left, the CSI may not be multiplexed.

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 arrives which would need to be scheduled immediately and transmission may collide with the eMBB transmission. In order to handle such intra-UE collisions with different latency & reliability requirements, two priority levels at the Physical Layer were introduced in Rel-<NUM>. In Rel-<NUM> intra-UE prioritisation is used, that is, when two UL transmissions with different Physical Layer priority levels collide, the UE will drop the lower priority transmission. If both UL transmissions have the same priority level, then the UE reuse Rel-<NUM> procedures as described in the previous sections.

It has been recognised that dropping lower priority transmissions can lead to inefficient resource usage. For example, dropping a PUCCH carrying HARQ-ACKs for multiple eMBB PDSCHs, due to collision with a high priority PUCCH/PUSCH, may result in multiple eMBB PDSCHs being retransmitted. Since each eMBB PDSCH consumes a large number of resources, such retransmissions will lead to inefficient utilisation of resources. Hence, one of the objectives of Rel-<NUM> eURLLC is to introduce intra-UE multiplexing of UL transmissions of different Physical Layer priority levels, i.e. allowing lower priority UL transmissions to be transmitted by multiplexing it with a higher priority UL transmission. Since in Rel-<NUM>, when two UL transmissions in the same UE collides, the UE will always drop the lower priority transmission, it presently isn't clear when or how the UE would known when to multiplex these UL transmissions in Rel-<NUM>. Embodiments of the present technique seek to provide solutions to such a problem, and allow for increased efficiency of resource usage.

<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. 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 determine <NUM> that the communications device should transmit at least two uplink signals to the wireless communications network, wherein the uplink signals are each to be transmitted in a set of uplink resources of a wireless access interface, to determine <NUM> that the set of uplink radio resources in which a first of the uplink signals should be transmitted at least partially overlaps the set of uplink radio resources in which a second of the uplink signals should be transmitted, wherein the first uplink signal has a different one of a plurality of physical layer priority levels to the second uplink signal, and to detect <NUM> an indication of whether the first uplink signal and the second uplink signal should be multiplexed, wherein, if the indication indicates that the first uplink signal and the second uplink signal should be multiplexed, the controller circuitry is configured in combination with the transceiver circuitry to multiplex <NUM> the first uplink signal and the second uplink signal into a third uplink signal, and to transmit <NUM> the third uplink signal, and wherein, if the indication indicates that the first uplink signal and the second uplink signal should not be multiplexed, the controller circuitry is configured in combination with the transceiver circuitry to transmit <NUM> only the one of the first uplink signal and the second uplink signal that has a higher physical layer priority level.

In at least some arrangements of embodiments of the present technique, each of the uplink signals to be transmitted to the wireless communications network may be based on a downlink signal, which indicates a set of uplink radio resources of the wireless access interface in which the each of the uplink signals should be transmitted.

Essentially, embodiments of the present technique propose that an intra-UE multiplexing indicator be introduced, where this multiplexing indicator (referred to below during the description of various embodiments and arrangements of the present technique as the indication) indicates whether the UE should multiplex colliding intra-UE transmissions of different (Physical Layer) priority levels or whether the UE should simply drop the lower priority one(s) in favour of transmitting only the highest priority transmission. It should be appreciated that, in reference to the third uplink signal in the present disclosure as the multiplexed signal, this third uplink signal may be one of the first uplink signal or second uplink signal (i.e. one of these signals is multiplexed onto the other), or occupy the resources in which one of the first uplink signal or second uplink signal have been scheduled. Alternatively, the third uplink signal may be a new, separate signal scheduled in resources other than (or partially overlapping) with the resources of either of the first or second uplink signals. This recognises that the legacy behaviour (i.e. Rel-<NUM>) is to always drop the lower priority transmission in favour of the higher priority one and hence an indicator is therefore required to stop the UE from dropping the lower priority, or at least part of the lower priority transmissions, in order to reduce wastage of resources. The intra-UE multiplexing indicator can be implicit, explicit or combination of implicit & explicit indicators which are described in the following arrangements below.

In some arrangements of embodiments of the present technique, the said intra-UE multiplexing indicator is an implicit indicator. That is, whether two UL transmissions can be multiplexed depends on the characteristics of the UL transmissions. In other words, the indication is implicit and is determined by the communications device on the basis of at least one of the first uplink signal and the second uplink signal. The following arrangements describe such characteristics.

In an arrangement of embodiments of the present technique, when two PUCCH transmissions of different Physical Layer priority levels collide, the UE multiplexes the UCIs of these two PUCCH if the total multiplexed UCI bits (OUCI = OUCI-URLLC + OUCI-eMBB + LUCI) do not exceed a threshold TUCI. Here OUCI- URLLC is the URLLC UCI bits, OUCI-eMBB is the number of eMBB UCI bits and LUCI is the CRC. For PUCCH Format <NUM> and Format <NUM>, there is no CRC bits, i.e. LUCI=<NUM>. If the total multiplexed UCI bits exceeds the threshold, i.e. OUCI > TUCI, the UE drops the lower priority PUCCH and transmit only the higher priority PUCCH. In other words, the first uplink signal comprises first uplink control information, and the second uplink signal comprises second uplink control information. Here, the indication may indicate that the first uplink signal and the second uplink signal should be multiplexed if the third uplink signal would comprise a total number of bits equal to or less than a threshold number of bits. Here, the total number of bits of the third uplink signal may be calculated by the communications device by adding a total number of bits of the first uplink control information, a total number of bits of the second uplink control information, and a number of bits of a Cyclic Redundancy Check, CRC, to be included within the third uplink signal.

In another arrangement of embodiments of the present technique, the said threshold TUCI is RRC configured. Separate thresholds can be configured for each PUCCH Physical Layer priority level. In other words, the threshold number of bits is configured via Radio Resource Control, RRC, signalling from the wireless communications network.

In another arrangement of embodiments of the present technique, the said threshold TUCI is dynamically indicated. This can be indicated in the DL Grant scheduling the PDSCH that is associated with the PUCCH or the UL Grant triggering an a-periodic CSI on a PUSCH. In other words, the threshold number of bits is indicated by the one of a plurality of downlink signals received by the communications device from the wireless communications network that schedules one of the first uplink signal and the second uplink signal, or alternatively, the threshold number of bits is indicated by one of the downlink signals, the one of the downlink signals indicating that the communications device should transmit an aperiodic Channel State Information, CSI, message which indicates one or more communications characteristics of an uplink data message transmitted by the communications device.

In another arrangement of embodiments of the present technique, the said threshold TUCI is a function of the Maximum Code Rate RUCI of the PUCCH. In legacy system (Rel-<NUM>), the Maximum Code Rate RUCI is RRC configured for the PUCCH (for all PUCCH Formats), which is used to determine the number of PRBs to use for the PUCCH transmission for a given number of UCI bits OUCI. In other words, the threshold number of bits is dependent on a maximum code rate, the maximum code rate being configured via RRC signalling from the wireless communications network (and indicating a number of physical resource blocks required for an uplink control channel which carries uplink control information comprising a given number of bits). In an implementation TUCI = γ × RUCI × NPUCCH, where γ is a parameter configured by RRC or indicated in the DCI (scheduling the DL Grant) and NPUCCH is the capacity of the PUCCH (in bits). For example, γ=<NUM> and so if the multiplexed UCI bits OUCI leads to the PUCCH exceeding its Maximum Code Rate, the UE drops the lower priority UCIs.

In another arrangement of embodiments of the present technique, when two PUCCH transmissions with different Physical Layer priority levels collide, the UE uses the PUCCH with the largest capacity NPUCCH. In other words, the third uplink signal is transmitted within the one of the set of uplink radio resources in which the first uplink signal was to be transmitted and the set of uplink radio resources in which the second uplink signal was to be transmitted which has the largest capacity.

In another arrangement of embodiments of the present technique, multiple Maximum Coding Rates RUCI can be configured for PUCCH with different Physical Layer priority levels. This allows the network to configure different RUCI values for URLLC PUCCH and eMBB PUCCH. In other words, a plurality of maximum code rates are configured via RRC signalling from the wireless communications network, each of the maximum code rates being associated with one of the plurality of physical layer priority levels (and indicating a number of physical resource blocks required for an uplink control channel which carries uplink control information comprising a given number of bits). For example, the network can configure URLLC PUCCH with a Maximum Coding Rate of RUCI-URLLC and eMBB PUCCH with a Maximum Coding Rate of RUCI-eMBB such that RUCI-URLLC < RUCI-eNBB.

In an arrangement of embodiments of the present technique, when a UCI transmission (e.g. on PUCCH) and a PUSCH with different priority level collide, these UL transmissions are multiplexed if the number of resources (i.e. Resource Elements) used for UCI on the PUSCH is less than a percentage threshold TPUSCH of the PUSCH REs otherwise the lower priority UL transmission is dropped. In other words, the first uplink signal comprises uplink control information (for example transmitted by the communications device in response to a downlink data message received by the communications device and having been scheduled by one of a plurality of downlink signals received by the communications device from the wireless communications network), and the second uplink signal comprises uplink data (which may be scheduled by one of the downlink signals). Here, the indication may indicate that the first uplink signal and the second uplink signal should be multiplexed if an amount of uplink radio resources of the wireless access interface required to transmit the uplink control information is equal to or less than a threshold percentage amount of the set of uplink radio resources in which the second uplink signal was to be transmitted.

In an implementation, the UE firstly calculates the HARQ-ACK bits OACK + CRC LACK as per Rel-<NUM> procedure (see <FIG> as discussed previously) and applies the βPUSCH offset to determine the number of REs, i.e. QACK required to carry the HARQ-ACK feedbacks. If QACK > TPUSCH × MPUSCH (where MPUSCH is the total REs scheduled for the PUSCH) then the UE drops the lower priority transmission. For example, if the PUSCH is URLLC and the HARQ-ACK is for eMBB PDSCH then if QACK> (TPUSCH × MPUSCH), the UE drops the HARQ-ACK bits, this is to ensure the URLLC PUSCH reliability is not compromised by eMBB UCI. In another example, if the PUSCH is eMBB and HARQ-ACK is for URLLC PDSCH then if QACK> (TPUSCH × MPUSCH), the UE drops the eMBB PUSCH and transmit only the HARQ-ACK for URLLC PDSCH. Here a high βPUSCH offset is expected for the URLLC HARQ-ACK and so if the number of REs exceed the threshold, it may not be worth transmitting the eMBB PUSCH as it may not have sufficient resources to carry both eMBB data and URLLC UCIs.

In another arrangement of embodiments of the present technique, the said threshold TPUSCH is a function of the scaling factor α. In other words, the threshold percentage amount is dependent on a scaling factor, the scaling factor being configured via RRC signalling from the wireless communications network (and indicating a maximum number of resource elements that can be used for an uplink control information message as a percentage of a number of resource elements of an uplink data channel which carries uplink data). In an implementation, TPUSCH = α. This arrangement can be used for the case where the PUSCH is lower priority (i.e. eMBB). This recognises that when QACK > α MPUSCH, the REs used to carry the URLLC HARQ-ACK is limited to the maximum allowed REs, i.e. Q'ACK = α MPUSCH, which is less than the required number of REs QACK. Since Q'ACK < QACK, the reliability requirement of the URLLC HARQ-ACK may not be met. Hence in such a scenario, it is better to drop the eMBB PUSCH and transmit the URLLC UCI bits using the required resources on the PUCCH to ensure the reliability requirement is met.

In another arrangement of embodiments of the present technique, the said threshold TPUSH ≤ α. In other words, the threshold percentage amount is equal to or less than the scaling factor. This arrangement is beneficial for the case where the PUSCH is higher priority (i.e. URLLC). It should be noted that the scaling factor α can be used for multiplexing of URLLC UCI onto URLLC PUSCH. The TPUSCH is used for multiplexing of eMBB UCI onto URLLC PUSCH and so it is beneficial to use a smaller value.

In another arrangement of embodiments of the present technique, the TPUSCH is RRC Configured. In other words, the threshold percentage amount is configured via RRC signalling from the wireless communications network. Different TPUSCH values can be configured for low priority transmission and high priority transmission. For example, eMBB PUSCH can be configured with TPUSCH = TPUSCH-eMBB whilst URLLC PUSCH can be configured with TPUSCH = TPUSCH-URLLC such that TPUSCH-eMBB > TPUSCH-URLLC, i.e. more REs can be used in an eMBB PUSCH compared to those in URLLC PUSCH.

In another arrangement of embodiments of the present technique, TPUSCH is indicated in the DCI. In other words, the threshold percentage amount is indicated by the one of a plurality of downlink signals received by the communications device from the wireless communications network that schedules one of the first uplink signal and the second uplink signal. In an implementation, the DCI carries the UL Grant for the PUSCH. This allows different values to be indicated for different PUSCH at different time thereby offering greater flexibility for the network scheduler.

In another arrangement of embodiments of the present technique, separate scaling factors α are configured for PUSCH with different Physical Layer priority level. That is, instead of having only a single scaling factor α for all PUSCH in Rel-<NUM>, this arrangement allows different scaling factors to be configured for URLLC & eMBB PUSCH. This recognises that eMBB and URLCC can tolerate different numbers of piggybacked UCI bits since they have different reliabilities. In other words, a plurality of scaling factors are configured via RRC signalling from the wireless communications network, each of the maximum code rates being associated with one of the plurality of physical layer priority levels (and indicating a maximum number of resource elements that can be used for an uplink control information message as a percentage of a number of resource elements of an uplink data channel which carries uplink data). For example, URLLC PUSCH is configured with scaling factor αURLLC and eMBB PUSCH is configured with scaling factor αeMBB such that αURLLC < αeMBB.

In some arrangements of embodiments of the present technique, the said intra-UE multiplexing indicator is an explicit indicator. This explicit indication may be explicitly indicated by at least one of the downlink signals, or may be configured via RRC signalling from the wireless communications network. Such explicit indications are described in the following arrangements.

In an arrangement of embodiments of the present technique the said intra-UE multiplexing is dynamically indicated. For the PUSCH, the DCI carrying the UL Grant for the PUSCH will indicate whether the PUSCH can be multiplexed with another UL transmission of a different priority. For the PUCCH, the DCI carrying the DL Grant for the PDSCH will indicate whether the corresponding PUCCH carrying HARQ-ACK can be multiplexed with another UL transmission of a different priority. In other words, the at least one of the downlink signals comprises a field indicating whether the one of the first uplink signal and the second uplink signal that is based on the at least one of the downlink signals can be multiplexed with another uplink signal of a different physical layer priority level to the one of the first uplink signal and the second uplink signal.

In another arrangement of embodiments of the present technique a new field in the DCI is introduced that indicates whether the PUSCH or the PUCCH can be multiplexed with another UL transmission (PUSCH/PUCCH) of a different priority level. In other words, the field is a new field specifically for carrying the indication. An implementation is a single bit indicating whether to multiplex or not.

In another arrangement of embodiments of the present technique an existing (Rel-<NUM> or Rel-<NUM>) field in the DCI is used to indicate whether the PUSCH or the PUCCH can be multiplexed with another UL transmission (PUSCH/PUCCH) of a different priority level. In other words, the field is an existing field repurposed for carrying the indication. It should be noted that this DCI field is ONLY used as multiplexing indicator only when there is a collision of two UL transmissions of different Physical Layer priority level. Otherwise it is used as per legacy system.

An example for PUCCH is to use one of the "PDSCH-to-HARQ_feedback timing indicator" in the DL Grant which indicates the slot or sub-slot (where the granularity of the K<NUM> value (i.e. the time difference between end of PDSCH and the start of its corresponding PUCCH) is smaller than a slot) of the PUCCH that carries HARQ-ACK for the PDSCH. Here, if there is a collision with different Physical Layer priority level, one of the values in the "PDSCH-to-HARQ_feedback timing indicator" would indicate "NOT MULTIPLEX" in addition to a K<NUM> value (otherwise the UE do not know where to transmit the PUCCH). If there is no collision of different Physical Layer priority levels, then all the values in "PDSCH-to-HARQ_feedback timing indicator" indicates only K<NUM> value.

In another arrangement of embodiments of the present technique, for the PUSCH, the "beta_offset indicator" (i.e. the offset βPUSCH used for UCI multiplexing onto PUSCH) field in the UL Grant is used to implicitly indicate whether UCI can be multiplexed onto the PUSCH. In other words, the existing field comprises an offset indicator indicating a value of one of a plurality of sets each comprising a plurality of values, the indicated value being for multiplication with a number of bits of third uplink signal to determine a total number of bits required for transmission of the third uplink signal. This field size is <NUM> bits indicating an index to one of <NUM> βPUSCH values. One of these βPUSCH values can be used to indicate that multiplexing is NOT allowed, when there is a collision of two UL transmissions of different Physical Layer priority level. It should be noted some prior art [<NUM>], [<NUM>] proposes the introduction of a new βPUSCH offset values such as βPUSCH = <NUM> or βPUSCH < <NUM>. For the case where βPUSCH = <NUM>, the UCI would be effectively dropped, regardless of priority level of the UCI. Here, in other words then, at least one of the values of at least one of the sets indicates that the first uplink signal and the second uplink signal should not be multiplexed. This arrangement does NOT propose any changes to the existing βPUSCH offset values, i.e. βPUSCH ≥ <NUM> because it recognises that the βPUSCH offset is also used to multiplex UCI that has the same Physical Layer priority level as the PUSCH. That is, if the UCI and the PUSCH have the same priority level then the βPUSCH values function as per legacy behaviour, i.e. indicates actual values.

In another arrangement of embodiments of the present technique, multiple sets of βPUSCH offset values can be configured for the "beta_offset indicator" in the UL Grant, where <NUM>st set is used if the UCI and the PUSCH has the same Physical Layer priority level, a <NUM>nd set is used if UCI has lower priority level than the PUSCH and a <NUM>rd set is used if UCI has higher priority level than the PUSCH. In other words, the set from which the value is indicated is dependent on whether the physical layer priority levels of the first uplink signal and the physical layer priority level of the second uplink signal are the same or different. An example configuration is shown in Table II, where <NUM> sets of βPUSCH offset values are configured. If the UCI is associated with eMBB and the PUSCH carries URLLC traffic, then the UE uses the <NUM>nd set βPUSCH offset values. NOTE, in this example, one of the entries for the <NUM>nd set βPUSCH offset values is indicated as "NOT MULTIPLEX" which means the UE drops the UCI of a lower Physical Layer priority level (i.e. one implementation of the previously described arrangement).

In another arrangement of embodiments of the present technique, different Physical Layer priority levels can be configured with different βPUSCH offset values. In Rel-<NUM>, a priority level indicator was introduced in the DCI that indicates the Physical Layer priority level of the PUSCH and so if this indicator indicates that PUSCH is high priority then the UE uses one configuration of βPUSCH offset values and if it indicates low priority the UE uses another configuration of βPUSCH offset values. Each βPUSCH offset configurations can have more than <NUM> set of values as per previous embodiment. In other words, the set from which the value is indicated is dependent on a determination made by the communications device, based on a priority indicator in the at least one of the downlink signals, of whether the physical layer priority level of one of the first uplink or the second uplink signal is a high physical layer priority level or a low physical layer priority level (here, what is "high" and what is "low" can be predetermined and known to the communications device, signalled by the wireless communications network, or implicit based on a comparison made by the communications device between the physical layer priority level of one of the first uplink or the second uplink signal and a physical layer priority level). An example is shown in Table III, where the set of βPUSCH offset values to use depends on whether the PUSCH is indicated in the UL Grant as high priority or low priority.

In another arrangement of embodiments of the present technique, the RNTI of the DCI is used to indicate whether the scheduled PUSCH or PUCCH can be multiplexed with another UL transmission of a different priority level. In other words, the indication is explicitly indicated by a Radio Network Temporary Identifier, RNTI, of the at least one of the downlink signals.

In another arrangement of embodiments of the present technique, the DCI format would indicate whether the scheduled PUSCH or PUCCH can be multiplexed with another UL transmission of a different priority level. In other words, the indication is explicitly indicated by a format of the at least one of the downlink signals.

As covered by the claims, the dynamic indicator can be in both DCIs associated with the colliding UL transmissions, e.g. if PUCCH collides with PUSCH or another PUCCH of different Physical Layer priority levels, a dynamic indicator can be in the DCI scheduling the PDSCH of the PUCCH and another dynamic indicator can be in the DCI of the UL Grant scheduling the PUSCH. In other words, the indication comprises a first dynamic indicator explicitly indicated by a first of the downlink signals on which the first uplink signal is based and a second dynamic indicator explicitly indicated by a second of the downlink signals on which the second uplink signal is based. If there are two indicators, then the following arrangements can be used (combined or independently) to interpret these indicators:.

Not covered by the claims, the dynamic indicator may be configured in only one of the DCIs associated with the colliding UL transmissions. For example, if PUCCH collides with PUSCH of different Physical Layer priority levels, a dynamic indicator is configured for the DCI scheduling the PDSCH of the PUCCH but the dynamic indicator is NOT configured for the DCI of the UL Grant scheduling the PUSCH. For this scenario, we have the following arrangement of embodiments of the present technique:.

In another arrangement of embodiments of the present technique, the said intra-UE multiplexing indicator is RRC configured, that is, the RRC will configure the UE to use Rel-<NUM> behaviour of dropping lower priority transmissions or use Rel-<NUM> behaviour of multiplexing transmissions of different priority levels. In other words, the indication is configured via RRC signalling from the wireless communications network. Here, in at least some implementations of this arrangement, the intra-UE multiplexing indicator is a single RRC parameter that switches between Rel-<NUM> (dropping lower priority transmission) or Rel-<NUM> (multiplexing) methods in handing intra-UE UL collisions.

In another arrangement of embodiments of the present technique, there is a list of different multiplexing schemes and the RRC configuration would configure which schemes to use in handling intra-UE UL collisions, i.e. they are multiple RRC parameters to configure. For example, the UE can be configured to use Rel-<NUM> method for collision between two PUCCH of different priority levels, i.e. dropping the lower priority PUCCH but use Rel-<NUM> method of multiplexing PUCCH and PUSCH when their transmissions collide. In other words, the indication is dependent on whether either the first uplink signal comprises uplink control information, or the first uplink signal comprises uplink data, and the indication is dependent on whether either the second uplink signal comprises uplink control information, or the second uplink signal comprises uplink data.

In another arrangement of embodiments of the present technique, the RRC will configure whether colliding uplink signals' transmission content can be multiplexed. The content can be data or UCI, where for the UCI, this can be a Scheduling Request (SR), HARQ-ACK and CSI. For example, the network can configure such that SR is not multiplex with another UL transmission of different Physical Layer priority level and so follows Rel-<NUM> methods whilst HARQ-ACK is always multiplexed when it collides with another UL transmission of different priority (i.e. Rel-<NUM> methods). In other words, the indication is dependent on transmission content carried by at least one of the first uplink signal and the second uplink signal.

In some arrangements of embodiments of the present technique, the UE uses combined explicit and implicit indicators to determine whether multiplexing or dropping is used when UL transmissions of different Physical Layer priority levels collide. In other words, the indication comprises an explicit indicator and an implicit indicator, the explicit indicator either being dynamically indicated by at least one of the downlink signals or being configured by RRC signalling from the wireless communications network, the implicit indicator being determined by the communications device on the basis of at least one of the first uplink signal and the second uplink signal.

In an arrangement of embodiments of the present technique the network can RRC configure to allow multiplexing but the UE still evaluates using one of the previously described implicit indicator arrangements (e.g. the total number of UCI bits) to decide whether to multiplex or drop the lower priority UL transmission. If RRC indicates that multiplexing is NOT allowed, the UE will not use any implicit indicator and will drop the lower priority transmission. In other words, if the explicit indicator indicates that the first uplink signal and the second uplink signal should not be multiplexed, the communications device is configured to determine that the indication is the explicit indicator, and subsequently to transmit only the one of the first uplink signal and the second uplink signal that has a higher physical layer priority level.

In another arrangement of embodiments of the present technique the network can dynamically indicate that multiplexing is allowed and the UE evaluates based on implicit indicator (e.g. total number of UCI bits or percentage of occupied PUSCH used for UCI) whether to multiplex or drop the lower priority UL transmission. If DCI indicates that multiplexing is not performed, the UE will not use the implicit indicator and will drop the lower priority transmission. In other words, if the explicit indicator indicates that the first uplink signal and the second uplink signal should be multiplexed, the method comprises determining that the indication is the implicit indicator.

In at least some arrangements of embodiments of the present technique, at least one of the first uplink signal and the second uplink signal may comprise uplink control information. Here, uplink control information may comprise periodic Channel State Information, CSI, which indicates one or more communications characteristics of an uplink data message transmitted by the communications device, and/or a Scheduling Request, SR, which indicates that the communications device is requesting a set up uplink resources of the wireless access interface for transmission of an uplink data message. It should be appreciated by those skilled in the art that no DCI is required for the triggering/scheduling of such UCI in these cases. Furthermore, the uplink control information may alternatively/also comprise feedback information (i.e. a HARQ-ACK), the feedback information indicating whether or not a downlink signal was received successfully by the communications device. In this case, the UCI carrying the HARQ-ACK will have been scheduled by the DCI which provides the DL grant that schedules the downlink signal (i.e. a PDSCH).

<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 or receive data from an infrastructure equipment of a wireless communications network.

The method begins in step S701. The method comprises, in step S702, determining that the communications device should transmit at least two uplink signals to the wireless communications network, wherein the uplink signals are each to be transmitted in a set of uplink resources of a wireless access interface. The process then moves to step S703, which involves determining that the set of uplink radio resources in which a first of the uplink signals should be transmitted at least partially overlaps the set of uplink radio resources in which a second of the uplink signals should be transmitted, wherein the first uplink signal has a different one of a plurality of physical layer priority levels to the second uplink signal. Next, in step S704, the method comprises detecting an indication of whether the first uplink signal and the second uplink signal should be multiplexed. The process then comprises, in step S705, if the indication indicates that the first uplink signal and the second uplink signal should be multiplexed, multiplexing the first uplink signal and the second uplink signal into a third uplink signal, and then in step S706, transmitting the third uplink signal. Alternatively, in step S707, the process comprises, if the indication indicates that the first uplink signal and the second uplink signal should not be multiplexed, transmitting only the one of the first uplink signal and the second uplink signal that has a higher physical layer priority level. The method ends in step S708.

Those skilled in the art would appreciate that the method shown by <FIG> may be adapted in accordance with embodiments of the present technique. For example, other intermediate steps may be included in the method, 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>, it would be clear to those skilled in the art that they could be equally applied to other systems to those described herein.

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>) in a wireless communications network, the method comprising
determining (<NUM>) that the communications device should transmit at least two uplink signals to the wireless communications network, wherein the uplink signals are each to be transmitted in a set of uplink resources of a wireless access interface,
determining (<NUM>) that the set of uplink radio resources in which a first of the uplink signals should be transmitted at least partially overlaps the set of uplink radio resources in which a second of the uplink signals should be transmitted, wherein the first uplink signal has a different one of a plurality of physical layer priority levels to the second uplink signal, and
detecting (<NUM>) an indication of whether the first uplink signal and the second uplink signal should be multiplexed,
wherein, if the indication indicates that the first uplink signal and the second uplink signal should be multiplexed, the method further comprises multiplexing (<NUM>) the first uplink signal and the second uplink signal into a third uplink signal, and transmitting (<NUM>) the third uplink signal,
wherein, if the indication indicates that the first uplink signal and the second uplink signal should not be multiplexed, the method further comprises transmitting (<NUM>) only the one of the first uplink signal and the second uplink signal that has a higher physical layer priority level,
wherein the indication is explicitly indicated by at least one of a plurality of downlink signals received by the communications device from the wireless communications network, and
characterized in that
the indication comprises a first dynamic indicator explicitly indicated by a first of the downlink signals on which the first uplink signal is based and a second dynamic indicator explicitly indicated by a second of the downlink signals on which the second uplink signal is based.