Patent ID: 12225574

DETAILED DESCRIPTION

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

Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device.

Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like.

Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.

Network Node: As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

FIG.1illustrates one example of a cellular communications network100according to some embodiments of the present disclosure. In the embodiments described herein, the cellular communications network100is a 5G NR network. In this example, the cellular communications network100includes base stations102-1and102-2, which in LTE are referred to as eNBs and in 5G NR are referred to as gNBs, controlling corresponding macro cells104-1and104-2. The base stations102-1and102-2are generally referred to herein collectively as base stations102and individually as base station102. Likewise, the macro cells104-1and104-2are generally referred to herein collectively as macro cells104and individually as macro cell104. The cellular communications network100may also include a number of low power nodes106-1through106-4controlling corresponding small cells108-1through108-4. The low power nodes106-1through106-4can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells108-1through108-4may alternatively be provided by the base stations102. The low power nodes106-1through106-4are generally referred to herein collectively as low power nodes106and individually as low power node106. Likewise, the small cells108-1through108-4are generally referred to herein collectively as small cells108and individually as small cell108. The base stations102(and optionally the low power nodes106) are connected to a core network110.

The base stations102and the low power nodes106provide service to wireless devices112-1through112-5in the corresponding cells104and108. The wireless devices112-1through112-5are generally referred to herein collectively as wireless devices112and individually as wireless device112. The wireless devices112are also sometimes referred to herein as UEs.

When there are multiple Uplink Control Informations (UCIs) (e.g., Channel State Information (CSI) and multiple Hybrid Automatic Repeat Request Acknowledge (HARQ-ACK) bits) with different priority levels to be multiplexed on a Physical Uplink Shared Channel (PUSCH), the use of beta offsets as in the current specification can be very complicated. For example, multiple beta offset indicators would have to be indicated, resulting in more bits required for beta offset indicators in the Downlink Control Information (DCI). Improved systems and methods for UCI resource determination are needed.

Systems and methods for priority-dependent UCI resource determination are provided.FIG.2illustrates an example operation of a wireless device according to some embodiments of the present disclosure. In some embodiments, a method of operating a wireless device for priority-dependent UCI resource determination includes determining that a plurality of UCI messages are to be multiplexed onto a Physical Uplink Shared Channel (PUSCH) (step200). The wireless device determines priorities of the PUSCH and of each of the plurality of UCIs (step202). Then, the wireless device determines at least one beta offset value for at least one of the UCIs based on one or more of the priorities of the PUSCH and each of the plurality of UCIs (step204). The wireless device sets or adjusts a UCI code rate based on the at least one beta offset value (step206). The wireless device transmits a UCI according to the UCI code rate (step208). This provides a simple and consistent method to deduce beta offset values for UCI based on priorities of UCIs and PUSCH. The solution supports possible multiple different beta offset values determined without extra explicit signaling, i.e., it helps to reduce DCI bits needed to indicate potentially multiple beta offset values. In some embodiments, there is a beta offset value per UCI type (HARQ-ACK or CSI) and each type can also be associated with a priority. A beta offset value for UCI (HARQ-ACK or CSI) tells the wireless device how to determine resources for the UCI. Hence, in some embodiments, there is a code rate associated per UCI (type). In some embodiments, an overall code rate for the total UCI (including both HARQ-ACK and CSI) is determined.

In some embodiments, if one UCI is multiplexed onto a PUSCH, then the beta offset value of the UCI is determined based on the priority of the UCI and/or the priority of the PUSCH. On the other hand, if there are multiple UCIs to be multiplexed onto a PUSCH, then one or more beta offset values for these multiple UCIs are determined based on the priority values of the UCIs and/or the priority value of the PUSCH.

In some embodiments, two levels of priority values are defined in the specification TS38.213. Priority of a HARQ-ACK codebook with index 0 corresponds to low priority, while priority index 1 corresponds to high priority. In some embodiments, if there are two HARQ-ACK codebooks, then the first HARQ-ACK codebook is associated with priority index 0 (low priority) while second HARQ-ACK codebook is associated with priority index 1 (high priority). In some embodiments, there can be one HARQ-ACK codebook which can be associated with both priorities. For example, a single HARQ-ACK codebook can first be used for one or more HARQ-ACKs associated with priority index 1 and then (after that first use) be used for one or more HARQ-ACKs associated with priority index 0.

