Transmitting data via a sidelink interface

Abstract

Apparatuses, methods, and systems are disclosed for improving communications using relaying over a sidelink radio interface. One apparatus includes a processor and a transceiver that transmits a data packet via a sidelink interface, where the data packet is transmitted to a first UE device and a second UE device. The transceiver receives first HARQ feedback from the first UE device and second HARQ feedback from the second UE device. Here, the first HARQ feedback indicates a decoding status of the data packet at the first UE device, and the second HARQ feedback indicates a decoding status of the data packet at the second UE device. The processor determines to stop transmission of the data packet in response to at least one of the first and second HARQ feedback being a positive acknowledgement.

Description

Technical Field

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 061,725, filed August 5, 2020, entitled “MECHANISMS FOR IMPROVED COMMUNICATIONS USING RELAY OVER SIDELINK RADIO INTERFACE”, which is incorporated herein by reference.

[0003] The subject matter disclosed in this article generally relates to wireless communication, and more specifically to mechanisms for improving communication using relays on side-link radio interfaces. Background Technology

[0004] SL relay is a potential means of increasing coverage using single-hop or multi-hop methods. For UE-to-network coverage extension, Uu coverage reachability is necessary for the UE to reach a server in the PDN network or a corresponding UE outside the vicinity. For UE-to-UE coverage extension, currently, proximity reachability is limited to single-hop sidelinks via EUTRA-based or NR-based sidelink technologies. Summary of the Invention

[0005] A process for improving communication using a relay over a sidelink radio interface is disclosed. The process can be implemented by an apparatus, system, method, or computer program product.

[0006] A method for transmitting remote user equipment (“Tx Remote UE”) using relay-enhanced communication on a sidelink radio interface includes transmitting data packets via the sidelink interface, wherein the data packets are sent to a first user equipment (“UE”) device and a second UE device. The method includes receiving a first Hybrid Automatic Repeat Request (“HARQ”) feedback from the first UE device and receiving a second HARQ feedback from the second UE device. Here, the first HARQ feedback indicates the decoding status of the data packet at the first UE device, and the second HARQ feedback indicates the decoding status of the data packet at the second UE device. The method includes determining to stop transmission of the data packet in response to at least one of the first and second HARQ feedbacks being a positive acknowledgment.

[0007] A method for a sidelink relay user equipment (“SL relay UE”) using a sidelink radio interface for improved communication via relay includes receiving data packets from a first UE device via a first sidelink interface, sending a first HARQ feedback to the first UE device in response to successfully decoding the data packets, and sending the data packets to a second UE device via a second sidelink interface. Attached Figure Description

[0008] A more detailed description of the embodiments briefly described above will be presented with reference to the specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and are therefore not to be considered as limiting the scope; these embodiments will be described and explained with additional specificity and detail using the drawings, in which:

[0009] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system that improves communication using relays on a sidelink radio interface;

[0010] Figure 2A This is a block diagram illustrating one embodiment of a relay arrangement for transmitting a transport block (“TB”) via unicast transmission;

[0011] Figure 2B This is a block diagram illustrating one embodiment of a sidelink (e.g., PC5) protocol stack;

[0012] Figure 3A This is a block diagram illustrating one embodiment of a relay arrangement for using multiple relays to unicast the same TB.

[0013] Figure 3B It is a diagram. Figure 3A A block diagram of an embodiment of mapping source identifiers (“ID”) and destination IDs of an interface;

[0014] Figure 4A This is a block diagram illustrating one embodiment of a relay arrangement for transmitting the same TB using multiple relays and direct paths;

[0015] Figure 4B The diagram is used for Figure 4A A block diagram of an embodiment of the mapping of source ID and destination ID of an interface;

[0016] Figure 4C The diagram is used for Figure 4A A block diagram of another embodiment of the mapping of source ID and destination ID of the interface;

[0017] Figure 5 This is a block diagram illustrating one embodiment of the 5G New Radio (“NR”) protocol stack;

[0018] Figure 6This is a block diagram illustrating one embodiment of a user equipment apparatus that can be used to improve communication using a relay over a sidelink radio interface;

[0019] Figure 7 This is a block diagram illustrating one embodiment of a network device apparatus that can be used to improve communication using relay over a sidelink radio interface;

[0020] Figure 8 This is a block diagram illustrating an embodiment of a first method for improving communication using a relay over a sidelink radio interface; and

[0021] Figure 9 This is a block diagram illustrating an embodiment of a second method for improving communication using a relay over a sidelink radio interface. Detailed Implementation

[0022] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Therefore, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0023] For example, the disclosed embodiments can be implemented as hardware circuitry, including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0024] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device uses only signals for accessing the code.

[0025] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.

[0026] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable compact disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0027] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, and C++, traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or it can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").

[0028] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as programming examples, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0029] Throughout this specification, references to "an embodiment," "embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases "in an embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, refer to the same embodiment, but rather mean "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly stated otherwise, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a," "an," and "the" also mean "one or more."

[0030] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of…” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of…” includes one and only one single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0031] The aspects of the embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that individual blocks in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to generate a machine, such that instructions executable by the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0032] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that implement the functions / actions specified in the flowchart and / or block diagram.

[0033] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0034] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing one or more specified logical functions.

[0035] It should also be noted that in some alternative implementations, the functions marked in the boxes may not appear in the order shown in the figure. For example, depending on the functionality involved, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the figure shown are conceivable.

[0036] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not to be construed as limiting the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of a depicted embodiment. It will also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware or a combination of dedicated hardware and code that performs the specified function or action.

[0037] The description of the elements in each figure can be referenced to the elements in the preceding figures. In all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0038] Generally, this disclosure describes systems, methods, and apparatuses for improving communications using relays on sidelink radio interfaces. In some embodiments, these methods may be performed using computer code embedded in a computer-readable medium. In some embodiments, the apparatus or system may include a computer-readable medium containing computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of a solution.

[0039] As mentioned above, this paper considers two types of relays:

[0040] 1) UE to Network Relay (also known as “N-Relay”): Uu coverage reachability is necessary for a UE to reach a server in the Packet Data Network (“PDN”) or a corresponding UE outside the vicinity. However, the N-Relay solution previously defined in 3GPP Rel-13 is limited to Evolved Universal Terrestrial Radio Access (“EUTRA”) technology and therefore cannot be applied to both NR-based systems used for Next Generation (i.e., 5G) Radio Access Networks (“NG-RAN”) and NR-based sidelink communications.

[0041] 2) UE-to-UE relay (also known as "UE relay"): Currently, proximity reachability is limited to single-hop sidelinks via EUTRA-based or NR-based sidelink technologies. However, given the limited coverage of single-hop sidelinks, this is insufficient in scenarios without Uu coverage (i.e., the UE is outside the RAN coverage area).

[0042] For both SL relay types, SL remote UEs need to discover and select a relay for transmission to the SL remote. Reliability requirements are already 10^-5 (e.g., PQI 91, as shown in Table 1) and will likely only increase further with the introduction of public safety. Furthermore, other communication applications—such as the Industrial Internet of Things (“IIoT”)—will begin to use sidelinks, requiring not only higher reliability but also extended coverage. SL relay is a potential means of increasing coverage using single-hop or multi-hop methods. This paper describes methods for achieving higher reliability and coverage.

[0043] Table 1: Standardized PQI to QoS Feature Mapping (from 3GPP TS 23.287)

[0044]

[0045] Multiple relays for NR side links are a new area of ​​research. In previous systems like EUTRA, there was no concept of using Hybrid Automatic Repeat Request (“HARQ”) feedback, and therefore no direct, traditional solution for using relays to increase reliability and / or coverage.

[0046] This disclosure describes numerous solution use cases whereby a remote transmitter device can communicate with a remote receiver device using one or more relays and optionally a direct link. As used herein, a relay device or relay UE can refer to the aforementioned N-relay or UE relay scenario. To optimize the system, several enhancements have been implemented to achieve maximum reliability and system efficiency. The solution revolves around a novel HARQ feedback transmit / receive method, under which not only the transmitter but also potential transmitters can determine whether they should also send the same data packets to the remote receiver device.

[0047] There is no prior solution in NR systems where relays are used in sidelinks to increase reliability. There is also no prior solution in 3GPP for sidelink communication using relays that utilize retransmissions based on sidelink HARQ feedback. Because relays are used to reach remote receiver UEs that may not be within the communication range of the remote transmitter, the solution disclosed here not only increases transmission reliability but also coverage.

[0048] In one embodiment, it has been determined that the sidelink receiver UE (also referred to herein as "UE3") cannot directly access or at least cannot effectively access the sidelink transmitter UE (also referred to herein as "UE1"), and further it is determined whether to use only the sidelink relay UE (i.e., use one or more relays) or also use the direct link to UE3. In some embodiments, the decision to use one of these different cases depends on the required reliability and the channel busy rate ("CBR") or other channel quality metrics.

[0049] In another embodiment, as a result of the handshake process, the relay UE (also referred to herein as "UE2") may "adopt" UE3's source ID as one of its own source identifiers, and thus when the SRC comes from UE1, the transmissions received using the destination identifier set to UE3's DST will not be filtered out.

