Resource allocation in wireless networks

Abstract

Methods for allocating and providing pass-through link communication in a wireless user equipment (UFO) with another UFO are disclosed. For example, a preemption procedure is implemented in the MAC layer of the UFO to allocate active Hybrid Automatic Repeat Request (HARQ) processes to valid transmit or receive transport blocks. The preemption procedure may be based on preemption status parameters and preemption priority parameters associated with the respective transport blocks competing for HARQ process resources.

Description

Technical Field

[0001] This disclosure generally relates to resource allocation in wireless networks. Background Technology

[0002] User equipment (UEs) in a wireless network can transmit data to each other via a direct sidelink communication channel without any radio access network (RAN) node relaying the data. Compared to other conventional applications involving UE-UE sidelink communication, some application scenarios involving vehicular wireless network equipment may have more stringent and unpredictable communication requirements. It is crucial to provide resource allocation and provisioning mechanisms to enable efficient use of sidelink communication resources and other hardware / software resources across all layers of the UE's sidelink communication protocol stack, such as the MAC layer. Summary of the Invention

[0003] This disclosure relates to methods, systems, and apparatus for allocating and providing wireless communication resources for transmitting and receiving data between UEs in a wireless network via a direct pass-through link communication channel.

[0004] In one embodiment, a method performed by a first wireless user equipment (WLAN) is disclosed. The method may include identifying a first transport block (TB) for transmission to a second WLAN via a pass-through link; using a HARQ process preemption process at the WLAN's Media Access Control (MAC) layer based on preemption status parameters and preemption priority parameters associated with the first TB, determining a preemptible active Hybrid Automatic Repeat Request (HARQ) process among a plurality of active HARQ processes; associating the first TB with the preemptible active HARQ process; and transmitting the first TB to the second WLAN via the pass-through link through the associated active HARQ process, and retransmitting the first TB to the second WLAN as needed.

[0005] In another embodiment, a method performed by a first wireless user equipment is disclosed. The method may include determining a communication session ID for receiving a first transport block (TB) from a second wireless user equipment via a pass-through link; monitoring pass-through link control information (SCI) via a physical pass-through link control channel (PSCCH) having a matching communication session ID; determining a preemptible active hybrid automatic repeat request (HARQ) process among multiple active HARQ processes using a process preemption procedure at the media access control (MAC) layer of the first wireless user equipment based on preemption status parameters and preemption priority parameters associated with the first TB; associating the first TB with the preemptible active HARQ process; and receiving the first TB from the second wireless user equipment via the pass-through link according to the preemptible active HARQ process.

[0006] In another embodiment, a method for multicast resource allocation in a wireless network is disclosed. The method may include mapping a Quality of Service (QoS) stream to a plurality of Logical Channels (LCHs) / Radio Bearers (RBs), wherein each LCH / RB is associated with a corresponding first reliability indicator, and wherein each first reliability indicator includes one of the following in ascending reliability order: disabling feedback, providing only NACK feedback, and providing both ACK and NACK feedback; performing a Logical Channel Prioritization (LCP) procedure based on the first reliability indicator; generating a Transport Block (TB) from the LCP procedure; and deriving a second reliability indicator, respectively, from one of the TBs.

[0007] In yet another embodiment, a method for multicast resource allocation in a wireless network is disclosed. The method may include mapping QoS flows to multiple logical channels (LCHs) / radio bearers (RBs), wherein each LCH / RB is associated with a first HARQ feedback indicator, the first HARQ feedback indicator including one of enabling HARQ feedback and disabling HARQ feedback; performing a logical channel prioritization (LCP) procedure based on the first HARQ feedback indicator; generating a transport block (TB) from the LCP procedure; and determining a second HARQ feedback indicator for each of the TBs.

[0008] In some embodiments, a wireless user equipment including one or more processors and one or more memories is disclosed. The one or more processors may be configured to read computer code from the one or more memories to implement the methods of any of the above embodiments.

[0009] In some other embodiments, a computer program product is disclosed, comprising a non-transitory computer-readable program medium having computer code stored thereon. When executed by one or more processors, the computer code can cause one or more processors to perform any of the embodiments described above.

[0010] Other aspects and alternatives of the above embodiments and their implementation are explained in more detail in the following drawings, description and claims. Attached Figure Description

[0011] Figure 1 An exemplary wireless network supporting pass-through link communication between UEs is shown.

[0012] Figure 2 An exemplary protocol stack structure involved in UE-UE direct link communication is shown.

[0013] Figure 3An exemplary HARQ resource allocation and preemption mechanism is shown. Detailed Implementation

[0014] like Figure 1 As shown, the wireless communication network 100 may include user equipment (UE) 110 and a carrier network 120. For example, the carrier network 120 may also include a radio access network 122 and a core network 124. The radio access network 122 may include a radio base station or radio access network node, such as 126 (only one node is shown for simplicity). The radio access network node 126 may be backhauled to the core network 124. The UE 110 may communicate with the carrier network 120 via the radio access network 122 using the air interface 140. The carrier network 120 may be configured to transmit and route voice, data, and other information between UEs 110, and between UEs 110 and other data networks or other carrier networks terminating at the input edge of the core network 124. The UEs 110 may also be configured to communicate directly with each other via a direct air link. For example, as... Figure 1 As shown, UE 112 can communicate directly with UE 114 via direct link 130, UE 112 can communicate directly with UE 116 via direct link 132, and UE 114 can communicate directly with UE 116 via direct link 134. This direct communication of data via direct links between UEs does not require any data relay from radio access network node 126.

[0015] UE 110 may include various types of mobile and fixed network devices for a variety of applications. For example, UE 110 may include, but is not limited to, mobile phones, tablets, personal digital assistants, laptops, desktop computers, Internet of Things (IoT) devices, distributed sensors, and vehicular network devices. In particular, vehicular network devices may be installed in vehicles as integral parts or auxiliary equipment. Therefore, vehicles may interconnect with each other or with other network devices via direct pass-through links 130, 132, and 134, and / or indirectly via air interface 140 through carrier network 120. Hereinafter, for simplicity, vehicular devices may be referred to as vehicles.

[0016] The term V2X can be used to refer to the exchange of information between a vehicle and another network device X, according to a set of V2X communication protocols and specifications. Network device X can be another vehicle, a pedestrian UE, a roadside unit UE, or a specific destination in the Internet (e.g., a data network terminating at the edge of the core network 124). Correspondingly, V2X can be categorized into several types, including but not limited to vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N). For example, V2X provides more efficient communication for delivering entertainment content to vehicles and improving vehicle safety.

[0017] The V2X protocol can be used to implement a variety of advanced application scenarios with higher communication requirements than conventional applications based on pass-through communication. These more advanced V2X application scenarios can include, but are not limited to, application categories such as vehicle platooning, extended sensor sharing, semi-autonomous or fully autonomous driving, and remote driving. Data transmission requirements can depend on the specific data services required by these applications. For example, V2X applications may require packet sizes of 50 to 12,000 bytes, message transmission rates of 2 to 50 messages per second, maximum end-to-end transmission latency of less than 3 to 500 milliseconds, data transmission reliability of 90% to 99.999%, data transmission rates of 0.5 to 1,000 Mbps, and a communication range of 50 to 1,000 meters. These requirements may vary between different data services.