In one embodiment, beta offset value of a UCI (HARQ-ACK or CSI) is determined based on priority of the UCI and/or PUSCH that the UCI is to be multiplexed on.

In one embodiment, multiple beta offset values for multiple UCIs (multiple HARQ-ACK and/or multiple CSI) to be multiplexed on PUSCH are determined separately based on priority of each UCI and the PUSCH.

In another embodiment, one beta offset value is determined for multiple UCIs to be multiplexed on PUSCH based on priority of all the UCIs and the PUSCH.

In one embodiment, beta offset values for different UCI messages are determined based on one indicated or configured beta factor, e.g., beta_1=2*beta_2.

In one embodiment, a field beta offset indicator is not included in the new specific DCI for URLLC. In other words, a beta offset value could be determined based on priorities if there is no field in the new specific DCI.

In one embodiment, a beta offset value of UCI is determined from a table indexed by a combination of priorities of UCI and PUSCH.

In another embodiment, a beta offset value of UCI is determined from a defined formula considering a combination of priority of UCI and Physical Downlink

Shared Channel (PDSCH). In some embodiments, a beta offset value can be determined from a specified function f, i.e., for the case of one UCI multiplexed on PUSCH, the beta offset value=f(the priority value of the UCI, the priority value of the PUSCH).

In one embodiment, a priority of UCI is implicitly determined based on higher layer data priorities, e.g., a priority of the corresponding DL data or priority of the accompanying UL data, etc.

In one embodiment, a priority of UCI and/or PUSCH can be explicitly indicated in the DCI, or semi-statically configured, or derived from other indicators.

In one embodiment, a priority of PUSCH is indicated in the UL scheduling grant or activation grant.

In another embodiment, a priority of PUSCH is semi-statically configured.

In one embodiment, HARQ-ACK for a PDSCH has the same priority as the priority of PDSCH.

In one embodiment, a priority of PDSCH is indicated in the DL scheduling DCI.

In another embodiment, a priority of PDSCH is semi-statically configured.

In one embodiment, aperiodic CSI (A-CSI) has the same priority as the priority indicator in UL grant requesting the CSI.

In another embodiment, A-CSI always has the lowest priority with respect to other UCI and PUSCH.

In another embodiment, priority of A-CSI is semi-statically configured.

In one embodiment, a beta offset value of A-CSI is the same as the beta offset indicator in the DCI.

In another embodiment, a beta offset of A-CSI is determined from a combination of the beta offset indicator in the DCI and priority of PUSCH.

In one embodiment, a priority of specific A-CSI determined based on PDSCH DMRS to be multiplexed on PUSCH is the same as priority of PDSCH.

In one embodiment, the beta offset value for a UCI multiplexed in PUSCH is determined based on the configuration used. Configuration is described herein as configuration type or number used in uplink (UL) with multiple Configured Grants (CGs). Different configurations may carry different traffic with different reliabilities or priorities. In some embodiments, this is applied to UL configured grant PUSCH. There can be multiple active configurations of configured grant PUSCH. In some embodiments, the beta offset value determination also depends on the configuration index of the configured grant PUSCH.

In one embodiment, where a dynamic grant may follow the failed UL transmission in CG, the determination of a beta offset value for the UCI transmitted in (retransmission) PUSCH utilizes the information for a given CG where an initial UL transmission happened (type or number) out of multiple CGs. In some embodiments, in case of UCI multiplexed onto a dynamically scheduled PUSCH which is a retransmission of the first CG PUSCH transmission, the beta offset value determination is also based on a configuration index of the first CG PUSCH.

In one embodiment, the offset value for the first transmission occasion in the CG period can be combined with a priority value to determine a beta offset value.

The same concept for multiple UL CGs can be mirrored for multiple DL Semi-Persistent Scheduling (SPS) configurations carrying different reliability traffic streams. Hence beta offset value can consider PDSCHs transmitted over particular DL SPS configurations.

In one embodiment, the priority of PUSCH or PDSCH can be based on the configuration allocated in UL (CG) or DL (SPS) where multiple configurations exist in either or both direction(s).

In one embodiment, the determined beta offset values include a value corresponding to dropping the UCI.

Determining HARQ-ACK Beta Offset From DL and UL Priority

