On-demand transmission of suspended hybrid automatic repeat request codebook in mobile communications

Abstract

An apparatus discontinues transmission of a first message of a first traffic type in a first time slot or sub-slot and does not resume the transmission in the first time slot or sub-slot. The apparatus then stores a payload of the first message. The apparatus later fully retransmits the payload in a second time slot or sub-slot after the first time slot or sub-slot.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 202080002911.1, filed on May 27, 2020, entitled "On-demand transmission of hybrid automatic repeat request codebook for interrupted mobile communication". [Technical Field]

[0002] This disclosure generally relates to mobile communications, and more specifically, to on-demand transmission of aborted Hybrid Automatic Repeat Request (HARQ) codebooks in mobile communications. [Background Technology]

[0003] Unless otherwise stated herein, the methods described in this section are not prior art to the claims listed below, and are not admitted as prior art by virtue of being included in this section.

[0004] The 3GPP Technical Specification (TS) Release 16 (Rel-16) for New Radio (NR) allows for the configuration of two simultaneous codebook determination processes. For example, one of these processes can be used for enhanced Mobile Broadband (eMBB), while the other is used for Ultra-Reliable Low-Latency Communication (URLLC). In this example, each Downlink Control Information (DCI) transmits its respective Acknowledgment and Negative Acknowledgment (ACK / NACK) bits to one or the other of these processes. However, in the event of a conflict between two HARQ codebooks with different priorities, the one with the lower priority (e.g., the codebook used for eMBB) will be discarded (e.g., pre-empted / aborted if a transmission is in progress). Typically, this will trigger a retransmission of all downlink (DL) packets that have been acknowledged in the deprioritized HARQ codebook. Therefore, a solution is needed to recover aborted low-priority (eMBB in this example) codebooks. [Summary of the Invention]

[0005] The following summary is illustrative only and is not intended to be limiting in any way. That is, it provides an overview to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious techniques described herein. Selected embodiments are further described in the detailed description below. Therefore, the following summary is neither intended to identify the essential features of the claimed subject matter nor to define the scope of the claimed subject matter.

[0006] The purpose of this disclosure is to provide schemes, concepts, designs, techniques, methods, and apparatus related to the on-demand transmission of HARQ codebooks interrupted in mobile communications. Under various proposed schemes according to this disclosure, solutions for recovering interrupted codebooks are introduced.

[0007] In one aspect, a method may include a processor of the apparatus suspending the transmission of a first message of a first type of service in a first time slot or sub-time slot, and not resuming the transmission in the first time slot or sub-time slot. The method may further include the processor storing the payload of the first message. The method may further include the processor retransmitting the payload in full in a second time slot or sub-time slot following the first time slot or sub-time slot.

[0008] In another approach, a method may include a processor of the device receiving a trigger from a wireless network. The method may further include, in response to receiving the trigger, the processor reporting the status of one or more HARQ procedures to the wireless network.

[0009] It is worth noting that, although the descriptions provided herein may be applicable to certain radio access technologies, networks, and network topologies (e.g., fifth-generation (5G) / NR), the proposed concepts, schemes, and any variations / derivatives thereof can be implemented in and by other types of radio access technologies, networks, and network topologies, such as, but not limited to, Long Term Evolution (LTE), LTE-Advanced, LTE-Pro, Internet of Things (IoT), Industrial Internet of Things (IIoT), and Narrowband Internet of Things (NB-IoT). Therefore, the scope of this disclosure is not limited to the examples described herein. [Attached Image Description]

[0010] The accompanying drawings are included to provide a further understanding of this disclosure, and are incorporated in and constitute a part of this disclosure. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. It will be understood that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of the disclosure.

[0011] Figure 1 This is a diagram of an example network environment that can realize various solutions and schemes according to this disclosure.

[0012] Figure 2 This is a diagram outlining example tables of various proposed schemes according to this disclosure.

[0013] Figure 3 This is a diagram illustrating an example scenario based on an embodiment of this disclosure.

[0014] Figure 4 This is a diagram illustrating an example scenario based on an embodiment of this disclosure.

[0015] Figure 5 This is a diagram illustrating an example scenario based on an embodiment of this disclosure.

[0016] Figure 6 This is a diagram illustrating an example scenario based on an embodiment of this disclosure.

[0017] Figure 7 This is a diagram illustrating an example scenario based on an embodiment of this disclosure.

[0018] Figure 8 This is a block diagram of an exemplary communication system according to embodiments of the present disclosure.

[0019] Figure 9 This is a flowchart of an example process according to an embodiment of the present disclosure.

[0020] Figure 10 This is a flowchart of an example process according to an embodiment of the present disclosure.

Detailed Implementation Methods

[0021] This document discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter, which can be embodied in various forms. This disclosure may be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that the description of this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0022] Overview

[0023] Embodiments of this disclosure relate to various techniques, methods, schemes, and / or solutions related to on-demand transmission of HARQ codebooks interrupted during mobile communications. According to this disclosure, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described separately below, two or more of these possible solutions may be implemented in one combination or another.

[0024] Figure 1 An example network environment 100 is shown that can implement various solutions and schemes according to this disclosure. Figures 2-7 Examples of implementing various proposed schemes in a network environment 100 are shown according to this disclosure. The following descriptions of the various proposed schemes refer to... Figures 1-7 supply.

[0025] Reference Figure 1 In part (A), network environment 100 may include UE 110 wirelessly communicating with wireless network 120 (e.g., a 5G NR mobile network). UE 110 may wirelessly communicate with wireless network 120 via base station or network node 125 (e.g., eNB, gNB, or Transmit-Receive Point (TRP)). Reference Figure 1 In part (B), when the UL transmission of the HARQ codebook for the URLLC scheduled by the DCI arrives in time slot n, the uplink (UL) transmission of the HARQ codebook for the eMBB PUCCH may have already been scheduled by the DCI in time slots n-1 and n. As a result, the UL transmission of the HARQ codebook for the eMBB, which has a lower priority than the URLLC, may be aborted. Therefore, as described herein, UE 110 can perform on-demand transmission of the HARQ codebook that has been aborted during mobile communication based on any of the proposed schemes of this disclosure.

