Method and apparatus for HARQ buffer management for sidelink configuration grant

Abstract

Methods, apparatus, and systems for managing a hybrid automatic repeat request buffer for a sidelink configuration grant are disclosed. A method (400) includes transmitting (405) a transport block ("TB") from a transmitting user equipment ("UE") device to a receiving UE device using configuration grant resources during a period of a sidelink configuration grant. A method (400) includes receiving (410) feedback from the receiving UE device on a physical sidelink feedback channel ("PSFCH") at the transmitting UE device during the period indicating whether the TB was successfully received. A method (400) includes, in response to the feedback indicating that the receiving UE device successfully received the TB, ceasing (415) transmission of the TB on subsequent configuration grant resources of the sidelink configuration grant within the same period.

Description

Technical Field

[0001] The subject matter disclosed herein relates generally to wireless communications and, more particularly, to managing a hybrid automatic repeat request buffer for sidelink configuration grants. Background Art

[0002] In some wireless communication systems, a Type 1 or Type 2 Configuration Grant ("CG") provides a set of resources for multiple sidelink ("SL") transmissions in a periodic manner. For Type 1 CG and Type 2 CG, the user equipment ("UE") implementation determines whether the SL grant is for initial transmission or retransmission within the periodicity. According to the 3GPP protocol, a transport block ("TB") stored in the SL process that has been transmitted in the CG resources of one cycle cannot use the CG resources of the next cycle associated with the same hybrid automatic repeat request ("HARQ") process. Summary of the invention

[0003] Methods, devices, and systems for managing a HARQ buffer for a sidelink configuration grant are disclosed. In one embodiment, a physical sidelink feedback channel ("PSFCH") determines whether to retransmit a pending TB on a next CG resource within a cycle. In one embodiment, if the PSFCH is NACK, the TB is retransmitted on the next CG resource. Otherwise, in one embodiment, if the PSFCH is ACK, further (re)transmission of the TB within the cycle is stopped, and the CG resources are used for retransmission of another pending TB of another HARQ process and / or the remaining CG resources are used for transmission of another TB. If the PSFCH has not been received or there is a discontinuous transmission ("DTX") without transmitting / receiving feedback, the TB is retransmitted on the next CG resource within the cycle and / or the buffer contents are saved but not transmitted.

[0004] In one embodiment, the subject matter described herein is directed to a UE that starts a timer after having sent a negative acknowledgement ("NACK") to a gNB on a physical uplink control channel ("PUCCH") for transmission of a TB on a CG resource within a period. While the timer is running, the UE shall not generate a new TB for a HARQ process at the next CG resource of the SL CG of the same HARQ process.

[0005] According to one implementation of the embodiment, for the case where the timer is running, the UE shall retransmit the pending TBs in the HARQ buffer on the subsequent CG resources associated with the same HARQ process. If the timer is not running at the next CG resource of the SL CG of the same HARQ process, the UE shall treat the new data indicator ("NDI") as being toggled for the HARQ process and generate a new TB if SL data is available for transmission. The timer is stopped upon receipt of a SL grant indicating a new transmission for the same HARQ process. For the case where the SL grant indicates a retransmission of the same HARQ process (e.g., the NDI is non-toggled, or the radio network temporary identifier ("RNTI") indicates that this is a retransmission), the timer may be started / restarted.

[0006] In another embodiment, a new timer is started at the initial transmission of the TB. The transmission may be an initial transmission on dynamically scheduled SL resources or on configured granted resources. The timer value is set so that it allows a certain number of retransmissions of the TB, which are still within the PDB of the TB. After receiving an ACK for the (re)transmission of the TB, the UE considers the timer to have expired, for example, no further retransmissions are required. Reception of a SL grant (DCI) indicating a new transmission for the same HARQ process stops the timer, for example, the corresponding SL transmission will (re)start the timer. After the timer expires, the UE can refresh the HARQ buffer of the associated HARQ process and consider the HARQ process to be available for another SL transmission, for example, the UE can generate a new TB and store it for transmission in the HARQ buffer / process. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more particular description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only some embodiments and, therefore, should not be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1A is a schematic block diagram illustrating one embodiment of a wireless communication system for managing a hybrid automatic repeat request buffer for a sidelink configuration grant;

[0009] Figure 1B is an example description of a sidelink configuration grant for managing a hybrid automatic repeat request buffer for a sidelink configuration grant;

[0010] Figure 2 is a block diagram illustrating one embodiment of a user equipment device that may be used to manage a hybrid automatic repeat request buffer for a sidelink configuration grant;

[0011] Figure 3 is a block diagram illustrating one embodiment of a network equipment device that may be used to manage a hybrid automatic repeat request buffer for a sidelink configuration grant; and

[0012] Figure 4 is a flow chart illustrating one embodiment of a method for managing a hybrid automatic repeat request buffer for a sidelink configuration grant. DETAILED DESCRIPTION

[0013] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as systems, devices, methods or program products. Thus, the embodiments may take the form of fully hardware embodiments, fully software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0014] For example, the disclosed embodiments may be implemented as hardware circuits including custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors or other discrete components such as logic chips, transistors, etc. The disclosed embodiments may 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 be organized, for example, as an object, procedure, or function.

[0015] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing 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-transmitting. The storage device may not embody a signal. In one embodiment, the storage device employs only a signal for accessing the code.

[0016] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0017] More specific examples of storage devices (a non-exhaustive list) would include the following: an electrical connection with one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0018] The code for performing the operations of the embodiments may be any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​(e.g., Python, Ruby, Java, Smalltalk, C++, etc.) as well as conventional procedural programming languages ​​(e.g., "C" programming language, etc.) and / or machine languages ​​(e.g., assembly language). The code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone 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 scenario, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0020] References to "one embodiment", "embodiment" or similar language throughout this specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment. Therefore, unless otherwise expressly specified, the phrases "in one embodiment", "in an embodiment" and similar language throughout this specification may but may not all refer to the same embodiment, but mean "one or more but not all embodiments". Unless otherwise expressly specified, the terms "comprising", "including", "having" and their variants mean "including but not limited to". Unless otherwise expressly specified, the list of items listed does not imply that any or all items are mutually exclusive. Unless otherwise expressly specified, the terms "a / an" and "described" also refer to "one or more".

[0021] As used herein, a list with 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 of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C and does not include a combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes one and only one of A, B, or C, and does not include a combination of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C, and combinations thereof” 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.

[0022] The following describes various aspects of the embodiments with reference to schematic flow charts and / or schematic block diagrams of the methods, devices, systems, and program products according to the embodiments. It should be understood that each frame of the schematic flow chart and / or schematic block diagram, and the combination of frames in the schematic flow chart and / or schematic block diagram can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, so that instructions executed by the processor of the computer or other programmable data processing device generate components for implementing the functions / actions specified in the flow chart and / or block diagram.