In this exemplifying embodiment, DL and UL priorities are “high” or “low”, i.e., a 1-bit priority differentiation is assumed. The UE may be pre-configured with a HARQ-ACK beta factor table according to:

TABLE 1HARQ-ACK beta factorBeta offset indexHARQ-ACK Beta factor“00”β1“01”β2“10”β3“11”β4

The beta factor index is in this embodiment referenced by the DL priority P_DL and the UL priority P_UL according to (P_DL, P_UL). That is, the most significant bit of the beta offset index is determined from the DL priority while the least significant bit of the beta offset index is determined by the UL priority. Clearly, in other embodiments, the beta offset index could be referenced by (P_UL, P_DL) instead or some other mapping function from P_DL and P_UL to a beta offset index.

In some embodiments, there are two or more HARQ-ACKs that are transmitted in UCI on a PUSCH with priority P_UL. In some such embodiments, the two or more HARQ-ACKs are associated with two or more PDSCHs with priorities P1_DL, P2_DL, . . . , wherein the UE determines two or more beta offset values for HARQ-ACK by determining multiple beta offset index lookup based on (P1_DL, P_UL), (P2_DL, P_UL), . . . .

In one embodiment, the offset index is determined implicitly from the DL priority P_DL and the UL priority P_UL in the following way. The beta factor is then determined from the beta factor in a manner similar to in Rel-15, perhaps with additional values added to the table mapping the offset index to the beta factor.

Ioffset,0HARQ-ACKorIoffset,1HARQ-ACKorP_DLU_DLIoffset,2HARQ-ACK001stoffset index provided by higher layers012ndoffset index provided by higher layers103rdoffset index provided by higher layers114thoffset index provided by higher layers

In some versions of the above embodiment, the offset index is not provided by higher layers but instead specified in the specification. In some versions of the above embodiment, an offset index specified in the specification is used unless another index is provided by higher layers, e.g., through RRC configuration.

In one embodiment, the offset index is determined both from the DL priority P_DL and the UL priority P_UL and the beta_offset_indicator in the DCI scheduling the PUSCH. One way of doing this is by using the following table, when the beta factor is then determined from the beta factor in a manner similar to in Rel-15, perhaps with additional values added to the table mapping the offset index to the beta factor.

Ioffset,0HARQ-ACKorIoffset,1HARQ-ACKorBeta_offset_indicatorP_DLU_DLIoffset,2HARQ-ACK‘00’001stoffset indexprovided by higher layers‘00’012ndoffset indexprovided by higher layers‘00’103rdoffset indexprovided by higher layers‘00’114thoffset indexprovided by higher layers‘01’005thoffset indexprovided by higher layers‘01’016thoffset indexprovided by higher layers‘01’107thoffset indexprovided by higher layers‘01’118thoffset indexprovided by higher layers‘10’009thoffset indexprovided by higher layers‘10’0110thoffset indexprovided by higher layers‘10’1011thoffset indexprovided by higher layers‘10’1112thoffset indexprovided by higher layers‘11’0013thoffset indexprovided by higher layers‘11’0114thoffset indexprovided by higher layers‘11’1015thoffset indexprovided by higher layers‘11’1116thoffset indexprovided by higher layers

In some versions of the above embodiment, the offset index is not provided by higher layers, but instead specified in the specification. In some versions of the above embodiment an offset index specified in the specification is used unless another index is provided by higher layers, e.g., through RRC configuration.

In some embodiments, a first offset index is obtained similar to in Rel-15. A second offset index used to find the beta factor is then obtained from the first offset index based on the priorities of the UL and DL transmissions.

In one version of the above embodiment, if the UL and DL transmissions have the same priority, the second offset index is the same as the first offset index.

In one version of the above embodiment, if the UL transmission has higher priority than the DL transmission, the second offset index is given by the first offset index minus a fixed non-negative integer. The integer can either be provided by higher layers, e.g., through RRC, or be fixed in the specification.

In one version of the above embodiment, if the second offset index would be negative (i.e., if the fixed non-negative integer is larger than the first offset index), then the second offset index is set to 0. In another version, if the second offset index would be negative (i.e., if the fixed non-negative integer is larger than the first offset index), then the second offset index is set such that the beta factor implies that the associated UCI transmissions is dropped.