[0026] Under the first proposed scheme according to this disclosure, in the event of a conflict between two HARQ codebooks with different priorities, UE 110 may first abort the UL transmission of information and / or data associated with the earliest, lower-priority codebook, and not retransmit the aborted codebook at the earliest time. Next, under the first proposed scheme, UE 110 may use one of several options to store the actual raw payload bits (e.g., the HARQ codebook). In the first option (hereinafter referred to as "Option S1"), UE 110 may store the raw payload bits until they are overwritten by the next cancellation (storing one rather than multiple codebooks). In the second option (hereinafter referred to as "Option S2"), UE 110 may utilize a First-In-First-Out (FIFO) arrangement to store the raw payload bits associated with each stored codebook until they are overwritten by multiple cancellations. Under one scheme of option S2 (hereinafter referred to as "Option S2a"), assuming the request specifies the time slot (or sub-time slot, depending on the granularity of K1) for the original HARQ to be scheduled for each codebook, UE 110 can retrieve the selected codebook for retransmission at a later time. Under another scheme of option S2 (hereinafter referred to as "Option S2b"), assuming the response specifies the time slot (or sub-time slot, depending on the granularity of K1) for the original HARQ to be scheduled for each codebook, UE 110 can retrieve the contents of all FIFOs for retransmission at a later time. In the third option (hereinafter referred to as "Option S3"), UE 110 can store the original payload bits until they are overwritten by the next HARQ codebook transmission, thus supporting HARQ codebook retransmission regardless of whether priority downgrading has occurred.

[0027] Furthermore, under the first proposed scheme, UE 110 can perform automatic retransmit in full using the initially allocated Physical Uplink Control Channel (PUCCH) resources in a later time slot (or sub-time slot, depending on the granularity of K1). This can occur after one of options S1, S2a, and S3. Alternatively, under the first proposed scheme, UE 110 can perform full retransmission when requested (e.g., by network node 125) using independent arbitrary resources, or possibly in combination with other payloads. This can be accomplished using one of two options. In the first option (hereinafter referred to as "Option R1"), UE 110 can transmit in full in a reported manner when requested by a specific UL-DCI. This option can be performed after one of options S1, S2, and S3. For example, a mechanism similar to Aperiodic Channel State Information (A-CSI) can be used. In the second option (hereinafter referred to as "Option R2"), UE 110 may fully transmit, upon receiving an implicit request (e.g., signaling in DL-DCI), the stored Uplink Control Information (UCI) to be concatenated to the new UCI. This option may be executed after one of Options S1 and S2. A more detailed description of the first proposed scheme is provided below.

[0028] Under the second proposal according to this disclosure, in the event of a conflict between two HARQ codebooks with different priorities, UE 110 can transmit a HARQ acknowledgment (HARQ-ACK) based on the current state of the HARQ procedure. For example, network node 125 can transmit a trigger (e.g., using UL-DCI or DL-DCI), and in response, UE 110 can report the current ACK / NACK status of all HARQ procedures configured by network node 125. Instead of reporting the status of all configured HARQ procedures, network node 125 can use a signal to notify UE 110 which HARQ procedures need to report ACK / NACK, which signal may be part of UL-DCI or DL-DCI. Notably, under the second proposal, it is not necessary to store payload bits. A more detailed description of the second proposal is provided below.

[0029] Figure 2This disclosure presents an example table 200 summarizing the proposed schemes described above. Specifically, Table 200 lists various combinations of storage, erasure, and retransmission methods involved in implementing the proposed schemes. For example, Table 200 shows that payload content can be stored based on option S1 for a single last codebook but not a single selected codebook, multiple selected codebooks, or all codebooks. As shown in Table 200, payload content can be stored based on option S2a for a single last codebook, a single selected codebook, or multiple selected codebooks but not all codebooks. As shown in Table 200, payload content can be stored based on option S2b for all codebooks but not a single last codebook, a single selected codebook, or multiple selected codebooks. As shown in Table 200, payload content can be stored based on option S3 for a single last codebook but not a single selected codebook, multiple selected codebooks, or all codebooks. As shown in Table 200, the payload content for automatic PUCCH can be stored for a single last codebook but not a single selected codebook, multiple selected codebooks, or all codebooks. As shown in Table 200, the payload content of the Automatic PUCCH can be stored for a single final codebook, a single selected codebook, multiple selected codebooks, all codebooks, and all HARQ procedures. The payload content of the Physical Uplink Shared Channel (PUSCH) can also be stored for a single final codebook, a single selected codebook, multiple selected codebooks, all codebooks, and all HARQ procedures.

[0030] Under the first proposed scheme, regarding storage, UE 110 can store the bits to be transmitted when a HARQ codebook transmission is aborted, the abort being due to prioritizing another transmission. In option S1, if a HARQ codebook transmission is aborted (and therefore needs to be stored) while another HARQ codebook has already been stored, the latest codebook can overwrite the earlier codebook, so that at most one codebook is stored at a time. In option S2, if a HARQ codebook transmission is aborted and there are limitations on the number or total size of stored codebooks, the earliest HARQ codebook can be overwritten by the latest one, so that multiple codebooks are stored at a time. In option S3, each HARQ codebook transmission, whether or not it is aborted, can overwrite the contents of the memory (e.g., the memory in UE 110) used to store the last HARQ codebook at any given time. This feature can be used when the PUCCH is transmitted normally (e.g., without de-priority), but the network node 125 fails to successfully decode the PUCCH transmission and requests a retransmission. As an alternative, under the proposed scheme, aborted codebooks may not be overwritten by non-aborted codebooks.