[0023] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus or other apparatus to function in a specific manner so that the instructions stored in the storage device produce an article of manufacture containing instructions for implementing the functions / actions specified in the flowchart and / or block diagram.

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

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

[0026] It should also be noted that in some alternative implementations, the functions mentioned in the blocks may not occur in the order mentioned in the drawings. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. Other steps and methods are conceivable that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated drawings.

[0027] Although various arrow types and line types may be used in flow charts and / or block diagrams, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other joints may be used to separately indicate the logical flow of the depicted embodiments. For example, arrows may indicate waiting or monitoring cycles of unspecified duration between the listed steps of the depicted embodiments. It should also be noted that each box in the block diagram and / or flow chart and the combination of boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs a specified function or action or a combination of dedicated hardware and code.

[0028] The description of the elements in each figure can refer to the elements of the previous figure. In all figures, the same numerals refer to the same elements, including alternative embodiments of the same elements.

[0029] In general, the present disclosure describes systems, methods, and apparatus for managing HARQ buffers for sidelink configuration grants. Based on the currently specified behavior, it is unclear when the UE refreshes the HARQ transmission buffer for the SL HARQ process and when the UE generates a new TB for the HARQ process, particularly for the case of SL CG. For CG types 1 and 2, whether the SL grant is used for initial transmission or retransmission within a periodicity depends on the UE implementation. According to the 3GPP protocol, TBs stored in the SL process that have been transmitted in the CG resources of one cycle cannot use the CG resources of the next cycle associated with the same HARQ process.

[0030] For example, if a TB has been transmitted from a SL process associated with HARQ process ID=1 in the first cycle of the CG, the TB may not be retransmitted in the second cycle of the CG of the same SL process. Therefore, the Tx UE may replace the old TB with the new TB in the HARQ Tx buffer of the SL process associated with the same HARQ process ID before the next CG resource associated with the HARQ process ID, or the Tx UE may keep the pending TB in the HARQ buffer for possible retransmission, e.g., dynamically scheduled by the gNB, and ignore the next CG resource associated with the HARQ process ID (skipping the allocated CG resource for SL transmission).

[0031] Figure 1A A wireless communication system 100 is depicted that supports HARQ buffer management for SL configuration authorization according to an embodiment of the present disclosure. 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 be composed of a base unit 110, with which the remote unit 105 communicates using a wireless communication link 115. Although in Figure 1A A specific number of remote units 105, base units 110, wireless communication links 115, RAN 120, and mobile core networks 140 are depicted in the figure, but those skilled in the art will recognize that any number of remote units 105, base units 110, wireless communication links 115, RAN 120, and mobile core networks 140 may be included in the wireless communication system 100.

[0032] In one embodiment, the RAN 120 complies with the 5G system specified in the 3GPP specification. In another embodiment, the RAN 120 complies with the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication network, such as WiMAX, among other networks. The present disclosure is not intended to be limited to implementations of any particular wireless communication system architecture or protocol.

[0033] In one embodiment, the remote unit 105 may include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (“PDA”), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a game console, a security system (including a security camera), a vehicle onboard computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, etc. In addition, the remote unit 105 may be referred to as a UE, a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit (“WTRU”), a device, or other terms used in the art.

[0034] The remote unit 105 may communicate directly with one or more of the base units 110 in the RAN 120 via uplink ("UL") and downlink ("DL") communication signals. In addition, the UL and DL communication signals may be carried over the wireless communication links 115. Here, the RAN 120 is an intermediate network that provides the remote unit 105 with access to the mobile core network 140.

[0035] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection with the mobile core network 140. For example, an application 107 in the remote unit 105 (e.g., a web browser, a media client, a phone / VoIP application) may trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session. It should be noted that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may simultaneously have at least one PDU session for communicating with the packet data network 150 and at least one PDU session for communicating with another data network (not shown).

[0036] The base units 110 may be distributed over a geographic area. In some embodiments, the base units 110 may also be referred to as access terminals, access points, bases, base stations, node Bs, eNBs, gNBs, home node Bs, relay nodes, RAN nodes, or any other terminology used in the art. The base units 110 are typically part of a radio access network (“RAN”), such as RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base units 110. These and other elements of a radio access network are not illustrated, but are generally well known to those of ordinary skill in the art. The base units 110 are connected to a mobile core network 140 via the RAN 120.

[0037] The base unit 110 may serve a number of remote units 105 within a service area (e.g., a cell or cell sector) via a wireless communication link 115. The base unit 110 may communicate directly with one or more of the remote units 105 via a communication signal. In general, the base unit 110 transmits DL communication signals in the time, frequency, and / or spatial domains to serve the remote units 105. In addition, the DL communication signals may be carried on the wireless communication link 115. The wireless communication link 115 may be any suitable carrier in a licensed or unlicensed radio spectrum. The wireless communication link 115 facilitates communication between one or more of the remote units 105 and / or one or more of the base units 110. It should be noted that during NR-U operation, the base unit 110 and the remote units 105 communicate on an unlicensed radio spectrum.

[0038] In one embodiment, mobile core network 140 is a 5G core ("5GC") or an evolved packet core ("EPC"), which may be coupled to a packet data network 150, such as the Internet and a private data network, among other data networks. Remote unit 105 may have a subscription or another account with mobile core network 140. Each mobile core network 140 belongs to a single public land mobile network ("PLMN"). The present disclosure is not intended to be limited to implementations of any particular wireless communication system architecture or protocol.