In one version of the above embodiment, if the UL transmission has lower priority than the DL transmission, the second offset index is given by the first offset index plus a fixed non-negative integer. The integer can either be provided by higher layers, e.g., through RRC, or be fixed in the specification.

In one version of the above embodiment, if the second offset index would be negative (i.e., if the fixed non-negative integer is larger than the first offset index), then the second offset index is set to 0. In another version, if the second offset index would be negative (i.e., if the fixed non-negative integer is larger than the first offset index), then the second offset index is set such that the beta factor implies that the associated UCI transmission is dropped.

In one version of the above embodiment, if the second offset index would be larger than the number of entries in the table mapping offset indices to beta factors, or if the offset index would correspond to a reserved entry in the table mapping offset indices to beta factors, then the second offset index is set to the largest entry in the table corresponding to a non-reserved entry.

Scaling Factor for UCI

The scaling factor, typically labeled “α′,” is used to limit the number of resource elements assigned to UCI on PUSCH. The total amount of resources occupied by UCI (including HARQ-ACK bits, CSI-part1, CSI-part2) cannot exceed α×MUCI, where MUCI is the total number of resource elements that can be used for transmission of UCI within the OFDM symbols occupied by the PUSCH. Here the PUSCH refers to the PUSCH that UCI may be multiplexed onto.

Similar to beta factors, the scaling factors can be adaptively adjusted according to UCI priority and/or PUSCH priority.

PUSCH Associated With Dynamic Grant

In one embodiment, a new scaling factor α is defined for a PUSCH associated with dynamic grant and high priority. Value 0 is allowed to indicate that no UCI is to be multiplexed onto the high priority PUSCH.

UCI-OnPUSCH ::=SEQUENCE {betaOffsetsCHOICE {dynamicSEQUENCE (SIZE (4)) OF BetaOffsets,semiStaticBetaOffsets}OPTIONAL, -- Need MscalingENUMERATED { f0p5, f0p65, f0p8, f1 }scaling-v16ENUMERATED { f0, f0p3, f0p7, f1 } -- ***NEW ***}

PUSCH Associated With UL Configured Grant

In one embodiment, scaling factor α is separately defined for a PUSCH associated with UL configured grant. Periodic deterministic Time Sensitive Networking (TSN) packets are expected to be carried by PUSCHs associated with UL configured grants. For such high priority UL CG PUSCHs, the scaling factor α can be set preferably lower than dynamically scheduled PUSCH, including having the value of 0. This is illustrated below.

CG-UCI-OnPUSCH ::=CHOICE {dynamicSEQUENCE (SIZE (1..4)) OF BetaOffsets,semiStaticBetaOffsetsscalingENUMERATED { f0, f0p5, f0p8, f1 } --*** NEW ***}

HARQ-ACK in Response to HIGH PRIORITY DL-SCH

For HARQ-ACK in response to high priority DL-SCHs, high priority should be designated in the transmission of HARQ-ACK bits as well.

The scaling factor α can therefore be adjusted upwards to give the HARQ-ACK higher reliability. For example, αhighPriocan be used instead of α in calculating the number of coded bits for HARQ-ACK.
αhighPrio=min(1, 2*α)

For CSI (both CSI-part1 and CSI-part2), α can be used as in Rel-15, since CSI bits typically do not need to be assigned high priority.

High Priority CSI

In certain special cases, the gNB may need to receive reliable CSI feedback from UE urgently, in order to schedule highly reliable data transmission of URLLC. In such special cases, the high priority CSI may also use αhighPrioinstead of α in calculating the maximum allowed coded bits for CSI.

EXAMPLES

FIG.3is a schematic block diagram of a radio access node300according to some embodiments of the present disclosure. The radio access node300may be, for example, a base station102or106. As illustrated, the radio access node300includes a control system302that includes one or more processors304(e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory306, and a network interface308. The one or more processors304are also referred to herein as processing circuitry. In addition, the radio access node300includes one or more radio units310that each includes one or more transmitters312and one or more receivers314coupled to one or more antennas316. The radio units310may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s)310is external to the control system302and connected to the control system302via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s)310and potentially the antenna(s)316are integrated together with the control system302. The one or more processors304operate to provide one or more functions of a radio access node300as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory306and executed by the one or more processors304.

FIG.4is a schematic block diagram that illustrates a virtualized embodiment of the radio access node300according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures.