[0018] Furthermore, V2X protocols may need to support the coexistence of various communication broadcast types, including broadcast as well as unicast and multicast (or multicast). Additionally, a single UE can support the simultaneous transmission or reception of up to a predetermined maximum number of unicast, multicast, or broadcast pass-through communication sessions. For example, a single UE can simultaneously support up to 32 unicast, multicast, or broadcast pass-through communication sessions. V2X pass-through communication sessions can further support multiple Quality of Service (QoS) streams with different QoS profiles and characteristics, and different levels of QoS granularity. V2X protocols can also be designed to support up to a predetermined maximum number of data retransmissions based on a Hybrid Automatic Repeat Request (HARQ) mechanism. For example, the predetermined maximum number of retransmissions can be set to 32. As a result of dynamic retransmission schemes, in V2X applications, the transmission time of a single data block may become uncertain and unpredictable.

[0019] Therefore, for the above application scenarios, V2X communication via the UE direct link may require improved resource allocation / management / utilization mechanisms not only for direct link communication resources, but also for resources within the UE software / hardware, such as HARQ process resources in the UE's MAC layer used for data transmission and retransmission.

[0020] For pass-through link communication resources, there are two types of pass-through link resource allocation modes: Mode 1 and Mode 2. In Mode 1, the radio access network node can schedule pass-through link resources for UE use for pass-through link communication. In Mode 2, the UE, rather than the radio access network node, determines the pass-through link transmission resources within the pass-through link resources configured by the radio access network node or within pre-configured pass-through link resources. The UE can operate in either mode for data transmission, or it can operate in both modes, which can be referred to as mode coexistence.

[0021] HARQ process resources are provided by the MAC layer and may be limited due to the potentially large number of pass-through link communication sessions that the UE may need to support simultaneously. Therefore, HARQ process resources may need to be shared among different services under a sharing mechanism to improve data communication performance and reliability, and reduce transmission latency for services that require high performance and reliability.

[0022] The following implementation provides an example of HARQ process resources being shared by different data services in the UE's MAC layer based on an exemplary preemption mechanism. Since the operation of the preemption mechanism in a particular UE may depend on information from other UEs and the carrier network, it may not be entirely left to a specific UE as a design choice. Specifications of parameters and other aspects of communication may need to be included as part of the pass-through standard for interoperability purposes between UEs.

[0023] While the implementations disclosed below are driven by V2X-related application scenarios, the underlying principles apply to any type of UE and any other UE-to-UE direct link communication resource management for applications not limited by V2X. Furthermore, although these implementations specifically relate to the sharing and preemption of HARQ resources in the UE's MAC layer, the underlying principles can be applied to providing other MAC resources, or hardware / software resources related to other layers in the communication stack.

[0024] Figure 2 An example communication protocol stack structure 200 is shown involving pass-through communication between UE 202 and UE 204. The communication protocol stack may include layers 230 and 240. Layer 230 may alternatively be referred to as Layer 1 and includes, for example, physical layers 218 or 228. Layer 240 may be referred to as Layer 2 and includes, for example, MAC protocol 218 or 226, followed by Radio Link Control (RLC) protocol 214 or 224, Packet Data Convergence Protocol (PDCP) 212 or 222, and Serving Data Adaptation Protocol (SDAP) 210 or 220. During the various phases of pass-through communication between UE 202 and UE 204, the aforementioned protocol entities may communicate with each other via pass-through control or a data channel as indicated by 250.

[0025] Once by Figure 2 Cut-through link communication sessions (unicast, multicast, or broadcast sessions) established at higher protocol layers (such as the Non-Access Straight Layer (NAS) layer, not shown in the diagram), can be handled by the SDAP entity. A cut-through link communication session can include multiple QoS streams carrying service data with different QoS requirements. Figure 2 In this context, the SDAP entity can be responsible for performing QoS stream processing. Specifically, the SDAP entity can group QoS streams and map them to various assigned radio bearers. In cases where the communication session includes a multicast / broadcast session targeting multiple UEs, the SDAP entity can also duplicate a set of QoS streams to map that set of streams to a radio bearer for unicasting multicast / broadcast data to a specific single UE among the multiple target UEs, or to map that set of QoS streams to another separate radio bearer for multicast / broadcasting multicast / broadcast data to a subset of UEs among the multiple target UEs. Such QoS stream processing is described in detail in PCT International Patent Application No. PCT / CN2019 / 114627, which belongs to the same applicant as this patent application and was filed with the Chinese Patent Office on October 31, 2019, the entire contents of which are incorporated herein by reference.

[0026] PDCP 212 or 222 can be responsible for header compression and encryption, and perform integrity protection on the data payload in the radio bearer. PDCP 212 or 222 may include independent PDCP entities, each configured to process each radio bearer. For example, RLC entity 214 can be responsible for segmenting, reordering, duplicate detection, error detection, and recovering the data carried in the radio bearer to generate data transmission units as logical channels.

[0027] MAC entity 216 or 226 may be responsible for mapping the logical channel associated with RCL entity 214 to physical radio resource blocks to generate transport blocks (TBs) that will be transmitted by the PHY layer 218 using the allocation of the corresponding physical resource blocks.

[0028] MAC entities 216 or 226 are also responsible for managing the transmission and retransmission of TBs. A TB may need to be retransmitted when a previously attempted transmission fails or is not acknowledged. The management of TB transmission and retransmission can be handled by a HARQ entity within the MAC entity. A HARQ entity can include multiple HARQ processes as MAC hardware / software resources, which can be individually allocated to each TB for transmission and retransmission management according to the HARQ specification. Each HARQ process can only be associated with one TB at a time and can assist only one TB. The number of HARQ processes configured within a HARQ entity may not be unlimited. For example, the number of HARQ processes in a HARQ entity can be predetermined. In other words, the number of TBs requesting transmission / reception may exceed the number of HARQ processes. In this case, HARQ processes may need to be effectively shared by the TBs.

[0029] In some implementations, HARQ processes can be shared based on a method similar to resource preemption. This mechanism... Figure 3 This is explained in the text. Figure 3 It applies to both transmitting UEs and receiving UEs. Specifically, Figure 3 HARQ entity 302 and HARQ processes 310, 312, 314, 316 and 318 are shown (with black boxes). Figure 3 It also shows a brief illustration of the HARQ process allocation or association for multiple TBs that need to be transmitted or received at a specific time. Figure 3 In the diagram, each shading line corresponds to a TB. For example, HARQ process 310 is assigned to TB 320, HARQ process 312 is assigned to TB 322, HARQ process 316 is assigned to TB 324, and HARQ process 318 is assigned to TB 326. Figure 3 A HARQ process 314 that is idle and available for allocation is shown. Figure 3 Two new TBs, TB 328 and TB 330, are also shown in the waiting transmission queue, and no HARQ process has been assigned to them. This may be due to... Figure 3 The TB used for receiving is not shown. The HARQ processes used for transmitting and receiving TBs can be configured independently. For example, there may be a predetermined number of transmit HARQ processes in the MAC entity for transmitting / retransmitting TBs, and similarly, there may be a predetermined number of independent receive HARQ processes in the MAC entity for receiving / re-receiving TBs.

[0030] An exemplary preemption mechanism can be implemented as follows. The MAC entity can assign preemption states and priorities to all TBs that are already associated with a HARQ process or not yet associated with one. The preemption state of a TB with index j can be represented by Sj. The preemption priority of a TB with index j can be represented by Pj. The MAC entity can perform the allocation and preemption process based on the preemption states Sj and preemption priorities Pj of all TBs, which may be allocated to or not allocated to a HARQ process. Figure 3 In this context, each of TB320, 322, 324, 326, 328, and 330 is associated with a (Pj, Sj) pair, as indicated by 340, 342, 344, 346, 348, and 350.