[0039] The mobile core network 140 includes several network functions ("NFs"). As depicted, the mobile core network 140 includes a plurality of user plane functions ("UPFs") 141. The mobile core network 140 also includes a plurality of control plane functions, including but not limited to an access and mobility management function ("AMF") 143, a session management function ("SMF") 145, a policy control function ("PCF") 147, and a unified data management function ("UDM") 149 serving the RAN 120. In certain embodiments, the mobile core network 140 may also include an authentication server function ("AUSF"), a network repository function ("NRF") (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for the 5GC.

[0040] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network 140 that is optimized for a specific type of business or communication service. A network instance may be identified by an S-NSSAI, and a set of network slices that a remote unit 105 is authorized to use is identified by an NSSAI. In some embodiments, various network slices may include separate 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 1A Different network slices are not shown in , but are assumed to be supported.

[0041] although Figure 1A Although a specific number and type of network functions are depicted in the mobile core network 140, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140. In addition, in the case where the mobile core network 140 is an EPC, the depicted network functions may be replaced by appropriate EPC entities, such as MME, S-GW, P-GW, HSS, etc. In some embodiments, the mobile core network 140 may include an AAA server.

[0042] In various embodiments, the remote units 105 may communicate directly with each other (e.g., device-to-device communications) using sidelink ("SL") communication signals 117. Vehicle-to-everything ("V2X") is an example of SL communications. Here, V2X transmissions may occur on SL resources on the PC5 interface. The remote units 105 may have different SL communication resources for different V2X modes. Mode 1 corresponds to a New Radio ("NR") network scheduled V2X communication mode. Mode 2 corresponds to a UE autonomously scheduled V2X communication mode.

[0043] although Figure 1AComponents of a 5G RAN and 5G core network are depicted, but the described embodiments are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in an LTE variant involving EPC, the AMF 141 may be mapped to the MME, the SMF to the control plane portion of the PGW and / or to the MME, the UPF to the user plane portion of the SGW and PGW, the UDM / UDR to the HSS, etc.

[0044] In the following description, the term "gNB" is used for a base station, but it may be replaced by any other radio access node, such as a RAN node, eNB, BS, gNB, AP, NR, etc. In addition, the operations are mainly described in the context of 5G NR. However, the proposed solution / method is also applicable to other mobile communication systems that support beamforming and / or beam-based cell sectors.

[0045] Dynamic SL grants may provide resources for one or more SL transmissions of a single TB. In certain embodiments, Type 1 and / or Type 2 CGs provide a set of resources for multiple SL transmissions in a periodic manner. In such embodiments, the UE decides which TB to transmit in each of the opportunities indicated by a given CG. Current standards do not specify whether different transmissions of a TB may occur across multiple CGs. Other restrictions on what may be transmitted in a given CG may be determined (e.g., based on Quality of Service ("QoS"), destination UE, etc.).

[0046] In some embodiments, NR SL does not support different transmissions of a TB using different CGs. To report the SL HARQ-ACK to the gNB, for dynamic SL grants and CG type 2 in SL, the Rel-15 procedures and signaling used for DL ​​HARQ-ACK may be reused for the purpose of selecting the PUCCH offset / resources and format in the UL. In various embodiments, the configuration for the SL is separated from the Uu link for the UE. The current standard does not specify how to indicate the timing of transmissions in the PUCCH, including whether to use physical slots or logical slots. For CG type 1 in SL, Radio Resource Control ("RRC") is used to configure the PUCCH offset / resources and format in the UL (if supported).

[0047] In one embodiment, the CG of the SL may carry TBs for which the SL HARQ FB is enabled or disabled. For the CG, if it is possible to carry a TB in which the SL HARQ FB is enabled, there may be a corresponding physical sidelink feedback channel ("PSFCH") configuration. In addition, if there is a corresponding PSFCH configuration for the CG, the TB with the SL HARQ FB may be enabled and may be carried by the CG.

[0048] In one embodiment, the mapping between the HARQ process number ("HPN") signaled in the downlink control information ("DCI") and the value of the HPN signaled in the sidelink control information ("SCI") is fixed for the TB and determined according to the UE implementation. For dynamic grants, the two-state switching of the NDI in the DCI can be used as the two-state switching of the NDI in the SCI for the first SL transmission scheduled by the DCI. The SCI of the remaining transmissions (if any) scheduled by the DCI can have an NDI that is not two-state switched relative to the first SL transmission. The current standard does not specify the NDI in the SCI for the PUCCH ACK-NACK error case.

[0049] In one embodiment, the HARQ process ID for each transmission in the resources corresponding to the SL CG is determined based on the formula for the UL CG. In such embodiments, the mapping to the value of HPN in the SCI is fixed for the TB and determined according to the UE implementation. It is worth noting that if any distinction is made, this may correspond to the HARQ process ID used for interaction between the gNB and the UE.

[0050] In one embodiment, a new TB may be transmitted in one cycle of a CG. Current standards do not address the issue of retransmissions spanning multiple cycles. The DCI that schedules retransmissions may use the HARQ process ID corresponding to the first transmission of the TB. In some embodiments, there may be multiple HARQ ID processes for a given SL CG.

[0051] In one embodiment, the time slot for SL transmission of CG Type 1 is determined using the UL formula in 38.321, with certain changes including using slot-level granularity instead of symbol-level granularity (i.e., removing numberOfSymbolsPerSlot, "number of symbols in a slot", S in the formula), the periodicity is expressed in number of slots, and the timeDomainOffset is expressed in number of slots. The current standard does not specify the use of frame indexes (e.g., system frame numbers ("SFN") or virtual frame numbers) and / or whether logical slots or physical slots are used.

[0052] In one embodiment, for Long Term Evolution ("LTE") Uu-scheduled NR, when NR Uu schedules NR SL (SFN=0 refers to LTE DL carrier), the timeslot for SL transmission is determined in the same way as for SL CG Type 1. In addition, for CG, the supported periodicity may be the same as the periodic resource reservation in Mode 2 (i.e., the list given by SL-ResourceReservePeriod-r16). In one embodiment, RAN1 assumes that if there is an issue with HARQ process number collision, it will be resolved by RAN2.

[0053] In one embodiment, according to the currently specified behavior, it is unclear when the UE refreshes the HARQ transmission buffer of the SL HARQ process and when the UE generates a new TB for the HARQ process, especially for the case of SL CG. For CG types 1 and 2, whether the SL grant is used for initial transmission or retransmission within the periodicity depends on the UE implementation. According to the 3GPP protocol, TBs stored in the SL process that have been transmitted in the CG resources of one cycle cannot use the CG resources of the next cycle associated with the same HARQ process.

[0054] For example, if a TB has been transmitted from a SL process associated with HARQ process ID=1 in the first cycle of the CG, the TB may not be retransmitted in the second cycle of the CG of the same SL process. Therefore, the Tx UE may replace the old TB with the new TB in the HARQ Tx buffer of the SL process associated with the same HARQ process ID before the next CG resource associated with the HARQ process ID, or the Tx UE may keep the pending TB in the HARQ buffer for possible retransmission, e.g., dynamically scheduled by the gNB, and ignore the next CG resource associated with the HARQ process ID (skipping the allocated CG resource for SL transmission).

[0055] In existing solutions, the Tx UE may use the ConfiguredGrantTimer as defined for UL CG in NR Rel-15 in order to ensure that retransmissions scheduled by the gNB are possible for TBs pending in the HARQ buffer, e.g., the Tx UE does not generate a new TB at the next CG resource and store it in the HARQ buffer with pending TBs. However, since there may be significant differences between UL transmissions on NR Uu and SL transmissions for NR V2X, applying the same behavior to the ConfiguredGrantTimer as defined for NR UL for NR V2X may not result in efficient operation.

[0056] For example, for the NR V2X case, the Tx UE may know whether a TB is correctly received by the receiving ("Rx") UE based on the feedback sent on the PSFCH. For the NR Uu case, the CGT timer is introduced because there is no HARQ feedback for a UL HARQ protocol, e.g., an asynchronous HARQ protocol. However, for NR V2X, the Tx UE may receive HARQ feedback (if configured) from the Rx UE (PSFCH) and also receive a physical downlink control channel ("PDCCH") (SL grant) from the gNB. Therefore, an optimized behavior for determining when to flush the HARQ buffer and / or generate a new TB for CG resources may be necessary, which takes into account two control channels, e.g., the PSFCH from the Rx UE and the PDCCH from the gNB.

[0057] Figure 1B An example of a SL CG is shown in FIG175. Figure 1B In the example shown in , three CG resources are allocated per cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181), and two different HARQ processes ("HP") (HP1 176 and HP2 178) are used for the SL CG. After each CG resource, in one embodiment, PSFCH 180 is allocated for transmission of HARQ feedback from the RxUE. After the last CG resource in a cycle, in some embodiments, PUCCH 182 resources are allocated to send HARQ feedback information indicating whether the transmission was successful to the gNB.

