User equipment, network node, and methods therein
By dynamically indicating HARQ feedback requirements in NTN systems using DCI or MAC header, the ambiguity issue in HARQ feedback is resolved, enhancing communication efficiency and reducing signaling overhead.
Patent Information
- Application Number
- JP2023559105
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-04-01
- Filing Date
- 2022-03-17
- Publication Date
- 2025-01-07
- Estimated Expiration
- 2042-03-17
AI Technical Summary
In non-terrestrial networks (NTN) of 5G communication systems, there is ambiguity between user equipment (UE) and the base station regarding HARQ feedback when all HARQ processes are disabled, leading to potential ambiguity due to discontinuous transmission (DTX) or downlink control information (DCI) miss detection.
A method to dynamically indicate to the UE whether HARQ feedback is required or omitted for a set of transmission opportunities using downlink control information (DCI) or MAC header, resolving ambiguity by ensuring only disabled HARQ processes are indicated, thus eliminating the need for feedback.
This approach reduces signaling overhead and eliminates ambiguity between the UE and the base station, ensuring accurate communication without additional signaling overhead.
Smart Images

Figure 0007609297000002 
Figure 0007609297000003 
Figure 0007609297000004
Abstract
Description
[Technical field]
[0001] The present disclosure relates to communication systems. [Background technology]
[0002] The present disclosure relates to wireless communication systems and apparatus therefor operating in accordance with 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The present disclosure relates in particular, but not exclusively, to improvements relating to Hybrid Automatic Repeat Request (HARQ) processes in so-called "5G" (or "next generation") systems employing non-terrestrial portions that include airborne or space network nodes.
[0003] In 3GPP standards, a NodeB (or "eNB" in LTE, "gNB" in 5G) is a base station through which communication devices (user equipment or UE) connect to the core network and communicate with other communication devices or remote servers. The communication devices may be, for example, mobile communication devices such as mobile phones, smartphones, smart watches, personal digital assistants, laptop / tablet computers, web browsers, e-book readers, etc. Such mobile (or generally fixed) device equipment is typically operated by a user (hence they are often collectively referred to as user equipment UE), although it is also possible for IoT devices and similar MTC devices to be connected to the network. For simplicity, this specification will use the term base station to refer to such base stations and the term mobile device or UE to refer to such communication devices.
[0004] The latest development in 3GPP standards is the so-called "5G" or New Radio (NR) standard, which refers to evolved communications technologies that are expected to support various applications and services, such as Machine Type Communication (MTC), Internet of Things (IoT) / Industrial Internet of Things (IIoT) communications, vehicular communications and autonomous vehicles, high-definition video streaming, and / or smart city services. 3GPP plans to support 5G via the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP Next Generation Core (NGC) networks. Various details of the 5G network are described, for example, in the "NGMN 5G White Paper" V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which is available at https: / / www.ngmn.org / 5g-white-paper.html.
[0005] End-user communication devices are commonly referred to as User Equipment (UE) and may be operated by humans or have automated (MTC / IoT) devices. Base stations in 5G / NR communication systems are commonly referred to as New Radio Base Stations (NR-BS) or "gNBs", although it is understood that they are more commonly referred to using the term "eNB" (or 5G / NR eNB), which is more commonly associated with Long Term Evolution (LTE) base stations (also commonly referred to as "4G" base stations). 3GPP Technical Specification (TS) 38.300 V16.4.0 and TS 37.340 V16.4.0 define, among other things, the following nodes:
[0006] gNB: A node that provides NR user plane and control plane protocol termination for the UE and is connected to the 5G core network (5GC) via the NG interface. ng-eNB: A node that provides E-UTRA (Evolved Universal Terrestrial Radio Access) user plane and control plane protocol termination for the UE and is connected to the 5GC via the NG interface. En-gNB: A node that provides NR user plane and control plane protocol termination for the UE and functions as a secondary node for EN-DC (E-UTRA-NR Dual Connectivity). NG-RAN node: Either gNB or ng-eNB.
[0007] 3GPP is also working on the specification of integrated satellite and terrestrial network infrastructure in the context of 5G. The term Non-Terrestrial Networks (NTN) refers to a network, or a segment of a network, that uses aircraft or spacecraft for communication. Satellite refers to a spacecraft in Geostationary Earth Orbit (GEO) or Non-Geostationary Earth Orbit (NGEO), such as Low Earth Orbit (LEO), Medium Earth Orbit (MEO), or Highly Elliptical Orbit (HEO). Aircraft refers to High Altitude Platforms (HAP), including Unmanned Aircraft Systems (UAS). This includes tethered UAS, lighter than aerial UAS, and heavier than aerial UAS, all of which typically operate in a quasi-geostationary manner at altitudes between 8 km and 50 km.
[0008] 3GPP Technical Report (TR) 38.811 V15.4.0 is a study on New Radio to support such non-terrestrial networks. This study includes, among other things, a description of NTN deployment scenarios and related system parameters (architecture, altitude, orbit, etc.) and adaptation of 3GPP channel models for non-terrestrial networks (propagation conditions, mobility, etc.). 3GPP TR 38.821 V16.0.0 provides further details on NTN.
[0009] In non-terrestrial networks, the following is expected: -Facilitate the rollout of 5G services in unserved and underserved areas and improve terrestrial network performance. -Enhancing service reliability by providing service continuity for user equipment and mobile platforms (e.g. passenger cars, aircraft, ships, high-speed trains, buses). -Improve service availability everywhere, especially for critical communications and future rail / maritime / air communications. - Achieving 5G network scalability through the provision of efficient multicast / broadcast resources for delivering data towards the network edge or directly to user equipment.
[0010] NTN Access typically includes (among other things): NTN terminal: may refer to a 3GPP UE, or a terminal specific to a satellite system in cases where the satellite does not directly provide a 3GPP UE. Service Link: refers to the radio link between user equipment and a space / airborne platform (which may be in addition to the radio link with the ground-based RAN). -Space or airborne platforms. -Gateway (NTN Gateway): connects satellite or aeronautical access networks to the core network. Gateways are almost always co-located with base stations. - Feeder link: Refers to the radio link between the gateway and the space / airborne platform.
[0011] A satellite or aircraft can generate multiple beams over a given area to provide each NTN cell, with the beams having a typical elliptical footprint on the Earth's surface.
[0012] 3GPP intends to support three types of NTN beams or cells. -Earth fixed cell: characterized by at least one beam that always covers the same geographical area (e.g. GEO satellites and HAPS). - Quasi-Earth fixed cell: characterized by at least one beam that covers one geographic area during a limited period of time and a different geographic area during another period of time (e.g., an NGEO satellite producing a steerable beam). -Earth moving cell: characterized by at least one beam that covers one geographical area at one moment and a different geographical area at another moment (e.g. NGEO satellites generating fixed or non-steerable beams).
[0013] If the satellite or aircraft has a fixed position in altitude / azimuth relative to a given point, such as GEO and UAS, the beam footprint is Earth-fixed.
[0014] If the satellite orbits the Earth (e.g., LEO) or is in an elliptical orbit around the Earth (e.g., HEO), the beam footprint may move over the Earth with the orbital motion of the satellite or aircraft. Alternatively, the beam footprint may be temporarily Earth-fixed (or quasi-Earth-fixed), in which case an appropriate beam-pointing mechanism (mechanical or electronic steering) can be used to compensate for the motion of the satellite or aircraft.
[0015] LEO satellites can have steerable beams, where the beams are temporarily directed to a substantially fixed footprint on the Earth. In other words, the footprint of the beam (representing the NTN cell) is stationary on the ground for a certain time before changing focus area to another NTN cell (due to the orbital movement of the satellite). From the cell coverage / UE point of view, even if the beams serve the same land area (have the same footprint), cell changes occur periodically at discrete intervals, since different Physical Cell Identity (PCI) and / or Signal / Physical Broadcast Channel (PBCH) blocks (SSB) have to be assigned after each service link change. In LEO satellites without steerable beams, as the satellite moves along its orbit, the beams (cells) perform a constant sweeping motion on the ground, and service link changes, and therefore cell changes, occur periodically at discrete intervals, just as in the case of steerable beams.
[0016] Similar to service link changes, feeder link changes also occur periodically as satellites move in orbit. Both service and feeder link changes can be implemented between different base stations / gateways (sometimes called inter-gNB radio link switches) or within the same base station / gateway (intra-gNB radio link switches).
[0017] The Physical Uplink Control Channel (PUCCH) carries a set of information called Uplink Control Information (UCI). UCI can also be transmitted via the Physical Uplink Shared Channel (PUSCH). The UCI used in NR (5G) includes one or more of the following: Channel State Information (CSI), HARQ feedback (ACK / NAK), and Scheduling Request (SR). This is roughly the same as in LTE (4G).
[0018] Typically, HARQ feedback is provided in the form of a codebook (a string of bits) that describes which data has been successfully received and which has not. The type of codebook used (e.g., "Type 1", "Type 2", or "Type 3") is determined based on appropriate RRC parameters. Each type of codebook is divided into two cases, depending on whether the HARQ feedback is reported using the PUCCH or the PUSCH.
[0019] To support NTN, several extensions to HARQ are being considered by 3GPP, such as extensions for the number of HARQ processes and enabling / disabling of HARQ feedback, as described in 3GPP TR 38.821. HARQ disablement is recommended by 3GPP to minimize the throughput impact of long propagation delays in NTN.
[0020] So far, the following agreements have been reached regarding enabling / disabling HARQ feedback: Enabling / disabling of HARQ feedback for downlink transmission should be configurable per HARQ process at least via UE specific RRC signaling. For a downlink (DL) HARQ process for which HARQ feedback is disabled, it is assumed that the UE will not receive another set of PDSCHs or slot-aggregated PDSCHs scheduled for that particular HARQ process that starts no later than “X” after the end of reception of the last PDSCH or slot-aggregated PDSCH for that HARQ process. The value and unit of X is yet to be defined. -For Type 1 HARQ codebooks, further discussion is needed on whether to report NACKs for invalid processes and whether to use criteria to reduce the size of the codebook. - For DL HARQ processes with invalid HARQ feedback, it is assumed that the UE does not receive another set of PDSCHs or slot-aggregated PDSCHs scheduled for that particular HARQ process that starts by "X" after the reception of the last PDSCH or slot-aggregated PDSCH of that HARQ process has finished. The working hypothesis is that X = T_proc,1. It is not yet decided whether X should be changed to X = max(T_proc,1,K1), where k1 is the minimum if K1 is set, and k1 = 0 otherwise. For Type 1 HARQ codebooks, a straightforward approach is to reuse the existing semi-static HARQ-ACK decision scheme. However, if a large number of HARQ processes are disabled, reducing the codebook size may be beneficial to reduce resources for the UL and reduce UE power consumption. Summary of the Invention [Problem to be solved by the invention]
[0021] A recent proposal by Vivo is recommended by 3GPP as a baseline for further discussion to reduce the size of the Type-1 codebook. This proposal is for the special case where only disabled HARQ processes are transmitted within each opportunity for candidate PDSCH reception (as per 3GPP TS 38.213 V16.5.0 clause 9.1.2.1). A,cIn this case, the HARQ-ACK feedback can be omitted.
[0022] The inventors have identified problems with this proposal. Specifically, A,c If all HARQ processes of an opportunity are disabled, there may be ambiguity between the base station and the UE, since the UE cannot know whether all HARQ processes are disabled in case of missed detection of discontinuous transmission (DTX) or downlink control information (DCI). Therefore, it is not clear how the UE knows whether only disabled HARQ processes are used in case of missed detection of DTX or DCI.
[0023] Accordingly, the present invention provides a method, and associated apparatus, that addresses or at least alleviates (at least some of) the problems set forth above.
[0024] For efficiency of understanding for those skilled in the art, the present invention will be described in detail in the context of a 3GPP system (5G network including NTN), but the principles of the present invention can be applied to other systems. [Means for solving the problem]
[0025] In one aspect, the present invention provides a method performed by a user equipment (UE) configured to communicate over a non-terrestrial based network, the method comprising receiving, from a network node, information indicating whether HARQ feedback is required for a set of transmission opportunities, and transmitting or omitting HARQ feedback for the set of transmission opportunities based on the information.
[0026] In one aspect, the present invention provides a method performed by a network node configured to communicate with a user equipment (UE) over a non-terrestrial network, the method comprising transmitting information to the UE indicating whether HARQ feedback is required for a set of transmission opportunities, and receiving or omitting HARQ feedback for the set of transmission opportunities based on the information.
[0027] In one aspect, the present invention provides a user equipment (UE) configured to communicate over a non-terrestrial based network, the UE including means for receiving information from a network node indicating whether HARQ feedback is required for a set of transmission opportunities, and means for transmitting or omitting HARQ feedback for the set of transmission opportunities based on the information.
[0028] In one aspect, the present invention provides a network node configured to communicate with a user equipment (UE) over a non-terrestrial based network, the network node comprising: means for transmitting information to the UE indicating whether HARQ feedback is required for a set of transmission opportunities, and means for receiving or omitting HARQ feedback for the set of transmission opportunities based on the information.
[0029] In one aspect, the present invention provides a user equipment (UE) configured to communicate over a non-terrestrial based network. The UE includes a processor, a transceiver, and a memory that stores instructions. A controller is configured to control the transceiver to receive information from a network node indicating whether HARQ feedback is required for a set of transmission opportunities, and to transmit or omit HARQ feedback for the set of transmission opportunities based on the information.
[0030] In one aspect, the present invention provides a network node configured to communicate with a user equipment (UE) over a non-terrestrial network. The network node includes a processor, a transceiver, and a memory storing instructions. A controller is configured to control the transceiver to send information to the UE indicating whether HARQ feedback is required for a set of transmission opportunities, and to receive or omit HARQ feedback for the set of transmission opportunities based on the information.
[0031] Aspects of the present invention extend to corresponding systems, apparatus, and computer program products, such as computer readable storage media having instructions stored thereon operable to program a programmable processor to perform the methods described in the above aspects and possibilities or as claimed, and / or suitably adapted to program a computer to provide an apparatus as described in any of the claims.
[0032] Each feature disclosed in this specification (including the claims) and / or shown in the drawings may be incorporated in the present invention independently of (or in combination with) other disclosed and / or shown features. In particular, but not limited to, any feature of a claim that relies on a particular independent claim may be introduced in any combination or individually in the independent claim. [Brief description of the drawings]
[0033] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
[0034] [Figure 1] FIG. 1 illustrates diagrammatically a mobile (cellular or wireless) communication system in which embodiments of the present invention are applicable. [Diagram 2] FIG. 2 is a schematic block diagram of a mobile device forming part of the system shown in FIG. [Diagram 3]FIG. 3 is a schematic block diagram of an NTN node (e.g., a satellite / UAS platform) forming part of the system shown in FIG. [Figure 4] FIG. 4 is a schematic block diagram of an access network node (eg a base station) forming part of the system shown in FIG. [Diagram 5] FIG. 5 illustrates diagrammatically some exemplary architectural options for providing NTN functionality in the system shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0035] overview FIG. 1 illustrates diagrammatically a mobile (cellular or wireless) communication system 1 in which embodiments of the present invention can be applied.
[0036] In this system 1, a user of a mobile device 3 (UE) communicates with an access network node using a suitable 3GPP radio access technology (RAT), for example E-UTRA and / or 5G RAT. ( Each satellite 5 and / or base station 6 ) and data network 7. As one skilled in the art will appreciate, while Figure 1 shows three mobile devices 3, one satellite 5 and one base station 6 for purposes of illustration, a system in implementation will typically include other satellite / UAS platforms, base stations / RAN nodes, and mobile devices (UE).
[0037] It will be understood that several base stations 6 form a (Radio) Access Network or (R)AN, and several NTN nodes 5 (satellite and / or UAS platforms) form a non-terrestrial based network (NTN). Each NTN node 5 is connected to an appropriate gateway (located with the base station 6 in this case) using a so-called feeder link and connected to each UE 3 via a corresponding service link. Thus, when the NTN node 5 provides a service, the mobile device 3 communicates data to and from the base station 6 via the NTN node 5 using the appropriate service link (between the mobile device 3 and the NTN node 5) and feeder link (between the NTN node 5 and the gateway / base station 6). In other words, the NTN forms part of the (R)AN, but can also provide satellite communication services independently of E-UTRA and / or 5G communication services.
[0038] It will be understood that several base stations 6 form a (Radio) Access Network or (R)AN, and several NTN nodes 5 (satellite and / or UAS platforms) form a non-terrestrial based network (NTN). Each NTN node 5 is connected to an appropriate gateway (located with the base station 6 in this case) using a so-called feeder link and connected to each UE 3 via a corresponding service link. Thus, when the NTN node 5 provides a service, the mobile device 3 communicates data to and from the base station 6 via the NTN node 5 using the appropriate service link (between the mobile device 3 and the NTN node 5) and feeder link (between the NTN node 5 and the gateway / base station 6). In other words, the NTN forms part of the (R)AN, but can also provide satellite communication services independently of E-UTRA and / or 5G communication services.
[0039] Although not shown in Figure 1, neighbouring base stations 6 are connected to each other via appropriate inter-base station interfaces (so-called "X2" interfaces, "Xn" interfaces, etc.) and the base stations 6 are connected to data network nodes via appropriate interfaces (so-called "S1", "NG-C", "NG-U" interfaces, etc.).
[0040] A data (or core) network 7 (e.g., EPC in LTE, NGC in NR / 5G) typically supports communications in the communication system 1 and includes logical nodes (or functions) for subscriber management, mobility management, charging, security, and call / session management. For example, the data network 7 in a "next generation" / 5G system includes user plane entities and control plane entities, such as one or more control plane functions (CPF) and one or more user plane functions (UPF). The data network 7 may also be coupled to other data networks, such as the Internet or similar Internet Protocol (IP)-based networks (not shown in FIG. 1).
[0041] Each NTN node 5 controls several directional beams in which an associated NTN cell may be provided. Specifically, each beam has an associated footprint on the Earth's surface that corresponds to the NTN cell. Each NTN cell (beam) has an associated Physical Cell Identity (PCI) and / or Beam ID. The beam footprint may move as the NTN node 5 moves along its orbit. Alternatively, the beam footprint may be Earth-fixed, in which case a suitable beam pointing mechanism (mechanical or electronic steering) may be used to compensate for the movement of the NTN node 5.
[0042] In their mutual communication, the UE 3 and the base station 6 communicate data organised in transport blocks (TBs) and provide associated HARQ feedback (one bit per TB) to check whether the data has been successfully received and decoded. In UE3 and base station 6 Media Access Control (MAC) layer( The serving cell (also referred to as the MAC entity) includes a HARQ entity for each serving cell that maintains multiple parallel HARQ processes, each of which is associated with a HARQ process identifier.
[0043] In the present system, at least when communicating via NTN, it is possible to enable / disable HARQ feedback (per HARQ process). Therefore, for each candidate opportunity for PDSCH reception (M A,c In case where only disabled HARQ processes are transmitted within a certain period (opportunity), the HARQ-ACK feedback may be omitted.
[0044] The base station 6 receives the corresponding M A,c The UE 3 is adapted to transmit a dynamic indication to the UE 3 that only disabled HARQ processes are / have been used during the M-channel hopping opportunity. For example, such an indication can be conveyed using an appropriate field of the DCI or an appropriate value in the MAC header. Based on this indication, the UE 3 can transmit a dynamic indication to the UE 3 that only disabled HARQ processes are / have been used during the M-channel hopping opportunity. A,c It may determine whether an opportunity is used during the transmission and may provide or omit HARQ-ACK feedback accordingly.
[0045] Thus, even if no DTX or DCI is detected, ambiguity between the base station 6 and the UE 3 can be avoided when only disabled HARQ processes are used (omitting HARQ-ACK feedback). Furthermore, this approach does not require additional signaling overhead.
[0046] User Equipment (UE) FIG. 2 is a block diagram showing the main components of the mobile device (UE) 3 shown in FIG. 1. As shown in the figure, the UE 3 includes a transceiver circuit 31 operable to transmit and receive signals to and from at least one connected node via one or more antennas 33. Although not necessarily shown in FIG. 2, the UE 3 of course has all the usual functions of a normal mobile device (such as a user interface 35), which may be provided by any one or any suitable combination of hardware, software, and firmware. The controller 37 controls the operation of the UE 3 according to software stored in the memory 39. The software may be pre-installed in the memory 39 or may be downloaded via the communication network 1, for example from a removable data storage device (RMD). The software includes, among other things, an operating system 41 and a communication control module 43.
[0047] The communication control module 43 is responsible for handling (generating / sending / receiving) signaling messages and uplink / downlink data packets between the UE 3 and other nodes including the NTN nodes 5, (R)AN nodes 6, and core network nodes. The signaling may include control signaling related to HARQ processes / HARQ feedback (e.g. enabling / disabling HARQ feedback per HARQ process).
[0048] NTN Node (Satellite / UAS Platform) FIG. 3 is a block diagram showing the main components of the NTN node 5 (satellite / UAS platform) shown in FIG. 1. As shown in the figure, the NTN node 5 includes a transceiver circuit 51 operable to transmit and receive signals to and from at least one connected UE 3 via one or more antennas 53, and to transmit and receive signals (directly or indirectly) to and from other network nodes such as gateways and base stations. A controller 57 controls the operation of the NTN node 5 according to software stored in a memory 59. The software may be pre-installed in the memory 59 or may be downloaded via the communication network 1, for example from a removable data storage device (RMD). The software includes, among other things, an operating system 61 and a communication control module 63.
[0049] The communication control module 63 is responsible for handling (generating / sending / receiving) signaling between the NTN node 5 and other nodes such as the UE 3, base stations 6, gateways, and core network nodes (via base stations / gateways). The signaling may include control signaling related to HARQ processes / HARQ feedback (e.g. enabling / disabling HARQ feedback per HARQ process).
[0050] Base Station / Gateway (Access Network Node) FIG. 4 is a block diagram showing the main components of the gateway 6 (base station (gNB) or similar access network node) shown in FIG. 1. As shown in the figure, the gateway / gNB 6 includes a transceiver circuit 71 operable to transmit and receive signals to and from at least one connected UE 3 via one or more antennas 73, and to transmit and receive signals to and from other network nodes (directly or indirectly) via a network interface 75. The signals may be transmitted and received directly to and from at least one UE 3 and / or via an NTN node 5. The network interface 75 typically includes a suitable base station-base station interface (such as X2 / Xn), and a suitable base station-core network interface (such as S1 / NG-C / NG-U). The controller 77 controls the operation of the base station 6 based on software stored in the memory 79. The software may be pre-installed in the memory 79, or may be downloaded via the communication network 1, for example from a removable data storage device (RMD). The software includes, among other things, an operating system 81 and a communication control module 83.
[0051] The communication control module 83 is responsible for handling (generating / sending / receiving) signaling between the base station 6 and other nodes such as the UE 3, the NTN node 5, and the core network nodes. The signaling may include control signaling related to HARQ processes / HARQ feedback (e.g. enabling / disabling HARQ feedback per HARQ process).
[0052] Detailed Description 3GPP TR 38.912 v16.0.0, section 8.2.2.2 provides the following overview of HARQ codebooks and processes used in NR systems:
[0053] One bit of HARQ-ACK feedback per TB is supported. For some UEs, the operation of more than one downlink (DL) HARQ process is supported, but for some UEs, the operation of one DL HARQ process is supported. The UE and the NR (base station) each have a minimum HARQ processing time. The HARQ processing time includes at least the delay from the DL data reception timing to the corresponding HARQ-ACK transmission timing and the delay from the uplink (UL) grant reception timing to the UL data transmission timing.
[0054] From the UE perspective, HARQ ACK / NACK feedback for multiple DL transmissions can be sent in one UL data / control region in time. The timing between DL data reception and the corresponding acknowledgment is indicated by a field in the DCI from a set of values, which is configured by higher layers. At least one timing is defined in case at least one timing is unknown to the UE.
[0055] Code Block Group (CBG) based transmission with single / multi-bit HARQ-ACK feedback is supported.
[0056] A more detailed description of some example embodiments and features is provided below for the case where HARQ feedback is omitted (only disabled HARQ processes are M A,c If sent within the opportunity, the details are provided below.
[0057] In order to avoid ambiguity between the UE 3 and the base station 6, the base station 6 A,C It is configured to dynamically indicate to the UE 3 whether HARQ feedback is expected or not for a set of opportunities.
[0058] In the first option, the base station 6 uses the DCI (e.g., an appropriate field thereof) to A,CAn appropriate indication can be conveyed to the UE 3 that only disabled HARQ processes are / were used for the UE 3 during the opportunity. A new field may be defined in the DCI to indicate when HARQ feedback is not expected (or to indicate when HARQ feedback is expected). Alternatively, since some fields of the DCI (e.g., the PUCCH resource indicator "PRI" field) are redundant for processes for which feedback is disabled, the base station 6 can reuse one of such redundant fields to dynamically indicate whether HARQ feedback is expected or not when HARQ feedback is not expected.
[0059] Based on the indication contained in the DCI (i.e., based on the value of the appropriate field), the UE 3 selects the appropriate M A,C It can be determined whether only disabled HARQ processes are used at the time of the opportunity. A,C If the HARQ process is used / used during the opportunity, the UE 3 may be configured to omit the HARQ feedback, or if all HARQ processes are not disabled (i.e., the corresponding M A,C If at least one HARQ process is enabled during the opportunity), the UE 3 may be configured to transmit appropriate HARQ feedback.
[0060] In the second option, the base station 6 uses the MAC header to identify the relevant M A,C During the opportunity, the UE 3 may convey an appropriate indication (e.g., an appropriate value in the MAC header) that only disabled HARQ processes are used / have been used. In this case, the UE 3 may determine whether or not the corresponding MARQ process is used based on the indication contained in the MAC header. A,C It may determine whether only disabled HARQ processes are used during the opportunity / have been used and send / omit HARQ feedback accordingly.
[0061] When using the MAC header for this purpose, the base station 6 uses reserved values for the fields and A,C In this case, the base station 6 may indicate to the UE 3 that no feedback is expected for the opportunity. A,C If the base station 6 knows that the feedback for an opportunity does not require the scheduling of a valid HARQ process, it can transmit the reserved value of the indicator field from the beginning. However, if the base station 6 is not sure at first whether it needs to schedule a valid HARQ process (e.g., due to a situation where the number of disabled processes is low or due to uncertainty about whether a large amount of DL traffic will suddenly arrive), but later finds that all processes will be HARQ disabled, the base station 6 can start transmitting the reserved value of the indicator field from the opportunity when it is sure. Even if one instance of the indicator field with a reserved value is detected by the UE 3, the UE 3 can send the corresponding MARQ process to the base station 6. A,C It may be determined that no HARQ-ACK feedback is expected for the opportunity.
[0062] Regardless of which option is used, the benefits associated with the dynamic indications described above include: -No additional signaling overhead and / or little additional signaling overhead In case of DTX or DCI detection miss, there is no ambiguity between the base station 6 and the UE 3.
[0063] UE and base station operation Here, only the disabled HARQ processes are A,c Some possible use cases and procedures performed in the UE 3 and base station 6, respectively, to dynamically omit HARQ feedback (if transmitted within an opportunity) are now described in more detail.
[0064] Case 1: All HARQ processes in the UE are disabled - Base station behavior: Always send reserved value in indicator field / do not expect HARQ-ACK feedback from UE3. -UE behavior: No HARQ-ACK feedback is sent even if one indicator field is correctly decoded. It will be appreciated that in this case, the UE 3 will ideally know that there is no need to send HARQ feedback since all processes are set to disabled.
[0065] Case 2: The base station has the corresponding M A,c There is no need to schedule feedback-enabled HARQ processes within an opportunity - Base station behavior: transmit reserved value of indicator field from the beginning / do not expect HARQ-ACK feedback from UE3. -UE behavior: No HARQ-ACK feedback is sent even if one instance of the indicator field is correctly decoded (DTX and DCI miss detection is ignored (HARQ disabled process is assumed)).
[0066] Case 3: The base station has the corresponding M A,C Not sure if a valid HARQ process needs to be scheduled within an opportunity? - Base station operation: Start PDSCH transmission using a HARQ process with feedback disabled without using a reserved value in the indicator field / send the reserved value in the indicator field from an instance where it can be confirmed that there is no HARQ enabled process and no feedback is required. -UE behavior: Ignore the indicator field value of the previous HARQ disabled process even if one instance of the indicator field is detected, and A,c Do not send HARQ feedback for the opportunity.
[0067] Case 4: Applicable M A,C At least one SPS PDSCH opportunity configured within the opportunity In this case, the HARQ process number of the Semi-Persistent Scheduling (SPS) configuration is associated with the slot index. Therefore, the base station 6 can assign the HARQ process number to the M without imposing strict scheduling restrictions or unless all HARQ processes of the UE 3 are disabled. A,c It is not possible to disable HARQ for all HARQ processes within an opportunity. In this case, the codebook size can be reduced as follows: - Base station action: Start transmitting PDSCH using a feedback disabled HARQ process without using a reserved value in the indicator field / send the reserved value from instances where it can be confirmed that no HARQ enabled processes exist and that no feedback is required on all occasions except when at least one SPS PDSCH is configured. -UE behavior: Even if one instance with a reserved value of the indicator field is detected, ignore the indicator field values of other HARQ disabled processes and send HARQ ACK / NACK feedback only for at least one SPS PDSCH opportunity. ACK / NACK feedback is sent for all SPS PDSCH opportunities regardless of the HARQ process number.
[0068] Modifications and Substitutions Detailed embodiments have been described above. As will be appreciated by those skilled in the art, the above embodiments are susceptible to several modifications and alternatives while still benefiting from the invention embodied therein. By way of example, some of these alternatives and modifications are described.
[0069] It will be understood that the above embodiments are applicable to both 5G New Radio and LTE systems (E-UTRAN). A base station (gateway) supporting E-UTRAN / 4G protocols can be referred to as an "eNB", and a base station supporting next-generation / 5G protocols can be referred to as a "gNB". It will be understood that some base stations can be configured to support both 4G and 5G protocols, and / or other 3GPP or non-3GPP communication protocols.
[0070] It will be appreciated that there are various architecture options for implementing NTNs in 5G systems, some of which are shown diagrammatically in FIG. 5. The first option shown is a satellite / aircraft based NTN featuring an access network serving UEs, with bent-pipe payloads and terrestrial (satellite hub or gateway level) gNBs. The second option is a satellite / aircraft based NTN featuring an access network serving UEs, with gNBs. The third option is a satellite / aircraft based NTN featuring an access network serving relay nodes, with bent-pipe payloads. The fourth option is a satellite / aircraft based NTN featuring an access network serving relay nodes, with gNBs. Other architecture options may also be used, for example a combination of two or more of the above options. Alternatively, the relay nodes may include satellites / UASs. [Table 1]
[0071] The above embodiments use a system including a non-terrestrial portion as an example. However, it will be understood that HARQ processes may be disabled in other types of systems as well (e.g., NR systems without NTN capabilities, or systems using a combination of NTN and NR cells). Thus, the above embodiments are applicable to any system using disabled HARQ processes that can provide dynamic indications to control whether to provide / omit associated HARQ feedback.
[0072] In the above description, for ease of understanding, the UE, NTN node (satellite / UAS platform), and access network node (base station) have been described as having several separate modules (such as communication control modules). These modules may be provided in this way for certain applications, such as when an existing system is modified to implement the present invention, but in other applications, such as systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into an overall operating system or code and therefore may not be identified as separate entities. These modules may also be implemented in software, hardware, firmware, or a combination of these.
[0073] Each controller may include any suitable form of processing circuitry including, but not limited to, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communications buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) facilities, hardware or software implemented counters, pointers and / or timers, etc.
[0074] In the above embodiment, some software modules are described. As can be understood by those skilled in the art, the software modules may be provided in compiled or uncompiled form and provided to the UE, the NTN node, and the access network node (base station) via a computer network or as a signal on a recording medium. Furthermore, the functions performed by some or all of the software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates updates to update the functionality of the UE, NTN node and access network node (base station).
[0075] The above embodiments are also applicable to "non-mobile" or generally fixed user equipment. Such mobile devices may include MTC / IoT devices and / or the like.
[0076] Information from a network node indicating whether HARQ feedback is required for a set of transmission opportunities may be included in Downlink Control Information (DCI). For example, the information may be included in a PUCCH Resource Indicator (PRI) field of the DCI. Alternatively, the information may be included in a Medium Access Control (MAC) header.
[0077] The HARQ feedback may include Type 1 HARQ feedback.
[0078] If the received information indicates that HARQ feedback is not required for the set of transmission opportunities, the method may include omitting HARQ feedback for the set of transmission opportunities.
[0079] The method performed by the UE may further include detecting a missed discontinuous transmission (DTX) or a missed DCI, and ignoring the missed DTX or DCI if the received information indicates that HARQ feedback is not required for the set of transmission opportunities.
[0080] The UE may be configured to communicate using semi-persistent scheduling (SPS), in which case the method may include sending HARQ feedback for an SPS transmission in a slot having a slot index if the received information indicates that HARQ feedback is not required for a transmission opportunity associated with the slot index.
[0081] If the UE is configured to communicate using semi-persistent scheduling (SPS), the method performed by the network node may further include, if the received information indicates that HARQ feedback is not required for a transmission opportunity associated with the slot index, receiving HARQ feedback for an SPS transmission in a slot having the slot index.
[0082] The network node may include a base station device or a gateway.
[0083] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
[0084] Below is a detailed description of how the invention may be implemented in the context of the currently proposed 3GPP standard. Although various features are described as essential or required, this is only the case for the proposed 3GPP standard, e.g., due to other requirements imposed by the standard. Thus, these descriptions should not be construed as limiting the invention in any manner.
[0085] Discussion on HARQ extension for NR NTN 1. Introduction A work item on NR solutions to support non-terrestrial networks (NTN) was approved in RAN#86, and one of the objectives is to specify HARQ extensions for NTN. Specifically, according to WID[1], the following HARQ extensions should be specified in RAN1: - Number of HARQ processes - Enable / disable HARQ feedback as described in TR 38.821 In this paper, we discuss our views on the extension of the HARQ-ACK codebook when HARQ-ACK information is disabled, the indication of HARQ process ID, and the limitations of HARQ feedback disablement.
[0086] 2. Discussion 2.1 HARQ-ACK Codebook Extension At the RAN1#102 e-conference, it was agreed that enabling / disabling of HARQ feedback for downlink transmissions should be configurable per HARQ process at least via UE-specific RRC signaling. To avoid redundant feedback overhead, at the RAN1#104 e-conference, the following agreement was reached regarding the extension of the HARQ-ACK codebook [2]:
[0087] agreement: For NTN type-2 HARQ codebook: The size of the codebook is reduced by using a HARQ-ACK codebook that only contains HARQ-ACKs for PDSCHs using feedback-enabled HARQ processes. FFS: Details of C-DAI and T-DAI count for DCI on PDSCH with feedback enabled / disabled HARQ process.
[0088] For the Type-1 HARQ-ACK codebook, the following options are under discussion without consensus: -Option 1: No expansion. -Option 2: Report a NACK for disabled processes. -Option 3: Use a criterion to reduce the codebook size.
[0089] Option 1, i.e., no extension, seems to be a straightforward way to avoid impact on the specification. However, it needs to be clarified whether the UE follows the conventional behavior to generate ACK / NACK for disabled HARQ processes. If not, option 2 seems to be the preferred choice for semi-static HARQ codebook decision. However, when only a few HARQ processes are enabled and the maximum number of supported HARQ processes is extended to 32, the type-1 HARQ-ACK codebook extension is useful to reduce the redundancy overhead. In our view, the following cases are considered for type-1 codebook extension: Case 1: All HARQ processes of one UE are set to disabled. -Case 2: M A,c All HARQ processes used for scheduling within the opportunity are disabled. In our opinion, if all HARQ processes of the UE are set to disabled, the HARQ-ACK report can be omitted without any ambiguity concerns between the gNB and the UE.
[0090] Proposal 1: If all HARQ processes of a UE are set to disabled, HARQ-ACK feedback is omitted. As in case 1, M A,c If the HARQ processes used for scheduling within an opportunity are disabled, the HARQ-ACK feedback can be omitted. However, a concern was raised in the last meeting that in case of DTX and DCI miss detection, ambiguity may arise between the gNB and the UE, since the UE will not know that all HARQ processes are disabled. In our view, M A,c The ambiguity can be avoided by informing the UE that all HARQ processes for the opportunity are disabled. There are two possible options to inform the UE of this information:
[0091] Option 1: DCI is A,c Carries an indication that only disabled HARQ processes are / were used by the UE during the opportunity. Since some fields in the DCI are redundant for processes for which feedback is disabled (e.g., PRI), it is proposed to reuse one of these redundant fields when no HARQ feedback is expected. The reserved value for the indication field is M A,c The UE may be informed that no feedback is expected for the opportunity.
[0092] Option 2: Layer 2 is M A,c Indicates to the UE that only disabled HARQ processes are used / have been used at the opportunity. For example, the MAC CE or one bit in the MAC header can be used for this indication.
[0093] Such dynamic indication can mitigate concerns about DCI miss detection or DTX ambiguity and is beneficial to reduce redundant UL overhead. For example, considering option 1, A,cIf the gNB knows that it does not need to schedule a feedback-enabled HARQ process at the opportunity, it can transmit a reserved value in the indicator field from the beginning. However, if the gNB is initially uncertain whether it needs to schedule an enabled HARQ process (e.g., due to a small number of disabled processes and uncertainty about whether a large amount of DL traffic will suddenly arrive), but later finds that all processes are HARQ disabled, it can start transmitting DCI with a reserved value in the indicator field from the opportunity when it is confident. Even if one DCI is successfully decoded with a reserved value in the indicator field, the UE may not be able to send DCIs in the M-channel UE. A,c It can be known that no HARQ-ACK feedback is expected for the opportunity.
[0094] Observation 1: M A,c A dynamic indication to the UE whether HARQ feedback is expected for an opportunity helps reduce the codebook size.
[0095] At least one SPS PDSCH is A,c If configured within an opportunity, the proposed dynamic indication mechanism also helps to reduce the Type-1 codebook size. The HARQ process number for SPS configuration is associated with the slot index. Thus, the gNB can schedule the MARQ process without imposing strict scheduling restrictions or unless all HARQ processes of the UE are disabled. A,c It is not possible to confirm that all HARQ processes within the opportunity are HARQ disabled, but the SPS PDSCH opportunity is known to the UE. Therefore, the reduction of the codebook size can be achieved as follows: -gNB operation: Set the indicator field to M A,cStart transmitting PDSCH using feedback-disabled HARQ processes without setting the feedback-enabled HARQ process to a value meaning that no feedback is expected for the opportunity. Depending on whether Option 1 or Option 2 is employed, transmit a Layer 1 or Layer 2 indicator field with a reserved value from instances where it can be ensured that there are no HARQ-enabled processes and that no feedback is required for all opportunities except for those where at least one SPS PDSCH opportunity is configured. -UE behavior: Even if one instance of the indicator field with a reserved value is detected, ignore the indicator field values of other HARQ disabled processes and send HARQ A / N feedback only for at least one SPS PDSCH opportunity. To avoid ambiguity due to DTX, we propose to send ACK / NACK feedback on all SPS PDSCH opportunities, regardless of the HARQ process number in this case.
[0096] Observation 2: M A,c If only HARQ disabled processes and SPS PDSCH are scheduled at an opportunity, a reduction in the codebook size can be achieved.
[0097] Proposal 2: Type-1 codebook enhancement is supported as follows. -Layer 1 / Layer 2 signaling is only for HARQ disabled processes A,c Used to indicate something is scheduled for an opportunity. -M A,c If the SPS PDSCH is not configured within the opportunity, the UE omits the HARQ feedback. -M A,c The UE omits HARQ feedback for non-SPS PDSCH opportunities if at least one SPS PDSCH is configured within the opportunity. The UE shall report HARQ feedback for all SPS PDSCH opportunities regardless of the HARQ process number.
[0098] 3. Conclusion As a result of the discussion, the following insights and suggestions were obtained:
[0099] Proposal 1: If all HARQ processes of a UE are set to disabled, HARQ-ACK feedback is omitted.
[0100] Observation 1: M A,c A dynamic indication to the UE whether HARQ-feedback is expected for an opportunity helps to reduce the size of the codebook.
[0101] Observation 2: HARQ disabled processes and only SPS PDSCH are A,c If scheduled opportunistically, a reduction in codebook size can be achieved.
[0102] Proposal 2: Type 1 codebook enhancement is supported as follows. -Layer 1 / Layer 2 signaling is only for HARQ disabled processes A,c Used to indicate something is scheduled on an occasion. -M A,c If the SPS PDSCH is not configured within the opportunity, the UE omits the HARQ feedback. -M A,c The UE omits HARQ feedback for non-SPS PDSCH opportunities if at least one SPS PDSCH is configured within the opportunity. The UE shall report HARQ feedback for all SPS PDSCH opportunities regardless of the HARQ process number.
[0103] 4. References [1]RP-193234, “NR-NTN: Solutions for NR to support non-terrestrial networks(NTN)”, RAN#86, December 2019. [2] RAN1 Chairman's Note, 3GPP TSG RAN WG1 Meeting#104-e, e-Meeting, January 25 - February 5, 2021.
[0104] For example, all or part of the exemplary embodiments disclosed above can be described as follows, but are not limited to these. (Appendix 1) 1. A method performed by a user equipment (UE) configured to communicate over a non-terrestrial based network, comprising: receiving information from a network node indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is required for a set of transmission opportunities; transmitting or omitting the HARQ feedback for the set of transmission opportunities based on the information. (Appendix 2) 2. The method of claim 1, wherein the information is included in Downlink Control Information (DCI). (Appendix 3) 3. The method of claim 2, wherein the information is included in a Physical Uplink Control Channel (PUCCH) Resource Indicator (PRI) field of the DCI. (Appendix 4) 2. The method of claim 1, wherein the information is included in a Medium Access Control (MAC) header. (Appendix 5) 5. The method of any one of claims 1 to 4, wherein the HARQ feedback comprises Type 1 HARQ feedback. (Appendix 6) 6. The method of any one of claims 1 to 5, wherein if the information indicates that HARQ feedback for the set of transmission opportunities is not required, HARQ feedback for the set of transmission opportunities is omitted. (Appendix 7) Detects missing discontinuous transmission (DTX) or missing DCI, 7. The method of any one of claims 1 to 6, wherein if the information indicates that HARQ feedback for the set of transmission opportunities is not required, ignoring the missed DTX or the missed DCI. (Appendix 8) When the UE is configured to communicate using Semi-Persistent Scheduling (SPS), 8. The method of claim 1, further comprising transmitting HARQ feedback for SPS communication in a slot having a slot index if the information indicates that the HARQ feedback is not required for at least one of the set of transmission opportunities associated with a slot index. (Appendix 9) 1. A method performed by a network node configured to communicate with a User Equipment (UE) over a non-terrestrial based network, comprising: sending, to the UE, information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is required for a set of transmission opportunities; receiving or omitting the HARQ feedback for the set of transmission opportunities based on the information. (Appendix 10) 10. The method of claim 9, wherein the information is included in Downlink Control Information (DCI). (Appendix 11) 11. The method of claim 10, wherein the information is included in a Physical Uplink Control Channel (PUCCH) Resource Indicator (PRI) field of the DCI. (Appendix 12) 10. The method of claim 9, wherein the information is included in a Medium Access Control (MAC) header. (Appendix 13) 13. The method of any one of claims 9 to 12, wherein the HARQ feedback comprises Type 1 HARQ feedback. (Appendix 14) When the UE is configured to communicate using Semi-Persistent Scheduling (SPS), 14. The method of any one of claims 9 to 13, comprising receiving HARQ feedback for an SPS communication in a slot having a slot index if the information indicates that the HARQ feedback for at least one of a set of transmission opportunities associated with a slot index is not required. (Appendix 15) 15. The method of any one of claims 9 to 14, wherein the network node comprises a base station or a gateway. (Appendix 16) 16. The method of any one of claims 1 to 15, wherein the information indicates that only disabled HARQ processes are used for transmission during each of the transmission opportunities. (Appendix 17) A user equipment (UE) configured to communicate over a non-terrestrial network, means for receiving, from a network node, information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is required for a set of transmission opportunities; and means for transmitting or omitting the HARQ feedback for the set of transmission opportunities based on the information. (Appendix 18) A network node configured to communicate with a user equipment (UE) via a non-terrestrial network, means for transmitting, to the UE, information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is required for a set of transmission opportunities; and means for receiving or omitting HARQ feedback for the set of transmission opportunities based on the information.
[0105] This application is based on and claims the benefit of priority to UK patent application No. 2104751.9, filed April 1, 2021, the disclosure of which is incorporated herein by reference in its entirety. [Explanation of symbols]
[0106] 1. Mobile communication systems 3. Mobile device users 5 satellites 6 base station 7 Data Network 31 Transceiver Circuit 33 Antenna 35 User Interface 37 Controller 39 Memory 41 Operating Systems 43 Communication Control Module 51 Transceiver Circuit 53 Antenna 57 Controller 59 Memory 61 Operating Systems 63 Communication Control Module 71 Transceiver Circuit 73 Antenna 75 Network Interface 77 Controller 79 Memory 81 Operating Systems 83 Communication Control Module
Claims
1. 1. A User Equipment (UE) configured to communicate over a non-terrestrial network (NTN), comprising: means for receiving, from a network node, information indicating whether HARQ feedback is required for each HARQ process; means for receiving Downlink Control Information (DCI) from the network node, the DCI including information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback for a set of Physical Downlink Shared Channel (PDSCH) candidate opportunities is required, in a field that was used to indicate information about HARQ resources; means for determining whether to transmit the HARQ feedback for the set of opportunities based on the information indicating whether the HARQ feedback for the set of opportunities is required, regardless of the information indicating whether the HARQ feedback is required for each HARQ process; A UE comprising:
2. means for detecting discontinuous transmission (DTX) or missing DCI; means for ignoring the missed DTX or the missed DCI if the information indicates that HARQ feedback for the set of opportunities is not required; The UE of claim 1 , comprising:
3. When the UE is configured to communicate using Semi-Persistent Scheduling (SPS), 3. The UE of claim 1, further comprising: means for transmitting HARQ feedback for SPS communication in a slot having a slot index when the information indicates that the HARQ feedback for the set of opportunities included in the slot having the slot index is not required.
4. 1. A network node configured for communicating with a User Equipment (UE) via a Non-terrestrial network (NTN), comprising: means for transmitting, to the UE, information indicating whether HARQ feedback is required for each HARQ process; means for transmitting, to the UE, Downlink Control Information (DCI) including information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback for a set of Physical Downlink Shared Channel (PDSCH) candidate opportunities is required in a field that was used to indicate information regarding HARQ resources; A network node in which the UE determines whether to transmit the HARQ feedback for the set of opportunities based on the information indicating whether the HARQ feedback is required for the set of opportunities, regardless of the information indicating whether the HARQ feedback is required for each HARQ process.
5. 1. A method in a User Equipment (UE) configured for communication over a Non-terrestrial network (NTN), comprising: receiving information from a network node indicating for each HARQ process whether HARQ feedback is required; receiving Downlink Control Information (DCI) from the network node, the DCI including information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback for a set of Physical Downlink Shared Channel (PDSCH) candidate opportunities is required in a field that was used to indicate information about HARQ resources; determining whether to transmit the HARQ feedback for the set of opportunities based on the information indicating whether the HARQ feedback for the set of opportunities is required, regardless of the information indicating whether the HARQ feedback is required for each HARQ process; A method comprising:
6. 1. A method in a network node arranged to communicate with User Equipment (UE) via a Non-terrestrial network (NTN), comprising: transmitting, to the UE, information indicating whether HARQ feedback is required for each HARQ process; transmitting Downlink Control Information (DCI) to the UE, the DCI including information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback for a set of Physical Downlink Shared Channel (PDSCH) candidate opportunities is required in a field that was used to indicate information regarding HARQ resources; A method in which the UE decides whether to transmit the HARQ feedback for the set of opportunities based on the information indicating whether the HARQ feedback for the set of opportunities is required, regardless of the information indicating whether the HARQ feedback is required for each HARQ process.
Citation Information
Patent Citations
Terminal device, base station device, control method for terminal device, and control method for base station device
WO2021029296A1