Display PUCCH iteration count

Abstract

Methods and apparatus for indicating the number of repetitions of a PUCCH are disclosed. A base unit includes a transmitter that transmits a configuration including an indication of the number of repetitions of a PUCCH — the configuration is determined according to the type of UCI carried in the PUCCH —; and a receiver that repeatedly receives the PUCCH with the number of repetitions.

Description

Technology Field

[0001] The subject matter disclosed in this specification generally relates to wireless communications, and more specifically, to methods and apparatus for indicating the number of repetitions of a PUCCH. Background Technology

[0002] The following abbreviations are defined herein, at least some of which are mentioned in the following description: 3GPP (Third Generation Partnership Project), LTE (Long Term Evolution), NR (New Radio), VLSI (Very Large Scale Integration), RAM (Random Access Memory), ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory) or Flash Memory, CD-ROM (Compact Disc Read-Only Memory), LAN (Local Area Network), WAN (Wide Area Network), UE (User Equipment), UL (Uplink), eNB (Evolved Node B), gNB (Next Generation Node B), DL (Downlink), CPU (Central Processing Unit), GPU (Graphics Processing Unit), FPGA (Field Programmable Gate Array), DRAM (Dynamic RAM), RRC (Radio Resource Control), UE (User Entity / Equipment (Mobile Terminal)), PDSCH (Physical Downlink Shared Channel), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Downlink control information (DCI), transmission reception point (TRP), multi-TRP (multi-TRP or M-TRP), frequency range 2 (FR2), channel state information (CSI), CSI-RS Resource Indicator (CRI),Transmission Configuration Indication (TCI), Sounding Reference Signal (SRS), Control Resource Set (CORESET), Synchronization Signal (SS), reference signal (RS), Uplink control information (UCI), media access control (MAC), control element (CE), Scheduling Request (SR), Hybrid Automatic Repeat Request (HARQ), Hybrid Automatic Repeat Request acknowledgment (HARQ-ACK), SPS (Semi-Persistent Scheduling), TS (Technical Specification), SP (Semi-persistent), BWP (bandwidth Part), URLLC (Ultra-reliable and Low Latency Communications).,

[0003] UCI iterations having multiple beams in multiple slots may utilize the spatial diversity of multiple beams of PUCCH transmission to increase the reliability and robustness of UCI transmission. However, in NR Release 15, the number of PUCCH iterations is configured per PUCCH format. Additionally, only long PUCCH resources with formats 1, 3, or 4 may be configured to be transmitted repeatedly (i.e., transmitted as an iteration). For example, for PUCCH formats 1, 3, or 4, the UE has multiple slots for the iterations of PUCCH transmission by their respective nrofSlots It can be composed of. The aforementioned notation for the number of iterations of PUCCH is not flexible.

[0004] The present disclosure aims to improve the indication of the number of iterations of PUCCH.

[0005] Methods and devices are disclosed.

[0006] In one embodiment, the base unit includes a transmitter that transmits a configuration including an indication of the number of repetitions of the PUCCH—the configuration is determined according to the type of UCI carried in the PUCCH—and a receiver that repeatedly receives the PUCCH with the number of repetitions.

[0007] In one embodiment, the configuration is RRC signaling for all types of UCI carried from PUCCH, and the indication is for each PUCCH resource. In another embodiment, the configuration is MAC CE for all types of UCI carried from PUCCH, and the indication is for each PUCCH resource or each PUCCH resource group.

[0008] In another embodiment, if the type of UCI carried from PUCCH is one of periodic CSI, SR, and HARQ-ACK corresponding to DL SPS, the configuration is RRC signaling. If the type of UCI carried from PUCCH is semi-persistent CSI, the configuration is MAC CE that activates semi-persistent CSI.

[0009] In some embodiments, if the type of UCI carried in the PUCCH is a HARQ-ACK corresponding to a DL transmission scheduled by the DCI, the configuration is the DCI scheduling the DL transmission. The indication may be included in a new field of the DCI. Alternatively, the indication may be included in the time domain resource allocation field of the DCI. For example, the value of the time domain allocation field indicates a row in a table containing a column to indicate the number of iterations. The table may be configured by the RRC as a pdsch time domain allocation list, or, if a pdsch time domain allocation list is not configured, a predefined table. The column to indicate the number of iterations may be a newly added column in the table, or an existing column in the table also used to indicate the number of iterations of the PDSCH carrying the scheduled DL transmission. The indication may also be included in the PDSCH-to-HARQ_feedback_timing indicator field of the DCI. For example, the value of the PDSCH-v-HARQ-feedback timing indicator field indicates a row in a table containing a column to indicate the number of iterations. The table may be configured by RRC as dl data for the ul ACK list, or it may be a predefined table if dl data for the ul ACK list is not configured. The column to indicate the number of iterations may be a newly added column in the table.