[0050] In some embodiments, two HARQ feedback opportunities are used: a first (time-based) opportunity is used by the sidelink receiver UE to send HARQ feedback, which is monitored by the sidelink transmitter UE and one or more sidelink relay UEs; while a second (time-based) opportunity is used by any sidelink relay UE and / or sidelink receiver UE to send ACK-only HARQ feedback on a common resource that is also linked by another offset to a physical resource (e.g., the lowest physical resource block (“PRB”) or subchannel) for transmitting transport blocks (“TB”, e.g., data packets) on interface 1.

[0051] In some embodiments, a new 1-bit flag (referred to as "Use Relay") is used. When this flag is set to "TRUE", it indicates "Tx from UE1 that needs to be relayed" (where "UE1" identifies the sidelink transmitter UE), and then the two HARQ feedback opportunities are used. When this flag is set to "FALSE", it indicates "Tx from UE2" (where "UE2" represents the sidelink relay UE), and then only one HARQ feedback opportunity is used. In some embodiments, the second relay UE listens for feedback from the sidelink receiver UE to the first relay, and if the feedback from the sidelink receiver UE is NACK, the second relay sends the corresponding TB. As used herein, "HARQ-ACK" can collectively represent a positive acknowledgment ("ACK"), a negative acknowledgment ("NACK"), and a discontinuous transmission ("DTX"). Signaling ACK means that the transport block ("TB") was received correctly. Signaling NACK (or NAK) means that the TB was received incorrectly (e.g., received but not successfully decoded), while signaling DTX means that the TB was not detected.

[0052] Figure 1 A wireless communication system 100 for improved communication using a relay over a sidelink radio interface, according to embodiments of the present disclosure, is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may consist of a base station unit 121, to which the remote unit 105 communicates using a wireless communication link 123. Even in Figure 1 A specific number of remote units 105, base station units 121, wireless communication links 123, RAN 120, and mobile core network 140 are depicted, but those skilled in the art will recognize that any number of remote units 105, base station units 121, wireless communication links 123, RAN 120, and mobile core network 140 may be included in the wireless communication system 100.

[0053] In one implementation, RAN 120 conforms to the 5G system specified in the 3rd Generation Partnership Project (“3GPP”) specifications. For example, RAN 120 could be a next-generation radio access network (“NG-RAN”) implementing a new radio (“NR”) radio access technology (“RAT”) and / or a long-term evolution (“LTE”) RAT. In another example, RAN 120 could include a non-3GPP RAT (e.g., Or an IEEE 802.11 series compliant WLAN. In another embodiment, RAN 120 conforms to the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 can implement other open or proprietary communication networks, such as Global Microwave Access Interoperability (“WiMAX”) or the IEEE 802.16 series standards and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0054] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transceiver unit (“WTRU”), device, or other terms used in the art. In various embodiments, remote unit 105 includes a subscriber identity and / or identification module (“SIM”) and a mobile device (“ME”) that provides mobile terminal functions (e.g., radio transmission, handover, voice encoding and decoding, error detection and correction, signal notification, and SIM access). In some embodiments, the remote unit 105 may include a terminal device (“TE”) and / or be embedded in an appliance or device (e.g., a computing device as described above).

[0055] Remote unit 105 can communicate directly with one or more base station units 121 in RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Alternatively, UL and DL communication signals can be carried via wireless communication link 123. Here, RAN 120 is an intermediate network providing access to the mobile core network 140 for remote unit 105.

[0056] In some embodiments, remote unit 105 communicates with application server 151 via a network connection to mobile core network 140. For example, application 107 in remote unit 105 (e.g., a web browser, media client, telephone, and / or Voice over Internet Protocol (“VoIP”) application) can trigger remote unit 105 to establish a Protocol Data Unit (“PDU”) session (or other data connection) with mobile core network 140 via RAN 120. Mobile core network 140 then uses the PDU session to relay traffic between remote unit 105 and application server 151 in packet data network 150. The PDU session represents a logical connection between remote unit 105 and user plane function (“UPF”) 141.

[0057] To establish a PDU session (or PDN connection), remote unit 105 must register with mobile core network 140 (also referred to as "attached to mobile core network" in the context of fourth-generation ("4G") systems). Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 140. Therefore, remote unit 105 may have at least one PDU session for communicating with packet data network 150. Remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0058] In the context of a 5G system (“5GS”), the term “PDU session” refers to a data connection that provides end-to-end (“E2E”) user plane (“UP”) connectivity between remote unit 105 and a specific data network (“DN”) via UPF 141. A PDU session supports one or more Quality of Service (“QoS”) streams. In some embodiments, there may be a one-to-one mapping between QoS streams and QoS profiles, such that all packets belonging to a particular QoS stream have the same 5G QoS identifier (“5QI”).

[0059] In the context of 4G / LTE systems such as Evolved Packet System (“EPS”), a Packet Data Network (“PDN”) connection (also known as an EPS session) provides end-to-end (E2E) connectivity between the remote unit and the PDN. The PDN connectivity process establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and the packet gateway (“PGW”, not shown) in the mobile core network 140. In some embodiments, a one-to-one mapping exists between the EPS bearer and a QoS profile, such that all packets belonging to a particular EPS bearer have the same QoS class identifier (“QCI”).

[0060] Base station unit 121 may be distributed across a geographical area. In some embodiments, base station unit 121 may also be referred to as an access terminal, access point, base station, Node-B (“NB”), evolved Node B (abbreviated as eNodeB or “eNB”, also known as Evolved Universal Terrestrial Radio Access Network (“E-UTRAN”) Node B), 5G / NR Node B (“gNB”), home Node B, relay node, RAN node, or any other term used in the art. Base station unit 121 is typically part of an RAN, such as RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base station units 121. These and other elements of the radio access network are not illustrated but are well known to those skilled in the art. Base station unit 121 is connected to mobile core network 140 via RAN 120.

[0061] Base station unit 121 can serve multiple remote units 105 within a service area (e.g., a cell or cell sector) via wireless communication link 123. Base station unit 121 can communicate directly with one or more of the remote units 105 via communication signals. Typically, base station unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried via wireless communication link 123. Wireless communication link 123 can be any suitable carrier in the licensed or unlicensed radio spectrum. Wireless communication link 123 facilitates communication between one or more remote units 105 and / or one or more base station units 121. Note that during NR operation on unlicensed spectrum (referred to as "NR-U"), base station unit 121 and remote units 105 communicate via unlicensed (i.e., shared) radio spectrum.

[0062] In one embodiment, the mobile core network 140 is a 5GC or Evolved Packet Core (“EPC”), which may be coupled to a packet data network 150, such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account to the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator (“MNO”). This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0063] Mobile core network 140 includes several network functions (“NFs”). As shown, mobile core network 140 includes at least one UPF 141. Mobile core network 140 also includes multiple control plane (“CP”) functions, including but not limited to Access and Mobility Management Functions (“AMF”) 143 serving RAN 120, Session Management Functions (“SMF”) 145, Policy Control Functions (“PCF”) 147, Unified Data Management Functions (“UDM”), and User Data Repository (“UDR”). Figure 1 A specific number and type of network functions are described, but those skilled in the art will recognize that any number and type of network functions can be included in the mobile core network 140.