[0031] Under the first proposed scheme, regarding the triggering of retransmission and resource allocation, in option R1, network node 125 can transmit UL-DCI to UE 110 to trigger a retransmission of the PUSCH. Advantageously, since control information can be transmitted on the PUSCH in a similar manner to A-CSI, the same mechanism can be utilized. In the first method of option R1 (hereinafter referred to as "Option R1-1"), a new DCI field can be introduced. For example, a single bit as a new DCI field can be used to trigger a retransmission. Alternatively or additionally, a slot index (or pointer) pointing to a prior time can be used to select the codebook that needs to be retransmitted. In the second method of option R1 (hereinafter referred to as "Option R1-2"), an existing DCI field can be reused to trigger a retransmission. For example, a configurable special value of the Radio Resource Control (RRC) of the A-CSI request field can be used to trigger a retransmission. Alternatively, multiple special values ​​of the A-CSI request field can trigger a retransmission and can be selected among options based on the content of the special values. For example, <special value #1> can specify the earliest codebook to be stored, and <special value #2> can specify all codebooks to be stored.

[0032] Under the first proposed scheme, regarding triggering retransmission and resource allocation, in option R2, network node 125 can transmit DL-DCI to UE 110 to trigger concatenation of the stored HARQ information (or a portion thereof) with the currently selected codebook. The concatenated size can be used in conjunction with the PRI field to select the PUCCH resource for transmission. In the first approach in option R2 (hereinafter referred to as "Option R2-1"), a new DCI field can be introduced for signal notification. For example, a single bit as a new DCI field can be used to trigger concatenation. Alternatively or additionally, a slot index (or pointer) pointing to a previous time can be used to select the codebook requested for retransmission and trigger concatenation. Under the second approach in option R2 (hereinafter referred to as "Option R2-2"), an existing DCI field can be reused for signal notification. As an example, a pre-configured special value for K1 or a combination of K1 and another field (e.g., HARQ) can trigger concatenation. As another example, concatenation can be triggered by a pre-configured special value for the HARQ procedure identifier (ID) (or a special value in another field different from K1). In the third method of Option R2 (hereinafter referred to as "Option R2-3"), concatenation can be triggered using implicit signaling methods (e.g., based on the Radio Network Temporary Identifier (RNTI) and / or search space). Under the fourth method of Option R2 (hereinafter referred to as "Option R2-4"), concatenation can be automatically performed to the earliest PUCCH transmitted after or subsequently in the current time slot or sub-time slot.