[0010] In some embodiments, when the type of UCI carried in the PUCCH is not a HARQ-ACK corresponding to a DL transmission scheduled by the DCI, the configuration is RRC signaling and the indication is for each PUCCH format.

[0011] In one embodiment, the method comprises the steps of: transmitting a configuration including an indication of the number of repetitions of the PUCCH — the configuration is determined according to the type of UCI carried in the PUCCH —; and repeatedly receiving the PUCCH with the number of repetitions.

[0012] In another embodiment, the remote unit includes a receiver that receives a configuration including an indication of the number of repetitions of the PUCCH—the configuration is determined by the type of UCI carried in the PUCCH—and a transmitter that repeatedly transmits the PUCCH with the number of repetitions.

[0013] In another embodiment, the method comprises the steps of receiving a configuration including an indication of the number of repetitions of the PUCCH — the configuration is determined according to the type of UCI carried in the PUCCH — and repeatedly transmitting the PUCCH with the number of repetitions. Brief explanation of the drawing

[0014] A more specific description of the embodiments briefly described above will be made with reference to specific embodiments illustrated in the accompanying drawings. With the understanding that these drawings illustrate only some embodiments and should not be construed as limiting the scope, embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings. Figure 1 illustrates a MAC CE for activating semi-permanent CSI in TS 38.321. FIG. 2 illustrates a MAC CE according to a fourth embodiment. FIG. 3 is a schematic flowchart illustrating an example of the method. FIG. 4 is a schematic flowchart illustrating an additional embodiment of the method. FIG. 5 is a schematic block diagram illustrating devices according to one embodiment. Specific details for implementing the invention

[0015] As understood by those skilled in the art, specific aspects of the embodiments may be implemented as a system, device, method, or program product. Accordingly, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as “circuit,” “module,” or “system.” Furthermore, the embodiments may take the form of a program product implemented in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code referred to as “code” below. The storage devices may be tangible, non-transient, and / or non-transmitting. The storage devices may not implement signals. In certain embodiments, the storage devices use only signals for accessing the code.

[0016] The specific functional units described herein may be labeled as "modules" to further emphasize their independent implementation. For example, modules may be implemented as off-the-shelf semiconductors, such as hardware circuits including custom very-large-scale integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. Modules may also be implemented as programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.

[0017] Modules may also be implemented in code and / or software for execution by various types of processors. An identified module of code may comprise one or more physical or logical blocks of executable code that can be organized, for example, as objects, procedures, or functions. Nevertheless, executable files of the identified module do not need to be physically located together, but may contain heterogeneous instructions stored in different locations that contain the module and achieve the stated purpose for the module when logically combined.

[0018] In effect, a module of code may contain a single instruction or multiple instructions, and may even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data may be identified and exemplified within modules in this specification, implemented in any suitable form, and organized within any suitable type of data structure. This operational data may be collected as a single data set or distributed across different locations, including those spanning different computer-readable storage devices. Where a module or parts of a module are implemented in software, the software parts are stored on one or more computer-readable storage devices.

[0019] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device that stores code. A storage device may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, device, or any suitable combination thereof, but is not required to be.

[0020] A non-comprehensive list of more specific examples of storage devices will include: electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any type of medium capable of containing or storing a program for use by or in connection with an instruction execution system, device, or device.

[0021] Code for performing operations for the embodiments may include any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, conventional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly languages. The code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider).

[0022] Throughout this specification, references to “one embodiment,” “an embodiment,” or similar language mean that the specific features, structures, or characteristics described in relation to that embodiment are included in at least one embodiment. Accordingly, throughout this specification, appearances of phrases such as “in one embodiment,” “in an embodiment,” and similar language may all refer to the same embodiment, but are not necessarily required to do so, and may mean “one or more but not all embodiments” unless explicitly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited thereto” unless explicitly specified otherwise. A list of enumerated items does not imply that any or all of the items are mutually exclusive, unless explicitly specified otherwise. The singular expressions (“a,” “an,” and “the”) also refer to “one or more” unless explicitly specified otherwise.