[0064] One or more UPF 141s are responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting data networks (DNs) in the 5G architecture. AMF 143 is responsible for NAS signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF 145 is responsible for session management (i.e., session establishment, modification, and release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and traffic bootstrapping configuration of UPF 141 for appropriate traffic routing.

[0065] PCF 147 is responsible for the unified policy framework, providing policy rules to CP functions for access subscription information determined in the UDR. UDM is responsible for generating authentication and key protocol (“AKA”) credentials, user identification processing, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to serve multiple network functions. For example, the UDR can store subscription data, policy-related data, subscriber-related data that may be exposed to third-party applications, etc. In some embodiments, the UDM and UDR are co-located and depicted as a combined entity “UDM / UDR” 149.

[0066] In various embodiments, the mobile core network 140 may also include a network repository function (“NRF”) (which provides network function (“NF”) service registration and discovery, enabling NFs to identify the appropriate services among themselves and communicate with each other via application programming interfaces (“APIs”), a network exposure function (“NEF”) (responsible for enabling customers and network partners to easily access network data and resources), an authentication server function (“AUSF”), or other NFs defined for the 5GC. When present, the AUSF can act as an authentication server and / or authentication proxy, thereby allowing the AMF 143 to authenticate remote unit 105. In some embodiments, the mobile core network 140 may include an authentication, authorization, and accounting (“AAA”) server.

[0067] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network 140 optimized for a specific traffic type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") service. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") service. In other examples, network slices may be optimized for machine-type communication ("MTC") service, massive MTC ("mMTC") service, and Internet of Things ("IoT") service. In other examples, network slices may be deployed for specific application services, vertical services, specific use cases, etc.

[0068] Network slice instances can be identified by a single network slice selection aid information (“S-NSSAI”), while a set of network slices authorized for use by remote unit 105 is identified by network slice selection aid information (“NSSAI”). Here, “NSSAI” refers to a vector value including one or more S-NSSAI values. In some embodiments, various network slices may include individual instances of network functions, such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For ease of illustration, Figure 1 Different network slices are not shown, but their support is assumed.

[0069] Although Figure 1 The components of the 5G RAN and 5G core network are described, but the embodiments described for use in relay-enhanced communications on sidelink radio interfaces are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications (“GSM”, i.e., 2G digital cellular networks), General Packet Radio Service (“GPRS”), General Mobile Telecommunications System (“UMTS”), LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and others.

[0070] Furthermore, in the LTE variant of the EPC where the mobile core network 140 is, the described network functions can be replaced with appropriate EPC entities, such as the Mobility Management Entity (“MME”), Serving Gateway (“SGW”), PGW, Home Subscriber Server (“HSS”), etc. For example, AMF 143 can be mapped to the MME, SMF 145 can be mapped to the control plane portion of the PGW and / or mapped to the MME, UPF 141 can be mapped to the SGW and the user plane portion of the PGW, and PGW, UDM / UDR 149 can be mapped to the HSS, etc.

[0071] In the following description, the term "RAN node" is used for a base station, but it is used in place of any other radio access node, such as a gNB, ng-eNB, eNB, base station ("BS"), access point ("AP"), etc. Furthermore, these operations are primarily described in the context of 5G NR. However, the solutions / methods described below are equally applicable to other mobile communication systems using relay-enhanced communication on sidelink radio interfaces.

[0072] In various embodiments, remote units 105 may communicate directly with each other using SL communication link 115 (e.g., device-to-device communication). Here, SL transmissions may occur on SL resources. Remote unit 105 performs SL HARQ processing on at least some of the data transmitted via SL communication signal 115, as discussed in more detail below.

[0073] In various embodiments, the transmitting remote unit 105 (i.e., the source UE) may not be within range of direct transmission to the receiving remote unit 105 (i.e., the destination UE). In such embodiments, the transmitting remote unit 105 may use one or more relay units 109 to reach the receiving remote unit. The relay unit 109 may be an embodiment of the remote unit 105, i.e., a UE configured to relay transmissions via the SL communication link 115. One or more relay units 109 may relay both data packets and HARQ feedback, as discussed in more detail below.

[0074] In NR V2X communication Rel.16, SL HARQ feedback is used for multicast and unicast communication to improve spectral efficiency. When SL HARQ feedback is enabled for unicast, in non-block group (“CBG”) operation, if the receiver UE (“Rx UE”, i.e., receiving remote unit 105) successfully decodes the corresponding TB, it generates HARQ-ACK. If the Rx UE fails to decode the corresponding TB after decoding the associated physical side link control channel (“PSCCH”) targeted to the Rx UE, it generates HARQ-NACK.

[0075] Regarding feedback transmitted by one or more receiver UEs to transmitter UEs for transmissions made by the transmitter, the following two options are available:

[0076] According to SL HARQ feedback option 1, i.e., NACK only on common feedback resources, all receivers that fail to successfully decode received Physical Side Link Shared Channel (“PSSCH”) data packets will send HARQNACK on resources common to all receivers. HARQ NACK feedback is the system frame number (“SFN”) combined in the air.

[0077] According to SL HARQ feedback option 2, i.e., Rx UE-specific ACK / NACK feedback resources, each receiver that receives the PSCCH (i.e., contains side link control information (“SCI”)) and attempts to decode the corresponding PSSCH (i.e., contains SL data) should feed back HARQ ACK / NACK in the corresponding resource depending on whether they successfully decode the data packet.

[0078] Figure 2A This is a block diagram of one embodiment of a relay arrangement 200 that transmits a TB via unicast transmission according to a simple transmission known as "Scenario 1" (e.g., unicast on a first-side link interface (depicted as "Interface-1"). Arrangement 200 involves a Tx-remote UE (i.e., UE1) 201, which is a UE having some application data to be transmitted via an SL-relay UE (i.e., UE2) 203 to another remote UE shown as an Rx-remote UE (i.e., UE3) 205. UE2 203 then transmits (i.e., relays) the TB to UE3 205 via a second-side link interface (depicted as "Interface-2"). At different points in time, UE3 205 may have data to be transmitted to UE1 201 via UE2 203, and in this scenario, UE3 205 will act as a transmitter UE. Here, Figure 2A The terms and roles shown are relative to a specific data group (i.e., TB).

[0079] In some cases, more than one relay UE may be available, for example, UE2a and UE2b: "UE2" is a general representation of one or both. For multicast and broadcast communications, UE3 205 is a representation of all Rx-remote UEs. Note that in further embodiments, an Rx-remote UE may act as a relay UE to a node not in the network. Figure 2A The relay UE of another destination UE (i.e., UE4) is shown in the figure.

[0080] According to an embodiment of the first solution, it has been determined that the Tx-remote-UE 201, which is not directly accessible to the SL-relay-UE 203 or at least cannot be effectively accessed, will further determine whether it will use only one or more relays and whether the direct link to the SL-relay-UE 203 can also be used. Figure 2A An example of a relay based on the first solution is shown. Figure 3A and Figure 4A Other possible relay arrangements are described in the text.

[0081] The decision to use one of these different cases may depend on the required reliability and the CBR. For the highest level of required reliability, if the CBR is above a threshold, then [the following can be used]. Figure 4ACase 3, and if the required reliability is slightly below the highest required reliability level and the CBR is not very high, then it can be used. Figure 3A Scenario 2. Furthermore, it can be noted that sidelink UEs (peer-to-peer remote UEs and / or relay UEs) may not support all of these scenarios; therefore, they may need to agree on solutions for the possible scenarios used among them. This can also be controlled by the network using (pre)configuration or specifications.

[0082] Figure 2B A PC5 protocol stack 250 according to an embodiment of this disclosure is depicted. Although Figure 2B Tx-Remote-UE 201, SL-Relay-UE 203, and Rx-Remote-UE 205 are shown, but these represent a set of UEs that communicate peer-to-peer via PC5, and other embodiments may involve different UEs. As shown, the PC5 protocol stack includes a physical (“PHY”) layer 755 for the control plane and a media access control (“MAC”) sublayer 760, a radio link control (“RLC”) sublayer 765, a packet data convergence protocol (“PDCP”) sublayer 770, and radio resource control (“RRC”) and service data adaptation protocol (“SDAP”) layers (described as the combined element “RRC / SDAP” 775).

[0083] The AS protocol stack for the control plane in the PC5 interface consists of at least RRC, PDCP, RLC, and MAC sublayers, as well as the physical layer. The AS protocol stack for the user plane in the PC5 interface consists of at least SDAP, PDCP, RLC, and MAC sublayers, as well as the physical layer. L2 is divided into SDAP, PDCP, RLC, and MAC sublayers. L3 includes the RRC sublayer for the control plane and includes, for example, the IP layer for the user plane. L1 and L2 are referred to as "lower layers," while L3 and above (e.g., transport layer, V2X layer, application layer) are referred to as "higher layers" or "upper layers."

[0084] In some embodiments, SL-Relay-UE 203 acts as an L3 relay (also known as an IP relay). Here, communication between Tx-Remote-UE 201 (i.e., the source UE) and Rx-Remote-UE 205 (i.e., the target UE) via the L3 relay passes through two combined PC5 links: a first PC5 link (corresponding to interface 1) between Tx-Remote-UE 201 and SL-Relay-UE 203, and a second PC5 link (corresponding to interface 2) between SL-Remote-UE 203 and Rx-Remote-UE 205. In such an embodiment, the protocol stack of SL-Remote-UE 203 may include SDAP, RRC, PDCP, RLC, MAC, and PHY layers, which interact with the corresponding layers at Tx-Remote-UE 201 via interface 1 and with the corresponding layers at Rx-Remote-UE 205 via interface 2. As described in further detail below, the SL-Relay-UE 203 may employ one or more L1 and / or L2 identifiers of the Tx-Remote-UE 201 to improve communication on the sidelink relay interface.

[0085] In some embodiments, SL-Relay-UE 203 acts as an L2 relay. In some embodiments, SL-Relay-UE 203, acting as an L2 relay, performs relay functions under PDCP layer 770, such that SL-Relay-UE 203 does not perform PDCP, RRC, and SDAP functions for SL communication. In such embodiments, the protocol stack of SL-Relay-UE 203 may include RLC layer 765, MAC layer 760, and PHY layer 755 entities, which interact with the corresponding layer at Tx-Remote-UE 201 via interface 1 and with the corresponding layer at Rx-Remote-UE 205 via interface 2. However, for PDCP layer 770, RRC, and SDAP layer 775, the link endpoint is between Tx-Remote-UE 201 and Rx-Remote-UE 205.

[0086] In some embodiments, SL-Relay-UE 203 acts as an SL-Relay with HARQ functionality (also known as an amplify and forward relay). In some embodiments, the protocol stack of SL-Relay-UE 203 may have a PHY layer 755 and a HARQ entity (i.e., MAC layer 760), which interact with the corresponding layer at Tx-Remote-UE 201 via interface 1 and with the corresponding layer at Rx-Remote-UE 205 via interface 2. However, for the remaining layers, the link endpoint is located between Tx-Remote-UE 201 and Rx-Remote-UE 205.

[0087] Note that the above relay description is exemplary, and the SL-Relay-UE 203 is not limited to the relay implementation described above. Therefore, according to the solution described below, the SL-Relay-UE 203 can implement a different protocol stack and / or link endpoint than those described above.

[0088] Figure 3A This is a block diagram illustrating an embodiment of a relay arrangement 300 for transmitting a TB according to a second scenario referred to as "Scenario 2," which involves using multiple relays to send the same TB to an Rx-remote UE 205 (e.g., two or more unicast transmissions on a first side-link interface (described as "Interface 1"). Arrangement 300 relates to a Tx-remote UE (i.e., UE1) 201, which is a UE having some application data to be sent via multiple parallel relays (i.e., a first SL-relay UE (i.e., "UE2a") 301 and a second SL-relay UE ("UE2b") 303) to another remote UE shown as an Rx-remote UE (i.e., UE3) 205. At different points in time, UE3 205 may have data to be sent to UE1 201 via UE2a 301 and / or UE2b 303, and in this scenario, UE3 205 will act as a transmitter UE.

[0089] like Figure 3A As depicted, UE1 201 performs two separate unicast transmissions via interface 1: a first unicast transmission to UE2a 301 and a second unicast transmission to UE2b 303. The relay (i.e., UE2a 301 and / or UE2b 303) then transmits the TB to UE3 205 via a second side link interface (depicted as "interface 2"). Here, interface 2 can be unicast ("UC") or multicast ("GC"), as indicated by UE1 201 to UE2a 301 and UE2b 303. Alternatively, interface 2 can be broadcast ("BC"), as indicated by UE1 201 to UE2a 301 and UE2b 303. Figure 3A Only one UE3 205 is shown in the image, but it represents one of several receivers used in GC or BC scenarios.

[0090] According to an embodiment of the second solution, when using one or more relays, the behavior of all UEs (UE1, UE2, and UE3) is described as responding to: which L1 IDs and L2 IDs to use, how to receive HARQ feedback, and when Tx-Remote-UE (UE1) 201 will stop the transmission of TB.

[0091] Figure 3B The diagram assumes that... Figure 3AA block diagram of an embodiment of Table 350 showing the source L1 / L2 IDs and destination L1 / L2 IDs on interface 1 and interface 2 under a relay arrangement. Regarding which Layer 1 IDs and Layer 2 IDs are used on each interface, the source (“SRC”) L2 ID and destination (“DST”) L2 ID are as follows: Figure 3B As shown. Figure 3B The document also shows which HARQ process IDs (“HPIDs”) should be used for each interface. Note that at Tx-Remote-UE (UE1) 201, the source layer 2 ID is set to an identifier provided by the upper layer, such as as defined in TS 23.287. This field is 24 bits long. Similarly, at Tx-Remote-UE 201, the destination layer 2 ID is set to an identifier provided by the upper layer, such as as defined in TS 23.287. This field is also 24 bits long.

[0092] Regarding how to receive HARQ feedback, in one embodiment, if either the first SL-relay UE 301 or the second SL-relay UE 303 indicates an affirmative ACK, then the Tx-remote UE 201 can stop retransmissions and refresh the HARQ buffer. Furthermore, the SL-relay UE that sent the ACK feedback can take over the transmission toward UE3. For example, if only the first SL-relay UE 301 sends an ACK indication to the Tx-remote UE 201, then the first SL-relay UE 301 will also relay TB toward the Rx-remote UE 205. In this embodiment, because the second SL-relay UE 303 did not successfully receive TB, the second SL-relay UE 303 does not attempt to relay TB to the Rx-remote UE 205.

[0093] In another embodiment, Tx-Remote UE 201 may continue retransmitting to other relays (i.e., UE2b) until it also successfully receives the TB and indicates a positive ACK. At this point, Tx-Remote UE 201 stops retransmitting and refreshes the HARQ buffer. Continuing the previous example, Tx-Remote UE 201 will continue retransmitting to the second SL-Remote UE 303 until the second SL-Remote UE 303 indicates a HARQ ACK (or until the maximum number of retransmissions is reached). After sending the ACK feedback, the second SL-Remote UE 303 begins sending the TB to Rx-Remote UE 205. When Rx-Remote UE 205 successfully receives the same TB from both the first SL-Remote UE 301 and the second SL-Remote UE 303, Rx-Remote UE 205 discards the duplicate TB at the PDCP layer, for example, using the PDCP sequence number (“SN”). Therefore, the PDCP at Tx-Remote-UE 201 can send duplicate PDCP PDUs to two different RLC entities, one RLC entity for each relay / link.

[0094] For HARQ feedback, the Physical Side Link Feedback Channel (“PSFCH”) can be used Figure 3A All four links shown are shown (i.e., UE1 to UE2a, UE1 to UE2b, UE2a to UE3, and UE2b to UE3).

[0095] Figure 4A This is a block diagram illustrating one embodiment of a relay arrangement 400 for transmitting a TB according to a third case, which involves sending the same TB to an Rx-remote-UE using multiple relays and direct paths (i.e., a single multicast transmission on interface 1, referred to as "Case 3"). Arrangement 400 relates to a Tx-remote-UE (UE1) 201, which is a UE having some application data to be sent via multiple parallel relays (i.e., first SL-relay-UE 301 and second SL-relay-UE 303) and / or via a direct interface to another remote UE shown as Rx-remote-UE (UE3). The direct interface between Tx-remote-UE 201 and Rx-remote-UE 205 is referred to as "Path 1". The interface between the first SL-relay-UE 301 and Rx-remote-UE 205 is referred to as "Path 2". The interface between the second SL-relay-UE 303 and Rx-remote-UE 205 is referred to as "Path 3". At different points in time, UE3 205 may have data to be sent to UE1 201 via UE2a / b301 / 303 and / or via path 1, and in this scenario, UE3 205 will act as the transmitter UE.

[0096] like Figure 4A As shown, UE1 201 performs multicast transmission via interface 1 (including the direct interface / path 1 and links to UE2a and UE2b). Relay UEs can send TB to UE3 205 via path 2 or path 3. Note that interface 2 (i.e., the side link interface between UE2a / 2B and UE3) can be UC or GC as indicated for UE1 to UE2a / b. Alternatively, interface 2 can be BC as indicated for UE1 to UE2a / 2b. Figure 4A In the image, only one UE3 is shown, but it represents one of multiple receiver UEs in the GC or BC case.

[0097] Figure 4B It is a diagrammatic assumption Figure 4A A block diagram of an embodiment of Table 450 of source L1 / L2 IDs and destination L1 / L2 IDs on interfaces 1 and 2 of implementation method A, under a relay arrangement.

[0098] Figure 4C It is a diagrammatic assumption Figure 4A A block diagram of another embodiment of Table 475 of source L1 / L2 IDs and destination L1 / L2 IDs on interfaces 1 and 2 according to implementation method B, under the relay arrangement.

[0099] Regarding which Layer 1 IDs and Layer 2 IDs are used and how HARQ feedback is received, as a result of the handshake process, the SL relay UE (i.e., the first SL-relay-UE 301 and / or the second SL-relay-UE 303) can “adopt” the source ID of the Rx-remote-UE 205 as one of their own source identifiers, and therefore when the SRC comes from the Tx-remote-UE 201, the received transmissions using the destination identifier set to the DST of the Rx-remote-UE 205 will not be filtered out.

[0100] As described above, two HARQ feedback (“HF”) opportunities can be used in case 3, and this can be indicated by the SCI (PSCCH) on interface 1 of Tx-Remote-UE201. This can be achieved via a 1-bit flag (referred to as “Use Relay”). In one embodiment, the value TRUE = “Tx from UE1 requires relay”, and then two HF opportunities are used. Here, the value FALSE = “Tx from UE2”, and then only one HF opportunity is used (e.g., in 3GPP Rel-16).

[0101] In some embodiments, both HF opportunities are linked by an offset to physical resources (e.g., minimum PRB, subchannel) used to transmit the TB on interface 1. A first (time-based) opportunity is used by Rx-Remote UE 205 to transmit HF, and this is monitored by Tx-Remote UE 201 and the first SL-Relay UE 301 and / or the second SL-Relay UE 303. A second (time-based) opportunity is used by any of the first SL-Relay UE 301, the second SL-Relay UE 303, and / or Rx-Remote UE 205 to transmit an ACK-only feedback on a common resource, which is also linked by another offset to physical resources (e.g., minimum PRB, subchannel) used to transmit the TB on interface 1.

[0102] According to SL HARQ feedback option 1 (i.e., NACK only, common feedback resource), all receivers that fail to successfully decode a received PSSCH data packet will send a HARQ NACK on a resource common to all receivers. The HARQ NACK feedback is an air-combined SFN.

[0103] According to SL HARQ feedback option 2 (i.e., Rx UE-specific ACK / NACK feedback resource), each receiver that receives PSCCH (SCI) and attempts to decode the corresponding PSSCH (data) should provide HARQ ACK / NACK feedback in the corresponding resource depending on whether it successfully decodes the data packet.

[0104] According to the new SL HARQ feedback option (i.e., option 3 or only ACK common feedback resource), all receivers that successfully decode the received PSSCH data packets will send a HARQ ACK on a resource common to all receivers. In some embodiments, the HARQ ACK feedback is an air-combined SFN.

[0105] In some embodiments, one or more SL relay UEs that have successfully received a TB may begin transmitting / relaying the TB before the first HF opportunity. For example, if the first HF opportunity is later than the possible transmission to Rx-Remote-UE 205, one or more SL relay UEs may begin transmitting the TB received from Tx-Remote-UE 201 before the first HF opportunity. However, in other embodiments, one or more SL relay UEs that have successfully received a TB may not begin transmitting / relaying the TB before the first HF opportunity. In such embodiments, the one or more SL relay UEs may evaluate the HARQ feedback from Rx-Remote-UE 205 during the first HF opportunity and selectively transmit / relay the TB depending on whether Rx-Remote-UE 205 indicates successful reception of the TB.

[0106] As described above, two slightly different implementations of scenario 3 are possible, referred to as "Implementation A" and "Implementation B". Table 2 shows the HARQ feedback details for Implementation A, while Table 3 shows the HARQ feedback details for Implementation B.

[0107] Assume that the first SL-relay UE 301 successfully received the TB before the second SL-relay UE 303 (and signaled an ACK to the Tx-remote UE 201). Here, the second SL-relay UE 303 can continue to attempt to receive the TB from the Tx-remote UE 201, and once successful, if the Rx-remote UE 205 has not yet indicated an ACK for the same TB, it initiates its own transmission to the Rx-remote UE 205. The transmission on interface 2 is performed using SL HARQ feedback option 2, and only the Rx-remote UE 205 sends HARQ feedback (i.e., only the PSFCH is assigned to the Rx-remote UE 205 as in the case of unicast transmission using SL HARQ feedback option 2), and the second SL-relay UE 303 also monitors for feedback from the Rx-remote UE 205.

[0108] Table 2

[0109]

[0110] Table 3

[0111]

[0112]

[0113] According to another implementation of Scenario 3 (“Implementation C”), after successfully receiving the TB (on Interface 1), the Tx-Remote UE 201 and the SL Relay UE take turns sending the TB to the Rx-Remote UE 205. This can be based on a prior agreement between them. For example, the Tx-Remote UE 201 may send it on an even-numbered transmission opportunity, while (one or more) SL Relay UEs may send it on an odd-numbered transmission opportunity.

[0114] According to a further implementation of Scenario 3 (“Implementation D”), one or more SL relay UEs (i.e., the first SL relay UE 301 and / or the second SL relay UE 303) and Rx-remote UE 205 may send ACK-only HARQ feedback on common resources (i.e., according to HARQ feedback option 3, as described above), also linked by another offset to the physical resources (e.g., minimum PRB, sub-channel) for Tx-remote UE 201 to transmit TB on interface 1. Tx-remote UE 201 stops transmitting TB and clears its buffer upon receiving the ACK. If the ACK comes from one of the one or more SL relay UEs (i.e., the first SL relay UE 301 and / or the second SL relay UE 303), then the one or more SL relay UEs will take over the transmission of TB to Rx-remote UE 205, as described in any previous implementation. Here, one or more SL relay UEs may stop sending TBs only after receiving an ACK indication from Rx-remote-UE 205. Similarly, duplicates (if any) will be discarded by Rx-remote-UE 205 at the PDCP layer (or above).

[0115] According to the third solution, Tx-Remote-UE 201 can vary between different cases of transmissions to different Rx-Remote-UE(s) or even to the same Rx-Remote-UE, but for different bearers and / or QoS flows. Additionally, Tx-Remote-UE 201 can occasionally or periodically perform direct transmissions to Rx-Remote-UE 205, i.e., by setting “use-relay” to FALSE. Performing direct transmissions helps Tx-Remote-UE 201 evaluate the direct link between itself and Rx-Remote-UE 205.

[0116] Although in the above description, one or more SL relay UEs (i.e., SL-relay-UE (UE2) 203, first SL-relay-UE (UE2a) 301, and / or second SL-relay-UE (UE2b) 303) relay communication from one UE to another, in other embodiments, one or more SL relay UEs relay communication between the UE and the network.

[0117] Figure 5 A protocol stack 500 according to an embodiment of this disclosure is depicted. Although Figure 5Remote unit 105 (i.e., UEs, such as SL-relay-UE (UE2) 203, first SL-relay-UE (UE2a) 301, and / or second SL-relay-UE (UE2b) 303)), RAN node 515 (i.e., an embodiment of base station unit 121) and 5G core (“5GC”) 520 (i.e., an embodiment of mobile core network 140) are shown, but these represent a group of UEs interacting with RAN nodes and NFs (e.g., AMFs) in the core network. As depicted, protocol stack 500 includes user plane protocol stack 505 and control plane protocol stack 510. User plane protocol stack 505 includes physical (“PHY”) layer 515, media access control (“MAC”) sublayer 520, radio link control (“RLC”) sublayer 525, packet data convergence protocol (“PDCP”) sublayer 530, and service data adaptation protocol (“SDAP”) layer 535. The control plane protocol stack 510 also includes a physical layer 515, a MAC sublayer 520, an RLC sublayer 525, and a PDCP sublayer 530. The control location protocol stack 510 also includes a radio resource control (“RRC”) layer and a non-access stratum (“NAS”) layer 545.

[0118] The AS protocol stack for the control plane protocol stack 510 consists of at least RRC, PDCP, RLC, and MAC sublayers, as well as a physical layer. The AS protocol stack for the user plane protocol stack 505 consists of at least SDAP, PDCP, RLC, and MAC sublayers, as well as a physical layer. Layer 2 (“L2”) is divided into SDAP, PDCP, RLC, and MAC sublayers. Layer 3 (“L3”) includes the RRC sublayer 540 and NAS layer 545 for the control plane, and includes, for example, the Internet Protocol (“IP”) layer or PDU layer (not depicted) for the user plane. L1 and L2 are referred to as “lower layers”, such as the Physical Uplink Control Channel (“PUCCH”) and / or the Physical Uplink Shared Channel (“PUSCH”) or MAC control element (“CE”), while L3 and above (e.g., transport layer, application layer) are referred to as “higher layers” or “upper layers”, such as RRC.

[0119] Physical layer 515 provides a transport channel to MAC sublayer 520. MAC sublayer 520 provides a logical channel to RLC sublayer 525. RLC sublayer 525 provides an RLC channel to PDCP sublayer 530. PDCP sublayer 530 provides radio bearers to SDAP sublayer 535 and / or RRC layer 540. SDAP sublayer 535 provides QoS flows to mobile core network 140 (e.g., 5GC). RRC layer 540 provides the addition, modification, and release of carrier aggregation and / or dual connectivity. RRC layer 540 also manages the establishment, configuration, maintenance, and release of signaling radio bearers (“SRB”) and data radio bearers (“DRB”). In some embodiments, the RRC entity is used to detect radio link failures and recover from them.

[0120] One or more SL relay UEs that relay communication between the UE and the network can implement the PC5 protocol stack 250 on the SL interface (e.g., interface 1) and the NR protocol stack 500 on the Uu interface (e.g., interface 2).

[0121] Figure 6 User equipment device 600, which can be used for improved communication using a relay via a sidelink radio interface, is depicted according to embodiments of the present disclosure. In various embodiments, user equipment device 600 is used to implement one or more of the solutions described above. User equipment device 600 may be an embodiment of remote unit 105, Tx-remote-UE 201, SL-relay-UE 203, Rx-remote-UE 205, first SL-relay-UE 301, and / or second SL-relay-UE 303, as described above. Furthermore, user equipment device 600 may include processor 605, memory 610, input device 615, output device 620, and transceiver 625.

[0122] In some embodiments, input device 615 and output device 620 are combined into a single device, such as a touchscreen. In some embodiments, user equipment device 600 may not include any input device 615 and / or output device 620. In various embodiments, user equipment device 600 may include one or more of processor 605, memory 610, and transceiver 625, and may not include input device 615 and / or output device 620.

[0123] As shown in the figure, transceiver 625 includes at least one transmitter 630 and at least one receiver 635. In some embodiments, transceiver 625 communicates with one or more cells (or radio coverage areas) supported by one or more base station units 121. In various embodiments, transceiver 625 may operate on unlicensed spectrum. Furthermore, transceiver 625 may include multiple UE panels supporting one or more beams. Additionally, transceiver 625 may support at least one network interface 640 and / or application interface 645. One or more application interfaces 645 may support one or more APIs. One or more network interfaces 640 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 640 may be supported, as understood by those skilled in the art.

[0124] In one embodiment, processor 605 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 605 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 605 executes instructions stored in memory 610 to perform the methods and routines described herein. Processor 605 is communicatively coupled to memory 610, input device 615, output device 620, and transceiver 625.

[0125] In various embodiments, processor 605 controls user equipment device 600 to perform the UE behaviors described above. In some embodiments, processor 605 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0126] In various embodiments, the user equipment device 600 operates as a remote Tx UE. In such an embodiment, transceiver 625 can transmit data packets via a sidelink interface, wherein the data packets are sent to a first UE device (i.e., the Rx remote UE) and a second UE device (i.e., the SL relay UE). Transceiver 625 receives a first HARQ feedback from the first UE device and a second HARQ feedback from the second UE device. Here, the first HARQ feedback indicates the decoding status of the data packet at the first UE device, and the second HARQ feedback indicates the decoding status of the data packet at the second UE device. Processor 605 determines to stop data packet transmission in response to at least one of the first and second HARQ feedbacks being a positive acknowledgment.

[0127] In some embodiments, the first UE device includes at least one sidelink remote receiver device, and the second UE device includes at least one sidelink relay device. In some embodiments, a first HARQ feedback is received at a first HARQ feedback opportunity and a second HARQ feedback is received at a second HARQ feedback opportunity, wherein the second HARQ feedback opportunity occurs later than the first HARQ feedback opportunity.

[0128] In some embodiments, when a first HARQ feedback indicates unsuccessful decoding of a data packet and a second HARQ feedback indicates successful decoding, the processor 605 waits for final feedback confirmation from the second UE device before sending the next data packet. In some embodiments, the data packets sent to the second UE device have a Layer 1 destination identifier and a Layer 2 destination identifier from the first UE device.

[0129] In some embodiments, the first UE device includes a first sidelink relay device and the second UE device includes a second sidelink relay device. In some embodiments, the processor 605 determines the CBR of the direct link to the sidelink remote receiver device and further determines the desired reliability level of the data packets. In such embodiments, the processor 605 transmits to the first UE device and the second UE device in response to the CBR being below a threshold limit and the desired reliability level being below a threshold level.

[0130] In some embodiments, the second HARQ feedback is a positive-only acknowledgment feedback sent on a public resource. In some embodiments, the processor 605 determines the desired reliability level of the data packet. In such an embodiment, the processor 605 sends a packet to both the first UE device and the second UE device in response to the desired reliability level being higher than a threshold level.

[0131] In some embodiments, processor 605 determines the CBR of the link to the first UE device (e.g., a direct link to an Rx remote UE). In such embodiments, processor 605 transmits to both the first and second UE devices in response to a CBR exceeding a threshold limit. In some embodiments, processor 605 determines the number of second UE devices to which data packets should be transmitted, based on the CBR and the desired reliability level of the data packets. In some embodiments, processor 605 implements a PDCP entity that replicates data packets to a first RLC entity and a second RLC entity, the first RLC entity being associated with an interface to the first UE device and the second RLC entity being associated with an interface to the second UE device.

[0132] In various embodiments, the user equipment device 600 operates as a relay UE. In such an embodiment, transceiver 625 may receive data packets from a first UE device (i.e., a Tx remote UE) via a first sidelink interface in response to processor 605 successfully decoding data packets, and send a first HARQ feedback to the first UE device (e.g., via the first sidelink interface). Transceiver 625 transmits data packets to a second UE device (i.e., an Rx remote UE) via a second sidelink interface.

[0133] In some embodiments, the transmission of a data packet occurs in response to receiving a negative HARQ feedback from the second UE device. In some embodiments, the transceiver 625 sends a final HARQ feedback to the first UE device in response to receiving a positive HARQ feedback for the data packet from the second UE device.

[0134] In some embodiments, the received data packets have Layer 1 and Layer 2 source identifiers of the first UE device and Layer 1 and Layer 2 destination identifiers of the second UE device. In such embodiments, sending data packets to the second UE device includes reusing the Layer 1 and Layer 2 source identifiers and Layer 1 and Layer 2 destination identifiers of the received data packets.

[0135] In some embodiments, the processor 605 reuses the HARQ process identifier of the first UE device, wherein the received data packet has a first RV value. In such an embodiment, transmitting the data packet includes generating a new HARQ retransmission packet corresponding to an RV value that is incremented by the next RV value of the data packet.

[0136] In some embodiments, the received data packets have layer 1 and layer 2 source identifiers of a first UE device and layer 1 and layer 2 destination identifiers of a second UE device. In such an embodiment, sending the data packets to the second UE device includes using the layer 1 and layer 2 source identifiers of the device 600 and reusing the layer 1 and layer 2 destination identifiers of the received data packets, wherein the layer 1 and layer 2 source identifiers of the device 600 are different from the layer 1 and layer 2 source identifiers contained in the received data packets.

[0137] In some embodiments, the received data packets have a first RV value. In such embodiments, transmitting data packets further includes a HARQ retransmission packet that increments the RV value and generates a data packet corresponding to the next RV value. In some embodiments, the processor 605 employs the Layer 1 and Layer 2 source identifiers of the second UE device.

[0138] Note that in the above description, the Rx remote UE can instead be a RAN node or other network entity, whereby the SL relay UE communicates with the Tx remote UE using a side link and relays communication between the Tx remote UE and, for example, a RAN node.

[0139] In one embodiment, memory 610 is a computer-readable storage medium. In some embodiments, memory 610 includes volatile computer storage media. For example, memory 610 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 610 includes non-volatile computer storage media. For example, memory 610 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 610 includes both volatile and non-volatile computer storage media.

[0140] In some embodiments, memory 610 stores data related to improved communication using relay over a sidelink radio interface. For example, memory 610 may store various parameters, panel / beam configurations, resource allocations, strategies, etc., as described above. In some embodiments, memory 610 also stores program code and related data, such as an operating system or other controller algorithms running on device 600.

[0141] In one embodiment, input device 615 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 615 may be integrated with output device 620, such as a touchscreen or similar touch-sensitive display. In some embodiments, input device 615 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0142] In one embodiment, output device 620 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 620 may include, but is not limited to, a liquid crystal display (“LCD”), a light-emitting diode (“LED”) display, an organic LED (“OLED”) display, a projector, or a similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, output device 620 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., that is separate from but communicatively coupled to the rest of user equipment device 600. Furthermore, output device 620 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0143] In some embodiments, output device 620 includes one or more speakers for generating sound. For example, output device 620 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 620 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 620 may be integrated with input device 615. For example, input device 615 and output device 620 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 620 may be located near input device 615.