[0033] Figure 3 An example scenario 300 for implementing the first proposed scheme is shown according to this disclosure. Figure 3 The example codebook format in a complete retransmission is shown in the diagram. In scenario 300, when a codebook or concatenation of codebooks is transmitted on the PUSCH or PUCCH according to the first proposed scheme, the format can be, for example, but not limited to: {slot #1, size #1, codebook #1, slot #2, size #2, codebook #2…}. Slots (or sub-slots) and sizes can be pre-added to each codebook. The total size can also be pre-set. Furthermore, for certain members within the format, 4 bytes (4-bit nibble) can be used instead of 8 bytes. No variations or derivations are excluded.

[0034] Under the first proposed scheme, several options can be implemented regarding the payload content in retransmissions. In the first option, a specific single codebook can be retransmitted. For example, in cases where at most a single codebook can be stored for retransmission. Alternatively, the earliest or latest codebook can be retrieved for retransmission. In the second option, the DCI can select multiple codebooks for retransmission. For example, the scheduling DCI can specify a sorted list of multiple pointers pointing to the selected previous time slot (or sub-time slot) where priority degradation occurred, requesting the retransmission of the corresponding codebook. In the third option, all codebooks can be retransmitted. For example, the report can include pointers to the previous time slot (or sub-time slot) for each retransmitted codebook, indicating the location where the abort occurred. As an example, the sorted list could be a bitmap (e.g., a 16-bit bitmap), where each bit can represent a time slot (or a sub-time slot used as a K1 unit). In the case of retransmission on the PUSCH, if the allocation and modulation and coding scheme (MCS) results in a bit size larger than the payload, the larger portion can be zero-padded or padded with copies.

[0035] Figure 4 , Figure 5 , Figure 6 and Figure 7 Example scenarios 400, 500, 600 and 700 for implementing the first proposed scheme are shown in this disclosure.

[0036] Reference Figure 4 In scenario 400, at most a single codebook is stored and retransmitted via PUSCH. In scenario 400, UE 110 first receives RRC signaling from network node 125, which configures a special value (e.g., a special value configurable by RRC in the A-CSI field) as a trigger to lower the priority of the HARQ codebook for eMBB services (e.g., by indicating that the transmission priority of URLLC services is scheduled higher than that of eMBB services). In response, UE 110 can store the payload bits of the HARQ codebook for retransmission at a later time. UE 110 can also place the size of the HARQ codebook before the payload. Next, UE 110 can schedule the retransmission of the payload in subsequent time slots or sub-time slots (e.g., as a result of receiving UL-DCI signaling from network node 125). During payload retransmission (e.g., in PUSCH), UE 110 can use the A-CSI reporting mechanism.

[0037] Reference Figure 5In scenario 500, at most a single codebook is stored and retransmitted via PUCCH. In scenario 500, UE 110 first receives RRC signaling from network node 125, which configures a special value (e.g., a special RRC-configurable value for the A-CSI field) as a trigger to lower the priority of the HARQ codebook for eMBB services (e.g., by indicating that the transmission priority of URLLC services is scheduled higher than that of eMBB services). In response, UE 110 can store the payload bits of the HARQ codebook for retransmission at a later time. UE 110 can receive a trigger from network node 125 (e.g., K1 with a pre-configured DL-DCI that specifies the HARQ ACK / NACK timing for a particular PDSCH). Therefore, UE 110 can select a time slot or sub-time slot based on K1. UE 110 can also place the stored codebook before the current codebook specified by K1 to form a concatenated codebook. UE 110 can further select the PUCCH based on the total size of the concatenated codebook. Next, UE 110 can retransmit the concatenated codebook in the PUCCH. If the priority of the PUCCH is reduced, UE 110 can store the concatenated codebook.

[0038] Reference Figure 6 In scenario 600, multiple codebooks are stored in a FIFO arrangement and retransmitted together on the PUSCH. In scenario 600, UE 110 first receives RRC signaling from network node 125, which configures a special value (e.g., a configurable RRC value for the A-CSI field) as a trigger to lower the priority of HARQ codebooks for eMBB services (e.g., by indicating that the transmission priority of URLLC services is scheduled higher than that of eMBB services). In response, UE 110 can store the payload bits of the HARQ codebooks for retransmission at a later time. The codebook size can be pre-stored in the already stored content, and the FIFO arrangement can be used to overwrite the existing stored payload. UE 110 can concatenate all stored codebooks, and UE 110 can pre-configure a bitmap (e.g., a 16-bit bitmap) pointing to the previous time slot or sub-time slot where the start position of all stored codebooks is located. Next, UE 110 can schedule the retransmission of the payload in a subsequent time slot or sub-time slot (e.g., as a result of receiving UL-DCI signaling from network node 125). UE 110 can utilize the A-CSI reporting mechanism to retransmit the payload (e.g., in PUSCH).

[0039] Reference Figure 7In scenario 700, multiple codebooks are stored and retransmitted via PUSCH. In scenario 700, the priority of a HARQ codebook (e.g., codebook 1) associated with eMBB service and scheduled for transmission in time slot n-7 can be reduced. Furthermore, another HARQ codebook (e.g., codebook 2) associated with eMBB service and scheduled for transmission in time slot n-1 can also have its priority reduced. Codebook 1 and codebook 2 can then be concatenated for retransmission in time slot n. A preset bitmap (e.g., a 16-bit bitmap) can be provided with bits indicating the start positions of codebook 1 and codebook 2 in multiple previous time slots or sub-time slots. Padding may optionally be included during retransmission as needed.

[0040] In the second proposed scheme, instead of storing a HARQ-ACK codebook, the state of the requested HARQ procedure can be transmitted based on the current state of the HARQ procedure. In the first option, network node 125 can transmit a trigger to UE 110 (e.g., using UL-DCI or DL-DCI), and in response, UE 110 can report the current ACK / NACK status of all HARQ procedures configured by the network. In the second option, network node 125 can transmit a trigger to UE 110 (e.g., using UL-DCI or DL-DCI), and in response, UE 110 can report the current ACK / NACK status of the marked HARQ procedure as part of the DCI. The signaling method for the HARQ procedure can be explicit (e.g., using the number of HARQ procedures) or implicit (e.g., via a service identifier such as that used for eMBB HARQ procedures). The content of the ACK / NACK report can be a bistate ACK / NACK, a tristate ACK / NACK for canceled ACK / NACK, or "transmitted" indicating that ACK / NACK information has been transmitted. Under the proposed scheme, four states are also possible, such as, but not limited to, ACK transmission, NACK transmission, ACK not transmitted, and NACK not transmitted. Equivalently, the latest ACK / NACK and the New Data Indicator (NDI) bit received along with the associated DCI can be indicated for each HARQ procedure.

[0041] Illustrative Implementation

[0042] Figure 8An example system 800 having at least example device 810 and example device 820 is illustrated according to embodiments of this disclosure. Each of device 810 and device 820 can perform various functions to implement the schemes, techniques, processes, and methods described herein relating to the termination of on-demand transmission of HARQ codebooks in mobile communications, including various schemes relating to the various proposed designs, concepts, schemes, systems, and methods described above, as well as the processes described below. For example, device 810 may be an exemplary embodiment of UE 110, while device 820 may be an exemplary embodiment of network node 125.

[0043] Each of devices 810 and 820 may be part of an electronic device, which may be a network device or UE (e.g., UE 110), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, each of devices 810 and 820 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device such as a tablet calculator, laptop calculator, or notebook calculator. Each of devices 810 and 820 may also be part of a machine-type device, such as an IoT device, home appliance, wired communication device, or computing device, such as a stationary or fixed device. For example, each of devices 810 and 820 may be implemented in a smart thermostat, smart refrigerator, smart door lock, wireless speaker, or home control center. When implemented in or as a network device, device 810 and / or device 820 may be implemented in a network node (e.g., network node 125), such as an eNB in ​​an LTE, LTE-Advanced, or LTE-Advanced Pro network, or a gNB or TRP in a 5G network, NR network, IoT network.

[0044] In some embodiments, each of devices 810 and 820 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. In the various embodiments described above, each of devices 810 and 820 may be implemented in a network device or a UE, or implemented as a network device or a UE. Each of devices 810 and 820 may include... Figure 8At least some of the components shown include, for example, processor 812 and processor 822, respectively. Each of devices 810 and 820 may further include one or more other components (e.g., internal power supply, display device, and / or user interface device) unrelated to the proposed solutions of this disclosure, and therefore, for simplicity and brevity, such components of devices 810 and 820 are... Figure 8 It is not shown in the image and will not be described below.

[0045] In one aspect, each of processors 812 and 822 may be implemented as one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors. That is, even though the singular term "one processor" is used herein to refer to processors 812 and 822, according to the invention, each of processors 812 and 822 may include multiple processors in some embodiments and a single processor in other embodiments. In another aspect, each of processors 812 and 822 may be implemented as hardware (and optionally, firmware) having electronic components including, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, configured and arranged to achieve a specific purpose according to the present disclosure. In other words, according to various embodiments of the present disclosure, in at least some embodiments, each of processors 812 and 822 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks, including those related to the on-demand transmission of a suspended HARQ codebook in a mobile device.

[0046] In some implementations, device 810 may further include a transceiver 816 coupled to processor 812. Transceiver 816 is capable of wirelessly transmitting and receiving data. In some implementations, device 820 may further include a transceiver 826 coupled to processor 822. Transceiver 826 may include a transceiver capable of wirelessly transmitting and receiving data.

[0047] In some embodiments, device 810 may further include a memory 814 coupled to and accessible by processor 812 and capable of storing data therein. In some embodiments, device 820 may further include a memory 824 coupled to and accessible by processor 822 and capable of storing data therein. Each of memory 814 and memory 824 may include random access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitor RAM (Z-RAM). Alternatively or additionally, each of memory 814 and memory 824 may include read-only memory (ROM), such as mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively or additionally, each of memory 814 and memory 824 may include non-volatile random access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0048] Each of devices 810 and 820 may be a communication entity capable of communicating with each other using various proposed schemes according to this disclosure. For illustrative purposes and not for limitation, the following description provides the capabilities of device 810 as a UE and device 820 as a base station of a serving cell of a wireless network (e.g., a 5G / NR mobile network). It is worth noting that although the example implementations described below are provided in the context of a UE, they can be implemented in and executed by a base station. Therefore, although the following description of the example implementations relates to device 810 as a UE (e.g., UE 110), it is also applicable to device 820 as a network node (e.g., network node 125) or base station of a wireless network (e.g., a 5G NR mobile network), such as a gNB, TRP, or eNodeB.