[0023] Furthermore, the described features, structures, or characteristics of the various embodiments may be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user choices, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided to provide a thorough understanding of the embodiments. However, a person skilled in the art will recognize that the embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other examples, well-known structures, materials, or operations are not illustrated or described in detail to avoid obscuring the aspects of the embodiments.

[0024] Aspects of different embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, may be implemented by code. This code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine such that instructions executed through the processor of the computer or other programmable data processing device generate means for implementing functions specified in the schematic flowcharts and / or schematic block diagrams for blocks or blocks.

[0025] The code may also be stored in a storage device capable of instructing a computer, other programmable data processing device, or other devices to function in a specific manner such that instructions stored in the storage device produce a manufactured article comprising instructions that implement a specific function in blocks or blocks of schematic flowcharts and / or schematic block diagrams.

[0026] The code may also be loaded onto a computer, other programmable data processing device, or other devices, so that a series of operational steps are performed on the computer, other programmable device, or other devices, thereby generating a process implemented by a computer such that the code executed on the computer or other programmable device provides processes for implementing functions specified in blocks or blocks of a flowchart and / or block diagram.

[0027] The schematic flowcharts and / or schematic block diagrams in the drawings illustrate the architecture, function, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or part of code comprising one or more executable instructions of code for implementing a specified logical function(s).

[0028] It should also be noted that in some alternative implementations, the functions mentioned in the blocks may occur out of the order mentioned in the drawings. For example, two consecutively drawn blocks may be executed substantially simultaneously, or the blocks may be executed in reverse order from time to time depending on the accompanying functions. For the illustrated drawings, other steps and methods equivalent to one or more blocks, or parts thereof, in terms of function, logic, or effect may be considered.

[0029] While various arrow and line types may be used in flowcharts and / or block diagrams, it is understood that these do not limit the scope of the corresponding embodiments. In practice, some arrows or other connectors may be used to indicate only the logical flow of the illustrated embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between the enumerated steps of the illustrated embodiments. It should also be noted that individual blocks of the block diagrams and / or flowcharts, and combinations of blocks within the block diagrams and / or flowcharts, may be implemented by special-purpose hardware-based systems that perform specified functions or operations, or by combinations of special-purpose hardware and code.

[0030] The descriptions of elements within each drawing may refer to the elements in the following drawings. Similar numbers in all drawings refer to similar elements, including alternative embodiments of similar elements.

[0031] UCIs carried in a PUCCH may be classified as periodic UCIs (e.g., any one of periodic CSIs, SRs, or HARQ-ACKs corresponding to DL SPS), semi-permanent UCIs (e.g., semi-permanent CSIs), and non-permanent UCIs (e.g., HARQ-ACKs corresponding to DL scheduling). The number of iterations in a PUCCH may be indicated according to the types of UCIs carried in a PUCCH. For example, the indication of the number of iterations in a PUCCH may be the same for all types of UCIs carried in a PUCCH. Alternatively, the number of iterations in a PUCCH may be indicated in different ways for different types of UCIs carried in a PUCCH. The descriptions of the present disclosure are described in detail.

[0032] According to the first embodiment, for all types of UCIs carried in the PUCCH, the number of iterations of the PUCCH (hereinafter abbreviated as "number of iterations") is configured for each PUCCH resource by the RRC. Unlike the prior art where the number of iterations is configured per PUCCH format, according to the first embodiment, the number of iterations is configured per PUCCH resource. Accordingly, the gNB can configure different number of iterations for different PUCCH resources of the same PUCCH format to provide maximum flexibility. Meanwhile, configuring the number of iterations for each PUCCH resource by the RRC can cause significant overhead and can also cause greater latency for updating the number of iterations.

[0033] As an example of the first embodiment, the RRC configuration of the PUCCH resource in TS 38.331 may add a line to indicate the number of iterations of PUCCH. In the following example, the added line is named nrofSlots, which has any one of the possible values ​​of {n1, n2, n4, n8}.

[0034]

[0035] According to the second embodiment, for all types of UCIs carried in PUCCH, the number of iterations can be displayed or updated by MAC CE. The number of iterations of PUCCH can be displayed in MAC CE for each PUCCH resource or for each PUCCH resource group comprising multiple PUCCH resources.

[0036] An example of a MAC CE for displaying the number of iterations for each PUCCH resource can be configured by displaying the number of iterations for each of the PUCCH resources displayed in the MAC CE.

[0037] Another example of a MAC CE for indicating the number of iterations for each PUCCH resource group can be configured by indicating the number of iterations for each of the PUCCH resource groups displayed in the MAC CE. All PUCCH resources included in a single PUCCH resource group will be configured with the same number of iterations.