[0144] Transceiver 625 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 625 operates under the control of processor 605 to transmit and receive messages, data, and other signals. For example, processor 605 may selectively activate transceiver 625 (or a portion thereof) at specific times to transmit and receive messages.

[0145] Transceiver 625 includes at least a transmitter 630 and at least one receiver 635. One or more transmitters 630 can be used to provide UL communication signals to base station unit 121, such as the UL transmissions described herein. Similarly, one or more receivers 635 can be used to receive DL communication signals from base station unit 121, as described herein. Although only one transmitter 630 and one receiver 635 are illustrated, user equipment device 600 can have any suitable number of transmitters 630 and receivers 635. Furthermore, the transmitter(s) 630 and receiver(s) 635 can be of any suitable type. In one embodiment, transceiver 625 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0146] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some transceivers 625, transmitters 630, and receivers 635 may be implemented as physically separate components accessing shared hardware and / or software resources (e.g., network interface 640).

[0147] In various embodiments, one or more transmitters 630 and / or one or more receivers 635 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (“ASIC”), or other types of hardware components. In some embodiments, one or more transmitters 630 and / or one or more receivers 635 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as a network interface 640 or other hardware components / circuits, may be integrated with any number of transmitters 630 and / or receivers 635 into a single chip. In such embodiments, transmitters 630 and receivers 635 may be logically configured as transceivers 625 using one or more common control signals, or logically configured as modular transmitters 630 and receivers 635 implemented in the same hardware chip or multi-chip module.