[0058] According to the recent 3GPP agreement, SL resources may be allocated semi-persistently to a UE (e.g., a Tx UE) with the aid of a SL CG. Similar to NR Uu, there may be two types of CGs, type 1 and type 2. SL resources may be allocated with a given configuration periodicity, which is also referred to as, for example, period 1 177, period 2 179, or period 3 181. Within each period of the SL CG (e.g., period 1 177, period 2 179, or period 3 181), up to three CG resources may be allocated by the gNB. The HARQ process ID for each transmission in the SL resources corresponding to the SL CG may be determined based on the formula for the UL configuration grant in TS38.321.

[0059] According to a first solution, the UE starts a timer after having sent a NACK to the gNB on a PUCCH 182, the PUCCH resource 182 being associated with the SL CG resource. The PUCCH 182 may be sent in response to having performed a SL transmission on a CG resource allocated by the SL CG, for which the corresponding receiving UE (e.g., PSFCH 180) did not confirm successful reception. In one embodiment, while the timer is running, the UE should not generate a new TB for the HARQ process HP1 176 or HP2 178 at the next CG resource of the SL CG of the same HARQ process (e.g., HP 1 176 or HP2 178). In various embodiments, the purpose of the timer is to ensure that the TBs stored in the HARQ buffer are not overwritten by the newly generated TBs, even though the gNB may schedule further retransmissions in response to the receipt of a NACK on the PUCCH 182.

[0060] According to one implementation of the embodiment, for the case where the timer is running, the UE should retransmit the pending TB in the HARQ buffer on the subsequent CG resources associated with the same HARQ process (e.g., HP1 176 or HP2 178). If the timer is not running at the next CG resource of the SL CG of the same HARQ process (e.g., HP1 176 or HP2 178), the UE may regard the NDI as being dual-state switched for the HARQ process (e.g., HP1 176 or HP2 178) and generate a new TB (if SL data is available for transmission). In some embodiments, the timer is stopped upon receiving the SL CG indicating a new transmission of the same HARQ process (e.g., HP1 176 or HP2178). For the case where the SL CG indicates a retransmission of the same HARQ process (e.g., HP1 176 or HP2178), for example, the NDI is non-dual-state switched or the RNTI indicates that this is a retransmission, the timer may be started / restarted.

[0061] In an embodiment in which the Tx UE sends a HARQ ACK to the gNB on a PUCCH resource 182, the PUCCH resource 182 is associated with the SLCG and the timer is not started. The PUCCH 182 may be sent in response to a SL transmission having been performed on a CG resource allocated by the SL CG, for which the corresponding receiving UE confirms successful reception. According to some alternative implementations of the embodiment, the Tx UE checks whether a SL grant indicating a retransmission of the same HARQ process (e.g., HP1 176 or HP2 178) has been received until a predefined time before the next CG resource of the same HARQ process (e.g., HP1 176 or HP2 178), for example, in the next cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181), after a NACK has been sent on the PUCCH 182, for example, after the last CG resource of a cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181).

[0062] For the case where a SL grant requesting retransmission has been received, the Tx UE may not generate a new TB at the next CG resource of the same HARQ process (e.g., HP1 176 or HP2 178), the next CG resource being, for example, the first CG resource (e.g., PSSCH) within a cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181). For the case where a SL grant requesting retransmission has not been received before a predefined time before the next CG resource, for example, the first CG resource of the next cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) of the same HARQ process (e.g., HP1 176 or HP2 178), the UE will generate a new TB. Figure 1B For example, according to this implementation, the UE, after having sent a NACK on PUCCH 182 in cycle 1 177, will determine whether the gNB sends a SL grant (e.g., DCI) requesting retransmission of HARQ process 1 176 until a predefined offset (e.g., in number of time slots / ms) before the start of cycle 3 181 (associated with HARQ process 1 176) in order to decide whether to generate a new TB for the first CG resource within cycle 3 181.

[0063] According to another aspect of the embodiment, the Tx UE starts a timer after having sent a TB on a CG resource. The timer may be associated with a corresponding associated HARQ process (e.g., HP1 176 or HP2 178). As long as the timer is running, the Tx UE does not generate a new TB on the next CG resource of the same HARQ process (e.g., HP1 176 or HP2 178), for example, a new TB is generated only when the timer is not running. When an ACK is received on PSFCH 180 for the (re)transmission of a TB on a CG resource, the corresponding timer may be stopped. When a NACK is received from the Rx UE on PSFCH 180, the timer may be restarted or kept running. According to one implementation of the embodiment, when the timer is running, the Tx UE may perform a retransmission of a pending TB on the next available CG resource of the same HARQ process (e.g., HP1 176 or HP2 178).

[0064] According to the second solution, in one embodiment, the UE may retransmit the TBs pending in the HARQ buffer of the HARQ process (e.g., HP1 176 or HP2 178) on the next CG resource of the same SL CG of the same HARQ process (e.g., HP1 176 or HP2 178) after having received a NACK on the PSFCH 180 for the previous CG transmission within a cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181). In the scenario where the UE has been configured with the SL CG (e.g., by the gNB), and within each cycle 177 of the SL CG, the UE may be allocated multiple CG resources, for which corresponding PSFCH 180 for HARQ feedback may be allocated. In such an embodiment, the UE determines the transmission behavior of the next CG resource within the same cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) based on the HARQ feedback received for the CG transmission within cycle 177, for example, whether to perform a retransmission / initial transmission or whether to not perform any SL transmission on the CG resource.