[0038] If the number of PUCCH iterations is indicated by RRC per PUCCH format or per PUCCH resource, the indication of the PUCCH iterations by MAC CE will update the existing indication.

[0039] Compared to displaying the number of iterations by RRC according to the first embodiment, displaying the number of iterations by MAC CE can cause faster and less overhead.

[0040] In the first and second embodiments described above, the indication of the number of repetitions of the PUCCH by RRC or MAC CE applies to all types of UCIs carried in the PUCCH. In the following third, fourth, and fifth embodiments, the number of repetitions of the PUCCH may be indicated in different ways for different types of UCIs carried in the PUCCH.

[0041] A third embodiment relates to indicating the number of iterations of a PUCCH carrying a periodic UCI (e.g., any one of a periodic CSI, SR, or HARQ-ACK corresponding to DL SPS). A fourth embodiment relates to indicating the number of iterations of a PUCCH carrying a semi-permanent UCI (e.g., a semi-permanent CSI). A fifth embodiment relates to indicating the number of iterations of a PUCCH carrying a non-permanent UCI (e.g., a HARQ-ACK corresponding to DL scheduling).

[0042] Any one of the periodic UCI, e.g., periodic CSI, SR, or HARQ-ACK corresponding to DL SPS, is configured to be transmitted from the PUCCH resource by the RRC. According to the third embodiment, the number of repetitions of the PUCCH carrying the periodic UCI is indicated in the RRC constituting the PUCCH resource.

[0043] For example, for a PUCCH resource carrying periodic CSI, the RRC configuration in TS 38.331 can be updated to add a line to indicate the number of iterations of the PUCCH carrying periodic CSI. In the following example, the added line is named nrofSlots, which has any one of the possible values ​​of {n1, n2, n4, n8}.

[0044]

[0045]

[0046]

[0047]

[0048] For a PUCCH carrying an SR, the RRC configuration in TS 38.331 may be updated to add a line to indicate the number of iterations of the PUCCH carrying the SR. In the following example, the added line is named nrofSlots, which has any one of the possible values ​​of {n1,n2,n4,n8}.

[0049]

[0050] For a PUCCH carrying a HARQ-ACK corresponding to a DL SPS, the RRC configuration in TS 38.331 may be updated to add a line to indicate the number of iterations of the PUCCH carrying the HARQ-ACK corresponding to the DL SPS. In the following example, the added line is named nrofSlots, which has any one of the possible values ​​of {n1, n2, n4, n8}.

[0051]

[0052] A semi-permanent UCI, e.g., a semi-permanent CSI, configured to be transmitted from a PUCCH resource is enabled by a MAC CE in NR Release 15. According to the fourth embodiment, the number of iterations of the PUCCH carrying the semi-permanent UCI, e.g., a semi-permanent CSI, is indicated in the redesigned MAC CE that enables the semi-permanent CSI.

[0053] A MAC CE for enabling semi-permanent CSI in TS 38.321 is illustrated in FIG. 1. As illustrated in FIG. 1, the SP CSI report for the PUCCH enable / disable MAC CE has a fixed size of 16 bits with the following fields:

[0054] Serving Cell ID: This field indicates the identity of the serving cell to which MAC CE applies. The length of the field is 5 bits.

[0055] BWP ID: This field indicates a UL BWP to which MAC CE is applied as a code point in the DCI bandwidth part indicator field as specified in TS 38.212 [9]. The length of the BWP ID field is 2 bits.

[0056] S i (i = 0, 1, 2 and 3): This field indicates the enabled / disabled status of semi-permanent CSI reporting configurations within csi-ReportConfigToAddModList, as specified in TS 38.331 [5]. S0 refers to the reporting configuration with the lowest CSI-ReportConfigId in the list that contains PUCCH resources for SP CSI reporting in the indicated BWP and has a type set to semiPersistentOnPUCCH, S1 refers to the reporting configuration with the second lowest CSI-ReportConfigId that contains PUCCH resources for SP CSI reporting in the indicated BWP, and so on. If the number of reporting configurations in the list that have a type set to semiPersistentOnPUCCH in the indicated BWP is less than i+1, the MAC entity is S i You must ignore the field. S i The field is set to 1 to indicate that the corresponding semi-permanent CSI reporting configuration must be enabled. S i The field is set to 0 to indicate that the corresponding semi-permanent CSI reporting configuration i should be disabled.

[0057] R: Reserved bit, set to 0.