[0148] Figure 7 A network device 700, which can be used to improve communication using relays on a sidelink radio interface, is depicted according to embodiments of the present disclosure. In one embodiment, the network device 700 may be an implementation of a RAN node, such as base station unit 121 and / or RAN node 210, as described above. Furthermore, the base station network device 700 may include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725.

[0149] In some embodiments, input device 715 and output device 720 are combined into a single device, such as a touchscreen. In some embodiments, network device 700 may not include any input device 715 and / or output device 720. In various embodiments, network device 700 may include one or more of processor 705, memory 710, and transceiver 725, and may not include input device 715 and / or output device 720.

[0150] As depicted, transceiver 725 includes at least one transmitter 730 and at least one receiver 735. Here, transceiver 725 communicates with one or more remote units 105. Additionally, transceiver 725 may support at least one network interface 740 and / or application interface 745. The application interface(s) 745 may support one or more APIs. The network interface(s) 740 may support 3GPP reference points such as Uu, N1, N2, and N3. Other network interfaces 740 may be supported, as will be understood by those skilled in the art.

[0151] In one embodiment, processor 705 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 705 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, processor 705 executes instructions stored in memory 710 to perform the methods and routines described herein. Processor 705 is communicatively coupled to memory 710, input device 715, output device 720, and transceiver 725.

