End-to-end hybrid automatic repeat request (HARQ) for relay communication through user equipment (UE) cooperation

Abstract

An end-to-end HARQ process is associated with a data transmission from a first end node to a second end node along a UE relay path. The UE relay path includes a plurality of links between nodes along an entire UE relay path between the first end node and the second end node. The end-to-end HARQ process is a single HARQ process represented by a single HARQ process identifier.

Description

[0001] Cross-reference to related applications

[0002] This application relates to and claims priority to U.S. Provisional Patent Application No. 63 / 135,138, filed January 8, 2021, entitled “End-to-End Hybrid Automatic Repeat Request (HARQ) for Relay Communications with User Equipment (UE) Collaboration”, and U.S. Patent Application No. 17 / 565,549, filed December 30, 2021, entitled “End-to-End Hybrid Automatic Repeat Request (HARQ) for Relay Communications with User Equipment (UE) Collaboration”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application generally relates to communications in wireless communication networks, and more specifically to end-to-end hybrid automatic repeat request (HARQ) for relay communications involving user equipment (UE) cooperation. Background Technology

[0004] According to "relay" technology in so-called Long Term Evolution (LTE) and New Radio (NR), UEs communicate directly to facilitate downlink and uplink transmissions. While the primary target for relay technology in LTE is public safety applications, new requirements are emerging in NR for commercial applications and public safety enhancements. The development of relay technology can increase the performance requirements for relay systems, in terms of performance measurements such as system throughput, coverage, latency, and reliability. New applications and requirements for multi-hop relay in NR may not only aim to provide coverage extension but also to provide enhanced system throughput, for example, for video surveillance and feedback in police and firefighter applications.

[0005] UE cooperation (UC) involves a collaborative process among UEs within a group of UEs. This can be achieved through a group of UEs assisting each other in downlink and / or uplink communication to improve UE peak data rates and system throughput, especially at the edge of coverage areas. One option for UC is to use UE relay, which involves a UE forwarding data for another UE. For example, cooperating UEs coordinate with each other to assist a target UE, with data being sent from or to the target UE.

[0006] In traditional UE relay methods, a conventional HARQ process is applied between two consecutive UEs (relay UEs) or between a relay UE and an end node. In multi-hop systems, this can be called a hop-by-hop HARQ process. A next-hop transmission only begins after the previous hop transmission (or retransmission) using the hop-by-hop HARQ process is successful. Each successful hop transmission terminates its corresponding hop-by-hop HARQ process. The separation of different hop transmissions and HARQ processes can be detrimental to UC (Uninterrupted Receiver) and retransmissions across discontinuous nodes, such as discontinuous relay UEs, relay UEs and discontinuous end nodes along the relay path, or nodes with multiple links from the previous node and capable of receiving the same data from multiple links. This can lead to increased latency, especially in multi-hop relay systems. Summary of the Invention

[0007] This paper proposes an end-to-end HARQ process to provide end-to-end HARQ for data communication between a pair of end nodes, thereby improving overall system performance such as stability and latency. The end-to-end HARQ process can be used for data communication on multiple links in a UE relay path involving UE cooperation, for example, and may involve multi-path communication, and each path may contain a single link (direct path) or multiple links.

[0008] In some embodiments, the HARQ process for end-to-end relays and UCs can be used for end-to-end multipath / multihop relays and UCs between a pair of nodes, including a source node and a destination node. In some embodiments, the HARQ entity may exist only at the source node and destination node at the beginning and end of the relay traffic. For example, the same HARQ process with the same HARQ identifier (ID) can be applied to each link, segment, or hop transmission between the source node and the destination node to carry the same data. If multiple paths are configured between the source node and the destination node, the same HARQ process can be applied to each path (including each link or segment of each path) to carry the same data between the source node and the destination node.

[0009] A HARQ buffer for the same HARQ process may be reserved or otherwise configured on each node in a multi-link path, including one or more relay UEs, the source node, and the destination node. In some embodiments, the HARQ buffer at a node may be a shared HARQ buffer shared between one or more end-to-end HARQ processes and one or more hop-by-hop HARQ processes.

[0010] After a relay UE and / or a destination node identifys the received data as the same or related data transmitted using the same end-to-end HARQ process, it can apply soft or hard merging of data received through different links.

[0011] Retransmissions to the destination node using an end-to-end HARQ process may be sent from the source node or a relay UE on the same or different paths between the source node and the destination node.

[0012] The potential applications of the HARQ process disclosed in this article may include scenarios with virtual UEs, different traffic types with relatively strict or less strict latency requirements, and scenarios with more periodic traffic (such as IoT scenarios).

[0013] One aspect of this disclosure relates to a method that may include transmitting signaling for configuring an end-to-end HARQ process in a wireless communication network. The end-to-end HARQ process is associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path including multiple links between nodes along the relay path between the first and second end nodes. The end-to-end HARQ process is a single HARQ process represented by a single HARQ process identifier.

[0014] An apparatus according to another aspect of this disclosure includes: a communication interface; a processor coupled to the communication interface; and a non-transitory computer-readable storage medium coupled to the processor. The non-transitory computer-readable storage medium stores a program executed by the processor. The program includes instructions to: transmit signaling in a wireless communication network for configuring an end-to-end HARQ process associated with a first data transmission along a UE relay path from a first end node to a second end node. The UE relay path includes multiple links between nodes along the relay path between the first end node and the second end node, and the end-to-end HARQ process is a single HARQ process represented by a single HARQ process identifier.

[0015] Another embodiment involving a medium relates to a computer program product comprising a non-transitory computer-readable storage medium containing a stored program. The program includes instructions to transmit signaling in a wireless communication network for configuring an end-to-end HARQ process. As in other embodiments described above and elsewhere herein, the end-to-end HARQ process is associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path comprising multiple links between nodes along the relay path between the first and second end nodes, and the end-to-end HARQ process is a single HARQ process represented by a single HARQ process identifier.

[0016] Other aspects and features of the embodiments of this disclosure will become apparent to those skilled in the art after reading the following description. Attached Figure Description

[0017] To more fully understand this embodiment and its advantages, the following description, taken with reference to the accompanying drawings, will now be provided by way of example, wherein:

[0018] Figure 1 A block diagram to provide a simplified schematic of a communication system;

[0019] Figure 2 To illustrate another exemplary communication system;

[0020] Figure 3 A block diagram illustrating exemplary electronic and network devices;

[0021] Figure 4 To illustrate the block diagram of a unit or module in the device;

[0022] Figure 5 Here is a block diagram illustrating another exemplary communication system for UE collaboration and multi-hop communication paths;

[0023] Figure 6 A block diagram illustrating another example of a multi-hop communication path;

[0024] Figure 7 A block diagram illustrating an exemplary HARQ protocol stack according to embodiments involving indirect relay paths and direct paths between a UE and a network device;

[0025] Figure 8 A block diagram illustrating an exemplary HARQ protocol stack based on another embodiment involving two indirect relay paths between a UE and a network device;

[0026] Figure 9 A block diagram illustrating an exemplary HARQ protocol stack according to another embodiment involving two indirect relay paths between two end nodes;

[0027] Figure 10 A block diagram illustrating an example of a HARQ process with a multi-hop communication path;

[0028] Figure 11 A block diagram illustrating an exemplary HARQ cache configuration;

[0029] Figure 12 A block diagram illustrating an example of multipath communication with end-to-end HARQ process buffer and hop-by-hop HARQ process buffer allocation;

[0030] Figure 13A block diagram illustrating an example of hop-by-hop feedback in multipath, multi-hop communication;

[0031] Figure 14 A block diagram illustrating another example of hop-by-hop feedback in multipath, multi-hop communication;

[0032] Figure 15 A block diagram illustrating an example of end-to-end feedback and retransmission in multipath, multi-hop communication;

[0033] Figure 16 A block diagram illustrating an exemplary application of HARQ combined with a virtual UE;

[0034] Figure 17 A block diagram illustrating the different types of HARQ processes used for different types of traffic;

[0035] Figure 18 Includes a diagram showing examples of bursts and periodic flows;

[0036] Figure 19 To illustrate a block diagram of an exemplary Internet of Things (IoT) system;

[0037] Figure 20 A signal flow diagram illustrating the operation provided in one embodiment;

[0038] Figure 21 A block diagram illustrating an example of a telecommunications network provided in one embodiment;

[0039] Figure 22 A block diagram illustrating an example of a network serving two UEs. Detailed Implementation

[0040] For the purpose of illustration, specific exemplary embodiments are explained in more detail below with reference to the accompanying drawings.

[0041] The embodiments described herein illustrate information sufficient to practice the claimed subject matter and demonstrate methods for practicing such subject matter. Upon reading the following description in conjunction with the accompanying drawings, those skilled in the art will understand the concepts of the claimed subject matter and will recognize that the application of these concepts is not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of this disclosure and the appended claims.

[0042] refer to Figure 1As a non-limiting illustrative example, a simplified schematic diagram of a communication system is provided. Communication system 100 includes a radio access network 120. Radio access network 120 may be a next-generation (e.g., sixth-generation, 6G, or later) radio access network, or a traditional (e.g., 5G, 4G, 3G, or 2G) radio access network. One or more electric devices (EDs) 110a to 110j (generally referred to as 110) may be interconnected with each other and may also, or alternatively, be connected to one or more network nodes (170a, 170b, generally referred to as 170) in radio access network 120. Core network 130 may be part of the communication system and may depend on or be independent of the radio access technology used in communication system 100. Furthermore, communication system 100 includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0043] Figure 2 An exemplary communication system 100 is illustrated. Generally, the communication system 100 enables multiple wireless or wired components to transmit data and other content. The purpose of the communication system 100 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, and unicast. The communication system 100 can operate by sharing resources such as carrier spectrum bandwidth among its constituent elements. The communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. The communication system 100 can provide a wide range of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery, and mobility). The communication system 100 can provide high availability and stability through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can result in a heterogeneous network that can be considered to include multiple layers. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0044] Terrestrial and non-terrestrial communication systems can be considered as subsystems of a communication system. In the example shown, communication system 100 includes electronic devices (EDs) 110a to 110d (generally referred to as ED 110), radio access networks (RANs) 120a and 120b, a non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RANs 120a and 120b include corresponding base stations (BSs) 170a and 170b, which can also be referred to as terrestrial transmit and receive points (T-TRPs) 170a and 170b. The non-terrestrial communication network 120c includes access nodes 120c, which can also be referred to as non-terrestrial transmit and receive points (NT-TRPs) 172.

[0045] Any ED 110 can optionally or additionally be used to connect to, access, or communicate with any T-TRP 170a and 170b, as well as NT-TRP 172, Internet 150, core network 130, PSTN 140, other network 160, or any combination thereof. In some examples, ED 110a can communicate uplink and / or downlink with T-TRP 170a via interface 190a. In some examples, ED 110a, 110b, and 110d can also communicate directly with each other via one or more sidechain air interfaces 190b. In some examples, ED 110d can communicate uplink and / or downlink with NT-TRP 172 via interface 190c.

[0046] Air interfaces 190a and 190b can use similar communication technologies, such as any suitable wireless access technology. For example, communication system 100 can implement one or more channel access methods in air interfaces 190a and 190b, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA). Air interfaces 190a and 190b can utilize other high-dimensional signal spaces, which may involve combinations of orthogonal and / or non-orthogonal dimensions.

[0047] The 190c air interface enables communication between an ED 110d and one or more NT-TRP 172s via a wireless link or a simple link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection for multicast transmission between a group of EDs and one or more NT-TRPs.

[0048] RANs 120a and 120b communicate with core network 130 to provide various services, such as voice, data, and other services, to EDs 110a, 110b, and 110c. RANs 120a and 120b and / or core network 130 may communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by core network 130 and may or may not use the same radio access technology as RANs 120a and / or RAN 120b. Core network 130 may also act as a gateway access between (i) RANs 120a and 120b and / or EDs 110a, 110b, and 110c, and (ii) other networks (e.g., PSTN 140, Internet 150, and other networks 160). Additionally, some or all of EDs 110a, 110b, and 110c may include the ability to communicate with different wireless networks via different radio links using different radio technologies and / or protocols. Instead of wireless communication (or other than wireless communication), ED 110a, 110b, and 110c can also communicate with service providers or exchanges (not shown) via wired communication channels and with the Internet 150. PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a network of computers and / or subnets (internal networks) and incorporate protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED 110a, 110b, and 110c may be multimode devices capable of operating under various wireless access technologies and include multiple transceivers required to support these wireless access technologies.

[0049] Figure 3Another example of an ED 110 and network equipment including base stations 170a, 170b (at 170) and NT-TRP 172 is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, such as cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery, and mobility.