[0031] In some implementations, a TB already associated with a HARQ process can maintain its association to continue transmitting / retransmitting or receiving / re-receiving data, or the associated HARQ process can be preempted by another TB, and the TB can be forcibly released from its association with the HARQ process. The buffer associated with the HARQ process can be flushed, and the TB will then lose its current opportunity to transmit / retransmit or receive / re-receive. Unassigned TBs not currently associated with a HARQ process can be assigned to currently available HARQ processes. If no HARQ process is available, the MAC, based on the preemption status and preemption priority information, can perform a preemption process to potentially preempt a HARQ process currently associated with another TB, forcing the other TB to release its HARQ process and assigning the released HARQ process to an unassigned TB to gain the opportunity to transmit or receive data. For a transmitting UE, if preemption fails, the service data in the unassigned TB is either reassembled during the LCP process to obtain another authorization or is discarded. For a receiving UE, if preemption fails, the service data is discarded and not stored in any HARQ process. The term TB (Transmit / Retransmit or Receive / Re-receive Opportunity) is used to indicate that a TB and associated HARQ information will be associated with the HARQ process, the TB will be stored in the HARQ buffer of the HARQ process, and the TB will be transmitted / retransmitted or received / re-received within the pass-through link resource authorization managed by the HARQ process.

[0032] exist Figure 3In the example shown, since HARQ process 314 is currently available, the MAC entity can assign HARQ process 314 to one of queues TB 328 or 330. In one implementation, the MAC entity can select a TB from the TB queues to allocate the available HARQ process based on the preemption status and preemption priority of the queue TB. After allocating the available HARQ process 314 to one of TBs 328 and 330, the remaining TBs can subsequently participate in the preemption process. Depending on the preemption status and preemption priority of each TB, it may or may not preempt one of the TBs currently allocated the HARQ process.

[0033] As further described below, the preemption status and preemption priority of a TB can change over time, causing the MAC entity to dynamically allocate and preempt HARQ processes at different times. For example, a high-preemption-priority TB that may not be preempted at a certain time may have its priority reduced at a later time, and its associated HARQ process may be preempted by a queue TB with a higher preemption priority at a later time.

[0034] The preemption priority Pj associated with TB can be determined based on a variety of exemplary static or dynamic parameters, including but not limited to:

[0035] Priority information in the Direct Link Control Information (SCI). This SCI can be carried in the Physical Direct Link Control Channel (PSCCH) and received by the MAC entity of the receiving UE. This priority information can be determined by the transmitting UE based on the characteristics of the QoS flows included in the TB being transmitted.

[0036] • The channel busy ratio (CBR) of the transmission resource pool used by the transmission UE associated with TB;

[0037] • Packet delay budget (PDB) associated with TB;

[0038] • The maximum number of retransmissions associated with TB;

[0039] • The ratio of the number of TBs transmitted by the first wireless user equipment to the maximum allowed number of retransmissions;

[0040] • The duration of TB associated with the active HARQ process;

[0041] • The number of code block groups (CBGs) that have been successfully transmitted in TB;

[0042] • The ratio of successfully transmitted CBG to the total number of CBG in TB; or

[0043] • The resource reservation status indicated in SCI (i.e., the number of retransmission resources successfully reserved, or the time offset between the current resource and the furthest reserved retransmission resource, or both) indicates the next or the next few retransmissions associated with TB.

[0044] The preemption priority of a TB can be derived based on a weighted combination of these parameters or in any other way. In some implementations, a smaller priority number can indicate a higher priority. For example, the preemption priority Pj can be mapped from a combination or a single value from the list above, such as priority information and CBR information in the SCI. The mapping rules or mapping table can be configured by the network node or based on a pre-configuration in the UE. Considering that multiple TBs may have the same Pj, the UE can implement a mechanism to determine which of the multiple TBs gains or loses the opportunity to receive or retransmit. Other factors or parameters can be used for tie breaker. For example, when multiple TBs have the same Pj, the TB with the lower PDB value can be assigned a higher priority.

[0045] A TB with a higher preemption priority (lower Pj) can preempt the HARQ process associated with a TB with a lower preemption priority (higher Pj). In another implementation, an offset can be considered during the preemption process. An offset can be added to the preemption priority of the TB that wants to preempt the HARQ process, and the TB will participate in the preemption process with the new preemption priority. For example, without an offset, TB1 with a preemption priority of 5 can preempt the HARQ process associated with a TB with a preemption priority of 7. However, when the offset is 2, the TB with a preemption priority of 5 cannot preempt the HARQ process associated with a TB with a preemption priority of 7 because, considering the offset, TB1 has the same preemption priority as other TBs with a preemption priority of 7. The offset can be configured by the network or based on a pre-configuration. As shown in the list above, some parameters, such as PDB, CBR information, maximum retransmission count, and the ratio of the number of TBs, may have already been transmitted by the first radio user equipment. In contrast, the maximum number of retransmissions allowed associated with a TB may need to be sent from the transmitting UE to the receiving UE via a Layer 1 or Layer 2 link (see [link to Layer 1 and Layer 2]). Figure 2 (230 and 240), or it can be derived based on partial information already sent to the RX UE. For example, based on priority information in the SCI and the transmitted CBR parameters, the maximum number of transmissions can be derived based on specific rules (such as a mapping table configured by the network or pre-configured). For example, such a Layer 1 or Layer 2 link may include SCI, MAC CE, or Radio Resource Control (RRC) signaling (RRC layer is part of Layer 2 in the control plane, although in...). Figure 2(Not explicitly shown in the text). Because these parameters need to be transmitted between UEs, the structure of these signaling messages may need to be redesigned to accommodate them. For example, bit allocation in the SCI could be made to include bits that can be used to indicate the values ​​of these parameters, such as PDB and CBR, which can be carried in the SCI. In another example, information such as PDB or CBR is carried in the MAC CE. Furthermore, since such inter-UE communication is required for the receiving UE to determine the preemption priority of the TB and thus effectively perform the preemption process, HARQ process resource allocation may not always be left to a single UE. Therefore, HARQ process resource allocation and preemption processes may require some interoperability between UEs.

[0046] In some implementations, the preemption state Sj associated with TB may include, but is not limited to, the following states:

[0047] • No preemption means that a TB will not be included in the preemption process. In other words, a HARQ process associated with a TB in a no-preemption state cannot be preempted by other TBs, and will not preempt other TB HARQ processes to obtain a HARQ process.

[0048] • Based on the preemption of Pj, this means that TB will be included in the preemption process and will gain or lose the opportunity to transmit / retransmit or receive / re-receive, depending on its Pj value compared to other TBs.

[0049] • Abandoned, meaning TB will lose its association with any HARQ process and will lose the opportunity to transmit / retransmit or receive / re-receive.

[0050] • Authorized: This means that the TB will always be associated with the HARQ process to obtain opportunities for transmission / retransmission or reception / re-reception. For example, service data similar to SRB (Signaling Radio Bearer) or URLLC (Ultra-Reliable Low-Latency Communication) can be assigned to an authorized preemption state, meaning that such data can always be served with the highest priority. If all TBs in a preemption are in the "authorized" state, preemption can be performed based on other information such as the factors listed above used to determine the preemption priority Pj, or it can be left to the UE to implement.

[0051] These states may or may not be exclusive. For any TB not associated with any HARQ process, its preemption status can be "preempted by Pj" or "authorized". For any TB associated with a HARQ process, its preemption status can be "no preemption", "preempted by Pj", "abandoned", or "authorized".

[0052] With a more detailed description of the preemption state and preemption priority, the exemplary implementation of the HARQ process allocation and preemption process described above can be further defined and described as follows: When a MAC entity determines that a new TB needs to be transmitted or received, if an available HARQ process exists, the new TB is allocated and associated with the available HARQ process to obtain the opportunity to transmit or receive. However, if no available HARQ process exists, the new TB will enter the HARQ process preemption process to compete with all other TBs in the "preemption according to Pj" state.

[0053] The preemption status Sj of TB may be determined / affected by the following factors, including but not limited to:

[0054] • All TBs associated with the HARQ process can be further associated with timers. Timers for specific time periods can be used to fully or partially determine the preemption state of a TB. Specifically, the expiration of a timer indicates that a TB has been associated with the HARQ process for a predetermined time period and can trigger a change in the TB's preemption state. For example, before the timer expires, the TB's preemption state Sj can be "no preemption," and after the timer expires, the TB's preemption state Sj can be modified by the HARQ entity to "preemption based on Pj." In some other implementations, after the timer expires, the TB's preemption state Sj can be modified to "abandoned," which will result in a direct loss of transmission / retransmission or reception / re-reception opportunities.

[0055] The preemption state Sj of TB can be modified according to the indication in SCI. For example, SCI can carry 1 or 2 bits of information indicating the preemption state Sj of the corresponding TB. In a specific example, SCI can indicate that TB has a "no preemption" state. In another example, SCI can indicate that TB has a "preemption according to Pj" or "gone" state.

[0056] The time period associated with the aforementioned TB can be predetermined, or it can be dynamically determined based on parameters including but not limited to the following:

[0057] Priority information in the Straight-through Link Control Information (SCI).

[0058] • Channel Busy Rate (CBR) of the transport resource pool used by the transport UE associated with TB;

[0059] • Packet latency budget (PDB) associated with TB;

[0060] • The maximum number of retransmissions associated with TB;

[0061] • The ratio of the number of TBs transmitted by the first wireless user equipment to the maximum allowed number of retransmissions;

[0062] • The duration of TB associated with the active HARQ process;

[0063] • The number of code block groups (CBGs) that have been successfully transmitted in TB;

[0064] • The ratio of successfully transmitted CBG to the total number of CBG in TB; or

[0065] • The resource reservation status indicated in SCI (i.e., the number of retransmission resources successfully reserved, or the time offset between the current resource and the furthest reserved retransmission resource, or both) indicates the next or the next few retransmissions associated with TB.

[0066] The time period of the timer can be derived or mapped from the parameters in the list above, based on a configuration that includes pre-configured mapping rules or mapping tables from the network or UE.

[0067] The timer's time period value can be determined or derived from any one of the above parameters, or from any combination of any two or more of the above parameters. Similarly, some of the above parameters, such as PDB and CBR information associated with the TB, may need to be transmitted from the transmitting UE to the receiving UE via a Layer 1 or Layer 2 link. For example, such a Layer 1 or Layer 2 link may include SCI, MAC CE, or RRC signaling. Because these parameters need to be transmitted between UEs, the structure of these signaling messages may need to be redesigned to accommodate them. For example, the bit allocation in the SCI signaling message may be made to include bits that can indicate the values ​​of these parameters. Furthermore, because such inter-UE communication is required for the receiving UE to determine the timer value and the preemption status of the TB, HARQ process resource allocation may not always be left to a single UE. HARQ process resource allocation and preemption procedures may require some interoperability between UEs.

[0068] In the above embodiments, more detailed policies or configurations, including deriving Pj / Sj based on mapping rules indicating how to map the relevant listed parameters to the values ​​of Pj and Sj, dynamic modification of Pj / Sj, and specific preemption procedures between TBs, can originate from and be specified in, for example, RRC messages, System Information Block (SIB) messages, or as pre-configuration. Policies or configurations can be based on different UE states. For example, for UEs within network coverage, or if the UE is in the RRC_CONNECTED state, configuration can be made via RRC signaling. On the other hand, if the UE is in the RRC_Idle or RRC_Inactive state, configuration can be made via SIB messages. Finally, if the UE is not within network coverage, it can act according to the pre-configuration.

[0069] The HARQ resource allocation and preemption mechanism described above can be applied to a detailed exemplary implementation in a receiving UE (RX UE). Specifically, after establishing a unicast session or identifying a multicast (or broadcast) service targeting the UE, the AS layer can be configured as a Layer 2 ID. Based on the Layer 2 ID, the receiving UE can derive the corresponding Layer 1 ID. Based on the Layer 1 ID, the corresponding SCI associated with the Layer 1 ID in the receiving resource pool can be monitored.

[0070] If the Layer 1 ID in the received SCI matches the Layer 1 ID corresponding to the unicast link or multicast / broadcast service of interest to the UE, and if an available HARQ process exists, the corresponding SCI and HARQ information can be stored in the HARQ entity. TBs can be received based on the resource information included in the SCI. The received TBs can be stored in the HARQ buffer associated with the HARQ process.

[0071] When no receive HARQ process is available, the MAC entity can preempt the receive HARQ process carried in the PSSCH indicated in the SCI. For example, all TBs with a preemption status of "preemption based on Pj" can participate in the preemption process. The HARQ process associated with a TB with a higher Pj value (lower preemption priority) may be preempted and lose the opportunity to receive / re-receive, while the TB associated with a newly received SCI may be allowed to preempt the lower-priority TB and be allocated the HARQ process released by the lower-priority TB. For example, for a HARQ entity with 10 receive HARQ processes all associated with a TB, there are no available HARQ processes for receiving a new TB. An SCI is detected in a subframe, which may indicate that the priority of the TB associated with the SCI is "4". During the preemption process, it is recognized that 8 of the 10 TBs associated with the receive HARQ process have a preemption status of "preemption based on Pj" and a preemption priority of: "10, 2, 3, 4, 5, 10, 4, 4". Therefore, one of the HARQ processes associated with a preemptive TB with a priority of "10" will lose its chance to receive / re-receive, and the service data in the corresponding HARQ process will be refreshed. The non-associated TB will be associated with a preemptive HARQ process and will gain its receiving opportunity. If the non-associated TB has the lowest priority, such as 11, then this type of TB will lose its receiving opportunity and will be discarded, and therefore will not be associated with any HARQ process.

[0072] With the reception of a new TB, its preemption state and priority may change. For example, the TB's preemption state Sj can change when a timer associated with the TB expires, or when the state indicated in the SCI signaling associated with the TB changes. Specifically, the TB's preemption state may change from "no preemption" to "preemption according to Pj," and it can participate in future preemption processes. As another example, the TB's preemption state may change from "no priority" to "abandoned," and therefore it may not participate in future preemption processes and lose its association with its HARQ process. For instance, if a TB associated with a preemption state of "no preemption" receives an SCI indicating an intention to release the associated HARQ process, the TB's preemption state will change to "abandoned," and the buffer associated with the HARQ process will be flushed. The released HARQ process will then be able to associate with other TBs.

[0073] For example, the time period of the timer associated with the TB can be determined by the CBR of the resource pool of the transmitting UE. Specifically, a higher CBR can result in a lower timer period. In this case, the timer associated with the TB will expire earlier, and the preemption status of the TB may change from "no preemption" to "abandoned" or "preemption according to Pj" due to the timer expiration. Therefore, the TB will release the HARQ process earlier, thus making more efficient use of HARQ process resources. In another example, the time period of the timer associated with the TB can be determined by the resource reservation status of the TB. Specifically, if the resource reservation in the SCI associated with the TB indicates the scheduling of future retransmissions, the timer period can be extended so that retransmissions are not missed due to timer expiration. For example, the resource reservation in the SCI can indicate the time offset between the current TB resource and one of the furthest reserved resources, so the timer can be extended to cover the range of the furthest reserved resource. As another example, the time period of the timer associated with the TB can be determined by the priority information in the SCI or the PDB value associated with the TB. Specifically, a higher priority or a lower PDB in the SCI may result in a longer timer period. Timers can be derived from one or more combined parameters, and the derived rules can be configured by the network through mapping rules or mapping tables.