[0058] According to the fourth embodiment, the number of repetitions of a PUCCH carrying a semi-permanent CSI can be indicated by using the reserved bits of the SP CSI report for the PUCCH enable / disable MAC CE, for example, the 4 reserved bits in Oct 2.

[0059] FIG. 2 illustrates an example of an SP CSI report for a PUCCH enable / disable MAC CE according to a fourth embodiment. As shown in FIG. 2, the four reserved bits in Oct 2 of FIG. 1 are used to indicate the number of iterations of PUCCH carrying a semi-permanent CSI enabled by the MAC CE. In particular, a field 'nrofSlots' of up to four bits is included in the SP CSI report for the PUCCH enable / disable MAC CE according to the fourth embodiment, and S is set to 1. i Indicates the number of repetitions of each PUCCH carrying each of the semi-permanent CSIs activated by (i = 0, 1, 2, and 3). That is, S set to 1 of the SP CSI report for the PUCCH activation / deactivation MAC CE according to the fourth embodiment. i All PUCCHs carrying one of the semi-permanent CSIs activated by (i = 0, 1, 2 and 3), respectively, are indicated by the nrofSlots field with the same number of repetitions.

[0060] The indication of the number of repetitions may not occupy all 4 reserved bits in Oct 2. For example, if the number of repetitions has 4 possible values, 2 reserved bits in Oct 2 are sufficient to indicate 4 different number of repetitions.

[0061] Incidentally, the number of repetitions of PUCCH carrying semi-permanent CSI can be alternatively indicated in CSI-ReportConfig by RRC in the same manner as in the third embodiment.

[0062] A HARQ-ACK corresponding to a scheduled DL transmission is transmitted from a PUCCH resource. The DCI scheduling the DL transmission also schedules the PUCCH resource used to transmit the HARQ-ACK corresponding to the scheduled DL transmission. Accordingly, according to the fifth embodiment, the number of repetitions of the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission is indicated in the DCI scheduling the DL transmission.

[0063] There are three options for indicating the number of repetitions of PUCCH carrying HARQ-ACK corresponding to the scheduled DL transmission in the DCI that schedules the DL transmission (hereinafter abbreviated as "Scheduling DCI").

[0064] According to the first sub-embodiment of the fifth embodiment, a new DCI field is added to the scheduling DCI to indicate the number of iterations of the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission. According to the first sub-embodiment, the highest flexibility is achieved. However, the payload of the scheduling DCI increases compared to the legacy scheduling DCI, which will increase the complexity of DCI decoding.

[0065] According to the second sub-embodiment of the fifth embodiment, the number of repetitions of a PUCCH carrying a HARQ-ACK corresponding to a scheduled DL transmission is indicated in the time domain resource allocation field of the scheduling DCI. The value m of the time domain resource allocation field indicates row m+1 for the table allocated in NR Release 15. The table allocated is configured by the pdsch-TimeDomainAllocationList in pdsch-Config by the RRC. If the pdsch-TimeDomainAllocationList is not configured, the table allocated is a predefined table. According to the second sub-embodiment, a new column is added to the table allocated to indicate the number of repetitions of a PUCCH carrying a HARQ-ACK corresponding to a scheduled DL transmission. That is, the value m of the time domain resource allocation field of the DCI according to the second sub-embodiment indicates row m+1 of the allocated table, which indicates the time allocation of the PDSCH carrying the scheduled DL transmission as well as the number of repetitions of the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission.

[0066] For example, the configuration of pdsch-TimeDomainAllocationList in TS 38.331 may be updated to add a column to indicate the number of repetitions of PUCCH carrying HARQ-ACKs corresponding to scheduled DL transmissions. In the following example, the added column is named nrofSlots, which has any one of the possible values ​​of {n1,n2,n4,n8}.

[0067]

[0068]

[0069] According to the second sub-embodiment described above, a column named nrofSlots is added to the configuration of the allocated table configured by pdsch-TimeDomainAllocationList (or a predefined table if pdsch-TimeDomainAllocationList is not configured) in TS 38.331 of NR Release 15. In Ultra-reliable and Low Latency Communications (URLC) scheme 4 of NR Release 16, the number of iterations of a PDSCH carrying a scheduled DL transmission is supported by adding a new column to the allocated table in the time domain resource allocation field. In the following example, the added column is named repNumR16, having any one of the possible values ​​of {n1, n2, n4, n8}.

[0070]