[0050] Each ED 110 represents any suitable end-user equipment used for wireless operation and may include (or be referred to as) user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smart book, vehicle, car, truck, bus, train, or IoT device, industrial equipment or apparatus of the above (e.g., communication module, modem, or chip), etc. Next-generation ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs and will be referred to as T-TRP 170 below. Also in Figure 3 As shown, NT-TRP will be referred to below as NT-TRP 172. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically turned on (i.e., established, activated, or enabled), turned off (i.e., released, deactivated, or disabled), and / or used in response to one or more of the following: connectivity availability and connectivity necessity.

[0051] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown. One, some, or all of the antennas may also be panels. For example, the transmitter 201 and receiver 203 may be integrated as a transceiver. The transceiver is used to modulate data or other content for transmission by at least one antenna 204 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0052] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by ED 110. For example, memory 208 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein, and executed by one or more processing units 210. Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, etc.

[0053] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., connected to...). Figure 1 (Wired interface of Internet 150 in the network). Input / output devices can interact with users or other devices on the network. Each input / output device includes any suitable structure for providing or receiving information from the user, such as a speaker, microphone, keypad, keyboard, display, or touchscreen, including network interface communication.

[0054] ED 110 also includes a processor 210 for performing operations related to transmissions prepared for uplink transmissions to NT-TRP 172 and / or T-TRP 170, operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170, and operations related to processing sidechain transmissions to and from another ED 110. Processing operations related to transmissions prepared for uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, the downlink transmission may be received by receiver 203, possibly using receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding signaling). Examples of signaling may be reference signals transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indications received from T-TRP 170, such as beam angle information (BAI). In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, processor 210 may perform channel estimation, for example, using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0055] Although not shown, processor 210 may be part of transmitter 201 and / or receiver 203. Although not shown, memory 208 may be part of processor 210.

[0056] The processor 210 and the processing components of the transmitter 201 and receiver 203 may each be implemented by one or more processors, which may be the same or different processors, for executing instructions stored in memory (e.g., memory 208). Alternatively, some or all of the processing components of the processor 210 and the transmitter 201 and receiver 203 may be implemented using dedicated circuitry, such as a programmable field-programmable gate array (FPGA), a graphical processing unit (GPU), or an application-specific integrated circuit (ASIC).

[0057] In some implementations, T-TRP 170 may be known by other names, such as base station, base transceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, Node B, evolved base station (eNodeB or eNB), home eNodeB, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP) or wireless router, relay station, remote radio head, ground node, ground network device or ground base station, base band unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. T-TRP 170 can be a macro base station, micro base station, relay node, host node, or a combination thereof. T-TRP 170 may refer to the aforementioned equipment, or to a component within the aforementioned equipment (e.g., a communication module, modem, or chip).

[0058] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules of T-TRP 170 may be located remotely from the device housing the antenna of T-TRP 170 and may be coupled to the device housing the antenna via a communication link (not shown), sometimes referred to as front-pull, such as the Common Public Radio Interface (CPRI). Therefore, in some embodiments, the term T-TRP 170 may also refer to modules that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding on the network side; these modules are not necessarily part of the device housing the antenna of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs that operate together to serve ED 110 through cooperative multicast and other means.

[0059] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown. One, some, or all of the antennas may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing the following operations: preparing transmissions for downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmissions to NT-TRP 172, and processing transmissions received from NT-TRP 172 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or backhaul may include operations such as receive beamforming, demodulation, and decoding received symbols. Processor 260 can also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates beam direction indications, such as a BAI, which can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the location for deploying NT-TRP 172, etc. In some embodiments, processor 260 can generate signaling, such as configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" as used herein may also optionally be referred to as control signaling. Dynamic signaling can be transmitted in control channels, such as the physical downlink control channel (PDCCH), while static or semi-static higher-layer signaling can be included in packets transmitted in data channels, such as the physical downlink shared channel (PDSCH).

[0060] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included in or operate separately from T-TRP 170, which may schedule uplink, downlink, and / or backhaul transmissions, including issuing scheduling grants and / or configuring unscheduled (“configuration grants”) resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by processor 260.

[0061] Although not shown, processor 260 may be part of transmitter 252 and / or receiver 254. Furthermore, although not shown, processor 260 may implement scheduler 253. Although not shown, memory 258 may be part of processor 260.

[0062] The processor 260, scheduler 253, and processing components of transmitter 252 and receiver 254 may each be implemented by the same or different one or more processors for executing instructions stored in memory (e.g., memory 258). Alternatively, some or all of the processing components of processor 260, scheduler 253, and transmitter 252 and receiver 254 may be implemented using dedicated circuitry (e.g., FPGA, GPU, or ASIC).

[0063] Although the NT-TRP 172 is shown as an example of a drone only, the NT-TRP 172 can be implemented in any suitable non-terrestrial form. Furthermore, the NT-TRP 172 may be known by other names (e.g., non-terrestrial node, non-terrestrial network device, or non-terrestrial base station) in some implementations. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 also includes a processor 276 for performing the following operations: preparing transmissions for downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmissions to the NT-TRP 170, and processing transmissions received from the NT-TRP 170 via backhaul. Processing operations related to preparing for downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to handling receive transmissions in uplink or backhaul may include operations such as receive beamforming, demodulation, and decoding receive symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling, for example, configuring one or more parameters of ED 110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as medium access control (MAC) or radio link control (RLC) layer functions. Since this is only an example, more generally, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

[0064] The NT-TRP 172 also includes a memory 278 for storing information and data. Although not shown, a processor 276 may be part of the transmitter 272 and / or receiver 274. Although not shown, the memory 278 may be part of the processor 276.

[0065] The processor 276 and the processing components of the transmitter 272 and receiver 274 may each be implemented by the same or different one or more processors for executing instructions stored in memory (e.g., memory 278). Alternatively, some or all of the processor 276 and the processing components of the transmitter 272 and receiver 274 may be implemented using dedicated circuitry (e.g., FPGA, GPU, or ASIC). In some embodiments, the NT-TRP 172 may actually be multiple NT-TRPs operating together to provide services such as cooperative multicast transmission ED 110.

[0066] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but for clarity these components are omitted.

[0067] One or more steps of the methods in the embodiments provided herein can be based on Figure 4 The corresponding unit or module is executed. Figure 4 Units or modules in devices such as ED 110, T-TRP 170, or NT-TRP 172 are illustrated. For example, signals can be transmitted by a transmitting unit or transmitting module. Signals can be received by a receiving unit or receiving module. Signals can be processed by a processing unit or processing module. Other steps can be performed by artificial intelligence (AI) or machine learning (ML) modules. The corresponding units or modules can be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules can be integrated circuits, such as programmable FPGAs, GPUs, or ASICs. It should be understood that, for example, if the above modules are implemented using software executed by a processor, these modules can be retrieved by the processor, in whole or in part, individually or collectively, for processing, in one or more instances, and these modules themselves can include instructions for further deployment and instantiation.

[0068] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0069] An air interface typically comprises numerous components and associated parameters that collectively specify how transmissions are sent and / or received over a wireless communication link between two or more communication devices. For example, an air interface may include one or more components that define waveforms, frame structures, multiple access schemes, protocols, coding schemes, and / or modulation schemes used to transmit information (e.g., data) over a wireless communication link. A wireless communication link may support links between a radio access network and user equipment (e.g., a "Uu" link), and / or wireless communication links may support links between devices, such as links between two user equipment (e.g., a "sidechain"), and / or wireless communication links may support links between non-terrestrial (NT) communication networks and user equipment (UEs). Below are some examples of the components described above:

[0070] Waveform components can specify the shape and form of the transmitted signal. Waveform options can include orthogonal multiple access (OFDM) and non-orthogonal multiple access (NOA) waveforms. Non-limiting examples of such waveform options include Orthogonal Frequency Division Multiplexing (OFDM), Filtered OFDM (f-OFDM), Time Window OFDM, Filter Bank Multicarrier (FBMC), Universal Filtered Multicarrier (UFMC), Generalized Frequency Division Multiplexing (GFDM), Wavelet Packet Modulation (WPM), Faster Than Nyquist (FTN) waveforms, and Low Peak-to-Average Power Ratio (LPPR WF) waveforms.

[0071] The frame structure component can specify the configuration of a frame or a set of frames. The frame structure component can indicate one or more parameters among time, frequency, pilot signature, code, or other parameters for a frame or a set of frames.