[0074] In some cases, a TB's preemption state may be configured as "authorized." For example, a TB may include high-priority service data or service data with strict PDB requirements, such as Ultra-Reliable Low-Latency Communication (URLLC) services, and therefore can be configured as "authorized." In some other cases, a TB may be associated with authorization from a network node in Mode 1 (Radio Access Network Nodes Allocate Cut-Through Link Communication Resources). Given that transmissions or receptions in Mode 1 have higher priority than those in Mode 2, a TB can be given an "authorized" state to always have a chance to receive. In the presence of multiple TBs with an "authorized" state and insufficient HARQ processes, the preemption priority Pj associated with the TB can be used to determine which TB gets the chance to receive. TBs in the authorized state can be multiplexed from a specific LCH or QoS flow based on the LCH (Logical Channel) configuration, and the specific LCH or QoS flow is configured by the network or based on pre-configuration. The derived rules for determining the preemption state of a TB based on the LCH / QoS flows it contains are configured by the network or based on pre-configuration.

[0075] In some cases, the preemption priority Pj associated with a TB can be determined by the priority information in the associated SCI. For example, a higher priority in the SCI may result in a lower Pj value or a higher preemption priority. For instance, the SCI associated with a TB may indicate a priority of 3, which would result in a Pj of 3 derived according to mapping rules or derivation methods provided by the network or pre-configuration. In some other cases, the preemption priority Pj associated with a TB may change as more TBs are received. For instance, as more TBs are received, the preemption priority Pj associated with the TB may decrease as the time the TB occupies the HARQ process increases, or as the number of TBs increases. In some cases, the preemption priority Pj associated with a TB may change based on the number or ratio of successfully received CBGs in the TB. For instance, when the ratio of the number of successful CBGs to the total number of CBGs in the TB becomes higher, the value of the preemption priority Pj associated with the TB may decrease, resulting in a higher preemption priority to increase the likelihood that the entire TB will be successfully received. For instance, the ratio of the number of successful CBGs to all CBGs may be 50%, which would result in a preemption priority Pj of 5 (higher than the original 10). The export method, mapping rules, or mapping table can be configured by the network or based on pre-configuration. In some other cases, some or all of the above factors can be considered to determine the preemption priority of receiving TBs.

[0076] The HARQ resource allocation and preemption mechanism described above can also be applied to detailed exemplary implementations in transport UEs (TX UEs). In this exemplary implementation, it is assumed that the transport UE operates in mode 2 or mode coexistence (the transport UE shares the HARQ process and other resources in the UE between mode 1 and mode 2 transport).

[0077] In this exemplary embodiment, after establishing a unicast session or identifying a multicast / broadcast service targeting another UE, the AS layer of the transport UE can be configured with a Layer 2 ID. Based on the Layer 2 ID, the corresponding Layer 1 ID can be derived. Based on the Layer 1 ID, service data can be transmitted on a pass-through link resource license in the transport resource pool.

[0078] When one or more transport HARQ processes are available, the transmission / retransmission of a TB can occur after the TB has been allocated and associated with an available HARQ process. The TB can be stored in a HARQ buffer associated with the HARQ process, and the HARQ process can be responsible for providing the transmission of the TB based on pass-through link resource grants.

[0079] However, when no transport HARQ process is available, the MAC entity can perform a preemption process for the transport TB at the point in time after a resource reservation in Mode 2 or a pass-through link resource grant is issued from a network in Mode 1 (e.g., a radio access network node), and before the pass-through link resource slot indicated in the pass-through link resource grant. All TBs with a preemption state of "preemption based on Pj" can participate in the preemption process. In some implementations, a TB associated with a HARQ process with a higher Pj value (lower priority) can be preempted and lose its association with the current HARQ process, and thus lose its transmission / retransmission opportunity, while the transport TB can be allocated a released HARQ process for transmission / retransmission. For example, for a HARQ entity with 10 transport HARQ processes all associated with a TB, no HARQ process is available to transport a new TB. Unassociated TBs associated with the SCI have a priority of "4". During preemption, it is recognized that 8 out of the 10 TBs associated with the transmission HARQ process have a preemption state of "preemption according to Pj", and their preemption priorities are: "10, 2, 3, 4, 5, 10, 4, 4". Therefore, one of the HARQ processes associated with the TB with a preemption priority of "10" will lose its transmission / retransmission opportunity, and the service data in the corresponding HARQ process will be refreshed. Unassociated TBs will be associated with the preempted HARQ processes and will gain their transmission opportunities. If the unassociated TB has the lowest priority, such as 11, then this type of TB will lose its transmission opportunity and will be discarded, and therefore will not be associated with any HARQ process.

[0080] During the transmission and retransmission of a TB, the preemption state Sj of the TB can change. For example, when the timer associated with the TB expires, the preemption state Sj of the TB will change. In some exemplary cases, the preemption state of the TB can change from "no preemption" to "preemption according to Pj" and can participate in future preemption processes. In some other exemplary cases, the preemption state of the TB can change from "no preemption" to "abandoned" and may lose its transmission opportunity and may not participate in future preemption processes. For example, for a TB associated with a preemption state of "preemption according to Pj" or "no preemption," at some point, the expiration of the timer indicates the intention to release the associated HARQ process, then the TB's preemption state will change to "abandoned," and the buffer associated with the HARQ process will be flushed. The released HARQ process will then be able to associate with other TBs for future transmission.

[0081] In some implementations, the time period value of the timer associated with the transmission TB can be determined by the CBR of the resource pool of the transmitting UE. A higher CBR may result in a smaller timer period value, and therefore, the timer associated with the transmission TB will expire earlier, and the preemption status of the transmission TB, for example, may change from "no preemption" to "abandoned" earlier. In some implementations, the timer associated with the transmission TB can be determined by the resource reservation status of the transmission TB. For example, when resource reservation is successfully used to schedule future retransmissions, the timer associated with the transmission TB can be extended so that the transmission TB does not miss the opportunity to schedule retransmissions. As another example, when resource reservation for scheduling future retransmissions of the transmission TB is unsuccessful, and any further reservation would violate the TB's PDB requirements, the time value of the timer associated with the transmission TB can be reduced, thereby allowing its HARQ process to be released more quickly so as to utilize the HARQ process more effectively. In some other implementations, the time value of the timer associated with the transmission TB can be determined by the priority associated with the transmission TB (which can be determined based on the characteristics of the QoS stream carried in the transmission TB) or the PDB value associated with the TB. For example, a higher priority or a longer PDB will result in a longer timer value. In some other implementations, the timer value associated with a transmission TB can be determined by the transmission / maximum retransmission count associated with the transmission TB. For example, a higher transmission / maximum retransmission count results in a longer timer value. The timer can be derived from one or more combined parameters (along with CBR, resource reservation status, etc.), and the derivation rules can be configured by the network through mapping rules or mapping tables.

[0082] In some exemplary cases, the preemption state of a transport TB can be configured as "authorized". For example, when a transport TB includes high-priority service data or service data with a strict PDB value (such as URLLC services), it can be configured as "authorized". As another example, when a transport TB is associated with a pass-through link resource authorization from a network node in Mode 1, given that the transport in Mode 1 has a higher priority than in Mode 2, the preemption state of the transport TB can be set to "authorized". In the presence of multiple TBs with an "authorized" state and insufficient available HARQ processes, the preemption priority Pj associated with these TBs can be used to determine which TB gets the transport opportunity.