[0065] According to one implementation of the embodiment, if a NACK is received on PSFCH 180 for a previous CG transmission of the same HARQ process (e.g., HP1 176 or HP2 178) within the same period (e.g., period 1 177, period 2 179, or period 3 181), the UE performs a retransmission on the next CG resource within a period (e.g., period 1 177, period 2 179, or period 3 181) of the same HARQ process (e.g., HP1 176 or HP2 178). For cases where no feedback is received due to timing constraints, for example, the PSFCH resource 180 occurs after the next CG resource within a cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) or the time between the PSFCH 180 and the next CG resource (e.g., PSSCH) is too short to prepare for retransmission of the new TB / pending TB, the UE may retransmit the TB on the next CG resource, or alternatively keep the TB in the HARQ buffer but not perform a retransmission (skipping SL transmission on the next CG resource).

[0066] In one embodiment, the assumption here is that a certain minimum processing time is required between the PSFCH 180 and the subsequent PSSCH of the same HARQ process (e.g., HP1 176 or HP2 178), for example, the time required for the UE to prepare a new TB for the initial transmission in the subsequent CG resources and to prepare the retransmission of the pending TB, respectively. For the case where the time between the end of the last symbol of the last PSFCH 180 of the same HARQ process (e.g., HP1 176 or HP2 178) and the first symbol of the next CG resource of the SL CG is less than the defined minimum processing time, the Tx UE should keep the TB in the HARQ buffer. The same behavior can be applied for the case where DTX is received for the previous CG transmission within the period (e.g., period 1 177, period 2 179 or period 3 181) of the same HARQ process (e.g., HP1 176 or HP2 178).

[0067] In certain embodiments, for the case where an ACK is received for a CG transmission on PSFCH 180, the UE may avoid performing any transmission on the next CG resources of the SL CG within the same cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) of the same HARQ process (e.g., HP1 176 or HP2 178), for example, skipping the SL transmission on the next CG resources within the cycle (e.g., cycle 1 177, cycle 2 179, cycle 3 181). According to another implementation, for the case where the previous CG transmission is a (re)transmission of a different TB acknowledged by the receiving UE, for example, for the case where an ACK is received on PSFCH 180, the UE may generate a new TB and perform an initial transmission on the next CG resources of the SL CG within a cycle.

[0068] According to another embodiment, the Tx UE may transmit a TB on the next CG resource associated with the same HARQ process (e.g., HP1 176 or HP2 178) within the same cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) in response to having received an ACK on the PSFCH 180 for the transmission of a TB on the CG resource, the TB waiting to be retransmitted from a different HARQ process (e.g., HP1 176 or HP2 178). The Tx UE may indicate the HARQ process ID of the pending TB for retransmission in the SCI accompanying the PSSCH transmission on the CG resource. Basically, in some embodiments, the Tx UE uses two different HARQ processes (e.g., HP 1 176 or HP2 178) for SL transmission within the same cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181). Alternatively, in one embodiment, the Tx UE uses the remaining CG resources within one cycle (e.g., cycle 1 177, cycle 2 179, or cycle 3 181) after receiving an ACK on PSFCH 180 for a previous CG transmission, e.g., for a SL transmission in mode 2.

[0069] According to the third solution, once the UE performs a SL transmission on a SL resource, for example, the SL resource may be dynamically allocated by the gNB or SL CG resources, a timer is started. In one embodiment, as long as the timer is running, the UE does not generate a new TB for the same HARQ process (e.g., HP1 176 or HP2 178), for example, to avoid covering TBs stored in the HARQ buffer and that may be subject to further retransmissions. In another embodiment, after the timer expires, the UE uses the HARQ process (e.g., HP1 176 or HP2 178) for transmitting a new TB, for example, the UE may refresh the HARQ buffer and generate a new TB and store it in the buffer. In various embodiments, after receiving a HARQ ACK for the transmission of a TB, the UE considers the associated timer to be expired. In one embodiment, for a case where the UE has CG resources for a HARQ process (e.g., HP1 176 or HP2 178) and a timer is not running for the HARQ process, the UE generates a new TB for the CG resources and / or the HARQ process (e.g., HP1 176 or HP2 178).

[0070] According to the fourth solution, in one embodiment, the timer is started only at the initial transmission of the TB. In some embodiments, the transmission may be an initial transmission on a dynamically scheduled SL resource or on a CG resource. In one embodiment, the timer value is set so that it allows a specific number of retransmissions of the TB, which are still within the PDB of the TB. In some embodiments, after receiving an ACK for the (re)transmission of the TB, the UE considers the timer to have expired, for example, no further retransmission is required. In some embodiments, the reception of a SL grant (e.g., DCI) indicating a new transmission of the same HARQ process (e.g., HP1 176 or HP2 178) stops the timer, and, for example, the corresponding SL transmission will start the timer. In one embodiment, after the timer expires, the UE refreshes the HARQ buffer of the associated HARQ process (e.g., HP1 176 or HP2 178), and the HARQ process is considered available for another SL transmission, for example, the UE may generate a new TB and store it for transmission in the HARQ buffer and / or process (e.g., HP1 176 or HP2 178).

[0071] According to the fifth solution, in one embodiment, the TX UE continuously (re)transmits the generated TB on the CG resources associated with the same HARQ process (e.g., HP1 176 or HP2 178), as long as the maximum number of retransmissions is not reached and / or the packet delay budget of the TB is not exceeded, even across different cycles (e.g., cycle 1 177, cycle 2 179, or cycle 3 181), unless an ACK has been received from the Rx UE for the TB on the PSFCH 180. According to an implementation of this embodiment, the Tx UE will also stop the (re)transmission of this TB once the gNB schedules the initial transmission of the same HARQ process (e.g., HP1 176 or HP2 178) under the SL authorization (e.g., DCI). According to another embodiment, the Tx UE stops the (autonomous) retransmission of TBs on CG resources associated with the same HARQ process (e.g., HP1 176 or HP2 178) after having received a SL grant (e.g., DCI) from the gNB, which dynamically schedules the retransmission of TBs of the same HARQ process (e.g., HP1 176 or HP2 178). In some embodiments, only further subsequent dynamically scheduled retransmissions of the TB may follow, e.g., without autonomous retransmission of the TB performed by the Tx UE. For the case where there is no PUCCH 182 associated with the CG resources allocated to the Tx UE for a cycle, the UE may flush the corresponding HARQ Tx buffer at the beginning of the next cycle associated with the same HARQ process, e.g., before the first CG resource of the next cycle.