[0152] In various embodiments, network device 700 is a RAN node (e.g., gNB) communicating with one or more UEs, as described herein. In such embodiments, processor 705 controls network device 700 to perform the RAN behaviors described above. When operating as a RAN node, processor 705 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0153] In various embodiments, processor 705 controls transceiver 725 to communicate with the UE via SL-relay-UE. In one embodiment, SL-relay-UE uses a side link to communicate with Tx-remote-UE and relays communication between Tx-remote-UE and device 700. In another embodiment, SL-relay-UE uses a side link to communicate with Rx-remote-UE and relays communication between Rx-remote-UE and device 700.

[0154] In one embodiment, memory 710 is a computer-readable storage medium. In some embodiments, memory 710 includes volatile computer storage media. For example, memory 710 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 710 includes non-volatile computer storage media. For example, memory 710 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 710 includes both volatile and non-volatile computer storage media.

[0155] In some embodiments, memory 710 stores data related to improved communication using a sidelink radio interface. For example, memory 710 may store parameters, configurations, resource allocations, policies, etc., as described above. In some embodiments, memory 710 also stores program code and related data, such as an operating system or other controller algorithms operating on device 700.

[0156] In one embodiment, input device 715 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 715 may be integrated with output device 720, such as a touchscreen or similar touch-sensitive display. In some embodiments, input device 715 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0157] In one embodiment, output device 720 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 720 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 720 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 720 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., that is separate from but communicatively coupled to the rest of network device 700. Furthermore, output device 720 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0158] In some embodiments, output device 720 includes one or more speakers for generating sound. For example, output device 720 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 720 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 720 may be integrated with input device 715. For example, input device 715 and output device 720 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 720 may be located near input device 715.