[0071] According to various second sub-embodiments, the number of repetitions of the PDSCH indicated in the column named repNumR16 is reused as the number of repetitions of the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission. That is, the PDSCH carrying the DL transmission scheduled by the DCI and the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission are repeatedly transmitted with the same number of repetitions indicated by the column 'repNumR16' added from the allocated table configured by the pdsch-TimeDomainAllocationList indicated by the time domain resource allocation field of the DCI (or from a predefined table if the pdsch-TimeDomainAllocationList is not configured).

[0072] According to various other second sub-embodiments, in addition to repNumR16, which is added to indicate the number of iterations of a PDSCH carrying a DL transmission scheduled by the DCI, a new column named nrofSlots (having any one of the possible values ​​of {n1, n2, n4, n8}) is additionally added to the allocated table configured by the pdsch-TimeDomainAllocationList in pdsch-Config (or to a predefined table if the pdsch-TimeDomainAllocationList is not configured). In the following examples, the added columns are named repNumR16 and nrofSlots in the pdsch-TimeDomainAllocationList of pdsch-Config, each of which has any one of the possible values ​​of {n1, n2, n4, n8}.

[0073]

[0074] It can be seen that the number of repetitions of PDSCH carrying a DL transmission scheduled by DCI of URLLC method 4 and the number of repetitions of PUCCH carrying a HARQ-ACK corresponding to the scheduled DL transmission are each individually indicated by repNumR16 and nrofSlots.

[0075] According to the third sub-embodiment of the fifth embodiment, the number of iterations of the PUCCH resource is indicated in the PDSCH-to-HARQ_feedback timing indicator field of the DCI. The value m of the PDSCH-to-HARQ_feedback timing indicator field indicates row m+1 of the table assigned in NR Release 15. The assigned table is configured by dl-DataToUL-ACK in pdsch-Config by the RRC. If dl-DataToUL-ACK is not configured, the assigned table is a predefined table. It should be noted that the table assigned in NR Release 15 has only one column. According to the present invention, dl-DataToUL-ACK is named dl-DataToUL-ACKList. According to the third sub-embodiment, a new column is added to dl-DataToUL-ACKList to indicate the number of iterations of the PUCCH resource carrying the HARQ-ACK corresponding to the scheduled DL transmission. Accordingly, the value m of the PDSCH-to-HARQ_feedback timing indicator field represents row m+1 in dl-DataToUL-ACKList, which indicates the repetition time of PUCCH as well as the time offset between the PDSCH carrying the scheduled DL transmission and the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission.

[0076] For example, the configuration in TS 38.331 may be updated to add a column to indicate the number of iterations of the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission. In the following example, the added column is named nrofSlots in dl-DataToUL-ACKList (having any one of the possible values ​​of {n1,n2,n4,n8}). Additionally, a column named 'k' indicates the time offset between the PDSCH carrying the scheduled DL transmission and the PUCCH carrying the HARQ-ACK corresponding to the scheduled DL transmission.

[0077]

[0078]

[0079] According to the 6th embodiment, similar to the 3rd to 5th embodiments, the number of repetitions of PUCCH can be indicated in different ways depending on the different types of UCI carried in PUCCH.

[0080] Considering that the reliability of a PUCCH carrying a HARQ-ACK corresponding to a scheduled DL transmission is more critical to network throughput than other types of UCIs, it is advantageous to provide more flexibility only for indicating the number of iterations of a PUCCH carrying a HARQ-ACK corresponding to a scheduled DL transmission. According to the 6th embodiment, if the PUCCH carries a UCI other than a HARQ-ACK corresponding to a scheduled DL transmission, the number of iterations of the PUCCH is indicated per PUCCH format as in TS 38.331. On the other hand, if the PUCCH carries a HARQ-ACK corresponding to a scheduled DL transmission, the number of iterations of the PUCCH may be indicated as being updated by the scheduling DCI as described in the 5th embodiment.

[0081] The advantage of the sixth embodiment is that the number of repetitions of a PUCCH carrying a HARQ-ACK corresponding to a scheduled DL transmission, which requires a high level of reliability, can be indicated more flexibly by using a scheduling DCI as described in the fifth embodiment, whereas the number of repetitions of a PUCCH carrying a UCI of a type other than a HARQ-ACK corresponding to a scheduled DL transmission can be indicated in the conventional manner to reduce the impact on existing specifications (i.e., can be indicated per PUCCH format as in TS 38.331).

[0082] Overall, according to the present application, a configuration including an indication of the number of iterations of a PUCCH may be determined according to the type of UCI carried in the PUCCH. The configuration may be RRC signaling, MAC CE, or scheduling DCI.