As used herein, a “virtualized” radio access node is an implementation of the radio access node300in which at least a portion of the functionality of the radio access node300is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node300includes the control system302that includes the one or more processors304(e.g., CPUs, ASICs, FPGAs, and/or the like), the memory306, and the network interface308and the one or more radio units310that each includes the one or more transmitters312and the one or more receivers314coupled to the one or more antennas316, as described above. The control system302is connected to the radio unit(s)310via, for example, an optical cable or the like. The control system302is connected to one or more processing nodes400coupled to or included as part of a network(s)402via the network interface308. Each processing node400includes one or more processors404(e.g., CPUs, ASICs, FPGAs, and/or the like), memory406, and a network interface408.

In this example, functions410of the radio access node300described herein are implemented at the one or more processing nodes400or distributed across the control system302and the one or more processing nodes400in any desired manner. In some particular embodiments, some or all of the functions410of the radio access node300described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s)400. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s)400and the control system302is used in order to carry out at least some of the desired functions410. Notably, in some embodiments, the control system302may not be included, in which case the radio unit(s)310communicate directly with the processing node(s)400via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node300or a node (e.g., a processing node400) implementing one or more of the functions410of the radio access node300in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

FIG.5is a schematic block diagram of the radio access node300according to some other embodiments of the present disclosure. The radio access node300includes one or more modules500, each of which is implemented in software. The module(s)500provide the functionality of the radio access node300described herein. This discussion is equally applicable to the processing node400ofFIG.4where the modules500may be implemented at one of the processing nodes400or distributed across multiple processing nodes400and/or distributed across the processing node(s)400and the control system302.

FIG.6is a schematic block diagram of a UE600according to some embodiments of the present disclosure. As illustrated, the UE600includes one or more processors602(e.g., CPUs, ASICs, FPGAs, and/or the like), memory604, and one or more transceivers606each including one or more transmitters608and one or more receivers610coupled to one or more antennas612. The transceiver(s)606includes radio-front end circuitry connected to the antenna(s)612that is configured to condition signals communicated between the antenna(s)612and the processor(s)602, as will be appreciated by on of ordinary skill in the art. The processors602are also referred to herein as processing circuitry. The transceivers606are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE600described above may be fully or partially implemented in software that is, e.g., stored in the memory604and executed by the processor(s)602. Note that the UE600may include additional components not illustrated inFIG.6such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE600and/or allowing output of information from the UE600), a power supply (e.g., a battery and associated power circuitry), etc.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE600according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

FIG.7is a schematic block diagram of the UE600according to some other embodiments of the present disclosure. The UE600includes one or more modules700, each of which is implemented in software. The module(s)700provide the functionality of the UE600described herein.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Embodiments

Embodiment 1. A method for priority-dependent Uplink Control Information (UCI) resource determination, the method comprising: determining that there are multiple UCIs to be multiplexed onto a Physical Uplink Shared Channel, PUSCH; determining the priorities of the UCIs and the PUSCH; determining beta offset value for

UCI based on the priorities of the UCI and/or the Physical Uplink Shared Channel (PUSCH) that the UCI is to be multiplexed on; setting or adjusting a UCI code rate based on the beta offset value; and transmitting a UCI according to the UCI code rate.

Embodiment 2. The method of embodiment 1 wherein the beta offset value for UCI comprises a beta offset value for Hybrid Automatic Request Acknowledge (HARQ-ACK) or a beta offset value for Channel State Information (CSI).

Embodiment 3. The method of embodiment 1 or 2 comprising determining beta offset values for a plurality of UCI messages.

Embodiment 4. The method of embodiment 3, wherein the beta offset value of each of the plurality of UCIs is determined separately based on the priority of the respective UCI and the PUSCH.

Embodiment 5. The method of embodiment3, wherein one beta offset is determined for multiple UCIs to be multiplexed on PUSCH based on the priority of all the UCIs and the PUSCH.

Embodiment 6. The method of any of embodiments 3-5 wherein the beta offset value for each of the plurality of UCIs is determined based on an indicated or configured beta factor.

Embodiment 7. The method of any of embodiments 1-6 wherein the beta offset value is determined from a table indexed by a combination of UCI and PUSCH priorities, determined from a defined formula that considers a combination of UCI and PUSCH priorities, and/or determined based on higher layer priorities.