[0049] Under the proposed embodiment of this disclosure, the processor 812 of device 810 can suspend the transmission of a first message belonging to a first type of service to a wireless network (e.g., wireless network 120) via device 820 in a first time slot or sub-time slot, and the transmission is not resumed in the first time slot or sub-time slot. Additionally, the processor 812 can store the payload of the first message in memory 814. Furthermore, the processor 812 can retransmit the payload completely to the wireless network via transceiver 816 and via device 820 in a second time slot or second sub-time slot following the first time slot or sub-time slot.

[0050] In some implementations, when the transmission of the first message is suspended, the processor 812 may suspend the transmission of the first message when it detects that the transmission of the second message of the second type of service is also scheduled in the first time slot or sub-time slot, wherein the priority of the second type of service is higher than the priority of the first type of service.

[0051] In some implementations, the first message may include a first HARQ codebook for the first type of service, and the second message may include a second HARQ codebook for the second type of service. In this case, the first type of service may include eMBB service, and the second type of service may include URLLC service.

[0052] In some implementations, when storing the payload of the first message, the processor 812 may store at most one payload at a time, such that: (a) any payload of any earlier message that is stored is overwritten by the payload of the first message, and (b) the payload of the first message is stored until it is overwritten by the payload of a subsequent second message, and the transmission of the second message is terminated after the second time slot or sub-time slot.

[0053] In some implementations, when storing the payload of the first message, the processor 812 may store multiple payloads at once, such that multiple payloads including the payload of the first message are stored according to a FIFO arrangement until the earliest payload among the multiple payloads is overwritten by a new payload of a new message, and the transmission of the new message is terminated after a second time slot or sub-time slot.

[0054] In some implementations, when storing the payload of the first message, the processor 812 may store the payload associated with each transmission, regardless of whether the transmission is aborted, such that a payload associated with a later transmission is stored to overwrite another payload associated with an earlier transmission.

[0055] In some implementations, when retransmitting the payload in a second time slot or sub-time slot, the processor 812 may automatically transmit the payload using the initially allocated PUCCH resources in the second time slot or sub-time slot.

[0056] In some implementations, processor 812 may perform certain operations during payload retransmission. For example, processor 812 may receive a trigger from the wireless network via transceiver 816 and via device 820. Furthermore, processor 812 may retransmit the payload in the PUSCH via transceiver 816 in response to receiving the trigger.

[0057] In some implementations, upon receiving a trigger, the processor 812 may receive UL-DCI signaling with the trigger indicated by a new DCI field or an existing DCI field. If the trigger is indicated by a new DCI field, the new DCI field may include a single bit or one or more time slot indices indicating a previous time and selecting the payload for retransmission. If the trigger is indicated by an existing DCI field, the RRC configurable value of the A-CSI field may trigger a retransmission.

[0058] In some implementations, processor 812 may perform certain operations during payload retransmission. For example, processor 812 may receive a trigger from the wireless network via transceiver 816 and via device 820. In response to receiving the trigger, processor 812 may perform certain operations. For example, processor 812 may concatenate the payload with one or more other payloads to form a concatenated payload. Furthermore, processor 812 may transmit the concatenated payload in the PUCCH via transceiver 816.

[0059] In some implementations, upon receiving a trigger, processor 812 may receive DL-DCI signaling with a trigger from a wireless network via device 820, the trigger being indicated by a new DCI field or an existing DCI field. In the case where the trigger is indicated by a new DCI field, the new DCI field may include a single bit or one or more time slot indices indicating a previous time and selecting the one or more other payloads. In the case where the trigger is indicated by an existing DCI field, the existing DCI field may include: (a) a pre-configured value for parameter (K1), which specifies the HARQ ACK / NACK timing for a particular PDSCH; and (b) a pre-configured value for the HARQ process ID or a value in another field different from K1.

[0060] Alternatively, triggering can be implicitly indicated based on RNTI or the search space.

[0061] In some implementations, when transmitting a cascaded payload in a PUCCH, the processor 812 may transmit the cascaded payload in the earliest PUCCH after the current time slot or sub-time slot.

[0062] In some implementations, when retransmitting the payload, the processor 812 may transmit a single HARQ codebook, multiple selected HARQ codebooks, or all stored HARQ codebooks associated with a previously aborted transmission. When payload retransmission includes transmitting multiple HARQ codebooks, the multiple HARQ codebooks can be selected via DCI signaling from the wireless network, which specifies a sorted list of pointers for selecting a prior time slot or sub-time slot where transmission of the multiple HARQ codebooks was aborted. When payload retransmission includes transmitting all stored HARQ codebooks associated with a previously aborted transmission, payload retransmission may further include transmitting a report containing multiple pointers, each pointing to a prior time slot or sub-time slot corresponding to all stored HARQ codebooks. In this case, the sorted list may include a bitmap with multiple bits (e.g., a 16-bit bitmap), each bit representing one of the prior time slots or sub-time slots.