[0083] In some exemplary cases, the preemption priority Pj associated with a transport TB can be determined by the priority associated with the TB (e.g., based on the characteristics of the QoS flows carried in the transport TB). For example, a higher priority may result in a lower Pj, indicating a higher preemption priority. The preemption Pj associated with a transport TB can change as the transport TB is being transmitted / retransmitted. For example, the preemption priority Pj associated with the transport TB may decrease as the time the transport TB occupies the HARQ process increases or as the number of transmissions / retransmissions increases. In some exemplary cases, the preemption Pj associated with a transport TB can change based on the number or ratio of successfully transmitted CBGs in the transport TB. For example, as the proportion of successful CBGs to all CBGs in the transport TB increases, the value of the preemption priority Pj associated with the transport TB may decrease, resulting in a higher preemption priority to increase the chances of the entire transport TB being successfully transmitted. Timers can be derived from one or more combined parameters (along with CBR, resource reservation status, etc.), and the derivation rules can be configured by the network through mapping rules or mapping tables.

[0084] The following further implementations and examples relate to enhancement mechanisms for Logical Channel Priority (LCP). For example, a logical channel can be coupled with... Figure 2 The PDCP and RLC layers are associated.

[0085] During LCP, the TX UE can allocate grants for specific radio resources to its logical channel (LCH) and generate a TB. Based on the grant or service data in the LCH contained in the TB, the TB can be associated with a property. Each LCH can be uniquely associated with one radio bearer. The term "property" can also be alternatively referred to as an "indicator." For example, a "reliability property" can be alternatively referred to as a "reliability indicator."

[0086] In multicast (or multicast), there are three possible HARQ feedback options. In Option 1, if the RX UE (receiving UE) fails to receive the transmission, only a negative acknowledgement (NACK) is transmitted, and no action is taken upon successful transmission. In Option 2, if the transmission is successful, the RX UE transmits a HARQ acknowledgement (ACK), and if the transmission is not received, it transmits a NACK. In Option 3, the UE does not transmit any feedback. Option 2 offers better transmission reliability compared to Option 1, which may suffer from discontinuous transmission (DTX) issues. Option 3 has the lowest reliability compared to Options 1 and 2.

[0087] In some implementations, to better indicate different feedback reliability and achieve more efficient resource allocation during LCP, the LCH with the finest QoS granularity in the air interface can be associated with reliability attributes.

[0088] In some implementations, the reliability attribute may directly include the various confirmation options described above. The reliability provided for the three options increases in the order of option 3, option 1, and option 2.

[0089] Alternatively, the reliability attribute can be implemented as a numerical value. In some implementations, the reliability attribute value can be implemented as part of the LCH / RB configuration provided by the network nodes on the carrier network side. Each of the aforementioned acknowledgment options can be associated with a segment of the reliability value. Assuming the reliability attribute is represented by a value between 0 and 1, the range of 0-1 can be divided into three segments using two values ​​(e.g., 0.5 and 0.9): 0-0.5, 0.5-0.9, and 0.9-1, corresponding to options 3, 1, and 2, respectively. An LCH with a certain reliability attribute value will be associated with the corresponding feedback option and will accordingly comply with the following LCP procedure. The segmentation rule or the mapping rule from numerical value to acknowledgment option is configured by the network or based on a pre-configuration.

[0090] In some implementations, reliability attribute values ​​as part of the LCH / RB configuration can be provided by the network node. For example, in NR V2X for a UE in RRC_CONNECTED or RRC_Idle / RRC_Inactive states, the direct-link radio bearer (SLRB) can be configured by the base station (gNB or eNB) based on the QoS flows reported by the UE and required to be transmitted, via dedicated signaling or a System Information Block (SIB). In some other implementations, reliability attribute values ​​as part of the LCH / RB configuration can be provided based on a pre-configuration. For example, in a UE in NR V2X with an out-of-coverage (OOC) state, the reliability attribute values ​​of the LCH / RB can be derived based on a pre-configuration, which may include mapping rules from the characteristics of the QoS flows required to be transmitted.

[0091] In some implementations, the LCH reliability indicator can be updated by network nodes of the wireless network via dedicated signaling or broadcast signaling, triggered by or following an update of the configured resource pool or updated group information. In some implementations, the LCH reliability indicator can be updated when triggered by an update of the configured resource pool or updated group information, or after such an update, following a mapping rule received from the wireless network or via a pre-configured QoS flow to the RB. For example, an update to the group information or configuration might prevent Option 2 from being implemented; for instance, the configuration of feedback resources might not allow each RX UE to have independent feedback. Therefore, the LCH reliability indicator may be updated accordingly.

[0092] In the first type of LCP procedure, the granting of radio resources can be associated with reliability attributes. In the first step of the LCP procedure for selecting an LCH, only LCHs that satisfy the reliability attributes associated with that grant can be considered in the subsequent steps of the LCP procedure. For example, the grant might be associated with the reliability attribute of option 2, therefore only LCHs with the reliability attribute of option 2 can be selected for the subsequent steps of the LCP procedure. In another example, the grant might be associated with the reliability attribute of option 2, therefore only LCHs with reliability attributes lower than or equal to feedback option 2 (i.e., feedback option 2, feedback option 1, and feedback option 3) can be selected for the subsequent steps of the LCP procedure.

[0093] In the second step of the LCP process, the destination can be selected. Specifically, the destination can be selected from the pass-through logical channels with the highest priority among the pass-through logical channels that have data available for transmission.

[0094] In the third step of the LCP process, radio resources are allocated. Specifically, radio resources can be allocated to the LCH selected in the first step and belonging to the destination selected in the second step, based on the LCH's priority (where a higher priority value indicates a lower priority level) and / or the prioritizedBitRate (which sets the Priority Bit Rate (PBR)) and / or the bucketSizeDuration (which sets the Bucket Size Duration (BSD)).

[0095] In some implementations, the TB generated after the LCP process will be associated with a reliability attribute that is identical to the attribute in the authorization. For example, if the authorization has the reliability attribute of Option 2, then the TB will have the same reliability attribute as Option 2. In some implementations, the MAC layer can indicate the reliability attribute associated with the TB to the PHY layer for inclusion in the SCI.

[0096] In the second type of LCP process, authorization may not be associated with reliability attributes. In the first step of the LCP process used to select an LCH based on authorization, reliability attributes may not be considered.

[0097] In the second step of the Type II LCP process for selecting a destination, the destination with the highest priority direct link logical channel can be selected from the direct link logical channels that have data available for transmission.

[0098] In the third step of the second type of LCP process for selecting reliability attributes, a reliability attribute equal to or lower than the LCH with the highest priority selected from the second step of the LCP process can be selected as the reliability attribute. For example, among the LCHs selected from the first step of the LCP process, LCH1 can have the highest LCH priority, and the reliability attribute associated with LCH1 can be selected in the second step of the LCP process. In the presence of multiple LCHs with the same highest LCH priority, another LCH attribute, such as Packet Delay Budget (PDB), can be used as a split decision so that the LCH with the lowest PDB can be selected. For example, if the selected reliability attribute is Option 2, then only LCHs with reliability attribute Option 2 can be selected for the following steps of the LCP process. In another example, if the selected reliability attribute is Option 2, then only LCHs with reliability attributes lower than or equal to Feedback Option 2 (i.e., Feedback Option 2, Feedback Option 1, and Feedback Option 3) can be selected for the following steps of the LCP process.

[0099] In the fourth step of the second type of LCP process, resources are allocated to LCHs that belong to the destination selected in the second step and have the selected reliability attributes in the third step, based on the LCH priority (where a higher priority indicates a lower priority), and / or prioritizedBitRate (which sets the priority bit rate (PBR)); and / or bucketSizeDuration (which sets the token bucket depth (BSD)).

[0100] In some implementations, the TB generated after the second type of LCP process can be associated with a reliability attribute that is the same as the attribute selected in the third step. For example, when the reliability attribute selected in the third step is option 2, the TB can have the same reliability attribute as option 2. In some implementations, the MAC layer can indicate the reliability attribute associated with the TB to the PHY layer for inclusion in the SCI.