[0072] Multiple access scheme components can specify multiple access technology options, including technologies that define how communication devices share the common physical channel, such as: Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Code Division Multiple Access (CDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Low Density Signature Multicarrier Code Division Multiple Access (LDS-MC-CDMA), Non-orthogonal Multiple Access (NOMA), Pattern Division Multiple Access (PDMA), Lattice Partition Multiple Access (LPMA), Resource Spread Multiple Access (RSMA), and Sparse Code Multiple Access (SCMA). In addition, multiple access technology options may include: scheduled access and unscheduled access, also known as unlicensed access; non-orthogonal multiple access and orthogonal multiple access, for example, through dedicated channel resources (e.g., not shared between multiple communication devices); contention-based shared channel resources and non-contention-based shared channel resources, and cognitive radio-based access.

[0073] The Hybrid Automatic Repeat Request (HARQ) protocol component can specify how transmissions and / or retransmissions are performed. Non-limiting examples of transmission and / or retransmission mechanism options include mechanisms for specifying the size of the scheduled data pipeline, signaling mechanisms for transmission and / or retransmission, and retransmission mechanisms themselves.

[0074] The coding and modulation components specify how the transmitted information is encoded / decoded and modulated / demodulated for transmission / reception. Encoding can refer to methods of error detection and forward error correction. Non-limiting examples of coding options include turbo lattice codes, turbo product codes, fountain codes, low-density parity-check codes, and polar codes. Modulation can refer only to constellations (e.g., including modulation techniques and orders), or more specifically to various types of advanced modulation methods such as layered modulation and low PAPR modulation.

[0075] In some embodiments, the air interface can be a "one-size-fits-all" concept. For example, once the air interface is defined, the components within it cannot be changed or adjusted. In some implementations, only a limited number of parameters or modes of the air interface can be configured, such as cyclic prefix (CP) length or multiple input multiple output (MIMO) mode. In some embodiments, the air interface design can provide a unified or flexible framework to support frequency bands below and above 6 GHz (e.g., mmWave) for both licensed and unlicensed access. For example, the flexibility of a configurable air interface provided by scalable null and symbol durations can optimize transmission parameters for different spectrum bands and different services / devices. Furthermore, a unified air interface can be self-contained in the frequency domain, and a frequency-domain self-contained design can support more flexible radio access network (RAN) slicing through channel resource sharing between different services in terms of frequency and time.

[0076] Figure 5 This is a block diagram illustrating another exemplary communication system for UE collaboration and multi-hop communication paths. Exemplary system 500 includes network device 502 (also referred to herein as a network apparatus), and UEs 504, 512, 514, 516, and 518. In a cellular network, a UE can connect directly to the network via a direct communication link, such as a so-called "Uu" link or another cellular link, through a Uu air interface. Figure 5 As shown by the dashed lines, UEs 512 and 514 are "within coverage" (within the geographical area where they directly communicate with network device 502), and communication between these UEs and the network device is conducted via a direct communication link. Figure 5 The example shown is link 520, designated "Uu". Sidelink (SL) communication occurs directly between UEs 512 and 516, between UEs 514 and 518, between UEs 516 and 504, and between UEs 518 and 504, via corresponding sidelinks 522, 524, 526, and 528. Examples of implementation options for these components and communication between them are provided elsewhere in this document. For example, network device 502 could be... Figure 1 Network nodes 170a and 170b, the UE can be Figure 1 ED 110a to 110j.

[0077] exist Figure 5In the example, UE cooperation can be used to enable UE 512, 514, or UE 516, 518, or all of these UEs to operate as a relay UE to assist remote UE 504 in uplink and / or downlink communication with network device 502. Although the term "relay UE" is primarily used here, a relay UE may also be referred to as a cooperating UE (or cooperative UE, CUE), or as such throughout this and elsewhere.

[0078] The two multi-hop paths between network device 502 and remote UE 504 are as follows: Figure 5 As shown. A multi-hop path involves Uu segments or links at relay UEs 512, 516, and 520, and sidelink segments or links at 522 and 526. Another multi-hop path in this example involves Uu segments or links at relay UEs 514, 518, and 520, and sidelink segments or links at 524 and 528. In another possible embodiment, multiple UEs cooperate to relay data in each hop, such as at 512 / 514 and 516 / 518, to provide a multi-hop path with multiple link options per hop. A “hop” as defined herein refers to a relay topology that includes a relay node between the relay UE or other two nodes. For example, a first hop refers to a topology where a first UE relays data from a source node to a second UE along the relay path, and a second hop refers to a topology where the second UE further relays data to a third UE along the relay path, and so on. Therefore, according to the above definition, a “multi-hop” relay path includes at least two consecutive relay nodes. Although a "hop" is sometimes defined differently elsewhere as a link between nodes, a conventional single-relay topology includes two links between nodes (i.e., a first link between the first and second nodes, and a second link between the second and third nodes), and thus includes two hops according to the alternative definition. However, a conventional single-relay topology, although including two links, is not a "multi-hop" relay path according to this disclosure.

[0079] For the downlink transmission in Example 500, in one embodiment, the gNB at 502 transmits data to relay UEs 512 and / or 514 within its coverage area on Uu link 520, and each relay UE 512, 514 receiving data from the gNB relays the data to the next relay UE 516, 518 via corresponding sidechains 522, 524. Similarly, each relay UE 516, 518 receiving data relays the data to a remote UE 504 via corresponding sidechains 526, 528. Typically, a multi-hop path according to this disclosure includes at least one UE-UE link or segment, involving direct communication between different UEs between two different “hops” as described above. In this downlink transmission example, there is a UE-UE segment between the UEs in hops 512 / 514 and 516 / 518.

[0080] Regarding uplink transmission, in one embodiment, remote UE 504 sends data to nearby relay UEs 516 and / or 518 via sidechains 526 and 528. Each of these relay UEs receiving data from remote UE 504 relays the data to its next relay UE 512 or 514 via sidechains 522 and 524, and each of the relay UEs 512 or 514 receiving data relays the data to network device 502 via Uu link 520. This uplink transmission example also relates to multi-hop paths with UE-UE segments between two hops.

[0081] Figure 5 These are non-limiting and illustrative examples. The features disclosed herein can be implemented with other communication systems having similar or different structures or topologies. In other embodiments, UEs 516 and / or 518 may also be within coverage. More specifically, any number of relay UEs may be within or outside coverage. Although Figure 5 The examples in the text and the other examples here refer to multi-hop relays, but relay communication can involve one or more hops.

[0082] Figure 6 A block diagram illustrating another example of a multi-hop communication path. Figure 6 Example 600 in the text is structurally similar to Figure 5 The examples are similar, but provide a more general example of multi-hop communication paths. As shown in the figure, Figure 6 Examples include end node #1 at 602 and end node #2 at 604, and a subset of relay UEs, comprising one or more relay UEs, for relaying data in each of the two hops. Relay UE #1 and relay UE #2 are shown at 610 and 612, relaying data for the first hop, and relay UE #3 and relay UE #4 are shown at 620 and 622, relaying data for the second hop. Typically, a subset of relay UEs handling data relay in any hop may include more than one relay UE, and the subset may be of the same or different sizes. This disclosure is not limited to any particular number of hops, or any particular number of relay UEs in any hop.

[0083] The relay UE involved in forwarding data is referred to herein as relaying data, which may be "in" the corresponding hop of a multi-hop relay, but may also be described as "at" each hop. UE relaying involves at least one UE relaying data along a relay path in at least one hop, while multi-hop relaying involves relaying data between end nodes along a multi-hop communication path in multiple steps or hops. In each hop, one or more relay UEs relay data to an end node or participate in relaying data in the next hop. In some embodiments, a hop involves receiving data to be relayed from one or more relay UEs or an end node, and transmitting the received data to one or more other relay UEs or another end node.

[0084] exist Figure 6 In this example, a transmission can be initiated from either end node #1 or end node #2 and terminated at another end node via a relay UE at the first and second hops in the illustrated example. Typically, the relay UE relays data along the multi-hop communication path between the end nodes in the corresponding hops. A transmission from one end node to another can pass through one or more relay UEs during the relay period at each hop in the multi-hop process, therefore... Figure 6 The communication path shown is referred to here as a multi-hop path or multi-hop relay. A single-hop path or single-hop relay with only one hop or only one subset of relay UEs between two end nodes is also possible.

[0085] about Figure 6 The following points need to be explained:

[0086] Each end node can be a user equipment, such as a UE, or a network device, such as a gNB, TRP, or other types of network nodes. Therefore, Figure 6 Other embodiments herein are intended to include UE-to-network relay and UE-to-UE relay scenarios. Unless otherwise indicated, UE-to-network is used herein as a general phrase intended to include communication in either direction between a UE and a network device.

[0087] A relay UE can be represented as a CUE because it cooperates with the end node in transmitting and / or receiving data. The term "relay UE" as used herein is intended to include, for example, Layer 1 (L1) relay UEs, Layer 2 (L2) relay UEs, Layer 3 (L3) relay UEs, and other types of relay UEs. A relay UE at least supports data forwarding and may also support some form of data processing, such as decoding data to determine that the data will be relayed and is not destined for the relay UE itself. A relay UE may also, or alternatively, support other data processing, such as amplifying data before forwarding. Relay UEs are not limited to these specific example operations.

[0088] For example, each link between a relay UE and another relay UE or end node can use a sidechain (e.g., Power Class 5, PC5) air interface, a Uu link air interface, or another type of air interface (e.g., WiFi, Bluetooth, etc.).

[0089] The end node that initiates data transmission can be called the source node or traffic source, while the end node that terminates data transmission can be called the destination node or target node.

[0090] Communication between two end nodes can be bidirectional. For example, end node #1 can transmit data to end node #2, and end node #2 can transmit data to end node #1. Therefore, a node can be either a source node or a destination node for different data transmissions.

[0091] For relay communications involving UC, an end-to-end HARQ process can be configured or enabled such that the same HARQ process, represented, identified, or otherwise indicated by the same HARQ process ID, is used to carry the same data, or related data, such as different edundancy versions (RVs) of the same data, on a Uu or SL link or segment between the same source end node and destination end node. This helps the relay UE and / or end node determine whether data is correctly received and decoded when multiple copies of the same data or related data (e.g., different RVs) are transmitted or relayed from different nodes (e.g., from different relay UEs or from a relay UE and directly from an end node). If the source-destination end node pair is fixed, the same HARQ ID on different links between the end node pairs can identify received transmissions as including the same or related data.

[0092] The end-to-end HARQ process disclosed in this paper is defined as a HARQ process associated with the transmission of data between the source end node and the destination end node. Traditionally, multi-hop data transmission relies on multiple hop-by-hop HARQ processes between corresponding consecutive node pairs in the path between end nodes. For example, the end-to-end HARQ process ID#1 on different Uu or SL links can indicate the same or related data transmitted on these links.

[0093] An end-to-end HARQ process spans or includes the transmission of data over multiple links. Transmitting data over multiple links as part of a single HARQ process can include an initial transmission and one or more retransmissions. While this document refers to the transmission and retransmission of data, unless otherwise stated, these references are generally intended to indicate or include the transmission of exactly the same data or a related version of that data, such as different RVs. In a more general sense, a related version might mean carrying the same information but with different header information inserted by the MAC or a higher layer. Therefore, transmitting data as part of an end-to-end HARQ process can involve transmitting data or different versions of data. The multiple links transmitting data can include different links between nodes in a single path, such as a UE relay path from the source end node to the destination end node, and / or different links in different paths from the source end node to the destination end node. In this sense, an end-to-end HARQ process can also be considered, or alternatively, as a form of a “joint” HARQ process spanning multiple links, or can involve transmissions over multiple links.

[0094] Further references to data, for example, to the transmission and reception of data are intended to include only the transmission and reception of such data, or data along with other information, such as header information or other information involved in the communication of data in a network or system.

[0095] Figure 7 This is a block diagram illustrating an exemplary HARQ protocol stack based on embodiments involving indirect relay paths and direct paths between a UE and a network device. In this example, the HARQ entity managing the end-to-end HARQ process exists only at the source and destination of the traffic. Typically, a HARQ entity is an entity that manages one or more HARQ processes, such as up to 16 HARQ processes. In some embodiments, the HARQ entity can manage both end-to-end HARQ processes and traditional hop-by-hop HARQ processes. For uplink traffic, the source is the source UE (SUE), and the destination is... Figure 7 In the example of a gNB, the network device is the source of downlink traffic, and the destination is TUE. Transmissions as part of an end-to-end HARQ process can occur on all paths between the source and destination, and... Figure 7 In this context, the path includes the direct Uu path and the indirect relay path through the relay UE, which is illustrated as a CUE by example.

[0096] As shown in the figure, a CUE or relay UE may include a PHY layer for each link it connects to. Therefore, a relay UE can maintain the same transport block (TB) across its connected links. In other embodiments, the CUE or relay UE may have medium access control (MAC) and / or higher layers (not shown), so the TB received by the CUE on one link and transmitted on another may differ due to changes in header information from the MAC or higher layers, even if the data or information bits remain the same.

[0097] More specifically, Figure 7 Features associated with an exemplary end-to-end HARQ process are shown, and other features or functionalities may be provided or supported.

[0098] Figure 8 A block diagram illustrating an exemplary HARQ protocol stack based on another embodiment involving two indirect relay paths between a UE and a network device. Figure 8 Examples and Figure 7 The examples in the text are basically the same, except... Figure 8 There are two indirect relay paths in China, CUE#1 and CUE#2 respectively.

[0099] Figure 9 A block diagram illustrating an exemplary HARQ protocol stack according to another embodiment involving two indirect relay paths between two end nodes. Figure 9 Examples and Figure 8 The examples in [the previous section] are basically the same, except that the source and destination are generalized to [the current section]. Figure 9 The end nodes in the relay path can be, for example, a UE or a network device. Similarly, one or two links in each indirect relay path can be a Uu link or an SL link, depending on whether each end node is a UE or a network device.

[0100] Figures 7 to 9 Several embodiments are illustrated, including different examples of links and paths to which the end-to-end HARQ disclosed herein can be applied; therefore, the HARQ entities shown in these examples are intended to manage the end-to-end HARQ process. Other embodiments may differ. Figures 7 to 9 The embodiments shown or otherwise disclosed herein. For example, in other embodiments, HARQ entities are not limited to source and destination end nodes. The HARQ process can also be applied to hop-by-hop transmissions. At least some HARQ features or portions of the HARQ entities can exist in intermediate nodes, for example, enabling the hop-by-hop HARQ process to be applied per-link in multi-link paths (such as hop-by-hop relay).

[0101] Typically, a HARQ entity on each UE or node, including the source end node and the destination end node, can manage both end-to-end HARQ processes and hop-by-hop HARQ processes. HARQ entities can exist on both the source and destination end nodes, or, in the case of UE relay, on each intermediate node, such as the UE itself. However, managing end-to-end HARQ processes on intermediate nodes may differ from managing them on the source and destination nodes. For example, end-to-end HARQ processes on the source and destination nodes may involve the destination end node sending and the source end node receiving end-to-end HARQ feedback, while intermediate nodes along the relay path may simply send and receive hop-by-hop HARQ feedback. Furthermore, hop-by-hop HARQ processes can be configured between any consecutive nodes along the relay path and managed by HARQ entities on those nodes; therefore, any node in the path or the HARQ entity on each node can manage one or more hop-by-hop HARQ processes and one or more end-to-end HARQ processes.

[0102] For each source-destination node pair, multiple end-to-end HARQ processes can be configured and mapped to generalized HARQ processes. For example, a node can support a certain number of generalized HARQ processes, which may include one or more end-to-end HARQ processes and one or more hop-by-hop HARQ processes. A generalized HARQ process refers to a group of HARQ processes, some of which can be end-to-end HARQ processes and some of which can be hop-by-hop HARQ processes. For example, a UE can be configured with 10 generalized HARQ processes, where 5 HARQ processes can be end-to-end HARQ processes and the remaining 5 can be hop-by-hop HARQ processes. These generalized HARQ processes can be configured using higher-level signaling such as radio resource control (RRC) signaling, which can indicate the total number of generalized HARQ processes, the number of end-to-end HARQ processes, and the number of hop-by-hop HARQ processes. End-to-end HARQ processes and hop-by-hop HARQ processes can be switched via explicit signaling. For example, explicit signaling in lower layers, such as downlink control information (DCI) or higher-layer signaling, can be used to more dynamically indicate the handover between end-to-end HARQ processes and hop-by-hop HARQ processes. The corresponding UE behavior (e.g., as a relay UE) can be changed accordingly.

[0103] Assume a node can support a maximum of 8 HARQ processes at any given time. In this case:

[0104] For the source #1 -> destination #1 pair, two end-to-end HARQ processes can be configured and mapped to generalized HARQ processes #1 and #2;

[0105] For the source #2 -> destination #2 pair, three end-to-end HARQ processes can be configured and mapped to generalized HARQ processes #3-#5; and

[0106] For the source #3 -> destination #2 pair, three end-to-end HARQ processes can be configured and mapped to generalized HARQ processes #6-#8.

[0107] Figure 10 A block diagram illustrating an exemplary HARQ process with a multi-hop communication path. Figure 10 Example 1000 in the example involves a scenario with two end-to-end HARQ processes for multi-hop UE relay between end nodes 1002 and 1004 via relay UEs 1010 / 1012 and 1020 / 1022 on each of the two hops.

[0108] An end-to-end HARQ process can be applied to each path in multiple paths between the same pair of source and destination end nodes, as well as to each link in a relay path. For example, consider... Figure 10 The upper path in the diagram. The same HARQ process, with the same HARQ ID, can be used to carry the same data, or related data (e.g., different RV versions), on all links between source end node 1002 and destination end node 1004, including the Uu or SL link between end node 1002 and relay UE 1010, the SL link between relay UEs 1010 and 1020, and the Uu or SL link between relay UE 1020 and end node 1004. In the example shown, there are two HARQ processes for different data. This is just an example; more or fewer HARQ processes may be used in other embodiments.

[0109] In scenarios where multiple relay paths exist between a pair of source and destination nodes, such as Figure 10 As shown, one or more end-to-end HARQ processes can be applied to each link (e.g., Uu and SL links) of every relay path between the same pair of source and destination end nodes. The same end-to-end HARQ process can be used to carry the same or related data, such as different RV versions, on all links between the source and destination end nodes.

[0110] Figure 10 One embodiment is shown, in which there can be four relay paths, including:

[0111] Relay path #1: End node #1 1002 <-> Relay UE #1 1010 <-> Relay UE #3 1020 <-> End node #2 1004;

[0112] Relay path #2: End node #1 1002 <-> Relay UE #2 1012 <-> Relay UE #4 1022 <-> End node #2 1004;

[0113] Relay path #3: End node #1 1002 <-> Relay UE #1 1010 <-> Relay UE #4 1022 <-> End node #2 1004;

[0114] Relay path #4: End node #1 1002<-> Relay UE #2 1012<-> Relay UE #3 1020<-> End node #2 1004.

[0115] like Figure 10 As shown, the same or related data is transmitted as part of each of the two end-to-end HARQ processes on each link (between consecutive nodes) of each multilink path, which in the example shown includes multiple links.

[0116] In some embodiments, an end-to-end HARQ process may be mapped to or otherwise configured to use HARQ buffers on relay UEs or nodes along the relay path between the source and destination nodes. For each relay UE or node, the mapping or configuration of HARQ buffers for the same end-to-end HARQ process may be the same or different. For example, an end-to-end HARQ process may be mapped to the k-th HARQ buffer of each relay UE or node along the relay path; in this sense, the same end-to-end HARQ process may use the same HARQ buffer (HARQ buffers with the same index) in each relay UE or node. In other embodiments, the end-to-end HARQ process is used to use an available HARQ buffer in each relay UE or node, which may be the same buffer or a different buffer.

[0117] Since end-to-end HARQ processes and hop-by-hop HARQ processes can be configured or supported simultaneously, to utilize HARQ resources more flexibly and efficiently, one or more end-to-end HARQ buffers can be allocated to one or more end-to-end HARQ processes, and one or more hop-by-hop HARQ buffers can be allocated to one or more hop-by-hop HARQ processes. End-to-end HARQ buffers can be allocated separately in different buffers or storage spaces, or within the same shared HARQ buffer. For example, a shared HARQ buffer at a relay UE or node can be configured as a number of HARQ buffers for individual HARQ processes. The configuration of end-to-end HARQ buffers can overlap with the configuration of hop-by-hop HARQ buffers, allowing shared HARQ buffers or storage spaces to be allocated to one or more end-to-end HARQ buffers for one or more end-to-end HARQ processes. Any remaining HARQ buffers or storage spaces on a relay UE or node can still be configured as one or more hop-by-hop (or per-hop) HARQ buffers associated with one or more hop-by-hop (or per-hop) HARQ processes.

[0118] Figure 11 A block diagram illustrating an exemplary HARQ buffer configuration is provided. In the example shown, the HARQ buffers or storage spaces 1120 and 1140 at each of the two UEs or nodes can accommodate individual HARQ buffers for up to n HARQ processes, and two end-to-end HARQ buffers for end-to-end HARQ processes are configured at each UE or node, shown as HARQ#1 and joint HARQ#2. This example illustrates different HARQ buffers allocated to each end-to-end HARQ process at each UE or node, including HARQ buffer #1 at UE / node #1 and HARQ buffer #2 at UE / node #2 for end-to-end HARQ#1, and HARQ buffer #3 at UE / node #1 and HARQ buffer #n at UE / node #2 for end-to-end HARQ#2. In other embodiments, the same buffers with the same index on each UE or node are allocated to the same end-to-end HARQ process.

[0119] Figure 11 Each of the two end-to-end HARQ processes can be mapped to or otherwise used to utilize the HARQ buffer on a relay UE or node along the relay path between the source and destination nodes. The mapping / configuration of the HARQ buffer for the same HARQ process can be the same for each UE / node, or it can be different for each UE / node, as shown in the figure.

[0120] exist Figure 11 In this context, the end-to-end HARQ cache and the hop-by-hop or per-hop cache share the same HARQ cache or storage space. Figure 11 There are two end-to-end HARQ buffers. The remaining n–2 HARQ buffers can be allocated to other HARQ processes as needed. These remaining HARQ buffers can be mapped, configured, or otherwise allocated to other end-to-end or hop-by-hop (or per-hop) HARQ processes.

[0121] Figure 12 A block diagram illustrating an example of multipath communication with end-to-end HARQ process buffer and hop-by-hop HARQ process buffer allocation. Figure 12 The example illustrates the end-to-end HARQ process buffer at each node, including each end node 1202, 1204 and each relay UE 1210, 1212, as well as the HARQ buffer for each hop HARQ process at end node #1 1202 and relay UE #1 1210 on the link between end node #1 and relay UE #1, and for each hop HARQ process at relay UE #2 1212 and end node #2 1204 on the link between relay UE #2 and end node #2. The end-to-end HARQ process may include... Figure 12 The end-to-end HARQ buffer can be configured on each UE / node on all links between end nodes 1202 and 1204. Furthermore, link, hop-by-hop, or per-hop HARQ processes can be configured individually for any or all individual links between end nodes 1202 and 1204.

[0122] There are several possible options for resource allocation in the joint HARQ process transfer.

[0123] For example, resources used for relay data can be pre-configured and triggered by control signals or signaling, such as signaling including downlink control information (DCI) in the case of a Uu link, and sidelink control information (SCI) in the case of an SL link or segment. The DCI / SCI can carry an end-to-end HARQ ID to indicate that the transmission is part of a corresponding HARQ process represented by the HARQ ID. In some embodiments, such resources can be shared with other HARQ processes, and nodes such as relay UEs can identify the transmission (for a specific end-to-end HARQ process) from the HARQ ID in the SCI (along with source and destination information). This can save resource overhead. In the context of enabling pre-configured resources, triggering can mean that when a node (such as a UE) receives a DCI / SCI or other signaling carrying an end-to-end HARQ ID, it should be assumed that the resources used for transmitting data can begin further after a time offset from the time of receipt. Other triggering methods are also possible.

[0124] According to another option for resource allocation, for example, resources used for relaying data can be scheduled by the source node and carry data or control signals from the source node.

[0125] Resource alternatives used for relay data can be scheduled by the relay data's CUE (relay UE), or by other components such as network devices, the primary UE in the cooperation group, or even the destination node.

[0126] These options for allocating and triggering the use of resources for relay data can also be applied to allocating other resources associated with HARQ processes, such as allocating HARQ buffers for end-to-end HARQ processes and / or allocating link or per-hop HARQ buffers for link or per-hop HARQ processes. In some embodiments, end-to-end and per-hop HARQ buffers are pre-allocated or otherwise pre-configured in the same shared HARQ buffer store on the node. Triggering or enabling such allocation of end-to-end and per-hop HARQ buffers on a node can be in response to the same signaling or individual signaling for each HARQ process.

[0127] Implementations related to the configuration of end-to-end HARQ processes include HARQ buffers and / or other HARQ resources that facilitate end-to-end HARQ processing of multiple links on one or more paths between end nodes and can be applied in multi-path and / or multi-hop communications to potentially improve system performance and latency.

[0128] Turning to the end-to-end HARQ process, in one embodiment, end-to-end HARQ may involve, for example, the initial transmission of data scheduled by the source node, and the transmission of data from the source node to the destination node. For multi-link paths, data is transmitted via links to the next successive node. Data may also, or alternatively, be transmitted to the destination node via direct links or paths to the destination node. In multi-path scenarios, data is transmitted via multiple paths. The end-to-end HARQ ID of the end-to-end HARQ process between the source and destination nodes may be carried by control signals that schedule the transmission, for example, in DCI and / or SCI.

[0129] In a multi-link path, the next CUE (or relay UE) can attempt to decode the control signals and the corresponding data. If the next CUE or relay UE successfully decodes the data, it further relays the data to its next CUE (relay UE) or destination node. For example, the same HARQ ID can be indicated in the control signals transmitted along with the relayed data.

[0130] Optionally, HARQ-ACK can be sent as hop-by-hop feedback as part of an end-to-end HARQ process. Otherwise, HARQ-NACK can be sent as hop-by-hop feedback. The transmitter can then send retransmissions of data, such as different RVs of the data.

[0131] CUE or relay UE operations are repeated by other CUE or relay UEs in the multi-hop path between the source node and the destination node.

[0132] If the destination node receives and decodes the data, it can send an end-to-end HARQ-ACK as feedback for the end-to-end HARQ process; otherwise, it sends a HARQ-NACK as feedback.

[0133] Decoding behavior of relay UEs or destination nodes may involve identifying received data via their end-to-end HARQ process ID. The end-to-end HARQ ID can be carried by the DCI / SCI, as described above by example, and the same end-to-end HARQ ID can indicate the same or related data, such as different RVs received over different links. Alternatively, data can be identified by the end-to-end HARQ ID plus the source ID and destination ID. For example, this can help identify data associated with a specific HARQ process where the node participates in relaying data across multiple paths between different source / destination pairs.

[0134] After a receiving node, such as a relay UE or destination node identifier, identifies the received data as part of the same HARQ process (e.g., by determining that their end-to-end HARQ process IDs are the same), the receiving node can perform soft merging of the received data or different RVs of related data that are identified, for example, as being associated with the same end-to-end HARQ process but originating from different links on different paths, or from different nodes (e.g., different relay UEs or one or more relay UEs and a source node). In some embodiments, this soft merging is based on the assumption that different RVs of the same TB or the same TB are transmitted and received as part of the same end-to-end HARQ process.

[0135] The receiving node can also, or alternatively, perform hard combining of multiple received transmissions of the same or related data (e.g., different RVs of the same data). For hard decoding, the receiving node attempts to decode the received data on the same end-to-end HARQ process from different links on different paths. If the data received from at least one path is successfully decoded, the data is considered to have been successfully received, and the receiving node can send a HARQ-ACK feedback, such as... Figure 13 As shown in the example.

[0136] Figure 13 A block diagram illustrating an example of hop-by-hop feedback in multipath, multi-hop communication. Figure 13 It reproduced Figure 6 An exemplary communication system is described, and HARQ-ACK feedback from relay UE#3 620 to relay UE#2 612 and relay UE#1 610 is shown after hard merging and successful decoding of data from relay UE#2. Even if only data transmission from relay UE#2 (hop 1) to relay UE#3 (hop 2) is successful, HARQ-ACK feedback can be transmitted by relay UE#3 on all links that receive the same or related data.

[0137] Hard combining can be based on the assumption that the same information bits or different RVs of the same information bits are transmitted with different side information, such as different header information. Hard combining is an example of a feature that can be provided in some embodiments. For example, L2 trunk UEs and / or L3 trunk UEs can support hard combining, while L1 trunk UEs can support TB forwarding without requiring higher-level features such as hard combining decoding, and therefore can support soft combining.

[0138] In some embodiments, end-to-end HARQ process feedback may include hop-by-hop feedback and end-to-end feedback.

[0139] Regarding hop-by-hop feedback, for each link between relay UEs of different hops or between the last-hop relay UE and the end node, if the receiving node (relay UE or end node) successfully receives and decodes the data, a hop-by-hop HARQ-ACK can be sent to the previous relay UE or end node. The previous relay UE or end node may not refresh the end-to-end HARQ buffer temporarily because, in this example, HARQ-ACK is hop-by-hop feedback, therefore, end-to-end data transmission success may not be guaranteed.

[0140] Otherwise, if the receiving node fails to decode the received data, it can send a hop-by-hop HARQ-NACK to the previous relay UE or end node, which can then retransmit the same data, the same RV version of the previously transmitted data, or a different RV version of the data. Transmitting a HARQ-NACK is not always necessary. For example, the absence of a HARQ-ACK within a certain time after transmission can be interpreted as a HARQ-NACK by the sending node.

[0141] Figure 14 A block diagram illustrating another example of hop-by-hop feedback in multipath, multi-hop communication. Figure 14 It reproduced Figure 6 An exemplary communication system is described, illustrating hop-by-hop HARQ-NACK feedback from relay UE#3 620 to relay UE#2 612 and relay UE#1 610 after unsuccessfully decoding received data. In this example, any or all transmitting nodes in relay UE#2 612 and relay UE#1 610 may retransmit data or its RV to relay UE#3 620 after receiving a hop-by-hop HARQ-NACK.

[0142] In some embodiments, in addition to end-to-end HARQ feedback, hop-by-hop feedback may optionally be provided.

[0143] Moving on to end-to-end feedback, if the destination node successfully receives and decodes the data, it can send an end-to-end HARQ-ACK for the end-to-end HARQ process to the source node, and it can also be received by one or more intermediate nodes (e.g., relay UEs) between the destination and source nodes. Each relay UE receiving the end-to-end HARQ-ACK can refresh its corresponding end-to-end HARQ buffer after receiving the end-to-end HARQ process for the end-to-end HARQ process and / or otherwise complete the end-to-end HARQ process.

[0144] Otherwise, the end-to-end HARQ-NACK of the end-to-end HARQ process can be sent to the source node through one or more intermediate nodes (e.g., a relay UE). Transmitting a HARQ-NACK is not necessarily required. For example, the absence of a HARQ-ACK within a certain time after transmission can be interpreted as a HARQ-NACK by the sending node. Data retransmission can be initiated using the same end-to-end HARQ process. If the data is still held in the corresponding HARQ buffer of the end-to-end HARQ process at the intermediate node, the data or a different RV version of the data can be retransmitted from the source node or from any intermediate node (e.g., a relay UE) between the source and destination nodes to save latency.

[0145] Figure 15 A block diagram illustrating an example of end-to-end feedback and retransmission in multipath, multi-hop communication. Figure 15 It reproduced Figure 6 An exemplary communication system is illustrated, and an end-to-end HARQ-NACK feedback is shown from end node #2 604 to end node #1 602, where end node #1 602 is the source node in the illustrated example and end node #2 604 is the destination node in the illustrated example. The end-to-end HARQ-NACK feedback is sent by end node #2 604 via relay UE after unsuccessfully decoding received data. Upon receiving such an end-to-end HARQ-NACK, any or all intermediate nodes may retransmit their data or RV to end node #2 604. In the illustrated example, if the end-to-end HARQ buffer is not flushed and still holds data, relay UE #1 610 sends a retransmission via relay UE #3 620 and relay UE #4 622.

[0146] Although hop-by-hop HARQ feedback is optional for the end-to-end HARQ process, end-to-end HARQ feedback enables the end-to-end HARQ process to complete or continue retransmission.

[0147] These examples of end-to-end HARQ processes, along with examples of decoding behavior and feedback from intermediate and destination nodes, enable end-to-end HARQ processes and can potentially improve the performance of multipath and multi-hop relay systems in terms of reliability and latency.

[0148] The end-to-end HARQ disclosed in this paper can be implemented in any of various scenarios or operating environments. For example, Figure 16 A block diagram illustrating an exemplary application of HARQ in conjunction with a virtual UE. Figure 16The top of the diagram shows the MAC and PHY layers of node 1502 and the virtual UE (formed by a group of UEs 1504, 1506, and 1508). In other embodiments, higher layers and / or other features or functions may also be provided or supported, or alternatively. For example, node 1502 and / or the virtual UE may include a HARQ entity and / or have a HARQ buffer allocated or configured for the end-to-end HARQ process.

[0149] The end-to-end HARQ process configured between nodes such as 1502 and the virtual UE can be called the virtual end-to-end HARQ process. The virtual MAC of the virtual UE can be used to handle the end-to-end HARQ process. The virtual MAC can be implemented on one of UE1504, 1506, and 1508 in the virtual UE, such as the main UE, or it can be implemented in a coordinated manner on each UE of the virtual UE.

[0150] Figure 16 The end-to-end HARQ process occurs between node 1502 and the virtual UE, but this does not mean that there is only a direct link between node 1502 and the virtual UE, or that no other nodes are involved. For example, there may be intermediate nodes (not shown) between node 1502 and the virtual UE, or there may be another multi-link path (not shown) between node 1502 and the virtual UE. The illustrated link between node 1502 and the virtual UE can be one link in a multi-link path between other end nodes (not shown). It should also be noted that the end-to-end HARQ process can be applied between virtual UEs. As an example, if data transmitted by node 1502 is successfully received by any UE 1504, 1506, or 1508 in the virtual UE, a HARQ-ACK will be sent from the virtual UE to node 1502. Alternatively, each UE 1504, 1506, or 1508 in the virtual UE can decode part of the data or cooperate to decode the data, and if such decoding is successful, a HARQ-ACK can be sent. In another example, if any or all of the virtual UEs 1504, 1506, 1508 send data or each UE sends part of the same data, they are considered to be part of the same virtual HARQ process, and if node 1502 successfully receives this data (sent from one or more of the virtual UEs), the HARQ process will be terminated and can be used for new data transmission.

[0151] For scenarios that support different types of traffic, traffic can be divided into different types, and different types of HARQ processes can be used. Figure 17 A block diagram illustrating different types of HARQ processes used for different types of traffic. For example, traffic with stricter latency and / or reliability requirements... Figure 17As an example, "Class A traffic" can use an end-to-end HARQ process between end nodes #11702 and #21704, and traffic with less stringent latency and / or reliability requirements. Figure 17 As an example, “Class B traffic” can be shown on each link between end node #1 1702 and relay UE #1 1710, between relay UE #1 1710 and UE #2 1720, and between relay UE #2 1720 and end node #2 1704.

[0152] For IoT or vertical scenarios, a large number of sensors need to transmit data to the network or central node, and most of the traffic is periodic bursts. Multiple sensors can be grouped together to cooperate in data transmission. Figure 18 Includes a diagram showing examples of bursts and periodic flows. Figure 19 This is a block diagram illustrating an exemplary IoT system. Figure 19 Multiple paths, including relay paths, can be formed between each sensor and the central node to transmit data. Figure 18 The sensor flow rate is shown in the figure.

[0153] End-to-end HARQ processes can be used to transmit different data between end-node pairs {sensors, central node}. Any remaining HARQ buffers can be used for hop-by-hop HARQ processes, for example, for low-latency-sensitive or non-periodic traffic.

[0154] Sensors can transmit data using one or more relay paths configured between themselves and a central node. For example, in Figure 19 In this system, sensor 1 has multiple paths connecting it to the central node, including paths through sensor nodes 1-2-3, 1-2-5, and 1-4-5. If a relay path is blocked by an obstacle or becomes unavailable, or experiences dynamic path quality degradation or failure, another backup or alternative path can be used.

[0155] For example, if the link from sensor 3 to the central node is blocked by an object, sensor 2 can still have data in its joint HARQ buffer if an end-to-end HARQ process is used, and the data can be transmitted or retransmitted using the alternative path 2->5->central node.

[0156] These examples of end-to-end HARQ processes illustrate that end-to-end HARQ can be applied to various scenarios, such as virtual UEs, multi-hop relays supporting different types of traffic, and / or IoT, potentially providing flexibility to support different types of nodes or traffic and overcome dynamic channel variations. More generally, end-to-end HARQ processes can be applied to other scenarios where a UE or other node can receive the same data or related versions (e.g., RV) from different links, and the same end-to-end HARQ process is configured to carry them on different links. Here, different links can be links with the same or different air interfaces, different component carriers, from different bandwidth parts (BWPs), from different network devices, or different UEs or other nodes, or some combination thereof. In this case, end-to-end HARQ allows the receiver to determine that the same data or its related versions are carried on different links but are part of the same HARQ process, and to apply appropriate receiving techniques to maximize reception performance and send HARQ feedback in a timely manner.

[0157] Figure 20 A signal flow diagram illustrating the operation provided in one embodiment is shown.

[0158] Figure 20 Various features that may be provided in some embodiments are illustrated. For example, a method may include transmitting signaling for configuring an end-to-end HARQ process in a wireless communication network. This signaling, in order to Figure 20 The examples 2022, 2024, and 2026 illustrate that the signaling can be sent by the network device and received by each node, including end node #1 2002, relay UEs 2010 and 2020, and end node #2 2004. Another possible option for configuring the signaling includes the network device transmitting this signaling to any one or more of these nodes, and then transmitting the signaling to another node. The signaling for configuring the end-to-end HARQ process can be generated and transmitted by a single node, such as end node #1 2002, which is the source end node in the illustrated example. Alternatively, the signaling for configuring the end-to-end HARQ process can be generated and transmitted by the master node. The transmitted signaling can be received directly or indirectly from the transmitting node by each of the other nodes.

[0159] Therefore, communication signaling can involve one or two nodes receiving and transmitting such signaling, including end nodes and any intermediate nodes in the path between end nodes. For example, if end node #1 2002 generates or receives configuration signaling, it can transmit that signaling to at least one intermediate node, which in the example shown is at least one relay UE at the first hop. Therefore, end node #1 2002 can at least transmit configuration signaling and can also receive such signaling from a network device (not shown). Intermediate nodes can receive configuration signaling from the source node, a network device (not shown), or a previous intermediate node and transmit the signaling to the next node along the relay path. Destination nodes such as end node #2 2004 can receive configuration signaling from at least a network device (not shown), the source node of end node #1 2002 as shown in the example, or one or more intermediate nodes (e.g., one or more relay UEs 2020) at the second hop as shown in the example.

[0160] For example, the signaling used to configure the end-to-end HARQ process may be or include higher-layer signaling or RRC signaling. Other types of signaling may also be used, or alternatively, in other embodiments.

[0161] exist Figure 20 In the example shown, the end-to-end HARQ process configured by the signaling at 2022, 2024, and 2026 is associated with the data transmission from the first end node to the second end node. Figure 20 An example of data transfer from end node #1 2002 to end node #2 2004 is shown. The data is transmitted along a UE relay path, which includes multiple links between nodes along the relay path. Figure 20 In this context, the UE relay path includes one or more links between the end node #1 2002 and the first-hop relay UE 2010, one or more links between the first-hop relay UE and the second-hop relay UE 2020, and one or more links between the second-hop relay UE and the end node #2 2004.

[0162] An end-to-end HARQ process is a single HARQ process represented by a single HARQ process ID, and includes or spans the entire UE relay path. Figure 20 In this context, the UE relay path is a multi-hop path between end node #1 2002 and end node #2 2004, consisting of one or more relay UEs 2010 and 2020 per hop in two hops. The HARQ process ID is indicated in the configuration signaling to configure the end-to-end HARQ process, and data can be transmitted as part of an end-to-end HARQ process with the HARQ process ID. For example, data can be transmitted using a DCI or SCI that includes or otherwise indicates the HARQ process ID.

[0163] Configuring an end-to-end HARQ process may involve allocating a HARQ buffer for the end-to-end HARQ process. In some embodiments, the HARQ buffer for the end-to-end HARQ process is the first buffer in a shared HARQ buffer, such as... Figure 11 As shown in the example. Then, one approach may include transmitting additional signaling for allocating a link or a second buffer for a hop-by-hop HARQ process associated with a second data transmission between two neighboring or adjacent nodes on the link, within a shared HARQ buffer.

[0164] Some embodiments involve allocating HARQ buffers for end-to-end HARQ processes at the first end node, the second end node, and each other node along the entire UE relay path between the first end node and the second end node, wherein the HARQ buffers are used for end-to-end HARQ processes.

[0165] Figure 20 An example of end-to-end HARQ associated with the transmission of first data between end nodes 2002 and 2004 is shown, and in some embodiments, a hop-by-hop HARQ process can be configured to transmit second data between adjacent nodes along the UE trunk path. Nodes involved in the UE trunk path and the end-to-end HARQ process can also be involved in hop-by-hop HARQ processes associated with different data transmissions.

[0166] In some embodiments, the HARQ entity for managing the end-to-end HARQ process may exist only at the end node. In this case, the end-to-end HARQ process is associated with only two HARQ entities: a first HARQ entity at a first (source) end node and a second HARQ entity at a second (destination) end node. In these embodiments, end-to-end HARQ feedback is provided only from the destination end node to the source end node.

[0167] refer to Figure 20Data transmission along the UE relay path from end node #1 2002 to end node #2 2004 involves transmitting data from end node #1 to one or more first-hop relay UEs 2010 in 2030, transmitting data (or, for example, related data with different header information) from one or more first-hop relay UEs to one or more second-hop relay UEs 2020 in 2040, and transmitting data (or, for example, related data with different header information) from one or more second-hop relay UEs to end node #2 2004 in 2050. End node #2 2004 performs decoding in 2054 and generates and transmits end-to-end feedback for the end-to-end HARQ process in 2058. The end-to-end feedback is forwarded back along the same UE relay path as the data in this example, but this is not necessarily the case in all embodiments. Optional retransmission in response to the HARQ NACK feedback in 2058 is shown at 2062.

[0168] An end-to-end HARQ process can include transmitting data or different versions of data.

[0169] For HARQ entities located only at each end node, intermediate nodes do not necessarily need to fully decode the received data and can, for example, forward the data to their destination without decoding to determine if the data has been received correctly. Therefore, decoding in... Figure 20 The brackets at 2034 and 2044 indicate that data decoding is optional. Furthermore, although the retransmission at 2062 includes retransmissions from the source node (end node #1 2002 in this example) and intermediate nodes (relay UEs 2010 and 2020 in this example), in some embodiments, only end-to-end HARQ feedback is provided, and the source node only retransmits data or related data after receiving HARQ NACK feedback.

[0170] Figure 20 This includes embodiments that provide link HARQ feedback, which is also referred to herein as... Figure 20 This is illustrated as hop-by-hop feedback. For example, a method may include generating and transmitting link or hop-by-hop HARQ feedback for the end-to-end HARQ process between one or more of the destination end node (end node #2 2004 in this example) and intermediate nodes (one or more relay UEs 2010, 2020 in this example) along the UE relay path. Figure 20In the diagram, at positions 2032, 2042, and 2052, hop-by-hop feedback and one or more possible per-hop or per-link retransmissions are shown for each link. Although these feedback and retransmission options are located between nodes along the UE relay path, they are still part of the same end-to-end HARQ process, not a separate hop-by-hop HARQ process. In the end-to-end HARQ process, hop-by-hop feedback and retransmissions can be configured for any or all links between end nodes.

[0171] For example, generating hop-by-hop feedback may include decoding the received data to determine whether the reception was successful. To avoid... Figure 20 Further congestion in the process, such decoding is shown as optional in 2034 and 2044, but can actually be performed before hop-by-hop feedback is sent in 2032 or 2042. Similarly, although decoding of the destination end node is shown in 2054, such decoding can be performed before hop-by-hop feedback is transmitted in 2052.

[0172] As described above, in some embodiments, only end-to-end HARQ feedback is provided, and only the source node retransmits data or related data after receiving HARQNACK feedback. In other embodiments, intermediate nodes (in Figure 20 One or more relay UEs (2010, 2020) in the illustrated example may store the data in a HARQ buffer, for example, at an intermediate node, after decoding the data from the received data transmission. The data may be relayed to the destination end node, and in response to a 2058 end-to-end HARQ feedback from the destination end node indicating a negative acknowledgment of the data, the data is retransmitted from the HARQ buffer to the second end node. Retransmission may include retransmitting the exact same data or related data, such as different RVs. The end-to-end HARQ process may also, or alternatively, include refreshing the data in the HARQ buffer at the intermediate node in response to a 2058 end-to-end HARQ feedback indicating data acknowledgment.

[0173] Figure 20 The UE relay path shown and some other examples in this document illustrate a multi-hop UE relay path that includes multiple intermediate nodes (in...) between the first and second end nodes along the relay path. Figure 20 (The first and second jumps in the middle).

[0174] Multi-path implementations are also possible, for example, if in Figure 20There may be multiple relay UEs at one or two hops, or there may be additional UE relay paths or direct paths between end nodes 2002 and 2004. In a multipath embodiment, the UE relay path is one of multiple paths between the first end node and the second end node, and the end-to-end HARQ process is associated with data transmission from the first end node to the second end node to transmit first data on multiple paths.

[0175] Methods in multipath scenarios may include merging data received on different paths across multiple paths as part of an end-to-end HARQ process at a second end node or an intermediate node between the first and second end nodes. The received data may include data from the original transmission and / or retransmitted data as part of the end-to-end HARQ process. The merging may be or include soft merging or hard merging.

[0176] Possible applications of end-to-end HARQ disclosed herein include, for example: virtual UE embodiments, wherein one or more of the following include a virtual UE: a first end node, a second end node, and a node in the UE relay path; embodiments where different types of traffic can be processed differently, wherein data processed as part of the end-to-end HARQ process has stricter requirements for latency and / or reliability compared to other data that is not transmitted or retransmitted in the end-to-end HARQ process or is otherwise unrelated to the end-to-end HARQ process; and IoT embodiments, wherein one or more of the following include IoT sensors: a first end node, a second end node, and a node in the UE relay path. These are illustrative and non-limiting examples disclosed herein, and other embodiments are possible.

[0177] Many of the embodiments described above relate to exemplary methods. Embodiments may also be implemented in other forms, such as including apparatus and non-transitory computer-readable storage media.

[0178] For example, a non-transitory computer-readable storage medium can store a program that is executed by a processor. Such a storage medium may include a computer program product, or be implemented in a device that also includes at least one processor coupled to the storage medium.

[0179] Processors 210, 260, 276 and memory media in the form of 208, 258, 278 are in Figure 3 The example shown is provided below. Therefore, device embodiments may include, for example... Figure 3 The example ED shown in 110, and as in Figure 3 The T-TRP and / or examples shown in 170 examples Figure 3The network device of NT-TRP shown in Figure 172. In some embodiments, the device may include other components, such as a communication interface coupled to a processor. Figure 3 The elements shown in 201 / 203 / 204, 252 / 254 / 256 and / or 272 / 274 / 280, etc., are illustrative examples of the apparatus, and other apparatus embodiments are possible.

[0180] In one embodiment, a program stored in a computer-readable storage medium, whether as a computer program product or implemented in an apparatus, may include instructions for or to cause a processor or apparatus to perform the following operations: transmitting signaling in a wireless communication network for configuring an end-to-end HARQ process associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path comprising multiple links between nodes along the relay path between the first and second end nodes. The end-to-end HARQ process is a single HARQ process represented by a single HARQ process identifier.

[0181] Features disclosed elsewhere herein may be implemented in embodiments of such devices and / or computer program products. For example, these features include any one, alone, or in any combination of the following:

[0182] The configuration includes allocating a first buffer for the end-to-end HARQ process;

[0183] The allocation includes allocating a first buffer in a shared HARQ buffer, and the procedure further includes instructions to perform the following: transmit additional signaling for allocating a second buffer in the shared HARQ buffer for a link HARQ process associated with a second data transmission between the two nodes via one of the links;

[0184] The end-to-end HARQ process is associated with only two HARQ entities, including the first HARQ entity of the first end node and the second HARQ entity of the second end node.

[0185] The procedure also includes: transmitting instructions for end-to-end HARQ feedback of the end-to-end HARQ process at the second end node;

[0186] The procedure further includes: transmitting instructions for link HARQ feedback of the end-to-end HARQ process at one or more intermediate nodes along the UE relay path between the second end node and the first end node and the second end node.

[0187] The end-to-end HARQ process may include: storing first data in the HARQ buffer of an intermediate node along the UE relay path between the first and second end nodes; relaying the first data to the second end node; and retransmitting the first data from the HARQ buffer to the second end node in response to an end-to-end HARQ feedback from the second end node indicating a negative acknowledgment of the first data.

[0188] The program also includes instructions for intermediate nodes along the UE relay path between the first and second end nodes to perform the following operations: store the first data in the HARQ buffer of the intermediate node; relay the first data to the second end node; and retransmit the first data from the HARQ buffer to the second end node in response to an end-to-end HARQ feedback from the second end node indicating a negative acknowledgment of the first data.

[0189] The end-to-end HARQ process may include: storing first data in the HARQ buffer of an intermediate node along the UE relay path between the first and second end nodes; relaying the first data to the second end node; and refreshing the first data from the HARQ buffer in response to an end-to-end HARQ feedback from the second end node indicating acknowledgment of the first data.

[0190] The procedure also includes instructions to perform the following operations: at an intermediate node along the UE relay path between the first and second end nodes, store the first data in the HARQ buffer of the intermediate node; relay the first data to the second end node; and refresh the first data from the HARQ buffer in response to an end-to-end HARQ feedback from the second end node indicating a negative acknowledgment of the first data.

[0191] The UE relay path includes a multi-hop UE relay path, wherein the multi-hop UE relay path includes a plurality of intermediate nodes along the relay path between a first end node and a second end node.

[0192] The UE relay path is one of multiple paths between the first end node and the second end node. The end-to-end HARQ process is associated with the transmission of first data from the first end node to the second end node through multiple paths.

[0193] The program also includes instructions for merging data received on different paths of multiple paths, received as part of an end-to-end HARQ process, at the second end node or an intermediate node between the first and second end nodes.

[0194] The merge instructions include instructions to merge data through soft merge or hard merge;

[0195] One or more of the first end node, the second end node, and the nodes in the UE relay path are or include virtual UEs;

[0196] Compared to other data that is unrelated to the end-to-end HARQ process, the first data has more stringent requirements for latency and / or reliability;

[0197] One or more of the first end node, the second end node, and the nodes in the UE relay path are IoT sensors or include IoT sensors;

[0198] The program also includes instructions for transmitting first data using downlink control information or sidechain control information that includes or otherwise indicates a HARQ process identifier;

[0199] The signaling is higher-level signaling or includes higher-level signaling;

[0200] The end-to-end HARQ process includes transmitting first data or different versions of the first data;

[0201] The procedure also includes instructions to perform the following operations: allocate HARQ buffers for the end-to-end HARQ process at the first end node, the second end node, and each other node along the entire UE relay path between the first end node and the second end node.

[0202] Other device or system features may be implemented in some embodiments. Figure 21 This is a block diagram illustrating an example of a telecommunications network 2100 provided in one embodiment. The telecommunications network 2100 includes a core network 2102 and an access network 2106. The access network 2106 serves multiple UEs 2104a, 2104b, 2104c, 2104d, 2104e, 2104f, 2104g, 2104h, and 2104i. In some embodiments, the access network 2106 is an evolved universal terrestrial radioaccess network (E-UTRAN). Another example of the access network 2106 is a cloud radioaccess network (C-RAN). The access network 2106 includes multiple BSs 2108a, 2108b, and 2108c. Each BS 2108a to 2108c provides a corresponding radio coverage area 2110a, 2110b, and 2110c, also referred to as a cell. Each BS in BS 2108a to 2108c can be implemented using a wireless transceiver, one or more antennas, and associated processing circuitry (e.g., antenna radio frequency (RF) circuitry, one or more analog-to-digital converters, one or more digital-to-analog converters, etc.).

[0203] Each of BS 2108a to 2108c is connected directly to core network 2102, or via one or more central processing centers (e.g., servers), but is not shown in the accompanying drawings. BS 2108a to 2108c can act as a gateway between the wired and wireless portions of access network 2106.

[0204] Depending on the implementation, each of BS 2108a to 2108c can also be called a base transceiver station, wireless BS, network node, transmission node, transmission point, Node B, eNode B, or remote radio head (RRH), etc.

[0205] In operation, multiple UEs 2104a to 2104i access the telecommunications network 2100 via access network 2106 by wirelessly communicating with one or more BSs 2108a to 2108c.

[0206] UEs 2104a to 2104d are adjacent to each other. Although each of UEs 2104a to 2104d can wirelessly communicate with BS 2108a, they can also communicate directly with each other, as shown in 2116. The communication represented in 2116 is direct communication between UEs without going through an access network component (e.g., a BS), such as the sidechain communication disclosed herein. Figure 21 As shown, UE-to-UE communication 2116 occurs directly between UEs 2104a and 2104d and is not routed through BS 2108a or any other part of access network 2106. Communication 2116 can also be referred to as lateral communication. In the embodiments disclosed herein, UE-to-UE communication uses a sidechain channel and a sidechain air interface. On the other hand, communication between access network components such as BS 2108a and UEs (e.g., in communication 2114) is referred to as access communication. Access communication occurs on an access channel, which can be an uplink or downlink channel, and uses a radio access communication interface, such as a cellular radio access air interface. Access and sidechain air interfaces can use different transmission formats, such as different waveforms, different multiple access schemes, or different radio access technologies. Some examples of radio access technologies that can be used for the access air interface or sidechain air interface are: Long Term Evolution (LTE), LTE License Assisted Access (LTE-LAA), and WiFi.

[0207] By using sidechain communication 2116, UEs 2104a to 2104d can assist in wireless communication between UEs 2104a to 2104d and BS 2108a. For example, if UE 2104c fails to correctly decode a data packet received from BS 2108a, but UE 2104d can receive and correctly decode the data packet from BS 2108a, then UE 2104d can directly send the decoded data packet to UE 2104c using sidechain communication 2116. Furthermore, if UE 2104c moves out of the wireless coverage area 2118c, making it impossible for UE 2104c to communicate wirelessly with BS 2108a, then UE 2104b can forward messages between UE 2104c and BS 2108a. For example, both UE 2104a and UE 2104c can receive signals transmitted from BS 2108a, carrying data packets intended for UE 2104c. UE 2104a can then transmit the signals received by UE 2104a to UE 2104c via sidechain communication 2116. UE 2104c can then use the information received from UE 2104a to help decode data packets from BS 2108a. In these examples, enhanced UEs can be formed to assist one or more of UEs 2104a, 2104b, and 2104d, thereby improving capacity or coverage.

[0208] In some embodiments, UEs 2104a to 2104d form UE group 2120. However, it should be noted that the features disclosed herein do not depend on a pre-formed UE group.

[0209] In UE group 2120 and in scenarios where UE 2104c is assisted, other UEs 2104a, 2104b, and 2104d constitute a cooperation candidate set for assisting UE 2104c. If UEs 2104a and 2104b assist UE 2104c, then UEs 2104a and 2104b constitute a cooperation active set. When UEs 2104a to 2104d move around, some UEs may leave UE group 2120. UE movement may also, or alternatively, cause other UEs to join UE group 2120. Therefore, the cooperation candidate set can change over time. For example, the cooperation candidate set can change semi-statically. For example, if the network determines that UE group 2120 no longer needs or has the opportunity to assist BS 2108a with wireless communication between members of UE group 2120, then UE group 2120 can also be terminated by network 2106.

[0210] More than one UE group can exist. For example, Figure 21 UEs 2104e and 2104f form another UE group 2122.

[0211] Figure 22 This is a block diagram illustrating an example of a network 2252 provided in one embodiment, serving two UEs 2254a and 2254b. Network 2252 may be... Figure 21 In the access network 2106, the two UEs 2254a and 2254b can be Figure 21 Two of the four UEs 2104a to 2104d. Alternatively, UEs 2254a and 2254b could be... Figure 21 UE 2104e and 2104f in the example. However, more generally, this is not necessarily the case, therefore, in Figure 22 Different figure labels are used.

[0212] Network 2252 includes a BS 2256 and a management module 2258. The management module 2258 instructs the BS 2256 to perform actions. As shown, the management module 2258 is physically separate from the BS 2256 but coupled to it via a communication link 2260. For example, the management module 2258 may be part of a server in network 2252. Alternatively, the management module 2258 may be part of the BS 2256.

[0213] Management module 2258 includes processor 2262, memory 2264, and communication module 2266. Communication module 2266 is implemented by processor 2262 when processor 2262 accesses and executes a series of instructions stored in memory 2264; these instructions define the actions of communication module 2266. When instructions are executed, communication module 2266 causes BS 2256 to perform the actions described herein, enabling network 2252 to establish, coordinate, instruct, or control UE operation and enhance UE formation and operation. Alternatively, communication module 2266 can be implemented using dedicated circuitry such as application-specific integrated circuits (ASICs) or programmable field-programmable gate arrays (FPGAs).

[0214] UE 2254a includes a communication subsystem 2270a, two antennas 2272a and 2274a, a processor 2276a, and a memory 2278a. UE 2254a also includes a communication module 2280a. The communication module 2280a is implemented by the processor 2276a when the processor 2276a accesses and executes a series of instructions stored in the memory 2278a, which define the actions of the communication module 2280a. When the instructions are executed, the communication module 2280a causes UE 2254a to perform the actions described herein regarding UE cooperation. Alternatively, module 2280a may be implemented using dedicated circuitry such as an ASIC or FPGA.

[0215] Communication subsystem 2270a includes processing circuitry, transmitting circuitry, and receiving circuitry for sending messages from and receiving messages from UE 2254a. Although one communication subsystem 2270a is shown, multiple communication subsystems 2270a may exist. Antenna 2272a transmits wireless communication signals to and receives wireless communication signals from BS 2256. Antenna 2274a transmits sidelink communication signals to and receives sidelink communication signals from other UEs (including UE 2254b). In some implementations, the two separate antennas 2272a and 2274a may not exist. A single antenna may be used. Alternatively, multiple antennas may be present, but not divided into antennas solely for sidelink communication and antennas solely for communication with BS 2256.

[0216] SL communication can be conducted via Wi-Fi, in which case antenna 2274a can be a Wi-Fi antenna. Alternatively, sidechain communication can be conducted via Bluetooth. TM In this case, antenna 2274a can be Bluetooth. TM Antenna. Sidechain communication can also or alternatively be conducted via licensed or unlicensed spectrum.

[0217] UE 2254b includes the same components described above with respect to UE 2254a. That is, UE 2254b includes communication subsystem 2270b, antennas 2272b and 2274b, processor 2276b, memory 2278b, and communication module 2280b.

[0218] Figure 21 and Figure 22 A system that can implement the embodiments is shown. In some embodiments, the UE includes a processor (e.g., Figure 22 2276a, 2276b) and non-transitory computer-readable storage media (e.g., 2276a, 2276b) for storing programs to be executed by a processor. Figure 22 (see 2278a and 2278b). Non-transitory computer-readable storage media may also be provided separately as a computer program product, or alternatively. Examples are provided elsewhere in this document.

[0219] This disclosure includes various embodiments related to the end-to-end HARQ process that can help identify identical or related data, such as RVs of identical data, in multi-link UE relays with UC, potentially increasing the chances of successful transmission from the source to a destination with lower latency.

[0220] End-to-end HARQ processes can facilitate the transmission of traffic with low latency requirements, such as ultra-reliable low latency communication (URLLC) in multi-hop relay systems, and can be useful in IoT scenarios with large amounts of periodic traffic.

[0221] The embodiments disclosed herein include at least the examples outlined below.

[0222] According to Example 1, a method includes: transmitting signaling in a wireless communication network for configuring an end-to-end HARQ process associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path comprising multiple links between nodes along the relay path between the first and second end nodes. The end-to-end HARQ process comprises a single HARQ process represented by a single HARQ process identifier.

[0223] Example 2 relates to the method of Example 1, wherein the configuration includes allocating a first buffer for the end-to-end HARQ process.

[0224] Example 3 relates to the method of Example 2, wherein the allocation includes allocating a first buffer in a shared HARQ buffer, and the method further includes: transmitting additional signaling for allocating a second buffer in the shared HARQ buffer for a link HARQ process associated with a second data transmission between two of the plurality of nodes via one of the plurality of links.

[0225] Example 4 relates to the method of any of Examples 1 to 3, wherein the end-to-end HARQ process is associated with only two HARQ entities, including a first HARQ entity of a first end node and a second HARQ entity of a second end node.

[0226] Example 5 relates to the method of any of Examples 1 to 4, and further includes: at the second end node, transmitting end-to-end HARQ feedback of the end-to-end HARQ process.

[0227] Example 6 relates to the method of Example 1, and further includes transmitting link HARQ feedback of the end-to-end HARQ process on one or more of the intermediate nodes along the UE relay path between the second end node and the first end node.

[0228] Example 7 relates to the method of Example 5, wherein the end-to-end HARQ process includes: storing first data in a HARQ buffer at an intermediate node along a UE relay path between a first end node and a second end node; relaying the first data to the second end node; and retransmitting the first data from the HARQ buffer to the second end node in response to an end-to-end HARQ feedback from the second end node indicating a negative acknowledgment of the first data.

[0229] Example 8 relates to the method of Example 5, wherein the end-to-end HARQ process includes: storing first data in a HARQ buffer at an intermediate node along a UE relay path between a first end node and a second end node; relaying the first data to the second end node; and refreshing the first data from the HARQ buffer in response to an end-to-end HARQ feedback from the second end node indicating acknowledgment of the first data.

[0230] Example 9 relates to a method of any of Examples 1 to 8, wherein the UE relay path includes a multi-hop UE relay path, wherein the multi-hop UE relay path includes a plurality of intermediate nodes along the relay path between a first end node and a second end node.

[0231] Example 10 relates to a method of any of Examples 1 to 9, wherein the UE relay path includes one of a plurality of paths between a first end node and a second end node, and the end-to-end HARQ process is associated with the transmission of first data from the first end node to the second end node via the plurality of paths.

[0232] Example 11 relates to the method of Example 10, and further includes merging data received as part of an end-to-end HARQ process on different paths of multiple paths at a second end node or an intermediate node between the first end node and the second end node.

[0233] Example 12 relates to the method of Example 11, wherein the merge includes a soft merge or a hard merge.

[0234] Example 13 relates to a method of any of Examples 1 to 12, wherein one or more of the following include a virtual UE: a first end node, a second end node, and a node in a plurality of nodes in the UE relay path.

[0235] Example 14 relates to the method of any of Examples 1 to 13, wherein the first data has more stringent requirements for latency and / or reliability compared to other data that is unrelated to the end-to-end HARQ process.

[0236] Example 15 relates to a method of any of Examples 1 through 14, wherein one or more of the following include an IoT sensor: a first end node, a second end node, and a node in a plurality of nodes in a UE relay path.

[0237] Example 16 relates to the method of any of Examples 1 to 15, and further includes: transmitting first data using downlink control information or sidechain control information including a HARQ process identifier.

[0238] Example 17 relates to a method of any of Examples 1 to 16, wherein the signaling is higher-layer signaling.

[0239] Example 18 relates to a method of any of Examples 1 through 17, wherein the end-to-end HARQ process includes transmitting first data or different versions of the first data.

[0240] Example 19 relates to the method of any of Examples 1 to 18, and further includes allocating HARQ buffers for the end-to-end HARQ process on the first end node, the second end node, and each other node along the entire UE relay path between the first end node and the second end node.

[0241] According to Example 20, an apparatus includes: a communication interface; a processor coupled to the communication interface; and a non-transitory computer-readable storage medium coupled to the processor and storing a program executed by the processor. The program includes instructions to: transmit signaling in a wireless communication network for configuring an end-to-end HARQ process associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path including multiple links between nodes along the relay path between the first and second end nodes. The end-to-end HARQ process includes a single HARQ process represented by a single HARQ process identifier.

[0242] Example 21 relates to the apparatus of Example 20, wherein the configuration includes allocating a first buffer for the end-to-end HARQ process.

[0243] Example 22 relates to the apparatus of Example 21, wherein the allocation includes allocating a first buffer in a shared HARQ buffer, and the program further includes instructions to perform the following: transmit additional signaling for allocating a second buffer in the shared HARQ buffer for a link HARQ process associated with a second data transmission between two of the plurality of nodes via one of the plurality of links.

[0244] Example 23 relates to an apparatus of any of Examples 20 to 22, wherein the end-to-end HARQ process is associated with only two HARQ entities, including a first HARQ entity of a first end node and a second HARQ entity of a second end node.

[0245] Example 24 relates to an apparatus of any of Examples 20 to 23, the procedure further comprising: at a second end node, transmitting instructions for end-to-end HARQ feedback of the end-to-end HARQ process.

[0246] Example 25 relates to the apparatus of Example 20, the procedure further including instructions for transmitting link HARQ feedback of the end-to-end HARQ process on one or more of the second end node and intermediate nodes along the UE relay path between the first end node and the second end node.

[0247] Example 26 relates to the apparatus of Example 24, wherein the end-to-end HARQ process includes: storing first data in a HARQ buffer at an intermediate node along a UE relay path between a first end node and a second end node; relaying the first data to the second end node; and retransmitting the first data from the HARQ buffer to the second end node in response to an end-to-end HARQ feedback from the second end node indicating a negative acknowledgment of the first data.

[0248] Example 27 relates to the apparatus of Example 24, wherein the end-to-end HARQ process includes: storing first data in a HARQ buffer at an intermediate node along a UE relay path between a first end node and a second end node; relaying the first data to the second end node; and refreshing the first data from the HARQ buffer in response to an end-to-end HARQ feedback from the second end node indicating acknowledgment of the first data.

[0249] Example 28 relates to an apparatus of any of Examples 20 to 27, wherein the UE relay path includes a multi-hop UE relay path, wherein the multi-hop UE relay path includes a plurality of intermediate nodes along the relay path between a first end node and a second end node.

[0250] Example 29 relates to an apparatus of any of Examples 20 to 28, wherein the UE relay path includes one of a plurality of paths between a first end node and a second end node, and the end-to-end HARQ process is associated with the transmission of first data from the first end node to the second end node via the plurality of paths.

[0251] Example 30 relates to the apparatus of Example 29, the program further including instructions on a second end node or an intermediate node between the first end node and the second end node to merge data received as part of an end-to-end HARQ process on different paths of multiple paths.

[0252] Example 31 relates to the apparatus of Example 30, wherein the merge instructions include instructions to merge data by means of soft merge or hard merge.

[0253] Example 32 relates to an apparatus of any of Examples 20 to 31, wherein one or more of the following include a virtual UE: a first end node, a second end node, and a node in a plurality of nodes of a UE relay path.

[0254] Example 33 relates to an apparatus of any of Examples 20 to 32, wherein the first data has more stringent requirements for latency and / or reliability compared to other data that is unrelated to the end-to-end HARQ process.

[0255] Example 34 relates to a device of any of Examples 20 to 33, wherein one or more of the following include an IoT sensor: a first end node, a second end node, and a node among a plurality of nodes in a UE relay path.

[0256] Example 35 relates to an apparatus of any of Examples 20 to 34, wherein the program further includes instructions for transmitting first data using downlink control information or sidechain control information including a HARQ process identifier.

[0257] Example 36 relates to an apparatus of any of Examples 20 to 35, wherein the signaling is higher-layer signaling.

[0258] Example 37 relates to an apparatus of any of Examples 20 to 36, wherein the end-to-end HARQ process includes transmitting first data or different versions of the first data.

[0259] Example 38 relates to an apparatus of any of Examples 20 to 37, the program further comprising instructions to allocate HARQ buffers for an end-to-end HARQ process on the entire UE relay path between the first end node and the second end node, at the first end node, the second end node, and each other node.

[0260] According to Example 39, a computer program product includes a non-transitory computer-readable storage medium storing a program. The program includes instructions to transmit signaling in a wireless communication network for configuring an end-to-end HARQ process associated with a first data transmission along a UE relay path from a first end node to a second end node, the UE relay path including multiple links between nodes along the relay path between the first and second end nodes. The end-to-end HARQ process includes a single HARQ process represented by a single HARQ process identifier.

[0261] The description is merely an illustration of the application of the principles of the embodiments disclosed herein. Other apparatuses and methods may be implemented by those skilled in the art.

[0262] For example, while combinations of features are shown in the illustrated embodiments, not all features need to be combined to achieve the advantages of the various embodiments of this disclosure. In other words, a system or method designed according to one embodiment of this disclosure does not necessarily include all features shown in any of the drawings or all portions schematically illustrated in the drawings. Furthermore, selected features of one exemplary embodiment may be combined with selected features of other exemplary embodiments.

[0263] While this disclosure has been described with reference to illustrative embodiments, it is not intended to be interpreted in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of this disclosure, will be apparent to those skilled in the art upon reference to this specification. Therefore, the appended claims are intended to cover any such modifications or embodiments.

[0264] Although various aspects of this disclosure have been described with reference to specific features and embodiments thereof, various modifications and combinations may be made to this disclosure without departing from it. The specification and drawings are therefore to be considered merely as illustrations of some embodiments of this disclosure as defined in the appended claims, and any and all modifications, variations, combinations, or equivalents covering the scope of this disclosure are to be considered. Thus, while embodiments and possible advantages have been described in detail, various changes, substitutions, and alterations may be made herein without departing from the disclosure as defined in the appended claims. Furthermore, the scope of this application is not intended to be limited to the specific embodiments of the processes, machines, articles of manufacture, compositions of matter, modules, methods, and steps described in the specification. Those skilled in the art will readily understand from the disclosure that processes, machines, articles of manufacture, compositions of matter, modules, methods, or steps (including those currently existing or later developed) can be used to perform or achieve substantially the same function or result as the corresponding embodiments described herein. Accordingly, the scope of the appended claims includes these processes, machines, articles of manufacture, compositions of matter, methods, and steps.

[0265] Furthermore, although described primarily in the context of methods and apparatus, other implementations are contemplated, for example, as instructions stored in a non-transitory processor-readable medium. These media may store programs or instructions to perform any of the various methods consistent with this disclosure.

[0266] Furthermore, any module, component, or device executing instructions illustrated herein may include or otherwise access one or more non-transitory computer-readable or processor-readable storage media to store information, such as computer-readable or processor-readable instructions, data structures, program modules, and / or other data. A non-exhaustive list of examples of non-transitory computer-readable or processor-readable storage media includes magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, compact disc read-only memory (CD-ROM), digital video disc or digital versatile disc (DVD), Blu-ray disc, etc. TM Optical discs or other optical storage, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other storage technologies. Any such non-transitory computer-readable or processor-readable storage medium may be part of a device or may be accessed or connected to a device. Any application or module described herein may be implemented using computer-readable and executable instructions, or a processor may be stored in or otherwise held by such non-transitory computer-readable or processor-readable storage medium.

Claims

1. A method characterized by, Comprising: transmitting, in a wireless communication network, signaling for configuring an end-to-end hybrid automatic repeat request, HARQ, process associated with a first data transmission along a user equipment, UE, relay path from a first end node to a second end node, the UE relay path comprising a plurality of links between nodes along a relay path between the first end node and the second end node, the end-to-end HARQ process comprising a single HARQ process represented by a single HARQ process identifier, the end-to-end HARQ process being associated with only two HARQ entities, a first HARQ entity of the first end node and a second HARQ entity of the second end node; the method further comprising: transmitting, at the second end node, end-to-end HARQ feedback for the end-to-end HARQ process; and allocating, on the entire UE relay path between the first end node and the second end node, a HARQ buffer for the end-to-end HARQ process at the first end node, the second end node, and each other node. the configuring comprises allocating a first buffer for the end-to-end HARQ process.

2. The method of claim 1, wherein, the allocating comprises allocating the first buffer in a shared HARQ buffer, the method further comprising:

3. The method of claim 2, wherein, transmitting other signaling for allocating a second buffer in the shared HARQ buffer for a link HARQ process associated with a second data transmission between two nodes of a plurality of nodes over one link of the plurality of links. further comprising, at the second end node and one or more of the intermediate nodes along the UE relay path between the first end node and the second end node, 4. The method of claim 1, wherein, transmitting link HARQ feedback for the end-to-end HARQ process. the end-to-end HARQ process comprises, at an intermediate node between the first end node and the second end node along the UE relay path:

5. The method of claim 1, wherein, storing the first data in a HARQ buffer of the intermediate node; relaying the first data to the second end node; retransmitting the first data from the HARQ buffer to the second end node in response to end-to-end HARQ feedback from the second end node representing a negative acknowledgement of the first data. the end-to-end HARQ process comprises, at an intermediate node between the first end node and the second end node along the UE relay path:

6. The method of claim 1, wherein, storing the first data in a HARQ buffer of the intermediate node; relaying the first data to the second end node; updating the first data from the HARQ buffer in response to end-to-end HARQ feedback from the second end node representing an acknowledgement of the first data. the UE relay path comprises a multi-hop UE relay path comprising a plurality of intermediate nodes along the relay path between the first end node and the second end node.

7. The method of claim 1, wherein, ​ 8. The method of claim 1, wherein, The UE relay path comprises one of a plurality of paths between the first end node and the second end node, the end-to-end HARQ process being associated with transmission of the first data from the first end node to the second end node over the plurality of paths.

9. The method of claim 8, wherein, Further comprising, at an intermediate node of the second end node or between the first end node and the second end node: combining data received as part of the end-to-end HARQ process, received on different paths of the plurality of paths.

10. The method of claim 9, wherein, The combining comprises soft combining or hard combining.

11. The method of claim 7, wherein, One or more of the following comprises a virtual UE: the first end node, the second end node, and a node of the plurality of intermediate nodes of the UE relay path.

12. The method of claim 1, wherein, The first data is more stringent in latency and / or reliability requirements than other data not associated with the end-to-end HARQ process.

13. The method of claim 7, wherein, One or more of the following comprises an Internet of Things, IoT, sensor: the first end node, the second end node, and a node of the plurality of intermediate nodes of the UE relay path.

14. The method of claim 1, wherein, Further comprising: transmitting the first data using downlink control information or sidelink control information comprising the HARQ process identifier.

15. The method of claim 1, wherein, The signaling is high layer signaling.

16. The method according to any one of claims 1 to 15, characterized in that, The end-to-end HARQ process comprises transmission of the first data or a different version of the first data.

17. An apparatus, comprising: Comprising: a communication interface; a processor coupled to the communication interface, configured to: transmit, in a wireless communication network, signaling for configuring an end-to-end hybrid automatic repeat request, HARQ, process associated with transmission of first data along a user equipment, UE, relay path from a first end node to a second end node, the UE relay path comprising a plurality of links between nodes along a relay path between the first end node and the second end node, the end-to-end HARQ process comprises a single HARQ process represented by a single HARQ process identifier, the end-to-end HARQ process is associated with only two HARQ entities, a first HARQ entity of the first end node and a second HARQ entity of the second end node; the processor is further configured to: transmit, at the second end node, end-to-end HARQ feedback for the end-to-end HARQ process; and allocate, at the first end node, the second end node, and each other node along the entire UE relay path between the first end node and the second end node, a HARQ buffer for the end-to-end HARQ process.

18. The apparatus of claim 17, wherein, the processor is further configured to allocate a first buffer for the end-to-end HARQ process.

19. The apparatus of claim 18, wherein, The allocation comprises allocating the first buffer in a shared HARQ buffer, the processor is further configured to: transmit other signaling for allocating a second buffer in the shared HARQ buffer for a link HARQ process associated with transmission of second data between two nodes of the plurality of nodes over one of the plurality of links.

20. The apparatus of claim 17, wherein, the processor is further configured to, at the second end node and one or more of the intermediate nodes between the first end node and the second end node along the UE relay path, transmitting link HARQ feedback for the end-to-end HARQ process.

21. The apparatus of claim 17, wherein, The end-to-end HARQ process comprises, between the first end node and the second end node, an intermediate node along the UE relay path: storing the first data in a HARQ buffer of the intermediate node; relaying the first data to the second end node; retransmitting the first data from the HARQ buffer to the second end node in response to end-to-end HARQ feedback from the second end node indicating a negative acknowledgement of the first data.

22. The apparatus of claim 17, wherein, The end-to-end HARQ process comprises, between the first end node and the second end node, an intermediate node along the UE relay path: storing the first data in a HARQ buffer of the intermediate node; relaying the first data to the second end node; updating the first data from the HARQ buffer in response to end-to-end HARQ feedback from the second end node indicating an acknowledgement of the first data.

23. The apparatus of claim 17, wherein, The UE relay path comprises a multi-hop UE relay path comprising a plurality of intermediate nodes along the relay path between the first end node and the second end node.

24. The apparatus of claim 17, wherein, The UE relay path comprises one of a plurality of paths between the first end node and the second end node, the end-to-end HARQ process being associated with transmission of the first data from the first end node to the second end node over the plurality of paths.

25. The apparatus of claim 24, wherein, The processor is further configured to, at the second end node or an intermediate node between the first end node and the second end node: merge data received as part of the end-to-end HARQ process, the data being received on different paths of the plurality of paths.

26. The apparatus of claim 25, wherein, The processor is further configured to merge the data by soft combining or hard combining.

27. The apparatus of claim 23, wherein, One or more of the following comprises a virtual UE: the first end node, the second end node, and a node of the plurality of intermediate nodes of the UE relay path.

28. The apparatus of claim 17, wherein, The first data is more stringent in latency and / or reliability requirements than other data not associated with the end-to-end HARQ process.

29. The apparatus of claim 23, wherein, One or more of the following comprises an Internet of Things, IoT, sensor: the first end node, the second end node, and a node of the plurality of intermediate nodes of the UE relay path.

30. The apparatus of claim 17, wherein, The processor is further configured to: transmit the first data using downlink control information or sidelink control information comprising the HARQ process identifier.

31. The apparatus of claim 17, wherein, The signaling is high layer signaling.

32. The apparatus of any one of claims 17-31, wherein, The end-to-end HARQ process comprises transmission of the first data or a different version of the first data.

33. A computer program product, characterised in that, A non-transitory computer-readable storage medium storing a program comprising instructions for causing a computer to perform the method according to any one of claims 1 to 16.

Images