[0063] Under the proposed embodiment of this disclosure, the processor 812 of device 810 can receive triggers from a wireless network (e.g., wireless network 120) via transceiver 816 and device 820. Furthermore, in response to receiving a trigger, the processor 812 can report the status of one or more HARQ processes of the wireless network via transceiver 816.

[0064] In some implementations, the trigger may include DCI signaling (e.g., UL-DCI or DL-DCI). In this case, when reporting the status of one or more HARQ procedures, processor 812 may report the current ACK / NACK status of all HARQ procedures configured by the wireless network. Alternatively, processor 812 may include the current ACK / NACK status of at least one HARQ procedure notified by a trigger, which is explicitly reported by the associated HARQ procedure number or implicitly reported by the associated service identifier.

[0065] Explanatory process

[0066] Figure 9An example process 900 is illustrated according to an embodiment of this disclosure. Process 900 may represent one aspect of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More specifically, according to this disclosure, process 900 may represent one aspect of proposed concepts and schemes related to the suspension of on-demand transmission of a HARQ codebook in mobile communications. Process 900 may include one or more operations, actions, or functions shown in one or more of blocks 910, 920, and 930. Although shown as discrete blocks, the individual blocks of process 900 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Furthermore, the blocks / sub-blocks of process 900 may be arranged according to... Figure 9 The execution may proceed in the indicated order or in another order. Furthermore, one or more boxes / sub-boxes of process 900 may be executed repeatedly or iteratively. Process 900 may be implemented by or in devices 810 and 820 or any variant thereof. For illustrative purposes only and not intended to limit the scope, process 900 is described below in the context of device 810 as a UE (e.g., UE 110) and device 820 as a network node (e.g., network node 125) of a wireless network (e.g., wireless network 120), such as a 5G / NR mobile network. Process 900 may begin at box 910.

[0067] At 910, process 900 may include the processor 812 of device 810 suspending the transmission of a first message to a wireless network (e.g., wireless network 120) via device 820 in a first time slot or sub-time slot, the first message belonging to a first type of service, and the transmission not being resumed in the first time slot or sub-time slot. Process 900 may proceed from 910 to 920.

[0068] At 920, process 900 may include processor 812 storing the payload of the first message in memory 814. Process 900 may proceed from 920 to 930.

[0069] At 930, process 900 may include processor 812 retransmitting the payload completely to the wireless network via transceiver 816 and via device 820 to a second time slot or sub-time slot following the first time slot or sub-time slot.

[0070] In some implementations, when suspending the transmission of the first message, process 900 may include processor 812 suspending the transmission of the first message when it is detected that the transmission of a second message of a second type of service is also scheduled in the first time slot or sub-time slot, and wherein the priority of the second type of service is higher than the priority of the first type of service.

[0071] In some implementations, the first message may include a first HARQ codebook for the first type of service, and the second message may include a second HARQ codebook for the second type of service. In this case, the first type of service may include eMBB service, and the second type of service may include URLLC service.

[0072] In some implementations, when storing the payload of the first message, process 900 may include processor 812 storing at most one payload at a time, such that: (a) any payload of any earlier message stored is overwritten by the payload of the first message, and (b) the payload of the first message is stored until it is overwritten by the payload of a subsequent second message, the transmission of the second message being terminated after a second time slot or sub-time slot.

[0073] In some implementations, when storing the payload of the first message, process 900 may include processor 812 storing multiple payloads at once, such that multiple payloads including the payload of the first message are stored according to a FIFO arrangement until the earliest payload among the multiple payloads is overwritten by a new payload of a new message, and the transmission of the new message is terminated after a second time slot or sub-time slot.

[0074] In some implementations, in storing the payload of the first message, process 900 may include processor 812 storing payloads associated with each transmission, regardless of whether the transmission is aborted, such that a payload associated with a subsequent transmission is stored to overwrite another payload associated with an earlier transmission.

[0075] In some implementations, when retransmitting the payload in a second time slot or sub-time slot, process 900 may include processor 812 automatically transmitting the payload using the initially allocated PUCCH resources in the second time slot or sub-time slot.

[0076] In some implementations, during payload retransmission, process 900 may include processor 812 performing certain operations. For example, process 900 may include processor 812 receiving a trigger from the wireless network via transceiver 816 and via device 820. Furthermore, process 900 may include processor 812 retransmitting the payload in the PUSCH via transceiver 816 in response to receiving a trigger.

[0077] In some implementations, upon receiving a trigger, process 900 may include processor 812 receiving UL-DCI signaling with a trigger, the trigger being indicated by a new DCI field or an existing DCI field. In the case of a trigger indicated by a new DCI field, the new DCI field may include a single bit or one or more time slot indices indicating a previous time and selecting the payload for retransmission. In the case of a trigger indicated by an existing DCI field, the RRC configurable value of the A-CSI field may trigger a retransmission.

[0078] In some implementations, during payload retransmission, process 900 may include processor 812 performing certain operations. For example, process 900 may include processor 812 receiving a trigger from the wireless network via transceiver 816 and via device 820. In response to receiving the trigger, process 900 may include processor 812 performing some operations. For instance, process 900 may include processor 812 concatenating the payload with one or more other payloads to form a concatenated payload. Furthermore, process 900 may include processor 812 transmitting the concatenated payload in a PUCCH via transceiver 816.

[0079] In some implementations, upon receiving a trigger, process 900 may include processor 812 receiving DL-DCI signaling with a trigger from a wireless network via device 820, the trigger being indicated by a new DCI field or an existing DCI field. In the case where the trigger is indicated by a new DCI field, the new DCI field may include a single bit or one or more slot indices indicating a previous time and selecting the one or more other payloads. In the case where the trigger is indicated by an existing DCI field, the existing DCI field may include: (a) a pre-configured value for parameter (K1), which specifies the HARQ ACK / NACK timing for a particular PDSCH; and (b) a pre-configured value for the HARQ process ID or a value in another field different from K1.

[0080] Alternatively, triggering can be implicitly indicated based on RNTI or the search space.

[0081] In some implementations, when transmitting a cascaded payload in a PUCCH, process 900 may include processor 812 transmitting the cascaded payload in the earliest PUCCH after the current time slot or sub-time slot.