[0101] In the third type of LCP process, authorization may not be associated with reliability attributes. In the first step of the LCP process for selecting the LCH, reliability attributes may not be considered.

[0102] In the second step of the Category 3 LCP process for selecting a destination, the destination with the highest priority direct link logical channel can be selected from the direct link logical channels that have data available for transmission.

[0103] In the third step of the third type of LCP process, radio resources are allocated. Specifically, resources are allocated to the LCH selected in the first step based on priority (where a higher priority value indicates a lower priority level) and / or prioritizedBitRate (which sets the priority bit rate (PBR)) and / or bucketSizeDuration (which sets the token bucket depth (BSD)).

[0104] In some implementations, the TB generated after the third type LCP process can be associated with a reliability attribute based on the reliability attribute associated with the LCH contained in the TB. For example, the reliability attribute of the TB can be the highest reliability level among all LCHs contained in the TB. For example, the TB can contain service data from LCH1, LCH2, and LCH3, with reliability attributes of Option 2, Option 1, and Option 1. Therefore, the reliability attribute of the TB can be Option 2. In some implementations, the MAC layer can indicate the reliability attribute associated with the TB to the PHY layer for inclusion in the SCI.

[0105] Finally, in cellular wireless communication systems, there are at least two possible transmission feedback schemes: enabling HARQ feedback and disabling HARQ feedback. If HARQ feedback is enabled, the TX UE will retransmit based on HARQ feedback from the RX UE. If HARQ feedback is disabled, the TX UE will not retransmit based on HARQ feedback from the RX UE.

[0106] In some implementations, to better indicate different QoS levels and achieve more efficient resource allocation during LCP, the LCH with the finest QoS granularity in the air interface can be associated with a HARQ feedback attribute, which can be either HARQ feedback enabled or disabled.

[0107] In some implementations, HARQ feedback attributes can be part of the network node's LCH / RB configuration. For example, in NR V2X for a UE in RRC_CONNECTED or RRC_Idle / RRC_Inactive states, the direct-link radio bearer (SLRB) can be configured by the base station (gNB or eNB) based on the QoS flows reported by the UE and required to be transmitted, via dedicated signaling or a System Information Block (SIB). In some other implementations, HARQ feedback attributes as part of the LCH / RB configuration can be provided based on pre-configuration. For example, in a UE in NR V2X with an out-of-coverage (OOC) state, the HARQ feedback attributes of the LCH / RB can be derived based on pre-configuration, which may include mapping rules from the characteristics of the QoS flows required to be transmitted.

[0108] In the first type of LCP procedure, the granting of radio resources can be associated with HARQ feedback attributes. In the first step of the LCP procedure for selecting an LCH, only LCHs that match the HARQ feedback attributes associated with the granting can be considered in the subsequent steps of the LCP procedure. For example, the granting can be associated with a HARQ feedback attribute that enables HARQ feedback; therefore, only LCHs with HARQ feedback enabled can be selected for the subsequent steps of the LCP procedure.

[0109] In the second step of the LCP process, a destination can be selected. Specifically, the destination with the highest priority direct link logical channel can be selected from the direct link logical channels that have data available for transmission.

[0110] In the third step of the LCP process, radio resources are allocated. Specifically, corresponding radio resources can be allocated to the LCH selected in the first step and belonging to the destination selected in the second step, based on the LCH's priority (where a higher priority value indicates a lower priority level) and / or the prioritizedBitRate (which sets the Priority Bit Rate (PBR)) and / or the bucketSizeDuration (which sets the Token Bucket Depth (BSD)).

[0111] In some implementations, the transport TB generated after the LCP process will be associated with a HARQ feedback attribute that is identical to the attribute in the authorization. For example, if the authorization has a HARQ feedback attribute that enables HARQ feedback, then the TB will have the same HARQ feedback attribute that enables HARQ feedback. In some implementations, the MAC layer may indicate the reliability attribute associated with the TB to the PHY layer for inclusion in the SCI.

[0112] In the second type of LCP process, authorization may not be associated with HARQ feedback attributes. In the first step of the LCP process for selecting the LCH based on authorization, HARQ feedback attributes may not be considered.

[0113] In the second step of the Type II LCP process for selecting a destination, the destination with the highest priority direct link logical channel can be selected from the direct link logical channels that have data available for transmission.

[0114] In the third step of the second type of LCP process for selecting HARQ feedback attributes, the HARQ feedback attribute equal to the LCH with the highest priority selected from the second step of the LCP process can be selected as the HARQ feedback attribute. For example, among the LCHs selected from the first step of the LCP process, LCH1 may have the highest LCH priority, and the HARQ feedback attribute associated with LCH1 can be selected in the second step of the LCP process. In the presence of multiple LCHs with the same highest LCH priority, another LCH attribute, such as packet delay budget (PDB) or reliability, can be used as a split decision, allowing the LCH with the lowest PDB or higher reliability to be selected. For example, if the selected HARQ feedback attribute is disabled HARQ feedback, only LCHs with the HARQ feedback attribute set to disabled HARQ feedback can be selected for the following steps of the LCP process.

[0115] In the fourth step of the second type of LCP process, resources are allocated to LCHs that belong to the selected destination in the second step and have the selected HARQ feedback attributes in the third step, based on the LCH priority (where a higher priority indicates a lower priority level), and / or PrioritizedBitrate (which sets the Priority Bit Rate (PBR)) and / or bucketSizeDuration (which sets the Token Bucket Depth (BSD)).

[0116] In some implementations, the TB generated after the second type of LCP process can be associated with a HARQ feedback attribute that is the same as the attribute selected in the third step. For example, when the HARQ feedback attribute selected in the third step is HARQ feedback enabled, the TB can have the same HARQ feedback attribute that enables HARQ feedback. In some implementations, the MAC layer can indicate the HARQ feedback attribute associated with the TB to the PHY layer for inclusion in the SCI.

[0117] The above description and accompanying drawings provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments described herein. The scope of the claimed or covered subject matter is quite broad. Among other things, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Thus, embodiments can take the form of, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the above-described method embodiments can be implemented by executing computer code stored in memory, by a component, apparatus, or system including memory and a processor.

[0118] Throughout the specification and claims, terms may have subtle, implied, or implicit meanings in the context that go beyond their expressly defined meanings. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to a different embodiment. For example, the claimed subject matter may include combinations of all or some of the exemplary embodiments.

[0119] Generally, terms can be understood at least in part from their usage in the context. For example, terms such as “and,” “or,” or “and / or” as used herein can include a variety of meanings, which depend at least in part on the context in which they are used. Typically, “or” means A, B, and C when used in an associative list, such as A, B, or C, in an inclusive sense, and A, B, or C in an exclusive sense. Furthermore, the term “one or more” as used herein, depending at least in part on the context, can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as “a” or “the” can be understood to indicate singular or plural usage, depending at least in part on the context. Additionally, the term “based on” can be understood to not necessarily convey a set of exclusive factors and may allow for additional factors that are not necessarily explicitly described, depending at least in part on the context.

[0120] References to features, advantages, or similar language in this specification do not imply that all features and advantages achievable by this solution should be or are included in any single implementation thereof. Rather, references to features and advantages are understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, discussions of features and advantages, as well as similar language, throughout this specification may, but not necessarily, refer to the same embodiment.

[0121] Furthermore, in one or more embodiments, the features, advantages, and characteristics of this solution can be combined in any suitable manner. Based on the description herein, those skilled in the art will recognize that this solution can be implemented without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of this solution can be identified in certain embodiments.

Claims