Embodiment 8. The method of any of embodiments 1-7 wherein a UCI or PUSCH priority is explicitly indicated in the Download Control Information (DCI), semi-statically configured, and/or derived from other indicators.

Embodiment 9. The method of any of embodiments 1-7 wherein a PUSCH priority is explicitly indicated in an UL scheduling grant or activation grant or is semi-statically configured.

Embodiment 10. The method of any of embodiments 1-9 wherein HARQ-ACK for a Physical Downlink Shared Channel (PDSCH) has the same priority as the priority of PDSCH.

Embodiment 11. The method of any of embodiments 1-10 wherein a PDSCH priority is indicated in the Downlink (DL) scheduling DCI.

Embodiment 12. The method of any of embodiments 1-11 wherein a PDSCH priority is semi-statically configured.

Embodiment 13. The method of any of embodiments 1-12 wherein an aperiodic CSI (A-CSI) has the same priority as the priority indicator in a UL grant requesting the CSI.

Embodiment 14. The method of embodiments 13 wherein the A-CSI always has the lowest priority with respect to other UCI and PUSCH.

Embodiment 15. The method of embodiment 13 or 14 wherein the priority of the A-CSI is semi-statically configured.

Embodiment 16. The method of any of embodiments 13-15 wherein the beta offset of the A-CSI is identical to or is derived from the beta offset indicator in the DCI.

Embodiment 17. The method of any of embodiments 13-15 wherein the beta offset of the A-CSI is determined from a combination of a beta offset indicator in the DCI and a priority of the PUSCH.

Embodiment 18. The method of any of embodiments 13-17 wherein a priority of a specific A-CSI that is determined based on a PDSCH Demodulation Reference Signal (DMRS) to be multiplexed on PUSCH is the same as the priority of the PDSCH.

Embodiment 19. The method of any of embodiments 1-18 wherein the beta offset value for a UCI multiplexed in PUSCH is determined based on the configuration used, wherein the configuration used comprises a configuration type or number used in UL with multiple Configured Grants (CGs).

Embodiment 20. The method of embodiment 19 wherein different configurations carry different traffic with different reliabilities or priorities.

Embodiment 21. The method of any of embodiments 1-20 wherein, where a dynamic grant follows a failed UL transmission in a CG, the determination of beta offset value for the UCI transmitted in (retransmission) the PUSCH utilizes the information for a given CG where the initial UL transmission happened (type or number) out of multiple CGs.

Embodiment 22. The method of any of embodiments 1-21 wherein the beta offset value for the first transmission opportunity in the CG period is combined with a priority value to determining beta offset value.

Embodiment 23. A User Equipment (UE), for priority-dependent Uplink Control Information (UCI) resource determination, the UE comprising: one or more processors; and memory storing instructions executable by the one or more processors, whereby the UE is operable to perform any of the steps of any of the methods disclosed herein.

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).3GPP Third Generation Partnership Project5G Fifth GenerationACK Acknowledge/AcknowledgementA-CSI Aperiodic Channel State InformationAN Access NetworkAP Access PointASIC Application Specific Integrated CircuitCBGTI Code Block Group Transmission InformationCG Configured GrantCPU Central Processing UnitCRC Cyclic Redundancy CheckCSI Channel State InformationDCI Downlink Control InformationDL DownlinkDMRS Demodulation Reference SignalDN Data NetworkDSP Digital Signal ProcessoreMBB enhanced Mobile BroadbandeNB Enhanced or Evolved Node BFPGA Field Programmable Gate ArraygNB New Radio Base StationGSM Global System for Mobile CommunicationsHARQ Hybrid Automatic Repeat RequestLTE Long Term EvolutionMME Mobility Management EntityMTC Machine Type CommunicationNR New RadioOFDM Orthogonal Frequency Division MultiplexingPDSCH Physical Downlink Shared ChannelP-GW Packet Data Network GatewayPTRS Phase Tracking Reference SignalPUSCH Physical Uplink Shared ChannelRAM Random Access MemoryRAN Radio Access NetworkROM Read Only MemoryRRC Radio Resource ControlRRH Remote Radio HeadSCEF Service Capability Exposure FunctionSCH Shared ChannelSPS Semi-Persistent SchedulingTS Technical SpecificationUCI Uplink Control InformationUE User EquipmentUL UplinkURLLC Ultra-Reliable, Low Latency Communication

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.