[0082] In some implementations, during payload retransmission, process 900 may include processor 812 transmitting a single HARQ codebook, multiple selected HARQ codebooks, or all stored HARQ codebooks associated with a previously aborted transmission. When payload retransmission includes transmitting multiple HARQ codebooks, the multiple HARQ codebooks may be selected via DCI signaling from the radio network, which specifies a sorted list of pointers for selecting a prior time slot or sub-time slot where transmission of the multiple HARQ codebooks was aborted. When payload retransmission includes transmitting all stored HARQ codebooks associated with a previously aborted transmission, payload retransmission may further include transmitting a report containing multiple pointers, each pointing to a prior time slot or sub-time slot corresponding to all stored HARQ codebooks. In this case, the sorted list may include a bitmap (e.g., a 16-bit bitmap) with each bit representing one of the prior time slots or sub-time slots.

[0083] Figure 10 An example process 1000 is illustrated according to an embodiment of this disclosure. Process 1000 may represent one aspect of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More specifically, according to this disclosure, process 1000 may represent one aspect of proposed concepts and schemes related to the suspension of on-demand transmission of a HARQ codebook in mobile communications. Process 1000 may include one or more operations, actions, or functions shown by one or more of blocks 1010 and 1020. Although shown as discrete blocks, the individual blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Furthermore, the blocks / sub-blocks of process 1000 may be arranged according to... Figure 10 The execution may proceed in the indicated order or in another order. Furthermore, one or more blocks / sub-blocks of process 1000 may be executed repeatedly or iteratively. Process 1000 may be implemented by or in devices 810 and 820 or any variant thereof. For illustrative purposes only and without limitation, process 1000 is described below in the context of device 810 as a UE (e.g., UE 110) and device 820 as a network node (e.g., network node 125) of a wireless network (e.g., wireless network 120), such as a 5G / NR mobile network. Process 1000 may begin at block 1010.

[0084] At 1010, process 1000 may include the processor 812 of device 810 receiving a trigger from a wireless network (e.g., wireless network 120) via transceiver 816 and via device 820. Process 1000 may proceed from 1010 to 1020.

[0085] In 1020, process 1000 may include processor 812 reporting the status of one or more HARQ processes to the wireless network via transceiver 816 in response to receiving the trigger.

[0086] In some implementations, the trigger may include DCI signaling (e.g., UL-DCI or DL-DCI). In such a case, when reporting the status of one or more HARQ procedures, process 1000 may include processor 812 reporting the current ACK / NACK status of all HARQ procedures configured by the wireless network. Alternatively, process 1000 may include processor 812 reporting the current ACK / NACK status of at least one HARQ procedure signaled by the trigger, which may be explicitly reported by the associated HARQ procedure number or implicitly reported by the associated service identifier.

[0087] Supplementary Explanation

[0088] The topics described herein sometimes illustrate different components contained within or connected to different other components. It is to be understood that the architectures depicted in this way are merely examples, and many other architectures that can actually achieve the same functionality can be implemented. Conceptually, multiple components in any arrangement that achieve the same function are effectively “associated” to achieve the desired functionality. Therefore, any two components combined to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associating can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associating can also be considered “operably coupled to each other” to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, physically pairable and / or physically interacting components and / or wirelessly interactive and / or logically interacting and / or logically interactive components.

[0089] Furthermore, regarding any plural and / or singular forms used herein, those skilled in the art can convert plural forms to singular forms and / or singular forms to plural forms as appropriate to the context and / or the application. The various singular / plural forms described herein are merely for clarity.

[0090] Furthermore, those skilled in the art will understand that, generally, the terms used herein, especially those in the appended claims, such as the text of the appended claims, are generally intended as “open-ended” terms. For example, the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” and the plural term “comprising” should be interpreted as “including but not limited to.” Those skilled in the art will further understand that if there is an intent to introduce a particular number of statements into a claim, such intent will be explicitly stated in the claim, and without such statements, such intent does not exist. For example, to aid understanding, the appended claims may contain introductory phrases such as “at least one” and “one or more” to introduce the statements of the claims. However, the use of these phrases should not be construed as implying that a statement of a claim introduced by the indefinite article “a” or “an” is limited to any particular claim containing only one implementation of such a statement, even if the same claim includes the introductory phrases “one or more” or “at least one,” and indefinite articles such as “a” or “an,” such as “a” and / or “an,” should be interpreted as “at least one” or “one or more”; this interpretation also applies to the use of definite articles to introduce the statements of the claims. Furthermore, even when a specific number of introductory claims are explicitly cited, those skilled in the art will recognize that such citations should be interpreted as indicating at least the number cited. For example, the simple statement "two citations," without any other modifiers, indicates at least two citations, or two or more citations. Additionally, in cases using phrases like "at least one of A, B, and C," such a structure is generally intended to be understood by those skilled in the art in the sense of the convention. For example, "a system having at least one of A, B, and C" includes, but is not limited to, having only a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Similarly, in cases using phrases like "at least one of A, B, or C," such a structure is generally intended to be understood by those skilled in the art in the sense of the convention. For example, "a system having at least one of A, B, or C" will include, but is not limited to, having only a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Those skilled in the art will further understand that virtually any word and / or phrase presenting two or more alternative terms, whether appearing in the specification, claims, or drawings, should be understood to include one of the terms, any one of the terms, or both. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”.

[0091] As can be understood from the foregoing, various implementations of this disclosure have been described herein for illustrative purposes, and various modifications may be made without departing from the scope and spirit of this disclosure. Therefore, the various implementations disclosed herein are not intended to limit the true scope and spirit indicated by the appended claims.

Claims

1. A method for reporting the status of hybrid automatic repeat request, characterized in that, include: The device's processor receives a trigger from the wireless network; and In response to receiving the trigger, the processor reports the status of one or more Hybrid Automatic Repeat Request (HARQ) procedures to the wireless network. The status of the reported one or more Hybrid Automatic Repeat Request (HARQ) processes includes: For each of the one or more HARQ processes, indicate the latest ACK / NACK and the new data indicator (NDI) received along with the associated DCI.