1. A method performed by a first wireless user equipment, comprising: Identify the first transport block TB for transmission to the second wireless user equipment via a pass-through link; Based on the preemption status parameters and preemption priority parameters associated with the first TB, a preemptible active Hybrid Automatic Repeat Request (HARQ) process is determined from among multiple active HARQ processes in the Media Access Control (MAC) layer of the first wireless user equipment using a HARQ process preemption procedure. The preemption status parameters indicate how the first TB participates in the HARQ process preemption procedure, which is shared and competed for by multiple TBs, and the preemption priority parameters are used to quantify the priority of the first TB in preempting or being preempted by other TBs when using one of the multiple active HARQ processes during the HARQ process preemption procedure. Associate the first TB with a preemptible active HARQ process; and The first TB is transmitted to the second wireless user equipment via the pass-through link through the associated active HARQ process, and the first TB is retransmitted to the second wireless user equipment when necessary. The process of determining the preemptible active HARQ process using the HARQ process preemption procedure includes: Determine the availability of idle HARQ processes among the plurality of active HARQ processes; and When no idle HARQ process is available: Identify the preemption state parameters associated with the first TB; Based on the preemption status parameters, determine whether to enter the HARQ process preemption process for the first TB; and The preemptive HARQ process for the first TB is executed in the plurality of active HARQ processes associated with the corresponding plurality of other TBs, in order to identify the preemptible active HARQ process based on the preemptive status parameters of the plurality of other TBs and the preemptive priority parameters corresponding to the first TB and the plurality of other TBs.

2. The method according to claim 1, wherein, The first TB includes a new TB generated by the first wireless user equipment, which was not previously associated with any active HARQ process.

3. The method according to claim 1, wherein, The first TB was previously associated with the active HARQ process before losing its previous association due to the previous preemption process.

4. The method according to claim 1, wherein, The preemption status parameters associated with the first TB and the plurality of other TBs include: No preemption, used to indicate that the corresponding TB will not be included in the preemption process of the HARQ process; The preemption based on the preemption priority parameter is used to instruct the corresponding TB to be included in the preemption process of the HARQ process based on the associated preemption priority parameter. Abandoned, used to indicate that the corresponding TB will lose its association with any HARQ process; or Authorized to indicate that the corresponding TB will always be associated with the active HARQ process.

5. The method according to claim 1, wherein: The first TB and each of the plurality of other TBs are associated with a preemption timer, which is initialized with an expiration time value when associated with an active HARQ process; and At least one of the preemption status parameters associated with the first TB and the plurality of other TBs changes when the corresponding preemption timer expires.

6. The method according to claim 1, wherein, The preemption priority parameter associated with TB is determined based on at least one of the following factors: The channel busy rate (CBR) of the transmission resource pool used by the transmission UE associated with the TB; The packet latency budget (PDB) associated with the TB; Priority information included in the pass-through link control information (SCI) associated with the TB; The maximum number of retransmissions associated with the TB; The ratio of the number of TBs already transmitted by the first wireless user equipment to the maximum allowed number of retransmissions; The duration of the TB associated with the active HARQ process; The number of code block groups (CBGs) of the TB that have been successfully transmitted; The ratio of successfully transmitted CBGs to the total number of CBGs in the TB; or The resource reservation status indicated in the SCI indicates the next or subsequent retransmissions associated with the TB.

7. The method according to claim 6, wherein, The expiration time value associated with the TB is derived based on a mapping rule or mapping table between the CBR, the PDB, or the priority information and the expiration time value.

8. The method according to claim 7, wherein, The mapping rules or mapping table are configured by the wireless network or pre-configured in the first wireless user equipment.

9. The method according to claim 6, wherein, The preemption priority parameter associated with the TB is derived based on a mapping rule or mapping table between the preemption priority parameter value and the listed factors.

10. The method according to claim 9, wherein, The mapping rules or mapping table are configured by the wireless network or pre-configured in the first wireless user equipment.

11. A method performed by a first wireless user equipment, comprising: Determine the communication session ID used to receive the first transport block TB from the second wireless user equipment via a direct link; The cut-through link control information (SCI) is monitored via the physical cut-through link control channel (PSCCH) with a matching communication session ID. Based on the preemption status parameters and preemption priority parameters associated with the first TB, a preemptible active Hybrid Automatic Repeat Request (HARQ) process is determined from among multiple active HARQ processes in the Media Access Control (MAC) layer of the first wireless user equipment using a HARQ process preemption procedure. The preemption status parameters indicate how the first TB participates in the HARQ process preemption procedure, which is shared and competed for by multiple TBs, and the preemption priority parameters are used to quantify the priority of the first TB in preempting or being preempted by other TBs when using one of the multiple active HARQ processes during the HARQ process preemption procedure. Associate the first TB with a preemptible active HARQ process; and According to the preemptible active HARQ process, the first TB is received from the second wireless user equipment via the direct link. The process of determining the preemptible active HARQ process using the HARQ process preemption procedure includes: Determine the availability of idle HARQ processes among the plurality of active HARQ processes; and When no idle HARQ process is available: Identify the preemption state parameters associated with the first TB; Based on the preemption status parameters, determine whether to enter the HARQ process preemption process for the first TB; and The preemptive HARQ process for the first TB is executed in the plurality of active HARQ processes associated with the corresponding plurality of other TBs, in order to identify the preemptible active HARQ process based on the preemptive status parameters of the plurality of other TBs and the preemptive priority parameters corresponding to the first TB and the plurality of other TBs.

12. The method according to claim 11, wherein, The preemption status parameters associated with the first TB and the plurality of other TBs include: No preemption, used to indicate that the corresponding TB will not be included in the preemption process of the HARQ process; The preemption based on the preemption priority parameter is used to indicate that the corresponding TB will be included in the preemption process of the HARQ process; Abandoned, used to indicate that the corresponding TB will lose its association with any HARQ process; or Authorized to indicate that the corresponding TB will always be associated with the active HARQ process.

13. The method according to claim 11, wherein: The first TB and each of the plurality of other TBs are associated with a preemption timer, which is initialized with an expiration time value when associated with an active HARQ process; and At least one of the preemption status parameters associated with the first TB and the plurality of other TBs changes when the corresponding preemption timer expires.

14. The method according to claim 11, wherein, The preemption priority parameter associated with TB is determined based on at least one of the following: The channel busy rate (CBR) of the transmission resource pool used by the transmission UE associated with the TB; The packet latency budget (PDB) associated with the TB; or Priority information included in the pass-through link control information (SCI) associated with the TB.

15. The method according to claim 14, wherein, The expiration time value associated with the TB is derived based on a mapping rule or mapping table between the CBR, the PDB, or the priority information and the expiration time value; and The mapping rules or mapping table are configured by the wireless network or pre-configured in the first wireless user equipment.

16. The method according to claim 11, wherein, The preemption priority parameter associated with TB is derived based on a mapping rule or mapping table between the preemption priority parameter value and the following factors: The channel busy rate (CBR) of the transmission resource pool used by the transmission UE associated with the TB; The packet latency budget (PDB) associated with the TB; Priority information included in the pass-through link control information (SCI) associated with the TB; The maximum number of retransmissions associated with the TB; The number of TBs that have been transmitted by the first wireless user equipment; The duration of the TB associated with the active HARQ process; The number of code block groups (CBGs) of the TB that have been successfully transmitted; The ratio of successfully transmitted CBGs to the total number of CBGs in the TB; or The resource reservation status indicated in the SCI associated with the TB; and The mapping rules or mapping table are configured by the wireless network or pre-configured in the first wireless user equipment.

17. A wireless user equipment comprising one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement the method according to any one of claims 1 to 16.

18. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, which, when executed by one or more processors, causes the one or more processors to perform the method according to any one of claims 1 to 16.

Images