[0072] It should be noted that the solution described above may be combined with a timer controlling the maximum transmission time of a TB, for example, a timer value set according to a PDB value associated with the TB. Thus, multiple timers may be applied simultaneously.

[0073] Figure 2 A user equipment device 200 is depicted that can be used to manage a hybrid automatic repeat request buffer for a sidelink configuration grant. In various embodiments, the user equipment device 200 is used to implement one or more of the solutions described above. The user equipment device 200 can be an embodiment of the remote unit 105 described above. In addition, the user equipment device 200 can include a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0074] In some embodiments, input device 215 and output device 220 are combined into a single device, such as a touch screen. In some embodiments, user equipment device 200 may not include any input device 215 and / or output device 220. In various embodiments, user equipment device 200 may include one or more of the following: processor 205, memory 210, and transceiver 225, and may not include input device 215 and / or output device 220.

[0075] In one embodiment, the processor 205 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 205 executes instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225.

[0076] In various embodiments, the processor 205 controls the user equipment device 200 to implement UE behavior according to one or more of the embodiments described above.

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

[0078] In some embodiments, the memory 210 stores data related to managing a hybrid automatic repeat request buffer for a sidelink configuration grant. For example, the memory 210 may store various parameters, configurations, policies, etc. as described above. In certain embodiments, the memory 210 also stores program code and related data, such as an operating system or other controller algorithms operating on the device 200.

[0079] In one embodiment, input device 215 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 215 may be integrated with output device 220, for example, as a touch screen or similar touch-sensitive display. In some embodiments, input device 215 includes a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 215 includes two or more different devices, such as a keyboard and a touch panel.

[0080] In one embodiment, the output device 220 is designed to output visual, auditory and / or tactile signals. In some embodiments, the output device 220 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 220 may include a wearable display that is separate from the rest of the user equipment device 200 but is communicatively coupled to the rest, such as a smart watch, smart glasses, a head-mounted display, etc. In addition, the output device 220 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0081] In some embodiments, the output device 220 includes one or more speakers for producing sounds. For example, the output device 220 may produce an audible warning or notification (e.g., a buzzer or chime). In some embodiments, the output device 220 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 220 may be integrated with the input device 215. For example, the input device 215 and the output device 220 may form a touch screen or similar touch-sensitive display. In other embodiments, the output device 220 may be located near the input device 215.

[0082] The transceiver 225 communicates with one or more network functions of the mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or a portion thereof) at a particular time in order to send and receive messages.

[0083] The transceiver 225 includes at least a transmitter 230 and at least one receiver 235. One or more transmitters 230 may be used to provide UL communication signals to the base unit 110, such as the UL transmissions described herein. Similarly, one or more receivers 235 may be used to receive DL communication signals from the base unit 110, as described herein. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment device 200 may have any suitable number of transmitters 230 and receivers 235. In addition, the transmitter 230 and the receiver 235 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 225 includes a first transmitter / receiver pair for communicating with a mobile communication network on a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network on an unlicensed radio spectrum.

[0084] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on a licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on an unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip that performs functions for use with both licensed and unlicensed radio spectrums. 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 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access shared hardware resources and / or software resources, such as a network interface 240.

[0085] In various embodiments, one or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as a network interface 240 or other hardware components / circuits may be integrated into a single chip with any number of transmitters 230 and / or receivers 235. In such embodiments, the transmitters 230 and receivers 235 may be logically configured as transceivers 225 using one or more common control signals, or may be configured as modular transmitters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.

[0086] Figure 3A network equipment device 300 that can be used to manage a hybrid automatic repeat request buffer for a sidelink configuration grant according to an embodiment of the present disclosure is depicted. The network equipment device 300 may be an embodiment of the base unit 110 or RAN node described above. In addition, the basic network equipment device 300 may include a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325. In some embodiments, the input device 315 and the output device 320 are combined into a single device, such as a touch screen. In certain embodiments, the network equipment device 300 may not include any input device 315 and / or output device 320. In various embodiments, the network equipment device 300 may include one or more of the following: a processor 305, a memory 310, and a transceiver 325, and may not include an input device 315 and / or an output device 320.

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

[0088] In various embodiments, the network equipment device 300 is a RAN node (e.g., a gNB) as described herein. Here, the processor 305 controls the network equipment device 300 to perform the behaviors described above. For example, the processor 305 may receive PSFCH content, retransmit the TB on the next CG resource in response to the PSFCH content including NACK, and stop transmitting the TB in the CG period in response to the PSFCH content including ACK.

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

[0090] In some embodiments, the memory 310 stores data related to managing the hybrid automatic repeat request buffer for the sidelink configuration grant. For example, the memory 310 may store various parameters, configurations, policies, etc. as described above. In some embodiments, the memory 310 also stores program code and related data, such as an operating system or other controller algorithms operating on the network equipment device 300.

[0091] In one embodiment, input device 315 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 315 may be integrated with output device 320, for example, as a touch screen or similar touch-sensitive display. In some embodiments, input device 315 includes a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 315 includes two or more different devices, such as a keyboard and a touch panel.

[0092] In one embodiment, the output device 320 is designed to output visual, auditory and / or tactile signals. In some embodiments, the output device 320 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 320 may include a wearable display that is separated from the rest of the network equipment device 300 but is communicatively coupled to the rest, such as a smart watch, smart glasses, a head-mounted display, etc. In addition, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0093] In some embodiments, the output device 320 includes one or more speakers for producing sounds. For example, the output device 320 can produce an audible warning or notification (e.g., a buzzer or chime). In some embodiments, the output device 320 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 320 can be integrated with the input device 315. For example, the input device 315 and the output device 320 can form a touch screen or similar touch-sensitive display. In other embodiments, the output device 320 can be located near the input device 315.

[0094] The transceiver 325 includes at least a transmitter 330 and at least one receiver 335. One or more transmitters 330 may be used to communicate with a UE, as described herein. Similarly, one or more receivers 335 may be used to communicate with a network function in a PLMN and / or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network equipment device 300 may have any suitable number of transmitters 330 and receivers 335. In addition, the transmitter 330 and the receiver 335 may be any suitable type of transmitter and receiver.

[0095] Figure 4 is a flow chart illustrating a method 400 for managing a hybrid automatic repeat request buffer for a sidelink configuration grant. The method 400 may be performed by a UE, such as a remote unit 105 and / or a user equipment device 200. In some embodiments, the method 400 may be performed by a processor executing program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0096] The method 400 includes transmitting 405 a transport block ("TB") from a transmitting user equipment ("UE") device to a receiving UE device using configuration grant resources during a period of a sidelink configuration grant. The method 400 includes receiving 410 feedback from the receiving UE device on a physical sidelink feedback channel ("PSFCH") at the transmitting UE device during the period indicating whether the TB was successfully received. The method 400 includes, in response to the feedback indicating that the receiving UE device successfully received the TB, stopping 415 transmission of the TB on subsequent configuration grant resources of a sidelink configuration grant within the same period. The method 400 ends.