[0159] Transceiver 725 includes at least a transmitter 730 and at least one receiver 735. One or more transmitters 730 can be used to communicate with a UE, as described herein. Similarly, one or more receivers 735 can be used to communicate with network functions in a PLMN and / or RAN, as described herein. Although only one transmitter 730 and one receiver 735 are shown, the network device 700 can have any suitable number of transmitters 730 and receivers 735. Furthermore, the transmitter(s) 730 and receiver(s) 735 can be of any suitable type.

[0160] Figure 8An embodiment of a method 800 for improving communication using a relay on a sidelink radio interface, according to embodiments of the present disclosure, is depicted. In various embodiments, method 800 is performed by a sidelink transmitter UE device in a mobile communication network, such as the remote unit 105, UE1 201, UE3 205, and / or user equipment device 600 described above. In some embodiments, method 800 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0161] Method 800 begins and transmits data packets 805 via a sidelink interface, wherein the data packets are sent to a first UE device (i.e., at least one Rx remote UE) and a second UE device (i.e., at least one SL relay UE). Method 800 includes receiving 810 a first HARQ feedback from the first UE device, the first HARQ feedback indicating the decoding status of the data packets at the first UE device. Method 800 includes receiving 815 a second HARQ feedback from the second UE device, the second HARQ feedback indicating the decoding status of the data packets at the second UE device. Method 800 includes determining 820 to stop data packet transmission when at least one of the first and second HARQ feedbacks is a positive acknowledgment. Method 800 ends.

[0162] Figure 9 An embodiment of a method 900 for improving communication using a relay on a sidelink radio interface, according to embodiments of the present disclosure, is depicted. In various embodiments, method 900 is performed by a sidelink relay UE device in a mobile communication network, such as remote unit 105, UE2203, UE2a 301, UE2b 303, and / or user equipment device 600, as described above. In some embodiments, method 900 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0163] Method 900 begins and receives a data packet 905 from a first UE device (i.e., a Tx remote UE) via a first sidelink interface. Method 900 includes sending a first HARQ feedback 910 to the first UE device (e.g., via the first sidelink interface) in response to successful decoding of the data packet. Method 900 includes sending a data packet to a second UE device (i.e., an Rx remote UE) via a second sidelink interface. Method 900 ends.

[0164] This document discloses a first apparatus for improved relay communication used on a sidelink radio interface according to embodiments of the present disclosure. The first apparatus may be implemented by a transmission remote UE apparatus in a mobile communication network, such as the remote unit 105 described above, Tx-remote-UE (i.e., UE1) 201, and / or user equipment apparatus 600. The first apparatus includes a processor and a transceiver for transmitting data packets via a sidelink interface, wherein data packets are transmitted to a first UE device (i.e., Rx remote UE) and a second UE device (i.e., SL relay UE). The transceiver receives a first HARQ feedback from the first UE device and a second HARQ feedback from the second UE device. Here, the first HARQ feedback indicates the decoding status of the data packet at the first UE device, and the second HARQ feedback indicates the decoding status of the data packet at the second UE device. The processor determines to stop the transmission of the data packet in response to at least one of the first and second HARQ feedbacks being a positive acknowledgment.

[0165] In some embodiments, the first UE device includes at least one sidelink remote receiver device, and the second UE device includes at least one sidelink relay device. In some embodiments, the first HARQ feedback is received at the first HARQ feedback opportunity, and the second HARQ feedback is received at a second HARQ feedback opportunity that is later in time than the first HARQ feedback opportunity.

[0166] In some embodiments, when a first HARQ feedback indicates unsuccessful decoding of a data packet and a second HARQ feedback indicates successful decoding of a data packet, the processor waits for final feedback confirmation from the second UE device before sending the next data packet. In some embodiments, the data packets sent to the second UE device have a Layer 1 destination identifier and a Layer 2 destination identifier from the first UE device.

[0167] In some embodiments, the first UE device includes a first sidelink relay device and the second UE device includes a second sidelink relay device. In some embodiments, the processor determines the CBR of the direct link to the sidelink remote receiver device and further determines the desired reliability level of the data packets. In such embodiments, the processor transmits to the first UE device and the second UE device in response to both the CBR being below a threshold limit and the desired reliability level being below a threshold level.

[0168] In some embodiments, the second HARQ feedback is a positive-only acknowledgment feedback sent on a common resource. In some embodiments, the processor determines the required reliability level for the data packet. In such embodiments, the processor sends data to both the first UE device and the second UE device in response to the required reliability level being higher than a threshold level.

[0169] In some embodiments, the processor determines the CBR of the link to the first UE device (e.g., a direct link to an Rx remote UE). In such embodiments, the processor transmits to both the first and second UE devices in response to the CBR exceeding a threshold limit. In some embodiments, based on the CBR and the required reliability level of the data packets, the processor determines the number of second UE devices to which it will transmit data packets. In some embodiments, the processor implements a PDCP entity that replicates data packets to a first RLC entity and a second RLC entity, the first RLC entity being associated with an interface to the first UE device and the second RLC entity being associated with an interface to the second UE device.

[0170] This document discloses a first method for improved relay communication used on a sidelink radio interface according to embodiments of the present disclosure. The first method can be performed by a transmission remote UE device in a mobile communication network, such as the remote unit 105 described above, Tx-remote-UE (i.e., UE1) 201, and / or user equipment device 600. The first method includes transmitting data packets via the sidelink interface, wherein the data packets are sent to a first UE device (i.e., Rx remote UE) and a second UE device (i.e., SL relay UE). The first method includes receiving a first HARQ feedback from the first UE device and receiving a second HARQ feedback from the second UE device. Here, the first HARQ feedback indicates the decoding status of the data packet at the first UE device, and the second HARQ feedback indicates the decoding status of the data packet at the second UE device. The first method includes determining to stop the transmission of the data packet in response to at least one of the first and second HARQ feedbacks being a positive confirmation.

[0171] In some embodiments, the first UE device includes at least one sidelink remote receiver device, and the second UE device includes at least one sidelink relay device. In some embodiments, the first HARQ feedback is received at the first HARQ feedback opportunity, and the second HARQ feedback is received at a second HARQ feedback opportunity that occurs later than the first HARQ feedback opportunity.

[0172] In some embodiments, the first method includes waiting for final feedback confirmation from a second UE device before sending the next data packet when a first HARQ feedback indicates unsuccessful decoding of a data packet and a second HARQ feedback indicates successful decoding of a data packet. In some embodiments, the data packets sent to the second UE device have a Layer 1 destination identifier and a Layer 2 destination identifier from the first UE device.

[0173] In some embodiments, the first UE device includes a first sidelink relay device and the second UE device includes a second sidelink relay device. In some embodiments, the first method includes determining the critical link ratio (CBR) of the direct link to the sidelink remote receiver device and determining the required reliability level for data packets. In such embodiments, the first method further includes transmitting to the first UE device and the second UE device in response to both the CBR being below a threshold limit and the required reliability level being below a threshold level.

[0174] In some embodiments, the second HARQ feedback is a positive-only acknowledgment feedback sent on public resources. In some embodiments, the first method includes determining a required reliability level for the data packet. In such embodiments, the first method further includes sending data to a first UE device and a second UE device in response to the required reliability level being higher than a threshold level.

[0175] In some embodiments, the first method includes determining the CBR of the link to a first UE device (e.g., a direct link to an Rx remote UE). In such embodiments, the first method also includes transmitting to a first UE device and a second UE device in response to the CBR exceeding a threshold limit. In some embodiments, based on the CBR and the required reliability level of the data packets, the first method includes determining the number of second UE devices to which data packets are to be transmitted. In some embodiments, the first method includes implementing a PDCP entity that replicates data packets to a first RLC entity and a second RLC entity, the first RLC entity being associated with an interface to the first UE device and the second RLC entity being associated with an interface to the second UE device.

[0176] This document discloses a second apparatus for improved relay communication used on a sidelink radio interface, according to embodiments of the present disclosure. The second apparatus may be implemented by a sidelink relay UE device in a mobile communication network, such as the remote unit 105, SL-relay-UE (UE2) 203, first SL-relay-UE (UE2a) 301, second SL-relay-UE (UE2b) 303, and / or user equipment device 600 as described above. The second apparatus includes a processor and a transceiver that receives data packets from the first UE device (i.e., Tx remote UE) via a first sidelink interface and sends a first HARQ feedback to the first UE device in response to the processor successfully decoding the data packets. The transceiver transmits data packets to the second UE device (i.e., Rx remote UE) via a second sidelink interface.