[0083] FIG. 3 is a schematic flowchart illustrating an embodiment of the method (300) according to the present application. In some embodiments, the method (300) is performed by a device such as a base unit. In certain embodiments, the method (300) may be performed by a processor that executes program code, e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0084] The method (300) may include the step (302) of transmitting a configuration including an indication of the number of repetitions of the PUCCH — the configuration is determined according to the type of UCI carried in the PUCCH — and the step (304) of repeatedly receiving the PUCCH with the number of repetitions.

[0085] FIG. 4 is a schematic flowchart illustrating additional embodiments of the method (400) according to the present application. In some embodiments, the method (400) is performed by a device such as a remote unit. In certain embodiments, the method (400) may be performed by a processor that executes program code, e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0086] The method (400) may include the step (402) of receiving a configuration including an indication of the number of repetitions of the PUCCH — the configuration is determined according to the type of UCI carried in the PUCCH — and the step (404) of repeatedly transmitting the PUCCH with the number of repetitions.

[0087] FIG. 5 is a schematic block diagram illustrating devices according to one embodiment.

[0088] Referring to FIG. 5, the UE (i.e., remote unit) includes a processor, memory, and a transceiver. The processor implements the functions, processes, and / or methods proposed in FIG. 4. The gNB (i.e., base unit) includes a processor, memory, and a transceiver. The processors implement the functions, processes, and / or methods proposed in FIG. 3. Layers of the radio interface protocol may be implemented by the processors. Memories are connected to the processors to store various information for driving the processors. Transceivers are connected to the processors to transmit and / or receive radio signals. Needless to say, the transceiver may be implemented as a transmitter that transmits radio signals and a receiver that receives radio signals.

[0089] Memories can be located inside or outside the processors and can be connected to the processors by various known means.

[0090] In the embodiments described above, the components and features of the embodiments are combined in a predetermined form. Each component or feature should be considered optional unless otherwise explicitly stated. Each component or feature may be implemented so as not to be associated with other components or features. Additionally, the embodiments may be constructed by associating some components and / or features. The order of operations described in the embodiments may be changed. Some components or features of any embodiment may be included in other embodiments or replaced with components and features corresponding to other embodiments. It is evident that claims not explicitly cited in the claims are combined to form an embodiment or are included in a new claim.

[0091] Embodiments may be implemented by hardware, firmware, software, or a combination thereof. In the case of a hardware implementation, according to the hardware implementation, the exemplary embodiments described herein may be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, etc.

[0092] The embodiments may be implemented in other specific forms. The described embodiments are not limiting in all respects and should be regarded merely as exemplary. Accordingly, the scope of the invention is defined by the appended claims rather than by the foregoing description. All modifications within the meaning and scope of the equivalents of the claims shall be included within their scope.

Claims