[0097] A first method for managing a hybrid automatic repeat request buffer for a sidelink configuration grant is disclosed. In one embodiment, the first method includes transmitting a transport block ("TB") from a transmitting user equipment ("UE") device to a receiving UE device using configuration grant resources during a period of a sidelink configuration grant. In certain embodiments, the first method includes receiving feedback from the receiving UE device on a physical sidelink feedback channel ("PSFCH") at the transmitting UE device during the period indicating whether the TB was successfully received. In one embodiment, the first method includes, in response to the feedback indicating that the receiving UE device successfully received the TB, stopping transmission of the TB on the configuration grant resources of a subsequent sidelink configuration grant within the same period.

[0098] In one embodiment, the first method includes retransmitting a pending TB from a different hybrid automatic repeat request ("HARQ") process during a period of a sidelink configuration grant in response to feedback indicating that the receiving UE device successfully received the TB. In one embodiment, the first method includes indicating an identifier of the HARQ process of the retransmitted pending TB within channel state information of the transmitting UE device.

[0099] In one embodiment, the first method includes generating a new TB in response to feedback indicating that the receiving UE device successfully received the retransmitted TB and performing an initial transmission of the new TB on a next configured grant resource during a period of the sidelink configuration grant. In some embodiments, the first method includes using the remaining configured grant resources of the period of the sidelink configuration grant for transmitting a different TB in response to feedback indicating that the receiving UE device successfully received the TB.

[0100] In one embodiment, the first method includes retransmitting the TB on the next configured grant resource during a period of the sidelink configuration grant in response to feedback indicating that the receiving UE device did not successfully receive the TB. In one embodiment, the first method includes retransmitting the TB on the next configured grant resource in response to not receiving any feedback from the receiving UE device on the PSFCH.

[0101] In one embodiment, the first method includes buffering the TB in the HARQ buffer in response to not receiving any feedback from the receiving UE device on the PSFCH and in response to the time between the end of the last symbol of the PFSCH of the HARQ process and the first symbol of the next configured granted resource being less than the minimum processing time. In one embodiment, the first method includes: in response to feedback indicating that the receiving UE device did not successfully receive the TB, sending an indication that the receiving UE device did not successfully receive the TB to a network entity of the mobile wireless communication network that provides the sidelink configuration grant, and the TB is buffered for retransmission; starting a timer associated with the retransmission of the TB; while the timer is running, preventing new TBs from being generated and overwriting the TBs in the buffer; and retransmitting the buffered TBs on subsequent configured granted resources until the timer expires and the feedback indicates that the receiving UE device successfully received one of the TBs.

[0102] In one embodiment, the first method includes retransmitting the TB in response to receiving a retransmission grant for the TB within a predefined time before subsequently configuring the authorized resources. In one embodiment, the first method includes generating a new TB for transmission in response to not receiving a retransmission grant for the TB within a predefined time before subsequently configuring the authorized resources.

[0103] In one embodiment, the first method includes, in response to feedback indicating that the receiving UE device successfully received the TB, not starting the timer and generating a new TB for transmission on a subsequent configuration grant resource. In one embodiment, the first method includes starting the timer in response to sending the TB on the configuration grant resource during a period of the sidelink configuration grant, and stopping the timer in response to feedback indicating that the receiving UE device successfully received the TB.

[0104] In one embodiment, the first method includes treating the NDI as toggled in response to expiration of the timer and generating a new TB for transmission. In one embodiment, the first method includes stopping the timer in response to receiving a sidelink grant for initial transmission of the new TB. In one embodiment, the first method includes flushing the buffer in response to expiration of the timer and generating a new TB for storage in the buffer.

[0105] In one embodiment, a timer is started in response to an initial transmission of a TB on at least one of the dynamically scheduled sidelink resources and the configured granted resources, the timer value being set such that it allows a predefined number of retransmissions of the TB that are still within the PDB of the TB. In one embodiment, the first method includes, in response to feedback indicating that the receiving UE device did not successfully receive the TB, retransmitting the TB on the configured granted resources as long as at least one of a maximum number of retransmissions is not exceeded and a packet delay budget of the TB is not exceeded.

[0106] A first apparatus for managing a hybrid automatic repeat request buffer for a sidelink configuration grant is disclosed. In one embodiment, the first apparatus includes a transceiver in communication with a receiving UE device and a network entity of a mobile wireless communication network. In certain embodiments, the first apparatus includes a processor that transmits a transport block ("TB") to the receiving UE device via the transceiver using a configuration grant resource during a period of the sidelink configuration grant.

[0107] In one embodiment, the first device includes a processor that receives feedback from a receiving UE device on a physical sidelink feedback channel ("PSFCH") during the period via a transceiver indicating whether the TB was successfully received. In one embodiment, the first device includes a processor that, in response to the feedback indicating that the receiving UE device successfully received the TB, stops transmission of the TB on subsequent configuration grant resources of the sidelink configuration grant within the same period.

[0108] In one embodiment, the first apparatus includes a processor that, in response to feedback indicating that the receiving UE device successfully received the TB, retransmits a pending TB from a different hybrid automatic repeat request ("HARQ") process during a period of a sidelink configuration grant. In one embodiment, the first apparatus includes a processor that indicates an identifier of the HARQ process of the retransmitted pending TB within channel state information of the transmitting UE device.

[0109] In one embodiment, the first device includes a processor that generates a new TB and performs an initial transmission of the new TB on a next configuration grant resource during a period of the sidelink configuration grant in response to feedback indicating that the receiving UE device successfully received the retransmitted TB. In some embodiments, the first device includes a processor that uses the remaining configuration grant resources of the period of the sidelink configuration grant for transmission of a different TB in response to feedback indicating that the receiving UE device successfully received the TB.

[0110] In one embodiment, the first device includes a processor that further retransmits the TB on a next configured grant resource during the period of the sidelink configuration grant in response to feedback indicating that the receiving UE device did not successfully receive the TB. In one embodiment, the first device includes a processor that retransmits the TB on a next configured grant resource in response to not receiving any feedback from the receiving UE device on the PSFCH.