[0177] In some embodiments, the transmission of a data packet occurs in response to receiving a negative HARQ feedback from the second UE device. In some embodiments, the transceiver sends a final HARQ feedback to the first UE device in response to receiving a positive HARQ feedback for the data packet from the second UE device.

[0178] In some embodiments, the received data packet has both a Layer 1 and a Layer 2 source identifier of the first UE device and a Layer 1 and a Layer 2 destination identifier of the second UE device. In such an embodiment, sending the data packet to the second UE device includes reusing the Layer 1 and Layer 2 source identifiers and the Layer 1 and Layer 2 destination identifiers of the received data packet.

[0179] In some embodiments, the processor reuses the HARQ process identifier of the first UE device, wherein the received data packet has a first RV value. In such an embodiment, transmitting the data packet includes generating a new HARQ retransmission packet corresponding to an RV value incremented by the next RV value of the data packet.

[0180] In some embodiments, the received data packet has both a Layer 1 and a Layer 2 source identifier of the first UE device and a Layer 1 and a Layer 2 destination identifier of the second UE device. In such an embodiment, sending the data packet to the second UE device includes using the Layer 1 and Layer 2 source identifier of the device and reusing the Layer 1 and Layer 2 destination identifiers of the received data packet.

[0181] In some embodiments, the received data packet has a first RV value. In such embodiments, transmitting the data packet further includes a HARQ retransmission packet that increments the RV value and generates a data packet corresponding to the next RV value. In some embodiments, the processor employs the Layer 1 and Layer 2 source identifiers of the second UE device.

[0182] This document discloses a second method for improved relay communication used on a sidelink radio interface, according to embodiments of the present disclosure. The second method can be performed by a sidelink relay UE device in a mobile communication network, such as remote unit 105, SL-relay-UE (UE2) 203, first SL-relay-UE (UE2a) 301, second SL-relay-UE (UE2b) 303, and / or user equipment device 600 as described above. The second method includes receiving data packets from a first UE device (i.e., a Tx remote UE) via a first sidelink interface; sending a first hybrid HARQ feedback to the first UE device in response to successful decoding of the data packets; and sending the data packets to a second UE device (i.e., an Rx remote UE) via a second sidelink interface.

[0183] In some embodiments, the transmission of a data packet occurs in response to receiving a negative HARQ feedback from the second UE device. In some embodiments, the transceiver sends a final HARQ feedback to the first UE device in response to receiving a positive HARQ feedback for the data packet from the second UE device.

[0184] In some embodiments, the received data packet has both a Layer 1 and a Layer 2 source identifier of the first UE device and a Layer 1 and a Layer 2 destination identifier of the second UE device. In such an embodiment, sending the data packet to the second UE device includes reusing the Layer 1 and Layer 2 source identifiers and the Layer 1 and Layer 2 destination identifiers of the received data packet.

[0185] In some embodiments, the second method includes reusing the HARQ process identifier of the first UE device, wherein the received data packet has a first RV value. In such embodiments, sending the data packet includes generating a new HARQ retransmission packet with an RV value incremented to the next RV value of the data packet.

[0186] In some embodiments, the received data packets have both Layer 1 and Layer 2 source identifiers of the first UE device and Layer 1 and Layer 2 destination identifiers of the second UE device. In such embodiments, sending data packets to the second UE device includes using the Layer 1 and Layer 2 source identifiers of the sidelink relay UE device and reusing the Layer 1 and Layer 2 destination identifiers of the received data packets.

[0187] In some embodiments, the received data packet has a first RV value. In such embodiments, sending the data packet further includes a HARQ retransmission packet that increments the RV value and generates a data packet corresponding to the next RV value. In some embodiments, the second method includes the sidelink relay UE device employing the Layer 1 and Layer 2 source identifiers of the second UE device.

[0188] Other specific embodiments may be implemented. The described embodiments should be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All variations falling within the meaning and scope of the equivalents of the claims should be included within their scope.

Claims

1. A User Equipment (UE) device, comprising: Memory; and A processor, coupled to the memory, configured to enable the device; Data packets are transmitted via a sidelink interface, wherein the data packets are sent to a first UE and a second UE, wherein the first UE includes at least one sidelink remote receiver device and the second UE includes at least one sidelink relay device; The first UE receives a first Hybrid Automatic Repeat Request (HARQ) feedback, the first HARQ feedback indicating the decoding status of the data packet at the first UE; Receive a second HARQ feedback from the second UE, the second HARQ feedback indicating the decoding status of the data packet at the second UE; and The transmission of the data packet is stopped in response to at least one of the first HARQ feedback and the second HARQ feedback being a positive confirmation.

2. The apparatus according to claim 1, wherein, The first HARQ feedback is received on the first HARQ feedback opportunity, and the second HARQ feedback is received on the second HARQ feedback opportunity, which occurs later in time than the first HARQ feedback opportunity.

3. The apparatus according to claim 1, wherein, When the first HARQ feedback indicates that the data packet was not successfully decoded and the second HARQ feedback indicates that the data packet was successfully decoded, the processor is configured to make the device wait for final feedback confirmation from the second UE before sending the next data packet.

4. The apparatus according to claim 1, wherein, The data packets sent to the second UE have the first UE's Layer 1 destination identifier and Layer 2 destination identifier.

5. The apparatus according to claim 1, wherein, The first UE includes a first sidelink relay device and the second UE includes a second sidelink relay device.

6. The apparatus according to claim 5, wherein, The processor is configured to cause the device to: Determine the channel busy rate (CBR) of the direct link to the sidelink remote receiver device, and further determine the required reliability level of the data packets. Transmission is sent to the first UE and the second UE in response to both the CBR being below a threshold limit and the required reliability level being below a threshold level.

7. The apparatus according to claim 1, wherein, The second HARQ feedback is a positive-only confirmation feedback sent on a public resource.

8. The apparatus according to claim 1, wherein, The processor is configured to cause the device to: Determine the required reliability level for the data packets, and Transmission is sent to the first UE and the second UE in response to the required reliability level being higher than a threshold level.

9. The apparatus according to claim 1, wherein, The processor is configured to cause the device to: Determine the channel busy rate (CBR) of the link to the first UE, and In response to the CBR exceeding the threshold limit, transmission is sent to the first UE and the second UE.

10. The apparatus according to claim 1, wherein, The processor is configured to enable the device to determine the number of second UEs that will transmit the data packets based on the channel busy rate (CBR) and the required reliability level of the data packets.

11. The apparatus according to claim 1, wherein, The processor is configured to enable the device to implement a Packet Data Convergence Protocol (PDCP) entity that replicates the data packets to a first Radio Link Control (RLC) entity and a second RLC entity, the first RLC entity being associated with an interface to the first UE and the second RLC entity being associated with an interface to the second UE.

12. A sidelink relay device, comprising: Memory; as well as A processor, coupled to the memory, is configured to cause the device to: Data packets are received from a first user equipment (UE) via a first side link interface, wherein the data packets are also transmitted from the first UE to a second UE; In response to successfully decoding the data packet, a first Hybrid Automatic Repeat Request (HARQ) feedback is sent to the first UE; as well as In response to receiving a negative HARQ feedback for the data packet from the second UE, the data packet is sent to the second UE via the second side link interface.

13. The apparatus according to claim 12, wherein, The received data packet has both a Layer 1 and a Layer 2 source identifier of the first UE and a Layer 1 and a Layer 2 destination identifier of the second UE, wherein, when the data packet is sent to the second UE, the processor is configured to cause the device to reuse the Layer 1 and Layer 2 source identifiers and the Layer 1 and Layer 2 destination identifiers of the received data packet.

14. The apparatus according to claim 12, wherein, The processor is configured to cause the device to reuse the HARQ process identifier of the first UE, wherein the received data packet has a first redundancy version RV value, and wherein, when transmitting the data packet, the processor is further configured to cause the device to generate a new HARQ retransmission packet corresponding to an RV value that is an increment of the next RV value for the data packet.

15. The apparatus according to claim 12, wherein, in, The received data packet has both the Layer 1 and Layer 2 source identifiers of the first UE and the Layer 1 and Layer 2 destination identifiers of the second UE, wherein, when the data packet is sent to the second UE, the processor is configured to cause the device to: use the Layer 1 and Layer 2 source identifiers of the device and reuse the Layer 1 and Layer 2 destination identifiers of the received data packet.

16. The apparatus according to claim 12, wherein, The received data packet has a first redundancy version RV value, wherein, when the data packet is sent, the processor is further configured to cause the device to increment the RV value and generate a HARQ retransmission packet for the data packet corresponding to the next RV value.

17. The apparatus according to claim 12, wherein, The processor is configured to cause the device to send a final HARQ feedback to the first UE in response to receiving a positive HARQ feedback for the data packet from the second UE.

18. The apparatus according to claim 12, wherein, The processor is configured to cause the device to adopt the Layer 1 and Layer 2 source identifiers of the second UE.

Images