Claim 1 A base unit for wireless communication comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to cause the base unit to: transmit a configuration including the number of repetitions of a physical uplink control channel (PUCCH) — said configuration is determined according to the type of uplink control information (UCI) carried in the PUCCH, said configuration is a radio resource control (RRC) signaling at least partially based on the type of the UCI carried in the PUCCH, which does not include a hybrid automatic repeat request acknowledgment (HARQ-ACK) —; and the base unit comprising at least one processor configured to repeatedly receive the PUCCH according to the number of repetitions. Claim 2 In paragraph 1, the base unit, wherein the number of repetitions is for each PUCCH resource. Claim 3 In claim 1, the at least one processor is further configured to cause the base unit to transmit a second configuration including a second repetition count of a second PUCCH, wherein the second configuration is a Media Access Control (MAC) control element (CE), and the second repetition count is for each PUCCH resource or for each PUCCH resource group. Claim 4 In claim 1, the base unit, wherein the type of the UCI carried in the PUCCH is one of the periodic channel state information (CSI) or the reference signal (SR) corresponding to downlink (DL) semi-permanent scheduling (SPS). Claim 5 delete Claim 6 In claim 1, the at least one processor is further configured to cause the base unit to transmit a second configuration including a second repetition number of a second PUCCH carrying a type of UCI including a HARQ-ACK corresponding to a downlink (DL) transmission scheduled by downlink control information (DCI), and the base unit, wherein the second configuration is the DCI that schedules the DL transmission. Claim 7 delete Claim 8 In paragraph 6, the second repetition count is a base unit included in the time domain resource allocation field of the DCI. Claim 9 delete Claim 10 delete Claim 11 delete Claim 12 delete Claim 13 delete Claim 14 In paragraph 6, the second repetition count is a base unit included in the physical downlink shared channel (PDSCH)-to-HARQ_feedback timing indicator field of the DCI. Claim 15 delete Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 A base unit, wherein the number of repetitions in paragraph 1 is for each PUCCH format. Claim 20 A method performed by a base unit, the method comprising: transmitting a configuration including a repetition count of a physical uplink control channel (PUCCH) — said configuration is determined according to the type of uplink control information (UCI) carried in said PUCCH, said configuration is a radio resource control (RRC) signaling at least partially based on the type of said UCI carried in said PUCCH that does not include a hybrid automatic repeat request acknowledgment (HARQ-ACK) — and repeatedly receiving said PUCCH according to said repetition count. Claim 21 In paragraph 20, the above number of repetitions is for each PUCCH resource, a method. Claim 22 A method according to claim 20, further comprising the step of transmitting a second configuration including a second repetition count of a second PUCCH, wherein the second configuration is a Media Access Control (MAC) control element (CE), and the second repetition count is for each PUCCH resource or each PUCCH resource group. Claim 23 A method according to claim 20, wherein the type of UCI carried in the PUCCH is one of periodic channel state information (CSI) or a reference signal (SR) corresponding to downlink (DL) semi-permanent scheduling (SPS). Claim 24 delete Claim 25 A method according to claim 20, further comprising the step of transmitting a second configuration including a second repetition number of a second PUCCH carrying a type of UCI including a HARQ-ACK corresponding to a downlink (DL) transmission scheduled by downlink control information (DCI) - wherein the second configuration is the DCI scheduling the DL transmission. Claim 26 delete Claim 27 delete Claim 28 delete Claim 29 delete Claim 30 delete Claim 31 delete Claim 32 delete Claim 33 delete Claim 34 delete Claim 35 delete Claim 36 delete Claim 37 delete Claim 38 In paragraph 20, the above number of repetitions is for each PUCCH format, a method. Claim 39 User equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled to said at least one memory and configured to cause said UE to: receive a configuration including a repetition count of a physical uplink control channel (PUCCH) — said configuration is determined according to the type of uplink control information (UCI) carried in said PUCCH, and said configuration is a radio resource control (RRC) signaling at least partially based on the type of said UCI carried in said PUCCH that does not include a hybrid automatic repeat request acknowledgment (HARQ-ACK) —; and to cause said PUCCH to be transmitted repeatedly according to said repetition count. Claim 40 In Clause 39, the above number of repetitions is for each PUCCH resource, user equipment. Claim 41 In paragraph 39, the at least one processor is further configured to allow the UE to receive a second configuration including a second iteration number of a second PUCCH, said second configuration being a Media Access Control (MAC) control element (CE) for all types of UCI carried in said PUCCH, and said second iteration number being for each PUCCH resource or for each PUCCH resource group, user equipment. Claim 42 In paragraph 39, the type of the UCI carried in the PUCCH is one of the periodic channel state information (CSI) or the reference signal (SR) corresponding to downlink (DL) semi-permanent scheduling (SPS), user equipment. Claim 43 delete Claim 44 In paragraph 39, the at least one processor is further configured to cause the UE to receive a second configuration including a second repetition number of a second PUCCH carrying a type of UCI including a HARQ-ACK corresponding to a downlink (DL) transmission scheduled by downlink control information (DCI), and the second configuration is the DCI scheduling the DL transmission, the user equipment. Claim 45 A method performed by a user equipment (UE), the method comprising: receiving a configuration including a repetition count of a physical uplink control channel (PUCCH) — said configuration is determined according to the type of uplink control information (UCI) carried in said PUCCH, said configuration is a radio resource control (RRC) signaling at least partially based on the type of said UCI carried in said PUCCH that does not include a hybrid automatic repeat request acknowledgment (HARQ-ACK) —; and repeatedly transmitting said PUCCH according to said repetition count. Claim 46 delete Claim 47 delete Claim 48 delete Claim 49 delete Claim 50 delete Claim 51 delete Claim 52 delete Claim 53 delete Claim 54 delete Claim 55 delete Claim 56 delete Claim 57 delete Claim 58 delete Claim 59 delete Claim 60 delete Claim 61 delete Claim 62 delete Claim 63 delete Claim 64 delete Claim 65 delete Claim 66 delete Claim 67 delete Claim 68 delete Claim 69 delete Claim 70 delete Claim 71 delete Claim 72 delete Claim 73 delete Claim 74 delete Claim 75 delete Claim 76 delete

Images