[0111] In one embodiment, the first device includes a processor that buffers the TB in a HARQ buffer in response to not receiving any feedback from the receiving UE device on the PSFCH and in response to the time between the end of the last symbol of the PFSCH of the HARQ process and the first symbol of the next configured granted resource being less than a minimum processing time. In one embodiment, the first device includes a processor that, in response to feedback indicating that the receiving UE device did not successfully receive the TB, sends an indication that the receiving UE device did not successfully receive the TB to a network entity of a mobile wireless communication network that provides a sidelink configured grant, the TB is buffered for retransmission; starts a timer associated with the retransmission of the TB; while the timer is running, prevents new TBs from being generated and overwrites the TB in the buffer; and retransmits the buffered TB on subsequent configured granted resources until the timer expires and the feedback indicates that the receiving UE device successfully received one of the TBs.

[0112] In one embodiment, the first device includes a processor that retransmits the TB in response to receiving a retransmission authorization for the TB within a predefined time before subsequently configuring the authorized resources. In one embodiment, the first device includes a processor that generates a new TB for transmission in response to not receiving a retransmission authorization for the TB within a predefined time before subsequently configuring the authorized resources.

[0113] In one embodiment, the first device includes a processor that, in response to feedback indicating that the receiving UE device successfully received the TB, does not start a timer and does not generate a new TB for transmission on a subsequent configuration grant resource. In one embodiment, the first device includes a processor that starts a timer in response to sending a TB on the configuration grant resource during a period of a sidelink configuration grant, and stops the timer in response to feedback indicating that the receiving UE device successfully received the TB.

[0114] In one embodiment, the first device includes a processor that treats the NDI as a toggle in response to expiration of the timer and generates a new TB for transmission. In one embodiment, the first device includes a processor that stops the timer in response to receiving a sidelink grant for initial transmission of the new TB. In one embodiment, the first device includes a processor that flushes the buffer in response to expiration of the timer and generates a new TB for storage in the buffer.

[0115] In one embodiment, a timer is started in response to an initial transmission of a TB on at least one of the dynamically scheduled sidelink resources and the configured granted resources, the timer value being set such that it allows a predefined number of retransmissions of the TB that are still within the PDB of the TB. In one embodiment, the first apparatus includes a processor that, in response to feedback indicating that the receiving UE device did not successfully receive the TB, retransmits the TB on the configured granted resources as long as at least one of a maximum number of retransmissions is not exceeded and a packet delay budget of the TB is not exceeded.

[0116] Embodiments may be practiced in other specific forms. The described embodiments should be considered in all respects to be illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes that fall within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method performed by a first user equipment UE, comprising: transmitting a first transport block TB from a buffer of the first UE to a second UE using the configuration grant resources during a period of the sidelink configuration grant; During the period, receiving first feedback from the second UE on a physical sidelink feedback channel (PSFCH) indicating whether the first TB is successfully received; In response to the first feedback indicating that the second UE successfully received the first TB: Stopping transmission of the first TB on subsequent configuration authorization resources of the sidelink configuration authorization; flushing the first TB from the buffer; as well as retransmitting a second TB associated with a different hybrid automatic repeat request (HARQ) process during said period of said sidelink configuration grant; as well as In response to second feedback indicating that the second UE successfully received the retransmitted second TB, transmission of a third TB is performed on next configured granted resources during the period of the sidelink configuration grant.

2. The method according to claim 1, further comprising: An identifier of the HARQ process of the retransmitted second TB is indicated in the sidelink control information SCI of the transmitting UE device.

3. The method according to claim 1, further comprising: In response to the first feedback indicating that the second UE successfully received the first TB, remaining configured grant resources of the period of the sidelink configuration grant are used to transmit the second TB or the third TB.

4. The method according to claim 1, further comprising: In response to the first feedback indicating that the second UE did not successfully receive the first TB, retransmit the first TB on a next configuration grant resource during the period of the sidelink configuration grant.

5. The method according to claim 1, further comprising: In response to not receiving any feedback from the second UE on the PSFCH, retransmitting the first TB on the next configured granted resources.

6. The method of claim 1, further comprising, in response to the first feedback indicating that the second UE did not successfully receive the first TB: sending an indication that the second UE did not successfully receive the first TB to a network entity that provided the sidelink configuration grant, the first TB being buffered for retransmission; starting a timer associated with retransmission of the first TB; While the timer is running: Preventing new TBs from being generated and overwriting the first TB in the buffer; and The first TB is retransmitted on subsequently configured granted resources until one of: the timer expires, or the first feedback indicates that the second UE successfully received the first TB.

7. The method according to claim 6, further comprising: In response to receiving a retransmission grant for the second TB before subsequently configuring the granted resources, the second TB is retransmitted.

8. The method according to claim 6, further comprising: In response to not receiving a retransmission grant for the second TB before subsequently configuring granted resources, the third TB is generated for transmission.

9. The method according to claim 1, further comprising: in response to sending the first TB on configuration grant resources during the period of the sidelink configuration grant, starting a timer; as well as In response to the first feedback indicating that the second UE successfully received the first TB, stopping the timer.

10. The method according to claim 9, further comprising: In response to the timer expiring and generating the third TB for transmission, the NDI is identified as a toggle.

11. A transmission user equipment UE device, comprising: a transceiver that communicates with a receiving UE and a network entity of a mobile wireless communication network; as well as A processor arranged to: transmitting, via the transceiver, a first transport block (TB) to the receiving UE using configuration grant resources during a period of a sidelink configuration grant; receiving, via the transceiver during the period, first feedback from the receiving UE on a physical sidelink feedback channel (PSFCH) indicating whether the first TB is successfully received; as well as In response to the first feedback indicating that the receiving UE successfully received the first TB: Stopping transmission of the first TB on subsequent configuration authorization resources of the sidelink configuration authorization; flushing the first TB from the buffer; as well as retransmitting a second TB associated with a different hybrid automatic repeat request (HARQ) process during said period of said sidelink configuration grant; as well as In response to second feedback indicating that the receiving UE successfully received the retransmitted second TB, transmission of a third TB is performed on a next configured grant resource during the period of the sidelink configuration grant.

12. The apparatus of claim 11, wherein the processor is further arranged to indicate an identifier of the HARQ process of the retransmitted second TB within sidelink control information (SCI) of the transmitting UE.

13. The apparatus of claim 11, wherein the processor is further arranged to use remaining configured grant resources of the period of the sidelink configuration grant for transmitting the second TB or the third TB in response to the first feedback indicating that the receiving UE successfully received the first TB.

14. The apparatus of claim 11, wherein the processor is further arranged to retransmit the first TB on a next configuration grant resource during the period of the sidelink configuration grant in response to the first feedback indicating that the receiving UE did not successfully receive the first TB.

15. The apparatus of claim 11, wherein the processor is further arranged to retransmit the first TB on a next configured granted resource in response to not receiving any feedback from the receiving UE on the PSFCH.

Images