2. The method for reporting the status of a hybrid automatic repeat request as described in claim 1, characterized in that, The triggering includes downlink control information signaling, and wherein reporting the status of the one or more hybrid automatic repeat request processes includes: Report the current acknowledgment and negative acknowledgment status of all hybrid automatic repeat request procedures in the wireless network configuration described; or The report shows the current acknowledgment and negative acknowledgment status of at least one Hybrid Automatic Repeat Request (HARQ) procedure notified by the trigger signal, which is explicitly indicated by the associated HARQ procedure number or implicitly indicated by the associated service identifier.

3. The method for reporting the status of a hybrid automatic repeat request as described in claim 1, characterized in that, Receiving the trigger includes: receiving downlink control information signaling with the trigger, wherein the trigger is indicated by a new downlink control information field or an existing downlink control information field.

4. The method for reporting the status of a hybrid automatic repeat request as described in claim 3, characterized in that, In the case where the trigger is indicated by the new downlink control information field, the new downlink control information field includes a single bit or one or more slot indices, the slot indices pointing to a prior time and selecting the one or more other payloads, and In cases where the trigger is indicated by an existing downlink control information field, the existing downlink control information field includes: The pre-configured value of parameter K1 specifies the hybrid automatic repeat request acknowledgment and negative acknowledgment timing for the physical downlink shared channel; or The pre-configured value of the hybrid automatic repeat process identifier or a value in another field different from K1.

5. The method for reporting the status of a hybrid automatic repeat request as described in claim 1, characterized in that, Further includes: The processor of the device suspends the transmission of a first message of a first type of service in a first time slot or sub-time slot, and does not resume the transmission in the first time slot or sub-time slot; The processor stores the payload of the first message; and The processor completely retransmits the payload in a second time slot or sub-time slot after the first time slot or sub-time slot.

6. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The retransmission of the payload includes: The payload is retransmitted in response to the trigger received from the wireless network.

7. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The suspension of the transmission of the first message includes: suspending the transmission of the first message when it is detected that the transmission of the second message of the second type of service is also scheduled in the first time slot or sub-time slot, wherein the priority of the second type of service is higher than the priority of the first type of service.

8. The method for reporting the status of a hybrid automatic repeat request as described in claim 7, characterized in that, The first message includes a first hybrid automatic repeat request codebook for the first type of service, wherein the second message includes a second hybrid automatic repeat request codebook for the second type of service, wherein the first type of service includes enhanced mobile broadband service, and wherein the second type of service includes ultra-reliable low-latency communication service.

9. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The payload for storing the first message includes storing at most one payload at a time, such that: The payload of the first message covers any stored payload of any earlier message, and the payload of the first message remains stored until it is covered by the second payload of a subsequent message, the transmission of which is terminated after the second time slot or sub-time slot.

10. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The payload for storing the first message includes storing multiple payloads at once, such that the multiple payloads including the payload of the first message are stored in a first-in-first-out arrangement until the earliest payload among the multiple payloads is overwritten by the new payload of the new message, and the transmission of the new message is terminated after the second time slot or sub-time slot.

11. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The payload for storing the first message includes: regardless of whether the transmission is interrupted, storing the corresponding payload associated with each transmission such that the storage of the payload associated with a later transmission overwrites the payload associated with a earlier transmission.

12. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, Retransmitting the payload in the second time slot or sub-time slot includes: transmitting the payload from the host location in the second time slot or sub-time slot using the initially allocated physical uplink control channel resources.

13. The method for reporting the status of a hybrid automatic repeat request as described in claim 6, characterized in that, Also includes: Receive uplink and downlink control information signaling with the trigger, wherein the trigger is indicated by a new downlink control information field or an existing downlink control information field.

14. The method for reporting the status of a hybrid automatic repeat request as described in claim 13, characterized in that, The retransmission is triggered by a configurable value for the radio resource control in the non-periodic channel state information field.

15. The method for reporting the status of a hybrid automatic repeat request as described in claim 6, characterized in that, Also includes: In response to receiving the trigger, the processor executes: The payload is connected in series with one or more other payloads to form a series payload; and The cascaded payload is transmitted in the physical uplink control channel.

16. The method for reporting the status of a hybrid automatic repeat request as described in claim 15, characterized in that, in, The trigger is explicitly indicated based on a temporary radio network identifier or search space.

17. The method for reporting the status of a hybrid automatic repeat request as described in claim 15, characterized in that, Transmitting the concatenated payload in the physical uplink control channel includes transmitting the concatenated payload in the earliest physical uplink control channel after the current time slot or sub-time slot.

18. The method for reporting the status of a hybrid automatic repeat request as described in claim 5, characterized in that, The retransmission of the payload includes: Transmit a single Hybrid Automatic Repeat Request (HARQ) codebook, multiple selected HARQ codebooks, or all stored HARQ codebooks associated with previously aborted transmissions.

19. The method for reporting the status of a hybrid automatic repeat request as described in claim 18, characterized in that, In cases where retransmitting the payload includes transmitting multiple hybrid automatic repeat codebooks, the multiple hybrid automatic repeat codebooks are selected via downlink control information signaling from the radio network. The downlink control information specifies an ordered list of multiple pointers used to select the previous time slot or sub-slot where the transmission of the multiple hybrid automatic repeat codebooks was aborted. In cases where the retransmission of the payload includes the transmission of all stored hybrid autoretransmission codebooks associated with previously aborted transmissions, the retransmission of the payload also includes the transmission of a report comprising a plurality of pointers, each pointer pointing to a previous time slot or sub-time slot for each of all stored hybrid autoretransmission codebooks.

20. The method for reporting the status of a hybrid automatic repeat request as described in claim 19, characterized in that, The sorting list includes a bitmap with multiple bits, each bit representing one of the corresponding previous time slots or sub-time slots.

Images