Method, device and equipment for resource management in wireless communication

Abstract

In wireless communication, downlink transmission processes of transport blocks (TBs) in terrestrial and non-terrestrial communication systems may be different. This may require resource management to be performed in a separate manner for terrestrial and non-terrestrial communication systems, which is not desirable. To solve this problem, the present invention provides a method that can be performed by an apparatus for resource management. The method may include receiving a first transport block (TB) associated with a first process and a second TB associated with a second process. During decoding the first TB using a resource associated with the first process, the method may also include releasing at least a portion of the resource associated with the first process. The method may also include using at least a portion of the released resource for decoding the second TB.

Description

Technical Field

[0001] This application generally relates to wireless communication, and more specifically, to methods, apparatus and devices for resource management in wireless communication systems. Background Technology

[0002] Wireless communication systems such as fourth-generation (4G) systems (e.g., Long-Term Evolution (LTE) systems) and fifth-generation (5G) systems (e.g., New Radio (NR) systems) have been deployed to provide various types of applications, such as messaging, voice, video, and other data.

[0003] In NR, a non-terrestrial network (NTN) was developed. This NTN can utilize satellites (including low Earth orbit (LEO), medium Earth orbit (MEO), geostationary Earth orbit (GEO), and highly elliptical orbit (HEO) satellites) or airborne equipment such as drones or aircraft (also known as high-altitude platforms) as base stations or repeaters for communication between different devices.

[0004] Satellites or drones in an NTN may move at high speeds relative to user equipment (UEs) and other devices operating within the NTN, unlike the scenario between a UE and a ground base station. Furthermore, the distance between a UE and a satellite or drone is much greater than the distance between a UE and a ground base station.

[0005] Therefore, there is a need to provide solutions suitable for NTN that can work in conjunction with terrestrial networks (TN) to achieve communication at an acceptable cost (e.g., power consumption and / or complexity). Summary of the Invention

[0006] As mentioned above, the propagation delay in non-terrestrial communication systems is expected to be significantly greater than the decoding delay in terrestrial communication systems. Therefore, the conventional hybrid automatic repeat request (HARQ) process, typically used in terrestrial communication systems, may not always be effective in non-terrestrial communication systems. Consequently, the HARQ process can be used for downlink (DL) transmission of transport blocks (TBs) in terrestrial communication systems, and different approaches may (and may be required) be employed for DL ​​transmission of TBs in non-terrestrial communication systems. For example, in non-terrestrial communication systems, the retention time of data blocks such as TBs in the soft buffer space can be determined based on the quality of service (QoS).

[0007] However, when different methods are used for DL ​​transmission of TBs in terrestrial and non-terrestrial communication systems, it may be necessary to perform resource management separately for the terrestrial and non-terrestrial communication systems. For example, this could involve having dedicated computing and / or hardware resources for terrestrial communication and separately managed computing and / or hardware resources for non-terrestrial communication. This is undesirable because the user equipment (UE) may need to allocate its computing and hardware resources separately for the terrestrial and non-terrestrial communication systems. For instance, the UE might utilize its dedicated resources for processing, receiving, and decoding DL TBs, such that a portion of these resources is assigned to the HARQ process communicating with terrestrial network devices, while another portion is assigned to a different type of process (e.g., a time-undiscard (TUD) process) communicating with non-terrestrial network devices.

[0008] Various aspects of the present invention provide solutions to overcome the aforementioned problems, such as specific methods, apparatus, and devices for resource management in wireless communication systems (e.g., terrestrial communication systems, non-terrestrial communication systems, and communication systems including both terrestrial and non-terrestrial network devices). However, these aspects are not limited to terrestrial or non-terrestrial scenarios, but are more broadly applicable to situations requiring the decoding of multiple TBs but with limited available decoding resources. This is not limited to scenarios involving a specific type of communication (e.g., terrestrial or non-terrestrial), a specific wireless access technology, or a specific decoding process (e.g., a HARQ process). As explained herein, resources used for decoding one TB can be freed up and reused for decoding another TB.

[0009] According to one aspect of the invention, a method can be provided, the method comprising: receiving a first transport block (TB) associated with a first process and a second TB associated with a second process. The method may further comprise: during decoding of the first TB using resources associated with the first process, releasing at least a portion of the resources associated with the first process. The method may further comprise: using the released at least a portion of the resources to decode the second TB.

[0010] In some implementations, the method may further include: determining, based on at least one of a first resource sharing restriction level of the first process and a second resource sharing restriction level of the second process, to release at least a portion of the resources associated with the first process. In some embodiments, the determination to release at least a portion of the resources associated with the first process may be performed as part of releasing at least a portion of the resources associated with the first process. In some embodiments, the determination to release at least a portion of the resources associated with the first process may be performed as a separate step from releasing at least a portion of the resources associated with the first process.

[0011] In some implementations, the method may further include: receiving first configuration information configuring the first resource sharing restriction level of the first process; and receiving second configuration information configuring the second resource sharing restriction level of the second process.

[0012] In some implementations, the resource may include memory space for storing one or more bits associated with the decoding of the first TB of codeblocks (CBs).

[0013] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, the portion of the memory space is released for decoding the second TB.

[0014] In some implementations, the portion of the memory space associated with the first process may be occupied by one or more decoded CBs of the first TB before being released for decoding the second TB.

[0015] In some implementations, the second resource sharing restriction level may be higher than or equal to the first resource sharing restriction level.

[0016] In some implementations, when the second resource sharing restriction level is higher than the first resource sharing restriction level, the determination to release at least a portion of the resources associated with the first process can be performed, regardless of the priority of the first process and the priority of the second process.

[0017] In some implementations, the second resource sharing restriction level may correspond to: restricting the release of memory space associated with the second process during the decoding of the second TB.

[0018] In some implementations, the second resource sharing restriction level can be equal to the first resource sharing restriction level, and the priority of the second process can be higher than the priority of the first process.

[0019] In some implementations, the priority of the first process can be determined based on the quality of service (QoS) associated with the data carried in the first TB, and the priority of the second process can be determined based on the QoS associated with the data carried in the second TB.

[0020] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

[0021] In some implementations, the second resource sharing restriction level can be higher than the first resource sharing restriction level.

[0022] In some implementations, the second resource sharing restriction level may correspond to: restricting the release of memory space associated with the second process during the decoding of the second TB; or, during the decoding of the second TB, when a portion of the memory space associated with the second process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the second TB, allowing the portion of the memory space to be released for decoding a TB associated with another process.

[0023] In some implementations, a portion of the memory space associated with the second process may be occupied by one or more decoded CBs of the second TB.

[0024] In some implementations, when the at least portion of the memory space is used for bit occupancy in decoding the one or more unsuccessfully decoded CBs of the first TB and is released during decoding of the first TB, the method may further include: generating feedback indicating the removal of the one or more unsuccessfully decoded CBs of the first TB from the memory space; and sending the feedback.

[0025] In some implementations, the resource may include at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

[0026] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process being released and used to decode the second TB.

[0027] In some implementations, the second resource sharing restriction level can be higher than the first resource sharing restriction level.

[0028] In some implementations, the first configuration information may further configure the number of at least one processing unit associated with the first process for decoding the first TB, and the second configuration information may further configure the number of at least one processing unit associated with the second process for decoding the second TB.

[0029] In some implementations, the method may further include: sending information indicating the capabilities of the device, the capabilities including the total number of the at least one processing unit that the device can use concurrently.

[0030] In some implementations, the first TB can be received from the first network device via a first physical downlink shared channel (PDSCH), and the second TB can be received from the second network device via a second PDSCH different from the first PDSCH.

[0031] In some implementations, the first PDSCH may be time-aligned with the second PDSCH.

[0032] In some implementations, the first resource associated with the first PDSCH and the second resource associated with the second PDSCH may partially overlap.

[0033] In some implementations, the first network device may be a terrestrial network device, and the second network device may be a non-terrestrial network device. In some embodiments, the first network device may be a non-terrestrial network device, and the second network device may be a terrestrial network device.

[0034] In some implementations, the first process can implement a first framework for managing the retransmission of the TB to be decoded, and the second process can implement a second framework for managing the retransmission of the TB to be decoded.

[0035] In some implementations, the first process may be a hybrid automatic repeat request (HARQ) process, and the second process may be a HARQ process or a time until discard (TUD) process.

[0036] In some implementations, the first process may be associated with a first radio access technology (RAT), and the second process may be associated with a second RAT.

[0037] According to one aspect of the invention, an apparatus is provided, the apparatus including components for performing the method described herein. Specifically, the apparatus includes a processor coupled to a computer-readable medium. The computer-readable medium is used to store computer-executable instructions, the processor being used to execute the computer-executable instructions to cause the apparatus to perform the method consistent with the embodiments described above and herein. A non-limiting example of the apparatus is user equipment (UE). In some embodiments, the apparatus includes a chip, such as an integrated circuit (IC) chip. In some embodiments, the apparatus performs the method without the processor executing instructions; for example, the apparatus may include circuitry performing the method, such as a field-programmable gate array (FPGA), a graphics processing unit (GPU), or an application-specific integrated circuit (ASIC). More generally, the apparatus may include modules, units, or components for performing the method.

[0038] According to one aspect of the present invention, a method may be provided, the method comprising: sending configuration information configuring a first resource sharing restriction level for a first process, the first resource sharing restriction level being configured to determine whether to release at least a portion of resources associated with the first process for decoding a first TB associated with the first process.

[0039] In some implementations, the method may further include: determining the first resource sharing restriction level of the first process.

[0040] In some implementations, the resource may include memory space for storing one or more bits associated with the decoding of the first TB of codeblocks (CBs).

[0041] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, causing the portion of the memory space to be released for decoding the second TB associated with the second process.

[0042] In some implementations, the portion of the memory space associated with the first process may be occupied by one or more decoded CBs of the first TB before being released for decoding the second TB.

[0043] In some implementations, when the first resource sharing restriction level is lower than or equal to the second resource sharing restriction level of the second process, a portion of the memory space associated with the first process can be released for decoding the second TB.

[0044] In some implementations, when the first resource sharing restriction level is lower than the second resource sharing restriction level, a portion of the memory space associated with the first process can be released for decoding the second TB, regardless of the priority of the first process and the priority of the second process.

[0045] In some implementations, when the first resource sharing restriction level is equal to the second resource sharing restriction level, and the priority of the second process is higher than that of the first process, a portion of the memory space associated with the first process can be released for decoding the second TB.

[0046] In some implementations, the priority of the first process can be determined based on the quality of service (QoS) associated with the data carried in the first TB, and the priority of the second process can be determined based on the QoS associated with the data carried in the second TB.

[0047] In some implementations, the first resource sharing restriction level may correspond to: restricting the release of the memory space associated with the first process during the decoding of the first TB.

[0048] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB associated with the second process, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

[0049] In some implementations, when the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, a portion of the memory space associated with the first process can be released for decoding the second TB.

[0050] In some implementations, the method may further include: receiving feedback instructing the removal of the one or more unsuccessfully decoded CBs of the first TB from the memory space when the at least portion of the memory space is used for bit occupancy in decoding the one or more unsuccessfully decoded CBs of the first TB and is released during decoding of the first TB.

[0051] In some implementations, the resource may include at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

[0052] In some implementations, the first resource sharing restriction level may correspond to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process are released and used to decode the second TB associated with the second process.

[0053] In some implementations, when the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, at least some of the processing units in the at least one processing unit associated with the first process can be released and used to decode the second TB.

[0054] In some implementations, the configuration information may further configure the number of at least one processing unit associated with the first process for decoding the first TB, and the method may further include: determining the number of at least one processing unit associated with the first process for decoding the first TB.

[0055] In some implementations, the method may further include: receiving information indicating the capabilities of a device executing the first process, the capabilities including the total number of the at least one processing unit that the device can use concurrently.

[0056] In some implementations, the device may be a terrestrial network device or a non-terrestrial network device.

[0057] In some implementations, the first process can implement a framework for managing the retransmission of the TB to be decoded.

[0058] In some implementations, the first process can be a hybrid automatic repeat request (HARQ) process or a time until discard (TUD) process.

[0059] According to one aspect of the present invention, an apparatus is provided, the apparatus including components for performing the method described herein. Specifically, the apparatus includes a processor coupled to a computer-readable medium. The computer-readable medium stores computer-executable instructions that, when executed, cause the apparatus to perform the method consistent with the embodiments described above. Non-limiting examples of the apparatus are terrestrial transmit and receive points (T-TRPs) or non-terrestrial transmit and receive points (NT-TRPs). In some embodiments, the apparatus includes a chip, such as an IC chip. In some embodiments, the apparatus performs the method without the processor executing instructions; for example, the apparatus may include circuitry for performing the method, such as an FPGA, GPU, or ASIC. More generally, the apparatus may include modules, units, or components for performing the method.

[0060] According to one aspect of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that, when executed, cause a computer to perform the method described above. The computer-readable storage medium may be a non-transitory computer-readable storage medium.

[0061] Through some aspects of the present invention, resource management in wireless communications (e.g., terrestrial scenarios, non-terrestrial scenarios, and scenarios where terrestrial and non-terrestrial communications coexist) can be improved. For example, the UE may be able to share its memory space (e.g., soft buffer space) between the HARQ process and the TUD process based on the corresponding resource sharing restriction levels (e.g., fence type) of the HARQ process and the TUD process. In another example, the UE may be able to share its processing units (e.g., code block (CB) processing units) that may be used to decode a given TB of CBs. The processing units may be shared between the HARQ process and the TUD process based on the corresponding resource sharing restriction levels of the HARQ process and the TUD process.

[0062] In some aspects of the present invention, a device / chipset system is provided, the device / chipset system including components (e.g., at least one processor) for implementing the methods implemented by a UE (or at a UE) of the present invention. The device / chipset system may be the UE (i.e., a terminal device) or a module / component within the UE. Specifically, the at least one processor may execute instructions stored in a computer-readable medium to implement the methods.

[0063] In some aspects of the invention, a device / chipset system is provided, the device / chipset system including components (e.g., at least one processor) for implementing the methods implemented by a network device (e.g., a base station) of the invention (or at a network device (e.g., a base station) of the invention). The device / chipset system may be the network device or a module / component within the network device. Specifically, the at least one processor may execute instructions stored in a computer-readable medium to implement the methods.

[0064] In some aspects of the invention, a system is provided that includes at least one of means in a UE (or at the UE) of the invention or means in a network device of the invention.

[0065] In some aspects of the invention, a method is provided performed by a system comprising at least one of means in a UE (or at the UE) of the invention or in a network device of the invention.

[0066] According to some aspects of the invention, the network can make enhanced scheduling decisions in wireless communications (e.g., HARQ process scenarios, TUD process scenarios, and especially scenarios where HARQ processes and TUD processes coexist). For example, the network can determine whether to retransmit data based on feedback indicating the removal of undecoded data blocks (e.g., CBs after NAK') from memory space (e.g., soft buffer space).

[0067] More generally, according to some aspects of the invention, resource management can be performed to enable scenarios where resources can be shared by releasing resources used to decode one TB and instead using those resources to decode another TB. This provides a technical advantage in resource-constrained environments (e.g., in UEs where memory space and / or processing resources may be limited). This benefit can be achieved in both terrestrial and non-terrestrial scenarios, regardless of the type of decoding process (HARQ, TUD, or others) or the radio access technology. Therefore, although embodiments are described herein primarily in the context of terrestrial and non-terrestrial coexistence, the invention is not limited to such embodiments. Attached Figure Description

[0068] The embodiments are described by way of example only with reference to the accompanying drawings.

[0069] Figure 1 A simplified schematic diagram of a communication system provided as an example is shown; Figure 2 Another example of a communication system is shown; Figure 3 Examples of electronic devices (ED), terrestrial transmit and receive points (T-TRP), and non-terrestrial transmit and receive points (NT-TRP) are shown. Figure 4 Exemplary units or modules in the device are shown; Figure 5 An example of an apparatus for communicating with two devices is shown in one embodiment; Figure 6 A block diagram of the 5th generation new radio (5G NR) hybrid automatic repeat request (HARQ) operation is shown. Figure 7An exemplary soft buffer provided by an embodiment of the present invention is shown, which is assigned to a HARQ process with the fence type set to "hard". Figure 8 An exemplary soft buffer provided by an embodiment of the present invention is shown, a portion of which is initially assigned to a HARQ process and subsequently reassigned to a time until discard (TUD) process; Figures 9 to 11 An exemplary soft buffer provided by an embodiment of the present invention is shown, wherein a portion of the exemplary soft buffer is initially assigned to a HARQ process with a “no” fence type and is reassigned to a TUD process with a “soft” fence type. Figure 12 An example of how to process a code block (CB) using a dedicated CB processing unit for decoding is shown, according to an embodiment of the present invention; Figure 13 An exemplary process is shown in an embodiment of the present invention for sharing a CB processing unit between a HARQ process with a “soft” fence type and a TUD process with a “hard” fence type; Figure 14 The CB processing unit provided in the embodiment of the present invention is shown in... Figure 13 An example allocation between the HARQ process and the TUD process; Figure 15 An exemplary process for sharing a CB processing unit between a HARQ process with a "hard" fence type and a TUD process with a "soft" fence type, provided by an embodiment of the present invention, is illustrated. Figure 16 An exemplary process is shown in an embodiment of the present invention, in which a CB processing unit is shared between a HARQ process with a “hard” fence type and a TUD process with a “soft” fence type when the UE simultaneously receives two PDSCH transmissions; Figure 17 An example of sharing a CB processing unit in a loosely integrated ground and non-ground system provided by an embodiment of the present invention is shown; Figure 18 An exemplary process for resource management provided by an embodiment of the present invention is illustrated.

[0070] Similar reference numerals may be used in different accompanying drawings to denote similar components. Detailed Implementation

[0071] For illustrative purposes, specific exemplary embodiments are explained in more detail below with reference to the accompanying drawings.

[0072] The embodiments described herein illustrate information sufficient to practice the claimed subject matter and explain methods for practicing such subject matter. Those skilled in the art will understand the concepts of the claimed subject matter upon reading the following description with reference to the accompanying drawings, and will recognize that the application of these concepts is not specifically mentioned herein. It should be understood that these concepts and applications are within the scope of this invention and the appended claims.

[0073] Exemplary communication systems and devices refer to Figure 1 This figure is a non-limiting illustrative example, providing a simplified schematic diagram of a communication system. Communication system 100 (which may be a wireless system) includes a radio access network (RAN) 120. RAN 120 may be a next-generation (e.g., sixth-generation, 6G, or later) RAN, or a traditional (e.g., 5G, 4G, 3G, or 2G) RAN. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (collectively referred to as 110) may interconnect with each other or be connected to one or more network nodes (170a, 170b, collectively referred to as 170) within RAN 120. Core network 130 may be part of the communication system and may depend on or be independent of the radio access technology used in communication system 100. The communication system 100 may also include a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0074] Generally, communication system 100 enables multiple wireless or wired components to transmit data and other content. Communication system 100 can provide voice, data, video and / or text content through broadcasting, multicasting, unicasting, etc., and communication system 100 can provide a wide range of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.).

[0075] The communication system 100 can operate by sharing resources such as carrier spectrum bandwidth among its constituent units.

[0076] Figure 2 A more detailed example of the communication system 100 is shown.

[0077] Communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. Communication system 100 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can create a heterogeneous network that can be considered as comprising multiple layers. Heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0078] Terrestrial communication systems and non-terrestrial communication systems can be considered as subsystems of a communication system.

[0079] and Figure 1 The example shown is the same, in Figure 2In the example shown, communication system 100 may include ED 110a, 110b, 110c, 110d (collectively referred to as ED 110) and RAN 120a, 120b. Furthermore, communication system 100 may also include a non-terrestrial communication network 120c. Communication system 100 may also include one or more of a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RAN 120a, 120b include corresponding RAN nodes, such as base stations (BS) 170a, 170b, which are typically referred to as terrestrial transmit and receive points (T-TRPs) 170a, 170b. In one implementation, non-terrestrial communication network 120c includes RAN nodes, such as access node 172, which are typically referred to as non-terrestrial transmit and receive points (NT-TRPs) 172. As can be inferred from the similarities in the reference numerals, the non-terrestrial communication network 120c can be considered a radio access network with common operational aspects to RANs 120a and 120b. In another implementation, the non-terrestrial communication network 120c may include at least one non-terrestrial network (NTN) device and at least one corresponding terrestrial network device, the at least one NTN device acting as a transport layer device, and the at least one corresponding terrestrial network device acting as a RAN node, which communicates with the ED through the NTN device. Furthermore, an NTN gateway (i.e., referred to as a terrestrial network device) may also exist on the ground as a transport layer device communicating with the NTN device, and the RAN node communicates with the ED through both the NTN device and the NTN gateway. In some implementations, the NTN gateway and the RAN node may reside in the same device.

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

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

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

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

[0084] Furthermore, the communication system 100 may include a sensing agent (not shown) to manage sensing data from ED 110 and / or T-TRP 170 and / or NT-TRP 172. In one implementation, the sensing agent is located within T-TRP 170 and / or NT-TRP 172. In another implementation, the sensing agent is a separate node with an interface for communicating with core network 130 and / or RAN 120 (e.g., T-TRP 170 and / or NT-TRP 172).

[0085] Figure 3Another example of the ED 110 and base stations 170a, 170b, and / or 170c is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, including, for example, cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery, and mobility.

[0086] Each ED 110 represents any suitable end-user equipment for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine-type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smart book, vehicle, car, truck, bus, train, or IoT device, wearable device (e.g., watch, glasses, head-mounted device, etc.), industrial equipment, or devices that include or incorporate the foregoing (e.g., communication module, modem, or chip), etc. Future generations of ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs and will be referred to as T-TRP 170 below. Similarly, Figure 3As shown, the NT device is referred to below as NT-TRP 172. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically started (i.e., established, activated, or enabled), shut down (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connectivity availability and connectivity necessity.

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

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

[0089] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., Figure 1(Wired interface of Internet 150 in the network). Input / output devices or interfaces support interaction with users or other devices in the network. Each input / output device or interface includes any suitable structure for providing or receiving information from the user and / or for network interface communication. For example, suitable structures include speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

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

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

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

[0093] When ED 110 is a device within a machine (e.g., a communication module, modem, chip, or chipset), it includes at least one processor, an interface, or at least one pin. In this scenario, transmitter 201 and receiver 203 can be replaced by an interface or at least one pin used to connect the device (e.g., a chip) and other devices (e.g., a chip, memory, or bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or another ED 110 can be termed sending information to an interface or at least one pin, while receiving information from NT-TRP 172 and / or T-TRP 170 and / or another ED 110 can be termed receiving information from an interface or at least one pin. This information may include control signaling and / or data.

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

[0095] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules of T-TRP 170 may be located remotely from the device housing the antenna 256 for T-TRP 170 and may be coupled to the device housing the antenna 256 via a communication link (not shown) sometimes referred to as a fronthaul (e.g., a common public radio interface (CPRI)). Therefore, in some embodiments, the term "T-TRP 170" may also refer to network-side modules that perform processing operations such as ED110 location determination, resource allocation (scheduling), message generation, and encoding / decoding, which are not necessarily part of the device housing the antenna 256 of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs operating together to, for example, serve ED 110 through cooperative multicast transmission.

[0096] The T-TRP 170 may include at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid crowding. Alternatively, one, some, or all of the antennas 256 may be a panel. The transmitter 252 and receiver 254 may be integrated as a transceiver.

[0097] T-TRP 170 includes processor 260 for performing various operations, including those related to: preparing to transmit downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing to transmit backhaul transmissions to T-TRP 170 and / or NT-TRP 172, and processing transmissions received from T-TRP 170 and / or NT-TRP 172 via backhaul. Processing operations related to preparing to transmit downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. Processor 260 can also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates an indication of beam direction (e.g., BAI), which scheduler 253 can schedule for transmission. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the deployment location of NT-TRP 172, etc. In some embodiments, processor 260 can generate signaling, such as configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" as used herein can also be referred to as control signaling. Signaling can be transmitted in physical layer control channels such as the physical downlink control channel (PDCCH), in which case the signaling can be referred to as dynamic signaling. Signaling transmitted in the downlink physical layer control channel can be called physical layer signaling, such as downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel can be called physical layer signaling, such as uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel can be called physical layer signaling, such as sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) packets transmitted in physical layer data channels such as the Physical Downlink Shared Channel (PDSCH). In this case, the signaling can be referred to as higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can also refer to radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling. Signaling can be included in a combination of physical layer signaling and higher-layer signaling.

[0098] Scheduler 253 may be coupled to or integrated into processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from it. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backhaul transmissions, including issuing scheduling authorizations and / or configuring unscheduled (e.g., “configuration authorization”) resources.

[0099] T-TRP 170 may also include memory 258 for storing information and optional data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by processor 260.

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

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

[0102] When T-TRP 170 is a device within a machine (e.g., a communication module, modem, chip, or chipset), it includes at least one processor, an interface, or at least one pin. In this scenario, transmitter 252 and receiver 254 can be replaced by an interface or at least one pin used to connect the device (e.g., a chip) to other devices (e.g., a chip, memory, or bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or ED 110 can be termed sending information to an interface or at least one pin, while receiving information from NT-TRP 172 and / or T-TRP 170 and / or ED 110 can be termed receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0103] Although the NT-TRP 172 is shown as an example of a drone only, the NT-TRP 172 can be implemented in any suitable non-terrestrial form, such as satellite and high-altitude platforms including international mobile telecommunications base stations and drones. Furthermore, in some implementations, the NT-TRP 172 may use other names, such as non-terrestrial node, non-terrestrial network device, or non-terrestrial base station.

[0104] The NT-TRP 172 may include a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid congestion. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver.

[0105] NT-TRP 172 includes a processor 276 for performing various operations, including operations related to: preparing to transmit downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing to transmit backhaul transmissions to T-TRP 170 and / or another NT-TRP 172, and processing transmissions received from T-TRP 170 and / or another NT-TRP 172 via backhaul. Processing operations related to preparing to transmit downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, the processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling, for example, for configuring one or more parameters of ED 110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as medium access control (MAC) or radio link control (RLC) layer functions. Since this is merely an example, more generally, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

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

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

[0108] When NT-TRP 172 is a device within a machine (e.g., a communication module, modem, chip, or chipset), it includes at least one processor, an interface, or at least one pin. In this scenario, transmitter 272 and receiver 257 can be replaced by an interface or at least one pin used to connect the device (e.g., a chip) and other devices (e.g., a chip, memory, or bus). Therefore, sending information to T-TRP 170 and / or another NT-TRP 172 and / or ED 110 can be termed sending information to an interface or at least one pin, while receiving information from T-TRP 170 and / or another NT-TRP 172 and / or ED 110 can be termed receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0109] It should be noted that "TRP" as used herein can refer to either T-TRP or NT-TRP. T-TRP can be alternatively referred to as terrestrial network TRP ("TN TRP"), and NT-TRP can be alternatively referred to as non-terrestrial network TRP ("NTN TRP"). T-TRP 170, NT-TRP 172, and / or ED 110 may include other components, but these components are omitted for clarity.

[0110] according to Figure 4 One or more steps of the method provided by the present invention can be executed by the corresponding unit or module. Figure 4Units or modules in a device or apparatus, such as those in ED 110, T-TRP 170, or NT-TRP 172, are shown. For example, a signal may be transmitted by a transmitting unit or transmitting module. A signal may be received by a receiving unit or receiving module. A signal may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules may be circuits such as integrated circuits. Examples of integrated circuits include programmed FPGAs, GPUs, or ASICs. For example, one or more of these units or modules may be logical functions, such as logical functions executed by circuits, by a portion of an integrated circuit, or by software instructions executed by a processor. It should be understood that if these modules are implemented using software executed by a processor, etc., then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, in single or multiple instances, and these modules themselves may include instructions for further deployment and instantiation.

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

[0112] In wireless communication systems, electronic devices or equipment such as user equipment (UE) are embedded systems with limited resources (e.g., limited power and limited memory space). Specifically, for radio access technologies such as 4G LTE and 5G NR, transport blocks (TBs) carrying UE-specific data are decoded by the UE and held in a soft buffer until these TBs have been correctly decoded or the maximum number of retransmissions has been attempted. According to conventional techniques, the soft buffer space size is the same for all hybrid automatic repeat request (HARQ) processes, based on the maximum TB size.

[0113] In current 5G NR systems, the UE acknowledges the Data Tolerance (TB) individually within a given interval, typically configured using a higher-layer signaling parameter called dl-DataToUL-ACK. Furthermore, the HARQ process in 5G NR is executed according to a "stop-and-wait" protocol. In this protocol, the transmitter (e.g., the transmit and receive point (TRP)) waits for an acknowledgment (ACK) / negative acknowledgment (NAK) response from the receiver (e.g., the UE) before transmitting a new data packet. There are also backup procedures, such as timers, to ensure retransmission of data packets in the absence of ACK / NAK feedback from the receiver.

[0114] In current 5G NR systems, the processing time of the UE's physical downlink shared channel (PDSCH) is determined by variables. Definition. The UE PDSCH processing time defines the shortest time required for the UE to decode a TB from a PDSCH transmission and generate a valid HARQ-ACK message for that PDSCH transmission. Therefore, the UE PDSCH processing time is determined by measuring the time between the last OFDM symbol of the PDSCH transmission and the first OFDM symbol of the corresponding PUCCH transmission (i.e., the PUCCH transmission corresponding to the PDSCH transmission). When insufficient PDSCH processing time is provided, the UE does not need to generate a valid HARQ-ACK message for the TB received via the PDSCH transmission. The UE PDSCH processing time can be determined according to the following equation (1): (1) Equation (1) is provided and discussed in detail in Section 5.3 of 3GPP Technical Specification (TS) version 17.5.0 38.214.

[0115] The propagation delay in non-terrestrial scenarios is expected to be significantly greater than the decoding delay in terrestrial scenarios. The decoded bits in the TB (Through Transmission) can be held in the soft buffer for at least the time required for the UE to complete the processing related to TB reception and decoding, also known as the TB decoding time. Incorrectly decoded bits can remain in the soft buffer for a period of T = (TB decoding time * number of transmission attempts) + (2 * propagation delay * number of retransmission attempts). This is the amount of time the corresponding HARQ process is "locked" for scheduling purposes. The corresponding soft buffer space assigned to a given HARQ process cannot accommodate any decoded bits of another HARQ process, even if there is still some available space in the corresponding soft buffer space of the given HARQ process. In other words, in non-terrestrial scenarios, due to the longer propagation delay, a UE communicating with a non-terrestrial TRP (NT-TRP) may run out of HARQ processes before the first "locked" HARQ process is released. Therefore, a large number of HARQ processes are required. For example, a 4ms propagation delay could require hundreds of HARQ processes, which is unsustainable and could lead to high overhead. For instance, requiring hundreds of HARQ processes means that each downlink control information (DCI) message would need to include a process ID that could be much longer than the current process ID.

[0116] These soft buffer spatial and timing characteristics illustrate aspects of traditional HARQ methods that can pose significant challenges in wireless communication, particularly in scenarios with long propagation delays, such as non-terrestrial network applications.

[0117] Some embodiments in this document refer to control information. Control information may sometimes be referred to alternatively as control signaling or signaling. In some cases, for example, control information may be dynamically transmitted at the physical layer of a control channel, such as in the physical uplink control channel (PUCCH) or physical downlink control channel (PDCCH). Examples of dynamically indicated control information are messages sent in physical layer control signaling, such as uplink control information (UCI) sent in the PUCCH or downlink control information (DCI) sent in the PDCCH. Dynamic indication may be an indication at a lower layer (e.g., physical layer / layer 1 signaling) rather than at a higher layer (e.g., rather than RRC signaling or MAC control element (CE)). Semi-static indication may be an indication in semi-static signaling. Semi-static signaling as used herein may refer to non-dynamic signaling, such as higher-layer signaling (e.g., RRC signaling) and / or MAC CE. The dynamic signaling used in this article can refer to dynamic signaling, such as physical layer control signaling sent in the physical layer, such as DCI sent in PDCCH or UCI sent in PUCCH.

[0118] Figure 5 An example of an apparatus 372 provided in one embodiment for wirelessly communicating with two devices 352a and 352b in a communication system (e.g., communication system 100) is shown. The terms "apparatus" and "device" are used only to more easily distinguish different entities. Apparatus 372 may be a UE. Device 352a may be a terrestrial network device (e.g., T-TRP), and device 352b may be a non-terrestrial network device (e.g., NT-TRP). However, this is not a necessary condition. For example, device 352a may be either a terrestrial network device or a non-terrestrial network device, and device 352b may be either a terrestrial network device or a non-terrestrial network device. They may be entities of the same type; for example, both devices 352a and 352b may be terrestrial devices, or both devices 352a and 352b may be non-terrestrial network devices, although more generally this is not a necessary condition. In the following, the reference character 352 may be used when referring to either device 352a or 352b or any other similar device.

[0119] Device 372 represents any suitable end-user equipment for wireless operation and may include, for example (but not limited to), smartphones, laptops, computers, tablets, wireless sensors, consumer electronics, smart books, vehicles, automobiles, trucks, buses, trains, IoT devices, industrial equipment, cellular phones, stations (STAs), machine type communication (MTC) devices, personal digital assistants (PDAs), wireless transmit / receive units (WTRUs), mobile stations, fixed or mobile user units, or devices (e.g., communication modules, modems, or chips) from any of the aforementioned devices.

[0120] Device 372 includes a transmitter 374, a receiver 376, a processor 380, a memory 382, ​​and one or more antennas 378. For simplicity, only the transmitter 374, receiver 376, processor 380, memory 382, ​​and antennas 378 are shown, but device 372 may include one or more other components.

[0121] Processor 380 performs (or controls device 372 performs) operations described herein as performed by device 372, as shown below and elsewhere in the invention. For example, processor 380 performs or controls device 372 to perform the following operations: receive a transport block (TB) from device 352; decode one TB of the received TB using resources; release the resources for decoding another TB of the received TB; and / or receive configuration information configuring a resource sharing restriction level for a given process. Processor 380 generates messages for uplink transmissions and processes received downlink transmissions. Generating messages for uplink transmissions may include arranging information in a message format, encoding messages, modulating, performing beamforming (if necessary), etc. Processing received downlink transmissions may include performing beamforming (if necessary), demodulating and decoding received messages, etc. Although not shown, processor 380 may form part of transmitter 374 and / or receiver 376. Although not shown, memory 382 may be part of processor 380. The memory 382 may be used to store control information and / or data associated with some or all of the operations performed by the device 372, such as some or all of the instructions to be executed by the processor 380 of the device 372.

[0122] If device 372 is a UE (e.g., ED 110), then processor 380 may be or include processor 210, transmitter 374 may be or include transmitter 201, receiver 376 may be or include receiver 203, and memory 382 may be or include memory 208.

[0123] Devices 352a and 352b may be T-TRP 170 or NT-TRP 172. However, as stated above, devices 352a and 352b may be entities of the same type or different types. In some embodiments, the various parts of device 352 may be distributed. For example, some modules of device 352 may be located remotely from the device housing the antenna of device 352 and may be coupled to the device housing the antenna via a communication link (not shown). For example, the baseband unit (BBU) of device 352 may be located remotely from the radio frequency unit (RFU) of device 352. As another example, one or more antennas of device 352 may be located remotely from the RFU of device 352, or alternatively, one or more antennas may be integrated into the RFU. The term “antenna” as used herein also encompasses a flat panel, such as a flat panel antenna.

[0124] Because devices 352 can be distributed, in some embodiments, the term "device 352" may also refer to a module on the network side that performs processing operations such as resource allocation (scheduling), message generation, encoding / decoding, etc., and is not necessarily part of the device housing the antenna of device 352. These modules may also be coupled to other devices (e.g., TRPs). In some embodiments, device 352 may actually be multiple TRPs that operate together to serve the device through cooperative multicast or similar means.

[0125] Device 352 includes a transmitter 354 and a receiver 356, which may be integrated into a transceiver. Transmitter 354 and receiver 356 are coupled to one or more antennas 358. Only one antenna 358 is shown in the figure. Device 352 also includes a processor 360. Processor 360 performs (or controls device 352 to perform) operations described herein as being performed by device 352, as shown below and elsewhere in the invention. For example, processor 360 performs or controls device 352 to perform the following operations: transmit configuration information configuring a resource sharing restriction level for a given process; processor 360 generates messages for downlink transmission and processes received uplink transmissions. Generating messages for downlink transmission may include arranging information in a message format, encoding messages, modulating, performing beamforming (if necessary), etc. Processing uplink transmissions may include performing beamforming (if necessary), demodulating and decoding received messages, etc. Although not shown, processor 360 may be part of transmitter 354 and / or receiver 356. Device 352 also includes a memory 362 for storing information (e.g., control information and / or data). The information stored in memory 362 may include control information and / or data associated with some or all of the operations performed by device 352, such as some or all of the instructions to be executed by processor 360 of device 352.

[0126] The processing components in processor 360, transmitter 354, and receiver 356 may be implemented by the same or different processors for executing instructions stored in memory (e.g., memory 362). Alternatively, some or all of the processing components in processor 360 and / or transmitter 354 and / or receiver 356 may be implemented using dedicated circuitry such as a programmed FPGA, GPU, or ASIC.

[0127] If device 352 is a T-TRP 170, then transmitter 354 may be or include transmitter 252, receiver 356 may be or include receiver 254, processor 360 may be or include processor 260 and may implement scheduler 253, and memory 362 may be or include memory 258. If device 352 is an NT-TRP 172, then transmitter 354 may be or include transmitter 272, receiver 356 may be or include receiver 274, processor 360 may be or include processor 276, and memory 362 may be or include memory 278.

[0128] Embodiments of the present invention are described in the context of communication between a UE and a TRP (T-TRP, NT-TRP), where the UE is device 372 and the TRP is device 352. However, more generally, the two entities communicating wirelessly with each other are not necessarily a UE and a TRP; they communicate with each other using uplink and / or downlink communication. For easier distinction between the two entities, one is referred to as a device and the other as a device. A device can be a UE, as in the embodiments below. A device can be a network device (e.g., a TRP), as in the embodiments below. However, this is not a necessary condition. For example, a device can be either a UE or a network device, and a device can be either a UE or a network device. The terms "device" and "device" are used only to facilitate distinction between the two entities. They can be the same type of entity; for example, both a device and a device can be a UE, or both a device and a device can be a network device (e.g., a base station or other TRP), although more generally this is not a necessary condition.

[0129] As mentioned above, in current 5G NR systems, transport blocks (TBs) carrying UE-specific data can be decoded by the UE and held in a soft buffer until these TBs have been correctly decoded or the maximum number of retransmissions has been attempted. According to conventional techniques, the soft buffer space size is the same for all hybrid automatic repeat request (HARQ) processes, based on the maximum TB size.

[0130] A soft buffer can refer to a buffer used by a device (e.g., user equipment (UE)) to store decoded transport block (TB) bits, where "soft" refers to the use of a so-called soft decoding algorithm, where the decoder's output includes not only the decoded bits but also reliability values, such as the log-likelihood ratio (LLR) of the decoded bits. In some embodiments of the invention, a soft buffer can be memory allocated in hardware or a portion thereof used to store soft-decoded bits, such as a physical form of registers and / or memory. However, soft buffers are not limited to such memory but include any other type or form of hardware capable of performing similar functions. In one example, the soft buffer is a portion of memory 382.

[0131] A TB can be a set of one or more code blocks (CBs), where each CB is the output of the decoder. Cyclic redundancy check (CRC) is typically appended to each CB to help the device determine whether a CB has been successfully decoded. For example, in low-density parity check (LDPC) coding, when using LDPC base... Figure 1 The maximum CB size (Kcb) can be 8448 bits, or when using LDPC base... Figure 2 At this time, the maximum CB size (Kcb) can be 3840 bits. When the number of bits in TB is greater than the maximum CB size (Kcb), the number of CBs can be determined according to equation (2) below, which is represented as C in equation (2) below: (2) Where B is the number of bits in TB and L is the number of bits in CRC.

[0132] In equation (2), assuming that the CRC is appended to each CB after segmenting the TB, the number of bits (B) in the TB may not include the number of bits (L) in the CRC, while the maximum CB size (Kcb) may include the number of bits (L) in the CRC. That is, B may not include L, and Kcb may include L. It should be noted that the number of bits (L) in the CRC may be 24 bits. Equation (2) is provided and explained in detail in section 5.2.2 of 3GPP Technical Specification (TS) version 38.212, version 17.2.0, which also discusses CB segmentation and CBCRC appending.

[0133] In current 5G NR systems, HARQ operation can rely on a stop-and-wait protocol, in which the transmitter waits for explicit confirmation of receipt of a data packet from the receiver before sending a new data packet. The 5G NR physical downlink control channel (PDCCH) can carry downlink control information (DCI) format, which includes a new data indicator (NDI) field to indicate a new transmission (NDI=1) or a retransmission of a given HARQ process identifier (ID) (NDI=0). Switching of the NDI field can be based on receiving ACK / NAK feedback from the UE. This allows 5G NR to execute asynchronous HARQ protocols.

[0134] In 5G NR, HARQ processes can belong to a HARQ entity comprising {8, 16, 32} processes, which can run in parallel. Each HARQ process can be used to process the reception of one TB at any given time on the UE side. Similarly, each HARQ process can be used to process the transmission of one TB on the network side at any given time. These HARQ processes can run in an "interleaved" manner to support continuous data reception at the UE, enabling the UE to decode different TBs in parallel. In conventional implementations, the soft buffer space allocated to a HARQ process may not be used to receive other TBs until the NDI field of that HARQ process is switched to 1.

[0135] The size or capacity of a soft buffer can be determined based on the number of HARQ processes (e.g., 8, 16, 32). The size of a soft buffer in 5G NR can be expressed as N*M*S, where N is the number of HARQ processes, M is the maximum TB size, and S is the number of TBs used for spatial multiplexing. Spatial multiplexing can be a multiple-input multiple-output (MIMO) transmission scheme, where the transmitter can use multiple layers (e.g., multiple MIMO layers) to send data to the receiver. Therefore, S can be the number of MIMO layers. However, in the context of non-terrestrial communication, the communication system can typically use only one MIMO layer (e.g., line-of-sight path). The nature of non-terrestrial channels may be unfavorable to multipath communication; non-terrestrial channels may be line-of-sight dominant. Therefore, only 1 TB can be transmitted at a time, i.e., S=1. The number of HARQ processes can also be determined in a way that matches the round-trip time of the communication system. The longer the round-trip time, the more HARQ processes may be required.

[0136] Figure 6 A block diagram of 5G NR HARQ operation is shown. Figure 6 In this diagram, a sequence or stream of TBs to be sent can be scheduled, and one of the TBs is marked at 602. Arrow 606 is intended to illustrate how HARQ processes are mapped to allocated soft buffer space in an example where up to eight HARQ processes can run at any time. 610 represents the soft buffer, and each row in soft buffer 610 can represent the space in the soft buffer that has been allocated to each HARQ process.

[0137] Allocate and lock a soft buffer space of a maximum size TB for each HARQ process, even if the scheduled TB size may be much smaller. The scheduled TB size may be much smaller than the maximum size TB, for example, if the link quality is not very good. Figure 6An example of this is shown at position 612, by only showing the portion of the soft buffer space already allocated to each HARQ process that is occupied. Although Figure 6 The soft buffer 610 in the current HARQ process obviously has available space, but TB 604 may not be sent until the soft buffer space of the current HARQ process has been cleared, which may depend on the UE sending ACK / NAK feedback to the network device that is sending the previous TB.

[0138] As mentioned above, for example, in non-terrestrial communication systems, the traditional hybrid automatic repeat request (HARQ) process may not be the most efficient. Therefore, different approaches can be used for downlink (DL) transmissions in terrestrial communication systems. One approach could be to use a "Time Until Discard" (TUD).

[0139] TUD can be defined as the time interval during which a data block (e.g., a transport block (TB)) carried in the corresponding physical downlink control channel (PDCCH) transmission is retained in the UE's soft buffer. TUD may or may not include the data block decoding time. For example, in some embodiments, TUD can be specified as an interval or time period following the decoding time; in this sense, it can be considered as applied after the decoding time or excluding the decoding time. The time unit used to represent TUD can be a time slot, for example, a set of orthogonal frequency division multiplexing (OFDM) symbols.

[0140] The DCI (also known as DCI format) carried in the PDCCH can define a new field to indicate the TUD. This new field can be called "Discard Waiting Time" or given any other name. The value of this field explicitly or implicitly indicates the time allowed for a data block carried in the corresponding PDSCH transmission to remain in the UE's soft buffer. The time unit of the TUD can be, for example, an OFDM symbol, a set of OFDM symbols, a mini-slot, a set of mini-slots, a slot, a set of slots, a second, a millisecond, a microsecond, etc. This invention is not limited to any particular time unit. The time unit is not the only value that the TUD field can carry. The value in this field can indicate an index of the configured time unit value or other identifier, for example, to provide an implicit indication of the TUD.

[0141] In one possible implementation, the network device can use higher-level signaling such as RRC signaling to configure the candidate value set of the TUD, and can also use lower-level signaling such as MAC-CE commands to activate or deactivate a subset of the candidate values ​​of the TUD from the configured candidate value set. Activation (or deactivation) of one or more candidate values ​​of the TUD can be accomplished using an activation command sent within a MAC-CE command to notify the UE of the values ​​that the TUD field in the DCI can take.

[0142] The UE can apply a TUD (e.g., the UE starts running a timer or counter and sets the value of the timer or counter to the (TUD) value indicated in the TUD field of the DCI) to the corresponding data block (e.g., TB) transmitted via PDSCH. For example, in the case of a counter, if the UE has not yet successfully decoded the data block, the UE can decrement the counter by one for each elapsed time slot. If the UE has not correctly decoded the data block before the counter expires (e.g., when the counter used for the data block decrements and eventually becomes 0), the UE clears the soft-decode bit and the corresponding Log Likelihood Ratio (LLR) value of the data block from its soft buffer. It should be noted that the UE can set the value of the timer or counter to 0 and increment the timer or counter over time. If the UE has not correctly decoded the data block before the counter expires (e.g., when the counter used for the data block increments and eventually becomes the TUD value), the UE can clear the soft-decode bit and the corresponding Log Likelihood Ratio (LLR) value of the data block from its soft buffer. In the case of a timer, the timer can be used in a manner similar to that of a counter described above and elsewhere in this invention.

[0143] The DCI format may have some limitations. For example, the presence of a TUD field in a DCI format message can implicitly indicate that the PDSCH (scheduled by the corresponding PDCCH) carries a new transmission of a data block. Conversely, the absence of a TUD field in a DCI format message can implicitly indicate that the PDSCH (scheduled by the corresponding PDCCH) carries a retransmission of a data block previously sent by the network device whose decoded bits are still in the UE's soft buffer. If the DCI format messages are inconsistent, the UE can consider the DCI format message invalid and discard all information in the DCI format message, which will prevent the UE from receiving and decoding the corresponding PDSCH transmission.

[0144] Embodiments of the present invention can solve problems related to resource management for efficient data communication in systems such as 6G terrestrial networks (TN) and / or non-terrestrial networks (NTN). For example, embodiments can propose how to share memory space (e.g., soft buffers) at the UE between processes used by the TN (e.g., HARQ processes) and processes used by the NTN (e.g., TUD processes). In another example, embodiments can propose how to share hardware resources (e.g., processing units such as CB processing units) at the UE for decoding CB in an integrated TN / NTN system (e.g., a network system where terrestrial and non-terrestrial equipment can coexist). Embodiments of the present invention can also solve problems related to managing different types of processes (e.g., HARQ processes and TUD processes) to ensure efficient and continuous data communication, and can have particular advantages in systems such as 6G integrated TN / NTN.

[0145] In this invention, a "fence" can refer to a region within memory space (e.g., a UE soft buffer) used by the UE to define or distinguish a region for storing the output of a decoder for a given process (e.g., decoded TB / CB bits and their reliability values). Whether a fenced region of memory space is shared can be determined based on the "fence type" of a given process, which can be considered and / or referred to as the resource sharing restriction level of the given process. The resource sharing restriction level or fence type can refer to information indicating the priority of a given process (e.g., a HARQ or TUD process) in terms of resource management. The resource sharing restriction level or fence type can be used to determine whether to release resources used by a given process to share that resource with one or more other processes. Although "fence," "fence type," and "resource sharing restriction level" are shown above in conjunction with a specific type of resource (i.e., memory space (e.g., a soft buffer)), they can be applied appropriately to other types of resources (e.g., various types of processing units (e.g., CB processing units)). In this invention, for illustrative purposes, "fence type" and "resource sharing restriction level" can be used interchangeably, or "fence type" can be an example of "resource sharing restriction level".

[0146] The present invention can provide methods, apparatus and devices for resource management that can be used in TN systems, NTN systems and integrated TN / NTN systems (e.g., network systems in which terrestrial and non-terrestrial equipment can coexist).

[0147] Aspects of the invention may include resource-sharing restriction levels (e.g., fence types) associated with a given process for sharing resources between different processes. As described above, the resources to be shared may include the UE's memory space (e.g., a soft buffer, which may be used to store one or more bits related to the decoding of code blocks (CBs) of a transport block (TB)) and / or the UE's processing unit (e.g., a CB processing unit, which may be used to decode CBs). Aspects of the invention may include feedback (e.g., 1-bit soft buffer sharing feedback) instructing the removal of one or more undecoded CBs from the memory space of the TB.

[0148] The embodiments can be implemented or combined with any type of user equipment, including terminals, telephones, vehicles, wearable devices, tablets, and any such devices that support wireless access technologies such as 5G NR, future 6G systems, Wi-Fi, and satellite communication systems. Such communication devices are generally referred to herein as UEs, and UEs are intended to include all such user equipments.

[0149] Terrestrial TRPs and non-terrestrial TRPs use physical layer control channels (e.g., physical downlink control channel (PDCCH) / physical uplink control channel (PUCCH)) and physical layer data channels (physical downlink shared channel (PDSCH) / physical uplink shared channel (PUSCH)) to communicate with the UE. These UEs may be embedded systems with limited storage and battery space; therefore, the buffer memory space for storing the decoded bits of received data blocks (e.g., data blocks received in the DL PDSCH) and their associated reliability bits (e.g., log-likelihood rate (LLR) values) may also be limited.

[0150] The following provides an overview of various embodiments of the present invention. In this overview, it is assumed that the UE is communicating with two network devices (e.g., T-TRP and NT-TRP), and that T-TRP uses a HARQ process to manage TB retransmissions, while NT-TRP uses a TUD process to manage TB retransmissions. For example, the UE may be device 372, T-TRP may be device 352a, and NT-TRP may be device 352b.

[0151] In some embodiments, the network device may send signaling to the UE, such as higher-layer signaling messages (e.g., in radio resource control (RRC) signaling). This signaling may carry configuration information (e.g., higher-layer configuration parameters) associated with a HARQ process for the TN and / or a TUD process for the NTN. This configuration information may configure the resource sharing restriction level (e.g., fence type) of the HARQ process and / or TUD process. Each of the HARQ process and TUD process may be configured with a resource sharing restriction level or fence type. The UE may receive data blocks (e.g., TBs) associated with a HARQ process or TUD process and decode the received data blocks based on the resource sharing restriction level associated with a given HARQ process or TUD process.

[0152] In some embodiments, signaling (e.g., higher-layer signaling messages) may include configuration information configuring the number of processing units (e.g., CB processing units) that will be used by a given HARQ process or TUD process to decode data blocks (e.g., decode one or more CBs of a given TB). The UE may send information indicating its capabilities, including the total number of available processing units. The total number of processing units (e.g., CB processing units) may correspond to the number of CBs that the UE can decode in parallel, concurrently, or simultaneously. Information indicating the UE's capabilities (e.g., the number of processing units) may be sent to the network device, for example, using a UE capability response message. Processing units may be used to decode one or more CBs of the same TB associated with a single process, or may be shared among multiple processes (e.g., between a HARQ process and a TUD process) and used to decode multiple different TBs associated with multiple different processes. In other words, a processing unit may be assigned to a single process for decoding CBs within the same TB, or assigned to multiple different processes for decoding multiple different TBs associated with multiple different processes.

[0153] In some embodiments, the UE can simultaneously receive PDSCH transmissions carrying TBs from different TN TRPs, NTN TRPs, or TN and NTN TRPs. TBs can be received from different TN TRPs and / or NTN TRPs using the same time resources. Such PDSCHs can be transmitted on different frequency resources. Different frequency resources can belong to the same bandwidth part (BWP), different BWPs, the same component carrier (CC), different CCs, the same frequency band, or different frequency bands. When receiving PDSCH transmissions carrying TBs from different TRPs, the UE can use the same memory (e.g., a soft buffer) to store one or more bits related to the decoding of a data block (e.g., a CB within the TB) and its associated reliability bits (e.g., the log-likelihood ratio (LLR) value of the CB belonging to the TB received via PDSCH transmission).

[0154] In some embodiments, the UE may be required to decode the CB of the TB within a certain time limit. Such a time limit can be regarded as the decoding time (e.g., CB decoding time). The decoding time can be expressed as an integer multiple of Tc. Tc can indicate a time unit defined, for example, in seconds, milliseconds, microseconds, nanoseconds, picoseconds, or femtoseconds. As an example, in 5G NR, Tc can be obtained using equation (3) described below.

[0155]

[0156] when =480 kHz and When Tc = 4096, according to equation (3), Tc will be 0.508626 nanoseconds. If a specific decoding time is provided to the UE for decoding the data block, the UE may be required to provide a valid indication (e.g., HARQ-ACK or HARQ-NAK) of whether the data block has been successfully decoded within a given decoding time. For example, the UE may need to send a valid HARQ-ACK for decoding the TB when all CBs belonging to the TB have been successfully and correctly decoded within a given decoding time. The UE may need to send a valid HARQ-NAK for decoding the TB when at least one CB belonging to the TB has been unsuccessfully or incorrectly decoded. On the other hand, if no specific decoding time is provided to the UE for decoding the data block, the UE may not be required to provide a valid indication (e.g., HARQ-ACK or HARQ-NAK) of whether the data block has been successfully decoded.

[0157] In some embodiments, the UE may generate feedback indicating the removal of one or more unsuccessfully decoded CBs of a TB from the UE's memory space (e.g., soft buffer space, SBS). This feedback may be referred to as SBS feedback or SBS feedback bits. When each HARQ process or TUD process has a different priority, the UE may generate SBS feedback if one or more unsuccessfully or incorrectly decoded CBs of a TB associated with a HARQ process or TUD process with a lower priority are removed from the memory space. The memory space may then be used to store bits associated with another HARQ process or TUD process with a higher priority. The SBS feedback may be appended to corresponding feedback information (e.g., HARQ-NAK) indicating that one or more CBs have been unsuccessfully or incorrectly decoded. In this way, the network device can be informed that one or more CBs of the TB corresponding to the received feedback information (e.g., HARQ-NAK) have been unsuccessfully or incorrectly decoded, and that the one or more unsuccessfully decoded CBs have been removed from the UE's memory space (soft buffer space). The SBS feedback bit can also be called the soft buffer shared information bit, SBS feedback information bit, SBS bit, or SBS information.

[0158] According to some embodiments, processes such as HARQ processes or TUD processes may be associated with a "fence". There may be one or more fence types, which can be considered and correspond to resource sharing restriction levels. Although there are various ways to define or name each fence type, for illustrative purposes, it is assumed in this invention that fence types include "none", "soft", or "hard". However, it should be noted that there may be fewer or more than three fence types associated with a given process. It should also be noted that each fence type may be represented in a way other than "none", "soft", or "hard".

[0159] In some embodiments, fences may be placed within memory space to define or demarcate a portion of memory space to be used by a given process (e.g., a HARQ process or a TUD process). The fenced-protected portion of memory space may be occupied by data corresponding to a TB, which may include one or more soft-decoded bits of the corresponding TB and its corresponding LLR. Data stored in the fenced-protected portion of memory space may be associated with the given process and will not be overwritten or erased from memory space by another process unless the other process is associated with a harder / higher fence type (i.e., a higher resource sharing restriction level) or has a higher priority. In other words, access to the fenced-protected portion of memory space by other processes may be restricted at least partially. The fence may remain in memory space until the associated process terminates. For example, the fenced-protected portion of memory space allocated to a given HARQ process or TUD process may be locked until the TB carried by the given HARQ process or TUD process is successfully and correctly decoded, or until the unsuccessfully or incorrectly decoded CBs of the TB (i.e., CBs after NAK') are cleared from memory space, corresponding to the time when the associated process terminates. In the case of the HARQ process, when the maximum number of HARQ retransmissions has been attempted, or in the case of the TUD process, when the TUD timer has expired (i.e., the TUD's expiration time has arrived), the CB after NAK' can be cleared from the memory space.

[0160] In some embodiments, a network device (e.g., a TN TRP or NTN TRP) can use higher-layer signaling to configure candidate values ​​for the fence type (resource sharing restriction level) of a given process. For example, the network device can determine the fence type (resource sharing restriction level) of a process and send configuration information configuring the fence type (or resource sharing restriction level) to the UE using higher-layer signaling such as RRC signaling. This configuration information may include parameters for the fence type (e.g., "fenceType") or the resource sharing restriction level. The value of this parameter can indicate the fence type of a given process.

[0161] As described above, for illustrative purposes, it is assumed in this invention that the fence type includes "none," "soft," or "hard." A "hard" fence type may correspond to: restricting the release of memory space associated with a given process during decoding of a TB associated with a given process. A "soft" fence type may correspond to: during decoding of a TB associated with a given process, when a portion of the memory space associated with the given process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the TB associated with the given process, allowing that portion of the memory space to be released for decoding a TB associated with another process. A "none" fence type may correspond to: during decoding of a TB associated with a given process, allowing at least a portion of the memory space associated with the given process to be released for decoding a TB associated with another process, regardless of whether at least a portion of the memory space associated with the given process was used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the TB associated with the given process.

[0162] In embodiments where the fence type is configured as "hard," the UE can allocate a portion of memory space (e.g., a soft buffer) to a given process. The allocated memory space portion can be used for mission-critical traffic, such as emergency messages related to earthquakes, tsunamis, or weather. When the fence type for a given process is "hard," the allocated portion of the memory space (i.e., the fence-protected portion of the memory space) may not be used or shared with other processes (e.g., other HARQ processes or TUD processes) until the allocated portion is released by the given process. For example, when the fence type is configured as "hard" and the given process is a HARQ process or a TUD process, the fence-protected portion of the memory space may not be released until the TB carried by the given HARQ process or TUD process is successfully and correctly decoded, or until the maximum number of HARQ retransmission attempts has been made, or the TUD timer has expired (i.e., the TUD timeout period for the TB carried by the given process has expired).

[0163] Figure 7 An exemplary soft buffer 700 provided by an embodiment of the present invention is shown, which is assigned to a HARQ process with the fence type set to "hard". References Figure 7A portion 710 of the soft buffer 700 can be allocated to the first HARQ process, and another portion 720 of the soft buffer 700 can be allocated to the second HARQ process. It should be noted that the remaining portion 730 of the soft buffer 700 can be empty memory space not allocated to other HARQ processes or TUD processes, or it can be memory space allocated to other processes unrelated to the TB decoding of the first and second HARQ processes. It should also be noted that the space representing the size of the soft buffer 700 can be larger than... Figure 7 The value shown is much smaller. In other words, the UE, especially the UE acting as a resource-constrained embedded system, may not always have enough free memory space to store all the decoded CBs (received in the DL PDSCH) and their corresponding LLR values.

[0164] The fence type or resource sharing restriction level of the first HARQ process can be set to "hard". When the TB associated with the first HARQ process (referred to as the "first TB", used to describe...) Figure 7 While being decoded, some CBs in the first TB may be successfully and correctly decoded, while other CBs in the first TB may be unsuccessfully or incorrectly decoded. Successfully decoded CBs in the first TB (i.e., CBs after ACK') may occupy a portion 714 of portion 710 of soft buffer 700, or alternatively, portion 714 may be unoccupied if successfully decoded CBs are removed from soft buffer 700. If the allocated portion 710 is large enough to accommodate the maximum TB size (e.g., the maximum size TB may be allocated to portion 710), but the TB being decoded is smaller than the maximum TB size, portion 714 may also include unoccupied memory space. Unsuccessfully decoded CBs in the first TB (i.e., CBs after NAK') may occupy another portion 712 of portion 710 of soft buffer 700.

[0165] The fence type or resource sharing restriction level of the second HARQ process can also be set to "hard". When a TB (referred to as the "second TB") is associated with the second HARQ process, it is used to describe... Figure 7While the second TB is being decoded, some CBs in the second TB may be successfully and correctly decoded, while other CBs in the second TB may be unsuccessfully or incorrectly decoded. Successfully decoded CBs in the second TB (i.e., CBs after ACK') may occupy a portion 724 of portion 720 of soft buffer 700, or alternatively, portion 724 may be unoccupied if successfully decoded CBs are removed from soft buffer 700. If the allocated portion 720 is large enough to accommodate the maximum TB size (e.g., the maximum size TB may be allocated to portion 720), but the TB being decoded is smaller than the maximum TB size, portion 724 may also include unoccupied memory space. Unsuccessfully decoded CBs in the second TB (i.e., CBs after NAK') may occupy another portion 722 of portion 720 of soft buffer 700.

[0166] The CBs following the ACK' of the first TB and the second TB can be removed from memory space 700 and placed in another location (e.g., a separate memory space, queue, or buffer) because decoding the first TB and the second TB no longer requires the CBs following the ACK''. Instead, further decoding processes may only require the CBs following the NAK' of each TB, so the CBs following the NAK' of the first TB and the second TB may need to be held in portions 712 and 722 of soft buffer 700, respectively. For example, to perform soft merging, portions 712 and 722 can be occupied by the CBs following the NAK' at least before retransmitting the first TB and the second TB.

[0167] As described above, the CB following the ACK' of the first TB and the second TB can be removed from the soft buffer 700, thus portions 714 and 724 of the soft buffer 700 can be freed. However, although portions 714 and 724 can theoretically be freed, assuming the fence type of the first HARQ process and the second HARQ process is set to "hard," portions 714 and 724 of the soft buffer 700 reserved for the first HARQ process and the second HARQ process can be locked until the first TB and the second TB are successfully and correctly decoded and thus released by the first and second processes. In other words, given that the fence type of the first HARQ process and the second HARQ process is set to "hard," portions 710 and 720 of the soft buffer 700 may not be used by other processes until these portions are released by the first HARQ process and the second HARQ process (e.g., until the first HARQ process and the second HARQ process terminate), even if portions 710 and 720 include unoccupied memory space.

[0168] In some embodiments, the fence type (resource sharing restriction level) configured using higher-level signaling (e.g., RRC signaling) can be set to "soft". In such embodiments, the UE can allocate a portion of memory space (e.g., a soft buffer) to a given process, such that a portion of memory space occupied by one or more undecoded CBs (i.e., CBs after NAK') is not used by other processes (e.g., other HARQ processes or TUD processes), and a portion of memory space occupied by CBs that have not been or have been successfully decoded by one or more CBs (i.e., CBs after ACK') can be released or made free. The released portion of memory space can be used by other processes (e.g., other HARQ processes or TUD processes). For example, when the fence type is configured to "soft" and the given process is a HARQ process or a TUD process, after a CB occupying a portion of the fenced-protected portion of memory space is successfully decoded, that fenced-protected portion of the memory space originally allocated to the given HARQ process or TUD process can be dynamically reassigned to another HARQ process or TUD process.

[0169] Figure 8 An exemplary soft buffer 800 provided by an embodiment of the present invention is illustrated, a portion of which is initially allocated to a HARQ process and subsequently reassigned to a TUD process. References Figure 8 A portion 810 of the soft buffer 800 can be initially allocated to a HARQ process. The fence type or resource sharing restriction level of the HARQ process associated with the memory portion 810 can be set to "soft".

[0170] When the TB associated with the first HARQ process (referred to as the first TB, used to describe) Figure 8 While the first TB is being decoded, some CBs in the first TB may be successfully and correctly decoded, while other CBs in the first TB may be unsuccessfully or incorrectly decoded. Successfully decoded CBs in the first TB (i.e., CBs after ACK') may initially occupy a portion 814 of portion 810 of soft buffer 800. For example, if the allocated portion 810 is large enough to accommodate the maximum TB size (e.g., the maximum size TB may be allocated to portion 810), but the TB being decoded is smaller than the maximum TB size, then portion 814 may also include unoccupied memory space. Unsuccessfully decoded CBs in the first TB (i.e., CBs after NAK') may occupy another portion 812 of portion 810 of soft buffer 800.

[0171] Assuming the HARQ process's fence type is set to "soft," memory space portion 814 can be freed. Any successfully decoded CBs in portion 814 are removed from the soft buffer for release. The release of memory space portion 814 can occur during the decoding of the first TB (e.g., before the decoding of the first TB is complete). The freed memory space portion 814 can be reallocated to the TUD process for use with the TB associated with the TUD process (referred to as the "second TB," for illustration purposes). Figure 8 Decoding is then performed. The fence type or resource sharing restriction level of the TUD process can be set to "hard" or "soft". If the fence type of the TUD process is "soft", the priority of the TUD process can be higher than that of the HARQ process. Process priority will be discussed below or elsewhere in this invention.

[0172] like Figure 8 As shown, the freed memory space portion 814 may be a part of memory space portion 820, which includes memory space portions 822 and 824. Memory space portion 822 may be occupied by one or more undecoded CBs (i.e., CBs after NAK') of the second TB, and memory space portion 824 may be occupied by one or more successfully decoded CBs (i.e., CBs after ACK') of the second TB or may otherwise be unoccupied. It should be noted that a portion of memory space portion 814 belongs to memory space portion 822, and another portion of memory space portion 814 belongs to memory space portion 824.

[0173] It is important to note that the remaining portion 830 of the soft buffer 800 can be empty memory space not allocated to other HARQ or TUD processes, or it can be memory space allocated to other processes unrelated to TB decoding of the HARQ and TUD processes. It is also important to note that the space representing the size of the soft buffer 800 can be larger than... Figure 8 The value shown is much smaller. In other words, the UE, especially the UE acting as a resource-constrained embedded system, may not always have enough free memory space to store all the decoded CBs (received in the DL PDSCH) and their corresponding LLR values.

[0174] In some embodiments, the UE may determine whether to release a portion of memory allocated to a given process based on at least one of the fence type (resource sharing restriction level) of a given process (e.g., a HARQ process or a TUD process) or the fence type (resource sharing restriction level) of another process that can utilize the memory space to be released by the given process. For example, if the fence type of the first process is "soft" and the fence type of the second process is "hard", a portion of the memory space occupied by one or more successfully decoded CBs of a TB associated with the first process (or a portion of memory space allocated to the first process but not used by the first process) may be released for decoding a TB associated with the second process.

[0175] In some embodiments, the UE can determine whether to release a portion of memory allocated to a given process (e.g., a HARQ process or a TUD process) based on the priority of that process. For example, the priority configured for a given HARQ process or TUD process can be based on the quality of service (QoS) associated with data carried in a TB associated with that HARQ process or TUD process. Assuming three QoS levels (e.g., "low", "medium", "high") are available, and the HARQ process or TUD process is configured with the same fence type (e.g., a "soft" fence), the process associated with "low" QoS data can have the lowest priority, the process associated with "medium" QoS data can have a medium priority, and the process associated with "high" QoS data can have a high priority. In other words, if the first process and the second process have the same "soft" fence type, the decision to release a portion of memory allocated to either the first process or the second process can be based on the QoS data associated with each of the first and second processes. For example, if a first process is associated with a TB carrying “low” QoS data and a second process is associated with a TB carrying “medium” or “high” QoS data, a portion of the memory space occupied by one or more successfully decoded CBs of the TB associated with the first process can be freed up and used to decode the TB associated with the second process.

[0176] In some embodiments, the UE can determine whether to release a portion of memory allocated to a given process based on the network slice to which that process (e.g., a HARQ process or a TUD process) belongs. In 5G NR, a network slice can be viewed as a network configuration capable of creating multiple networks over a common physical infrastructure, where each network slice corresponds to a specific type of traffic (e.g., enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communication (URLLC), Massive Machine Type Communication (mMTC), or Public Safety). For example, the priority configured for a given HARQ process or TUD process can be based on the network slice associated with the data carried in a TB, which is associated with the given HARQ process or TUD process. Assuming there are four network slice types (e.g., "eMBB", "URLLC", "mMTC", "Public Safety") and the HARQ process or TUD process is configured with the same fence type (e.g., a "soft" fence), the process associated with "eMBB" can have the lowest priority, while the process associated with "Public Safety" can have the highest priority. In other words, if the first process and the second process have the same "soft" fence type, it is possible to determine whether to release a portion of the memory allocated to the first process or the second process based on the network slice associated with each of the first and second processes. For example, if the first process is associated with a TB carrying "eMBB" data and the second process is associated with a TB carrying "URLLC" data, a portion of the memory space occupied by one or more successfully decoded CBs of the TB associated with the first process can be released and used to decode the TB associated with the second process.

[0177] In some embodiments, a process's fence type can take precedence over its priority. In other words, when a given process's fence type or resource-sharing restriction level is lower than another process's, a portion of the memory space associated with that given process will be released, regardless of the priority of the given process or the priorities of other processes. For example, if a first process has a "soft" fence and is associated with a TB carrying "high" QoS data, and a second process has a "hard" fence and is associated with a TB carrying "low" QoS data, the second process can take precedence over the first process. Therefore, memory space allocated to the first process that is not occupied by or has been occupied by a CB following an ACK' associated with the first process can be released and reallocated to the second process for decoding the TB associated with the second process.

[0178] In some embodiments, a fence type may take precedence over a hardened or softened fence relative to a fence belonging to another HARQ process / TUD process. In such embodiments, subcategories of fence types may be defined. For example, a process with a "soft" fence type may have different priority subcategories and be configured to have "soft higher priority" and "soft lower priority". When both a process with "soft higher priority" and a process with "soft lower priority" exist, and only one process has memory available for decoding, the process with "soft higher priority" may take precedence over the process with "soft lower priority".

[0179] In some embodiments, the fence type (resource sharing restriction level) configured using higher-level signaling (e.g., RRC signaling) can be set to "None," meaning there is no fence around the data associated with the corresponding TB (e.g., a soft decode bit and its corresponding LLR). In such embodiments, data associated with a given process (e.g., a soft decode bit and its corresponding LLR) can be deleted from the memory space used for TBs associated with the given process, or it can be overwritten by another process. Such overwriting and erasure can occur under specific modes and conditions as shown below.

[0180] In embodiments where the fence type is configured as "None," the UE can allocate a portion of memory space (e.g., a soft buffer) to a given process (e.g., a HARQ process or a TUD process), such that a portion of the memory space used by the given process can be freed and used by another process (e.g., a HARQ process or a TUD process) with a higher priority than the given process. Priorities can be implemented in various ways. One way to achieve this is by utilizing fence types (HARQ or TUD) for the process. For example, as described above, a "hard" fence type can have the highest priority, a "soft" fence type can have a medium priority, and a "none" fence type can have the lowest priority.

[0181] It should be noted that "fences" can be implemented in various ways. For illustrative purposes, it is assumed that different blocks of instruction (CBs) are processed as "atomic" blocks, each effectively corresponding to a sequential instruction stream. In some embodiments, the fence instruction can be implemented as a "virtual" instruction. It should be noted that virtual instructions have no function; for example, a virtual instruction does not trigger any action. The purpose of this "virtual" instruction may be to effectively separate the different atomic blocks corresponding to different CBs. This allows the UE to separate the "processing" instructions corresponding to different CBs in the time domain and / or the CB processing unit domain. In some embodiments, the fence instruction can be implemented as a dedicated "CB switching" instruction. The CB switching instruction can store the output of the instruction stream corresponding to the first CB in memory and trigger the memory to receive the input of the instruction stream corresponding to the second CB. In some embodiments, based on the nature of the underlying hardware (e.g., ASIC, DSP, CPU, etc.) and aspects related to the implementation of the instruction set architecture, other fence instruction implementations can be considered (e.g., the fence instruction can be implemented as a different type of instruction than a virtual instruction or a dedicated CB switching instruction).

[0182] Figures 9 to 11 An exemplary soft buffer 900 provided by an embodiment of the present invention is shown, a portion of which is initially assigned to a HARQ process with a “no” fence type and subsequently reassigned to a TUD process with a “soft” fence type. Figures 9 to 11 In this context, as elsewhere in the invention, it is assumed that “soft” fence types are considered to be preferred over “no” fence types.

[0183] exist Figure 9In this configuration, the UE can receive two data blocks (TBs) associated with two different HARQ processes (i.e., a first HARQ process and a second HARQ process). A portion of the soft buffer 900 can then be initially allocated to the first HARQ process, and another portion can be initially allocated to the second HARQ process. The fence type or resource sharing restriction level for the first and second HARQ processes can be set to "none". It is important to note that even though the first and second HARQ processes have the same fence type (i.e., "none"), the data carried in the TB associated with the first HARQ process and the data carried in the TB associated with the second HARQ process may not occupy the same portion of the soft buffer 900. It is also important to note that any successfully decoded CBs (i.e., CBs after ACK') can be removed from the soft buffer 900 because CBs after ACK'' are no longer needed when decoding the TBs associated with the first and second HARQ processes. Therefore, in the TB associated with the first HARQ process and the second HARQ process, only one or more unsuccessfully decoded CBs (i.e., CBs after NAK') can occupy soft buffer 900. Specifically, unsuccessful CBs associated with the first HARQ process can occupy a portion 910 of soft buffer 900, and unsuccessful CBs associated with the second HARQ process can occupy another portion 920 of soft buffer 900.

[0184] It should be noted that portion 930 of the soft buffer 900 can be empty memory space not allocated to other HARQ processes or TUD processes, or it can be memory space allocated to other processes unrelated to the TB decoding of the first and second HARQ processes. It should also be noted that the space representing the size of the soft buffer 900 can be larger than... Figures 9 to 11 The value shown is much smaller. In other words, the UE, especially the UE acting as a resource-constrained embedded system, may not always have enough free memory space to store all the decoded CBs (received in the DL PDSCH) and their corresponding LLR values.

[0185] The UE can also receive TBs associated with a TUD process that is different from the first HARQ process or the second HARQ process. It is assumed here that there is insufficient memory space in the soft buffer 900 to decode the TBs associated with the TUD process. The UE can determine whether to reallocate memory space portions 910 and 920, initially allocated to the first and second HARQ processes, to the TUD process. It is assumed that the TUD process can be configured to have a “soft” fence type. Therefore, given that the first and second HARQ processes have a “no” fence type, memory space portions 910 and 920 occupied by undecoded CBs (e.g., undecoded bits and their corresponding LLR bits) associated with the first and second HARQ processes can be released and used instead for decoding the TBs associated with the TUD process (i.e., reallocated to the TUD process).

[0186] After reallocation, the freed memory spaces 910 and 920 can be occupied by data carried in the CB of the TB associated with the TUD process, such as... Figure 10 As shown. In Figure 10 In the memory space portion 1010, it represents the portion of memory space 910 and 920 that was initially allocated to the first HARQ process and the second HARQ process, and then reallocated to the TUD process (in Figure 9 (As shown in the diagram). After reallocation, memory space portion 1010 can be considered to have a "soft" fence, as indicated by the dashed line at the boundary of memory space portion 1010. Memory space portion 1010 can be considered to have a "soft" fence because memory space portion 1010 is now allocated to a TUD process configured to have a "soft" fence type.

[0187] In some embodiments, a given memory space portion 1010 has a “soft” fence, which includes not only unsuccessfully decoded CBs of the TUD process, but also portions occupied by CBs that have been successfully decoded (i.e., CBs after ACK') from one or more TBs associated with the TUD process, either unused or already occupied. In this case, if the decoding of the TB associated with the TUD process is completed, or if it needs to be used by another process with a “hard” fence type or with the same fence type and a higher priority (e.g., a “soft” fence type but carrying higher QoS data than the TUD process), the CBs after ACK' of the TUD process can be removed from the soft buffer 900, and thus a portion of the memory space portion 1010 of the soft buffer 900 can become free.

[0188] It should be noted that the above description is an example of dynamically reallocating memory space to other HARQ processes / TUD processes.

[0189] Dynamic reallocation of memory space can occur in TN systems, NTN systems, and integrated TN / NTN systems (e.g., network systems where terrestrial and non-terrestrial equipment may coexist). For example, when large data with lower priority is carried in a TB and transmitted via a terrestrial link, while small data with higher priority is carried in another TB and transmitted via a non-terrestrial link, a portion of the soft buffer can be reallocated as described above. Dynamic reallocation of memory space is not limited to TN, NTN, or integrated TN / NTN systems, but is more broadly applicable to situations requiring decoding of multiple TBs but with limited available decoding resources (e.g., available memory in the soft buffer). This is not limited to specific types of communication (e.g., terrestrial or non-terrestrial), specific radio access technologies, or specific decoding processes (e.g., HARQ, TUD).

[0190] In some embodiments, when one or more undecoded CBs (CBs after NAK') are removed from one or more TBs of memory space (e.g., soft buffers) associated with a process of higher priority (e.g., a process with a "soft" or "hard" fence type), as described above and Figure 10 As shown, the UE may need to notify the network device (e.g., send a ground TRP for a TB associated with a process with a "None" fence type) that the CB after the NAK' is removed from the memory space before the decoding of the CB is complete. To do this, the UE can generate feedback (e.g., a 1-bit soft buffersharing (SBS) feedback) indicating that one or more undecoded CBs associated with a TB of the process with a "None" fence type are removed from the memory space. The UE can then send the feedback to the network device. Figure 11 An example is shown in the figure.

[0191] As described above, the memory space portion 1010 of the soft buffer 900 may include the freed memory space portions 910 and 920 that were initially allocated to the first HARQ process and the second HARQ process, and then newly reallocated to the TUD process. Figure 11 (Not shown in the image). In Figure 11In this context, it is assumed that memory space portion 1010 comprises a combination of memory space portions 910 and 920. Memory space portion 1010 is initially occupied by a CB following NAK' associated with a first HARQ process and a second HARQ process, which are configured to have a "no" fence type. Then, memory space portion 1010 is reassigned to a TUD process configured to have a "soft" fence type. To perform this reassignment, the CB following NAK' associated with the first and second HARQ processes is removed from memory space portion 1010 of soft buffer 900. Since the CB following NAK' is removed from soft buffer 900 before decoding is complete, the UE can generate feedback 1110 instructing the removal of the CB following NAK' associated with the first HARQ process from soft buffer 900, and feedback 1120 instructing the removal of the CB following NAK' associated with the second HARQ process from soft buffer 900. Feedback 1110 may include (i) NAK feedback 1112 indicating a decoding failure of the TB associated with the first HARQ process, and (ii) a soft buffer sharing (SBS) bit 1114 indicating the removal of the CB after the NAK' associated with the first HARQ process from the soft buffer 900. Similarly, feedback 1120 may include (i) NAK feedback 1122 indicating a decoding failure of the TB associated with the second HARQ process, and (ii) a soft buffer sharing bit 1124 indicating the removal of the CB after the NAK' associated with the second HARQ process from the soft buffer 900. The generated feedbacks 1110 and 1120 may be sent to the network device.

[0192] Several methods can be used to generate feedback (e.g., feedback 1110, feedback 1120). In some embodiments, the UE can generate feedback for each CB following a NAK' removed from memory space, including a pair of bits in the order {"ACK / NAK" bit, "SBS" bit}. In some embodiments, the UE can generate feedback for each code block group (CBG) including a CB following a NAK' removed from memory space, including a pair of bits in the order {"ACK / NAK" bit, "SBS" bit}. In some embodiments, the UE can generate feedback for each TB including a CB following a NAK' removed from memory space, including a pair of bits in the order {"ACK / NAK" bit, "SBS" bit}. It should be noted that other methods can be used to generate feedback indicating the removal of one or more undecoded CBs associated with a TB having a "None" fence type from memory space.

[0193] It should be noted that the above and Figure 11The procedure and example shown may be referred to as a "HARQ-ACK-SBS codebook," in which the UE generates HARQ-ACK feedback bits and soft buffer sharing (SBS) bits. The HARQ-ACK feedback bits and SBS feedback bits may be included in the Uplink Control Information (UCI). In some embodiments, other feedback bits, such as channel state information (CSI) feedback bits and / or scheduling request (SR) bits, may also be included in the UCI.

[0194] Or, as mentioned above and Figure 11 The procedures and examples shown can be referred to as "multiplexing" because the SBS feedback bit can be "multiplexed" with at least one of the HARQ-ACK feedback bit, CSI feedback bit, or SR bit in a single PUCCH transmission. The UE can then transmit UCI over the Physical Uplink Control Channel (PUCCH) on PUCCH resources. The PUCCH resources can be configured for the UE by the network using higher-layer signaling (e.g., RRC) and indicated to the UE by the network in the corresponding Physical Downlink Control Channel (PDCCH) carrying the DCI format.

[0195] In some embodiments, if the UL resources scheduling the PUCCH transmission overlap with the PUSCH transmission in time, the UE can multiplex the SBS feedback bit with at least one of the HARQ-ACK feedback bit, CSI feedback bit, or SR bit in a single PUSCH transmission.

[0196] In some embodiments, the UE can generate "softbuffer sharing (SBS)" feedback along with the HARQ process identifier feedback bit. The network can be configured for the UE to periodically report the SBS bit to understand the status of the UE's softbuffer. In the first example, assuming the UE supports HARQ operations for up to 16 HARQ processes, the UE can generate an SBS feedback bit as a bitmap, where the most significant bit (MSB) (equivalent to the leftmost bit) corresponds to the HARQ process with an identifier equal to 0, and the least significant bit (LSB) (equivalent to the rightmost bit) corresponds to the HARQ process with an identifier equal to 15. For example, the UE can generate a bitmap like the one shown below: "0011100010100000". This bitmap can indicate that the TB associated with the HARQ process corresponding to the bit position with a value of "1" has been cleared from the softbuffer, so that the resources occupied by these TBs (e.g., a portion of the UE's softbuffer) can be occupied by other TBs associated with processes with higher priority. In the bitmap example above, the TBs corresponding to the HARQ processes identified as {2, 3, 4, 8, 10} have been cleared from the UE's soft buffer. In the second example, assuming the UE supports HARQ operations with up to 16 HARQ processes, the UE can generate, for example, the SBS feedback bits and HARQ process identifier bits as shown in Table 1 (from MSB to LSB): Table 1

[0197] The first field is a 1-bit "SBS Feedback Bit," indicating that one or more TBs have been cleared from the UE's soft buffer. Following the SBS Feedback Bit are one or more HARQ process identifier bits. Given a TB, there is a one-to-one correspondence with a HARQ process; the number of HARQ process identifier fields indicates the total number of TBs cleared from the UE's soft buffer. For example, if one HARQ process identifier field exists, one TB is cleared from the UE's soft buffer; if two HARQ process identifier fields exist, two TBs are cleared from the UE's soft buffer; and so on. In some embodiments, based on the assumption that the UE supports HARQ operations with up to 16 HARQ processes, each HARQ process identifier field has a 4-bit width. In some embodiments, if the UE supports HARQ operations with up to 32 HARQ processes, the HARQ process identifier bit width is 5 bits.

[0198] In some embodiments, the UE can generate a "soft buffer sharing (SBS)" feedback along with the bits corresponding to the slot indexes of the PDSCH transmission carrying the TB, which are received, detected, and decoded by the UE. Assuming the UE supports HARQ operations for up to 16 HARQ processes, the UE can generate SBS feedback bits and slot index bits as shown below (from MSB to LSB): Table 2

[0199] The first field is a 1-bit SBS feedback bit, used to indicate that one or more TBs have been cleared from the UE's soft buffer. Following the SBS feedback bit are one or more slot index fields. Given a TB, there is a one-to-one correspondence with a slot index; the number of slot indices indicates the total number of TBs cleared from the UE's soft buffer. For example, if one slot index field exists, one TB is cleared from the UE's soft buffer; if two slot index fields exist, two TBs are cleared from the UE's soft buffer; and so on. In some embodiments, a slot index with a value of "0000" can be mapped to the current slot, a slot index with a value of "0001" can be mapped to the previous slot, a slot index with a value of "0010" can be mapped to the two slots preceding the current slot, and so on. Alternatively, in other embodiments, a slot index with the value "0000" can be mapped to a slot 16 slots preceding the current slot, a slot index with the value "0001" can be mapped to a slot 15 slots preceding the current slot, a slot index with the value "0010" can be mapped to a slot 13 slots preceding the current slot, and so on. In some embodiments, based on the assumption that the UE supports HARQ operations for up to 16 HARQ processes, each slot index field can have a 4-bit width. In some embodiments, if the UE supports HARQ operations for up to 32 HARQ processes, the slot index width is 5 bits.

[0200] As described above or elsewhere in this invention, the concept of fence type or resource sharing restriction level can be applied to memory space (e.g., soft buffers) occupied by data carried in a TB associated with a specific process (e.g., a HARQ process or a TUD process). In some embodiments, the fence type or resource sharing restriction level associated with a process (e.g., a HARQ process or a TUD process) can also or alternatively be used in a context where hardware logic (e.g., at least one processing unit) that can be used to decode one or more CBs is shared with other processes. In other words, the concept of fence or fence type or resource sharing restriction level can be similarly applied to hardware logic (e.g., CB processing unit) that can be used to process received data (e.g., decode CBs).

[0201] Hardware logic can be dedicated to processing (e.g., decoding) CBs, and can be referred to as CB processing units. Some of this hardware logic can be implemented on a circuit, such as an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a programmed field-programmable gate array (FPGA), a graphics processing unit (GPU), or a central processing unit (CPU). A UE may include one or more CB processing units, each capable of processing one CB at a time. CB decoding can be an "atomic" operation, as a CB processing unit can complete the decoding of a CB in a single step without interruption. Each TB can be a collection of individually encoded CBs. Therefore, each CB within a TB may need to be decoded individually before the decoding of a TB is considered complete.

[0202] Figure 12 This illustration shows an example of how a CB processing unit dedicated to decoding CBs can be used to process CBs, as provided by embodiments of the present invention. Each of CB processing units 1201 and 1202 can process a corresponding CB from CB input 1210. CB input 1210 may include one or more CBs associated with certain processes (e.g., a HARQ process or a TUD process). The output of CB processing units 1201 and 1202 is CB output 1220. Each CB processed (e.g., decoded) by CB processing unit 1201 or 1202 can be processed uninterruptedly in one step. In one example, each of the CBs that can be considered as encoded CB input 1210 can be processed separately by CB processing units 1201 and 1202. For example, the processing could be decoding of the CB. After each processing (e.g., decoding) is completed, the CB (e.g., the decoded CB) can be considered processed and regarded as CB output 1220.

[0203] As described above, the concept of fence types can be applied to CB processing units. In some embodiments, a given process with a "hard" fence type (e.g., a HARQ process or a TUD process) can be considered to place a "hard" fence around the CB processing units allocated to the given process. Therefore, a "hard" fence type in the context of shared CB processing units can correspond to: restricting the release of CB processing units associated with a given process during decoding of a TB associated with that process. In other words, a given process with a "hard" fence type can use all the CB processing units allocated to it without sharing them with other processes (e.g., a HARQ process or a TUD process) until all CBs of the TB have been successfully or unsuccessfully decoded.

[0204] In some embodiments, a given process with a “soft” fence type (e.g., a HARQ process or a TUD process) can be considered to place a “soft” fence around the CB processing unit allocated to the given process. Therefore, the “soft” fence type in the context of shared CB processing units can correspond to: during the decoding of a TB associated with the given process, at least some of the CB processing units associated with the given process are released and used to decode TBs associated with other processes of higher priority (e.g., a HARQ process or a TUD process with a “hard” fence type). In other words, when a CB processing unit is allocated to a process with a “soft” fence type, the process with the “soft” fence type can share at least a portion of the CB processing units allocated to it with processes with a “hard” fence type, but may not share any CB processing units with processes with a “no” fence type.

[0205] In some embodiments, it can be considered that a given process with a "no" fence type (e.g., a HARQ process or a TUD process) can place a "no" fence around the CB processing unit assigned to the given process. Therefore, the "no" fence type in the context of shared CB processing units can correspond to: during the decoding of a TB associated with a given process, at least some and possibly all of the CB processing units associated with the given process are released and used to decode TBs associated with other processes of higher priority (e.g., HARQ processes or TUD processes with "hard" or "soft" fence types). In other words, when a CB processing unit is assigned to a process with a "no" fence type, the process with the "no" fence type can use the CB processing unit assigned to it, while other processes with "hard" or "soft" fence types do not need to use the CB processing unit.

[0206] In some embodiments, if no CB processing units are available, and / or if a process of the "hard" fence type requires more CB processing units than allocated to it, a given process of the "hard" fence type (e.g., a HARQ process or a TUD process) can acquire CB processing units from processes of the "soft" or "no" fence type. Thus, a process with a softer fence type (or a lower resource sharing restriction level) can start using a given number of CB processing units, but eventually use fewer as decoding progresses. This dynamic reallocation of CB processing units can be useful because, for example, due to the cost of zone logic, the number of CB processing units may not grow proportionally to the number of HARQ / TUD processes. For example, a UE might run 32 HARQ processes and 32 TUD processes, but might not have 64 CB processing units. In this case, dynamic reallocation of CB processing units can help execute more important processes first.

[0207] In some embodiments, the UE may send information indicating its capabilities, which may include the total number of processing units that the UE can use concurrently. For example, after the initial access procedure, the UE may send its capability information message to the network device. For instance, the capability information message may include a higher-layer signaling parameter called “numofParallelCBProcessingUnits”, which indicates the total number of CB processing units that the UE can use in parallel. The parameter “numofParallelCBProcessingUnits” may have integer values, such as 1, 2, 4, 8, 16, etc.

[0208] In some embodiments, a network device (e.g., a TN TRP or NTN TRP) can use higher-layer signaling to configure the number of processing units associated with a given process for decoding a TB associated with that process. For example, the network device can determine the number of CB processing units associated with each HARQ process or TUD process for decoding a TB associated with that HARQ process or TUD process, and send configuration information configuring the number of CB processing units to the UE using higher-layer signaling such as RRC signaling. The configuration information may include a parameter for the number of processing units (e.g., “numCBProcessingUnits”). This allows the UE to share processing units (e.g., CB processing units) between processes (e.g., between HARQ processes and TUD processes) based on, for example, the fence type of each process.

[0209] In some embodiments, the UE may send information indicating its capabilities, including its ability to share its soft buffer between processes (e.g., HARQ and TUD processes). For example, after the initial access procedure, the UE may send its capability information message to the network device. For instance, the capability information message may include a higher-layer signaling parameter called “ueSoftBufferSharingBetweenHARQTUD”, which indicates whether the UE sending the capability information message can share its soft buffer between the HARQ and TUD processes. The parameter “ueSoftBufferSharingBetweenHARQTUD” may have a single value, such as “Supported”. The parameter “ueSoftBufferSharingBetweenHARQTUD” may also have an integer value, such as 1.

[0210] Figure 13 An exemplary process 1300, provided by an embodiment of the present invention, is illustrated in which a CB processing unit is shared between a HARQ process having a "soft" fence type and a TUD process having a "hard" fence type. Figure 13 In this configuration, the UE can execute HARQ process 1301 and TUD process 1302. HARQ process 1301 can be configured to have a "soft" fence type, and TUD process 1302 can be configured to have a "hard" fence type. 1310 represents the time slot for PDSCH reception at the UE associated with HARQ process 1301, and 1320 represents another time slot for PDSCH reception at the UE associated with TUD process 1302. Each rectangle in 1315 represents the time unit in which HARQ process 1301 is decoding the CB, and each rectangle in 1325 represents the time unit in which TUD process 1302 is decoding the CB.

[0211] exist Figure 13 In this context, it is assumed that the network device (e.g., TN TRP or NTN TRP) is configured to allow HARQ process 1301 to use a maximum of two CB processing units, while TUD process 1302 can use a maximum of one CB processing unit. In other words, the number of CB processing units associated with HARQ process 1301 is 2, and the number of CB processing units associated with TUD process 1302 is 1. Furthermore, it is assumed that the UE has at least two CB processing units that can be used concurrently.

[0212] exist Figure 13In time slot 1310, the UE can receive PDSCH transmissions based on HARQ process 1301. In time slot 1320, the UE can receive another PDSCH associated with TUD process 1302 and also begin decoding the TB carried by HARQ process 1301. Assuming the TB carried by HARQ process 1301 has 10 CBs, and both of the UE's CB processing units are available, then during time slot 1320, both CB processing units can be used to decode the CBs of the TB associated with HARQ process 1301, since it is not yet necessary to use CB processing units to decode the CBs of the TB carried by TUD process 1302. Therefore, in time slot 1320, the UE decodes 4 CBs of the TB carried by HARQ process 1301.

[0213] However, after time slot 1320, the UE can begin decoding the TB carried by TUD process 1302. Assume that the TB carried by TUD process 1302 has 10 CBs. Assume that HARQ process 1301 is configured with a "soft" fence type and TUD process 1302 is configured with a "hard" fence type, then TUD process 1302 can use the CB processing unit preferentially over HARQ process 1301. Therefore, one CB processing unit allocated to HARQ process 1301 can be released and used instead to decode the CB associated with TUD process 1302. When one CB processing unit is reassigned to TUD process 1302, after time slot 1320, HARQ process 1301 can be executed using only one CB processing unit, as... Figure 13 and Figure 14 As shown. Figure 14 This illustrates an exemplary allocation of CB processing units 1201 and 1202 between HARQ process 1301 and TUD process 1302 when both HARQ process 1301 and TUD process 1302 require CB processing units to decode the TB carried by the respective processes.

[0214] refer to Figures 13 to 14 After the decoding of the TB carried in the TUD process 1302 begins, and before the decoding of the TB carried in the HARQ process 1301 is completed, the UE may need to share CB processing units 1201 and 1202 between the HARQ process 1301 and the TUD process 1302. Specifically, one CB processing unit 1201 can be used to decode the CB in the TB carried in the HARQ process 1301, and another CB processing unit 1202 can be used to decode the CB in the TB carried in the TUD process 1302.

[0215] In some embodiments where the HARQ process is configured with a "no" fence type and the TUD process is configured with a "soft" or "hard" fence type, the sharing of CB processing units between the HARQ process and the TUD process can be similar to that described above. Figure 13 and Figure 14 This is performed in a manner that... In some embodiments, if a given HARQ process or TUD process has a "no" fence type, it may be necessary to release all of its CB processing units for use by another process with a higher priority (e.g., a process with a "soft" or "hard" fence type). In this case, decoding by the given HARQ process or TUD process with a "no" fence type is temporarily suspended until the CB processing units become available again.

[0216] Figure 15 An exemplary process 1500, provided by an embodiment of the present invention, is illustrated in which a CB processing unit is shared between a HARQ process having a "hard" fence type and a TUD process having a "soft" fence type. Figure 15 In this configuration, the UE can execute HARQ process 1501 and TUD process 1502. HARQ process 1501 can be configured with a "hard" fence type, and TUD process 1502 can be configured with a "soft" fence type. 1510 represents the time slot for PDSCH reception at the UE associated with HARQ process 1501, and 1520 represents another time slot for PDSCH reception at the UE associated with TUD process 1502. Each rectangle in 1515 represents the time unit in which HARQ process 1501 is decoding the CB, and each rectangle in 1525 represents the time unit in which TUD process 1502 is decoding the CB. 1520a represents the start time of CB decoding in the TB carried by HARQ process 1501 and the start time of PDSCH reception at the UE based on TUD process 1502. 1520b represents the end time of PDSCH reception at the UE based on TUD process 1502. 1520c represents the end time of decoding CB in TB carried by HARQ process 1501 and the start time of decoding CB in TB carried by TUD process 1502.

[0217] exist Figure 15 In, with Figure 13 Similarly, it is assumed that the network device (e.g., TN TRP or NTN TRP) is configured to use a maximum of two CB processing units for HARQ process 1501, while the TUD process 1502 can use a maximum of one CB processing unit. Furthermore, it is assumed that the UE has at least two CB processing units that can be used concurrently.

[0218] exist Figure 15In time slot 1510, the UE can receive PDSCH transmissions based on HARQ process 1501. In time slot 1520, the UE can receive another PDSCH associated with TUD process 1502. At time slot 1520a, the UE can begin decoding the TB carried by HARQ process 1501. Assuming the TB has 10 CBs and both CB processing units at the UE are available, both CB processing units can be used to decode the CBs of the TB associated with HARQ process 1501.

[0219] After time slot 1520, it may be necessary to use a CB processing unit to decode the TB carried by TUD process 1502. However, given that HARQ process 1501 is configured with a "hard" fence type and TUD process 1502 is configured with a "soft" fence type, HARQ process 1501 can use the CB processing unit preferentially over TUD process 1502; that is, TUD process 1502 has lower priority than HARQ process 1501 in terms of using the CB processing unit. Therefore, TUD process 1502 can delay (e.g., wait) until all CBs in the TB carried by HARQ process 1501 have been successfully or unsuccessfully decoded. When the decoding of the CBs associated with HARQ process 1501 is complete and therefore the CB processing unit is released, one of the CB processing units can be used to decode the CBs in the TB carried by TUD process 1502. This explains the situation in... Figure 15 The reason for the time gap between the end of PDSCH reception associated with TUD process 1502 (i.e., time 1520b) and the start of decoding of CB associated with TUD process 1502 (i.e., time 1520c).

[0220] In some embodiments where the HARQ process is configured with a "soft" fence type and the TUD process is configured with a "no" fence type, the sharing of CB processing units between the HARQ process and the TUD process can be similar to that described above. Figure 15 It is executed in the following manner.

[0221] Figure 16 An exemplary procedure 1600, provided by an embodiment of the present invention, is illustrated in which a CB processing unit is shared between a HARQ process with a "hard" fence type and a TUD process with a "soft" fence type when the UE simultaneously receives two PDSCH transmissions. Figure 16In this configuration, the UE can execute HARQ process 1601 and TUD process 1602. HARQ process 1601 can be configured with a "hard" fence type, and TUD process 1602 can be configured with a "soft" fence type. 1610 represents the time slot at the UE used for the reception of two PDSCHs associated with HARQ process 1601 and TUD process 1602. Each rectangle in 1615 represents the time unit in which HARQ process 1601 is decoding a CB, and each rectangle in 1625 represents the time unit in which TUD process 1602 is decoding a CB. 1610a represents the end time of the reception of the two PDSCHs at the UE. 1610b represents the end time of decoding the CB in the TB carried by HARQ process 1601 and the start time of decoding the CB in the TB carried by TUD process 1602.

[0222] exist Figure 16 In, such as Figure 13 and Figure 15 As shown, it is assumed that the network device (e.g., TN TRP or NTN TRP) is configured to use a maximum of two CB processing units for HARQ process 1601, while the TUD process 1602 can use a maximum of one CB processing unit. Furthermore, it is assumed that the UE has at least two CB processing units that can be used concurrently.

[0223] exist Figure 16 In this configuration, the UE can receive PDSCH transmissions based on HARQ process 1601 at time slot 1610. At time slot 1610, the UE can also receive another PDSCH transmission associated with TUD process 1602. Therefore, two PDSCH transmissions can be received simultaneously at the UE. For example, the two PDSCH transmissions can occupy the same orthogonal frequency division multiplexing (OFDM) symbols.

[0224] Related to the above and Figure 15 The example shown is similar, in Figure 16 In this configuration, HARQ process 1601 can be configured with a "hard" fence type, and TUD process 1602 can be configured with a "soft" fence type. In other words, HARQ process 1601 can use the CB processing unit preferentially over TUD process 1602; that is, TUD process 1602 has lower priority than HARQ process 1601 in using the CB processing unit. Therefore, after two PDSCH transmissions are completed at 1610a, i.e., when the CB decoding time has arrived, the CB decoding process can be performed based on the fence type of HARQ process 1601 and / or the fence type of TUD process 1602. Specifically, Figure 16In this process, the UE can use two CB processing units to begin decoding the CBs in the TB carried by HARQ process 1601. Decoding of the CBs in the TB carried by TUD process 1602 can be delayed (e.g., waited) until all CBs in the TB carried by HARQ process 1601 have been successfully or unsuccessfully decoded. After completing the CB decoding associated with HARQ process 1601 (at time 1610b), the UE can begin decoding the CBs in the TB carried by TUD process 1602. Figure 16 The process shown can be similar to the one described above and Figure 15 The process shown.

[0225] In some embodiments where two or more processes have the same priority (e.g., HARQ and TUD processes are configured to have the same fence type), CB decoding can be performed in various ways. In one example, the UE may determine the process that allocates the CB processing unit first based on its implementation. In another example, the UE may allocate the CB processing unit first to the process of the TB with the highest bearer bit count. In yet another example, the UE may allocate the CB processing unit first to the process of the TB with the lowest bearer bit count. It should be noted that other methods of allocating CB processing units are possible, although not explicitly described.

[0226] Dynamic reallocation of processing resources (e.g., CB processing units) can occur in TN systems, NTN systems, and integrated TN / NTN systems (e.g., network systems where terrestrial and non-terrestrial equipment may coexist). The example above is in the context of an integrated TN / NTN system, where one process is a HARQ process from the TN and another is a TUD process from the NTN. However, dynamic reallocation of processing resources is not limited to TN, NTN, or integrated TN / NTN systems, but is more broadly applicable to situations requiring decoding of multiple TBs but with limited available decoding resources (e.g., available CB processing units). This is not limited to specific types of communication (e.g., terrestrial or non-terrestrial), specific radio access technologies, or specific decoding processes (e.g., HARQ, TUD).

[0227] In some embodiments, the resource management processes described above, including processing resources such as shared memory space (e.g., soft buffers) and shared processing units (e.g., CB processing units), can be executed in tightly synchronized terrestrial and non-terrestrial systems. In such embodiments, all frames, slots, and OFDM symbol boundaries can be aligned in time or within the length of the OFDM cyclic prefix.

[0228] In some embodiments, the resource management process described above, including shared memory space and a shared CB processing unit for decoding CB, can be executed in loosely integrated or non-integrated terrestrial and non-terrestrial systems. Here, "integrated" can mean that the terrestrial and non-terrestrial systems occupy the same BWP within the same carrier. "Non-integrated" can mean that the terrestrial and non-terrestrial systems occupy different BWPs within the same or different carriers. "Loosely integrated" can mean that the terrestrial and non-terrestrial systems are not tightly synchronized, and the frames, time slots, and OFDM symbol boundaries may not be perfectly aligned in time; for example, the misalignment may be greater than the length of the OFDM cyclic prefix.

[0229] Figure 17 This illustration shows how an embodiment of the invention provides a method for sharing a CB processing unit between HARQ process 1701 and TUD process 1702 in a loosely integrated terrestrial and non-terrestrial system. 1710 represents a timeslot for PDSCH reception at the UE associated with HARQ process 1701, and 1720 represents another timeslot for PDSCH reception at the UE associated with TUD process 1702. 1730 represents the end time of PDSCH reception at the UE based on HARQ process 1701 and the start time of decoding of the CB in the TB carried by HARQ process 1701. 1740 represents the end time of PDSCH reception at the UE based on TUD process 1702 and the start time of decoding of the CB in the TB carried by TUD process 1702.

[0230] exist Figure 17 In this context, it is assumed that TN occupies a given BWP within a carrier, while NTN occupies another BWP within the same carrier. It is also assumed that TN is used to transmit PDSCH using HARQ process 1701, while NTN is used to transmit PDSCH using TUD process 1702. Figure 17 Furthermore, it is assumed that network devices (e.g., TN TRP or NTN TRP) are configured to use a maximum of one CB processing unit for HARQ process 1701, and a maximum of one CB processing unit for TUD process 1702. Additionally, it is assumed that the UE has at least two CB processing units that can be used concurrently.

[0231] exist Figure 17In this context, the UE can receive one or both PDSCH transmissions from the TN / NTN system. The UE can receive PDSCH transmissions based on HARQ process 1701 at time slot 1710. At time slot 1720, the UE can receive another PDSCH associated with TUD process 1702. However, due to the nature of non-integrated or loosely integrated systems, the PDSCH transmissions associated with HARQ process 1701 and TUD process 1702 may not be perfectly orthogonal or simultaneous in the time domain; for example, the time slot boundaries between TN and NTN systems are not as... Figure 17 The alignment shown is correct.

[0232] However, decoding of the CB in the TB carried by HARQ process 1701 and TUD process 1702 may still require UE hardware resources such as shared memory space (e.g., soft buffer) and processing units (e.g., CB processing unit) across TN and NTN systems. Regardless of the nature of the scenario, PDSCH transmissions can ultimately be mapped to the same memory space of the UE (e.g., the same soft buffer) and the same hardware logic (e.g., the same CB processing unit) can be used to decode the CB.

[0233] exist Figure 17 At time 1730, the PDSCH reception associated with HARQ process 1701 may have been completed, but the PDSCH reception associated with TUD process 1702 may not have been completed yet. However, as mentioned above, it may be necessary to share a CB processing unit between HARQ process 1701 and TUD process 1702. For example, the UE may start at time 1730 using one CB processing unit to decode the CB in the TB carried by HARQ process 1701, and start at time 1740 using another CB processing unit to decode the CB in the TB carried by TUD process 1702.

[0234] All the examples above describe processes for resource management, where the managed resources are memory space (e.g., soft buffer space) or processing resources (e.g., CB processing units). Resource management involves, for example, dynamically releasing at least a portion of resources so that the released resources (a portion) can be used to decode another TB. More generally, Figure 18 An exemplary process 1800 for resource management, provided by some embodiments of the present invention, is illustrated. Figure 18In this context, device 372 can be a UE. Each of devices 352a and 352b can be a terrestrial network device (e.g., T-TRP) or a non-terrestrial network device (e.g., NT-TRP). Devices 352a and 352b can be entities of the same type or entities of different types. In the following text, when referring to any one or both of devices 352a and 352b or any other similar devices, the reference character 352 may be used.

[0235] In step 1810, device 372 may send information indicating the capabilities of device 372 to device 352. The information indicating the capabilities of device 372 may indicate the resources available at device 372, for example, it may indicate the total number of at least one processing unit that device 372 can use concurrently.

[0236] In step 1815, device 352a may generate first configuration information configuring a first resource sharing restriction level for the first process, and device 352b may generate second configuration information configuring a second resource sharing restriction level for the second process. In some embodiments, the first configuration information may also configure the number (e.g., the number of CB processing units) of at least one processing unit associated with the first process for decoding a first TB associated with the first process to be sent to device 372. In such embodiments, although in Figure 18 While not explicitly shown, device 352 can determine the number of at least one processing unit associated with the first process for decoding the first TB. Similarly, in some embodiments, the second configuration information can also configure the number of at least one processing unit associated with the second process for decoding the second TB associated with the second process to be sent to device 372 (e.g., the number of CB processing units). In such embodiments, device 352 can determine the number of at least one processing unit associated with the second process for decoding the second TB.

[0237] In some embodiments, devices 352a and 352b may generate the first configuration information and the second configuration information separately, for example, without affecting each other.

[0238] In step 1820, device 352a may send first configuration information configuring a first resource sharing restriction level for the first process, and device 352b may send second configuration information configuring a second resource sharing restriction level for the second process. In an alternative variant, the first configuration information configuring the first resource sharing restriction level for the first process and the second configuration information configuring the second resource sharing restriction level for the second process may be generated and / or sent by the same device; for example, it may be carried in signaling (e.g., RRC signaling) sent to device 372 by a single network device.

[0239] The first resource sharing restriction level and / or the second resource sharing restriction level can be used, for example, by device 372 to determine whether to release at least a portion of the resources associated with the first process for decoding the first TB associated with the first process and / or at least a portion of the resources associated with the second process for decoding the second TB associated with the second process.

[0240] In some embodiments, transports can be performed independently; for example, transports at the first resource sharing restriction level may not affect transports at the second resource sharing restriction level.

[0241] Although Figure 18 The illustration shows that after device 352a sends the first resource sharing restriction level, device 352b determines and sends the second resource sharing restriction level, but this is not always the case. For example, device 352b may determine and send the second resource sharing restriction level before device 352a determines the first resource sharing restriction level. Devices 352a and 352b may perform the determination and sending in other orders.

[0242] In step 1825, device 352a may send a first transport block (TB) associated with the first process to device 372. In some embodiments, device 352a may send the first TB via a first physical downlink shared channel (PDSCH).

[0243] In some embodiments, the first process may implement a first framework for managing retransmissions of the TB to be decoded. In some embodiments, the first process may include signal streams and data processing instructions to be implemented for successful decoding of the first TB. In some embodiments, the first process may be a hybrid automatic repeat request (HARQ) process or a time until discard (TUD) process. The first process may be associated with any suitable radio access technology (RAT).

[0244] In step 1830, device 372 may use resources associated with the first process to decode the first TB (or begin decoding the first TB). Resources may be, for example, memory (e.g., soft-buffered memory space for storing partially decoded TBs) and / or processing resources (e.g., one or more CB processing units for decoding). It is assumed that decoding of the first TB is not completed in step 1830.

[0245] In step 1835, device 352b may send a second TB associated with the second process to device 372. In some embodiments, device 352b may send the second TB via a second PDSCH different from the first PDSCH. In some embodiments, the second PDSCH may be time-aligned with the first PDSCH. In some embodiments of those embodiments, the second resource associated with the second PDSCH and the first resource associated with the first PDSCH may partially overlap.

[0246] In some embodiments, the second process may implement a second framework for managing retransmissions of the TB to be decoded. In some embodiments, the second process may include a signaling stream and data processing instructions to be implemented for successful decoding of the second TB. In some embodiments, the second process may be a hybrid automatic repeat request (HARQ) process or a time until discard (TUD) process. The second process may be associated with any suitable RAT. The RAT associated with the second process may be the same as or different from the RAT associated with the first process.

[0247] It should be noted that the first and second processes can be the same type of process (e.g., both are HARQ processes or TUD processes), or they can be different types of processes (e.g., one is a HARQ process and the other is a TUD process). Figure 18 For illustrative purposes, we assume that the first process is the HARQ process and the second process is the TUD process.

[0248] Although Figure 18 The illustration shows that after device 352a transmits the first TB and device 372 begins decoding the first TB, device 352b transmits the second TB, but this is not always the case. For example, in some cases, devices 352a and 352b may transmit the first TB and the second TB simultaneously.

[0249] In step 1840, device 372 may determine to release at least a portion of the resources associated with the first process based on at least one of a first resource sharing restriction level of the first process or a second resource sharing restriction level of the second process.

[0250] In some embodiments, the resources may include memory space for storing one or more bits associated with the decoding of the first TB of code block (CB).

[0251] In some cases, the first resource sharing restriction level can correspond to restricting the release of memory space associated with the first process during the decoding of the first TB. For example, the first resource sharing restriction level can be the "hard" fence type described earlier. In this case, the memory space associated with the first process may not be shared with the second process during the decoding of the first TB.

[0252] In some cases, the first resource sharing restriction level may correspond to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, that portion of the memory space is released for decoding the second TB. For example, the first resource sharing restriction level may correspond to the "soft" fence type described above. A portion of the memory space associated with the first process may be occupied by one or more decoded CBs of the first TB before being released for decoding the second TB. When the second resource sharing restriction level is higher than or equal to the first resource sharing restriction level, a portion of the memory space associated with the first process may be released for decoding the second TB. When the second resource sharing restriction level is higher than the first resource sharing restriction level, device 372 may determine that at least a portion of the resources (e.g., memory space) associated with the first process is released for decoding the second TB, regardless of the priority of the first process and the priority of the second process. In this case, the second resource sharing restriction level may correspond to: restricting the release of memory space associated with the second process during the decoding of the second TB (e.g., the second resource sharing restriction level may be a "hard" fence type). When the second resource-sharing restriction level is equal to the first resource-sharing restriction level (e.g., when both the first and second resource-sharing restriction levels are "soft" fence types), device 372 can determine that at least a portion of the resources (e.g., memory space) associated with the first process is to be released for the second TB, because the priority of the second process may be higher than that of the first process. The priority of the first process can be determined based on the quality of service (QoS) associated with the data carried in the first TB, and the priority of the second process can be determined based on the QoS associated with the data carried in the second TB.

[0253] In some cases, a first resource sharing restriction level may correspond to: during the decoding of a first TB, freeing at least a portion of the memory space associated with the first process for decoding a second TB, regardless of whether that portion of the memory space associated with the first process was used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB. For example, a first resource sharing restriction level may correspond to the “none” fence type described above. In this case, when a second resource sharing restriction level is higher than a first resource sharing restriction level, device 372 may determine that at least a portion of resources (e.g., memory space) associated with the first process is freed for decoding the second TB. A second resource sharing restriction level may correspond to: (i) restricting the release of memory space associated with the second process during the decoding of the second TB; or (ii) during the decoding of the second TB, freeing that portion of the memory space associated with the second process for decoding a TB associated with another process when that portion was not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the second TB. A portion of the memory space associated with the second process may be occupied by one or more decoded CBs of the second TB.

[0254] In some embodiments, the resource includes at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

[0255] In some cases, the first resource sharing restriction level may correspond to: during the decoding of the first TB, at least some of the processing units of at least one processing unit associated with the first process are released and used to decode the second TB. In such cases, when the second resource sharing restriction level is higher than the first resource sharing restriction level, the device 372 may determine to release at least some of the processing units of at least one processing unit associated with the first process and instead use the released one or more processing units to decode the second TB.

[0256] Assuming that device 372 determines in step 1840 to release at least a portion of resources (e.g., memory space, at least one processing unit) associated with the first process, device 372 may release at least a portion of the resources associated with the first process in step 1845 during decoding of the first TB using the resources associated with the first process.

[0257] In some embodiments where the resources include memory space for storing one or more bits associated with decoding a first TB of CBs, when at least a portion of the memory space is used for bit occupancy of one or more unsuccessfully decoded CBs in the first TB and is released during decoding of the first TB, device 372 may generate feedback instructing the removal of one or more unsuccessfully decoded CBs of the first TB from the memory space and send the feedback to device 352a in step 1850. In this case, the second resource sharing restriction level may be higher than the first resource sharing restriction level; and the first resource sharing restriction level may correspond to: during decoding of the first TB, freeing at least a portion of the memory space associated with the first process for decoding the second TB, regardless of whether at least a portion of the memory space associated with the first process was used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

[0258] In step 1855, device 372 may use at least a portion of the resources released in step 1845 to decode the second TB.

[0259] It should be noted that some or all of steps 1810, 1815, 1820, 1840, and 1850 are optional steps. It should also be noted that the above and... Figure 18 The process 1800 shown is merely an example; one or more steps may be omitted or performed in a different order. Devices 372, 352a, and / or 352b may perform the above or Figure 18 One or more other steps not shown in the diagram.

[0260] The embodiments described above are in the context of an apparatus (e.g., a UE) communicating with a device (e.g., a TRP). However, more generally, devices that wirelessly communicate with each other via time-frequency resources are not necessarily UEs communicating with one or more TRPs. For example, two or more UEs can wirelessly communicate with each other via a sidelink using device-to-device (D2D) communication. As another example, two network devices (e.g., terrestrial base stations and non-terrestrial base stations, such as drones) can wirelessly communicate with each other via a backhaul link. The embodiments are not limited to uplink and / or downlink communication. For example, in the embodiments described above, device 352 can be replaced by other devices, such as nodes or UEs in the network. As another example, in the embodiments described above, apparatus 372 can be a network device. As another example, if both device 352 and apparatus 372 are UEs, the uplink / downlink communication can also be sidelink communication.

[0261] in conclusion It is important to note that the expression "at least one of A or B" used in this document is interchangeable with the expression "A and / or B". It refers to a list in which you can choose either A or B, or both A and B. Similarly, the expression "at least one of A, B, or C" used in this document is interchangeable with "A and / or B and / or C" or "A, B, and / or C". It refers to a list in which you can choose: A or B or C, or A and B, or A and C, or B and C, or all of A, B, and C. The same principle applies to longer lists with the same format.

[0262] In this invention, when used in conjunction with the terms "comprising" or "including" in the claims and / or specification, the word "a" or "an" may refer to "one," but it also has the same meaning as "one or more," "at least one," and "one or more," unless explicitly stated otherwise. Similarly, the word "another" may refer to at least a second or more, unless explicitly stated otherwise.

[0263] In this invention, when used before the same term (e.g., ED or operational step), the words "first," "second," etc., do not imply an order or sequence of the terms. For example, unless otherwise specified, "first ED" and "second ED" refer to two different EDs; similarly, unless otherwise specified, "first step" and "second step" refer to two different operational steps, but this does not mean that the first step must occur before the second step. The actual order depends on the logic of the two steps.

[0264] The terms “coupled” or “connected” as used herein may have several different meanings depending on the context in which they are used. For example, the terms “coupled” or “connected” as used herein may indicate that two elements or devices are directly connected to each other or connected to each other via mechanical elements through one or more intermediate elements or devices, depending on the specific context.

[0265] The terms “receive,” “detect,” and “decode” used in this document can have several different meanings depending on the context in which they are used. For example, without specific indication, the term “receive” can indicate that information (e.g., DCI or MAC-CE, RRC signaling, or TB) has been successfully received by the receiving node, meaning that the receiving side correctly detected and decoded it. In this case, “receive” may include both “detect” and “decode,” or it may mean the same thing. The term “receive” can sometimes mean that a signal has arrived at the receiving side, but this does not necessarily mean that the information in that signal has been correctly detected and decoded. The receiving side then needs to detect and decode the signal to obtain the information carried by it. In this scenario, “receive,” “detect,” and “decode” represent different processes by which the receiving side obtains information.

[0266] Although the invention has been described with reference to specific features and embodiments thereof, various modifications and combinations may be made to the invention without departing from its scope. Therefore, the specification and drawings are to be considered only as illustrative of some embodiments of the invention as defined in the appended claims, and any and all modifications, variations, combinations, or equivalents covering the scope of the invention are contemplated. Thus, while the invention and its advantages have been described in detail, various changes, substitutions, and alterations may be made without departing from the invention as defined in the appended claims. Furthermore, the scope of this application is not limited to the specific embodiments of the processes, machines, articles of manufacture, material compositions, components, methods, and steps described in the specification. Those skilled in the art will readily understand from the disclosure of the invention that existing or soon-to-be-developed processes, machines, articles of manufacture, material compositions, components, methods, or steps that perform substantially the same functions as the corresponding embodiments described herein, or that can achieve substantially the same results as the embodiments described herein, can be used according to the invention. Accordingly, the scope of the appended claims is intended to include such processes, machines, articles of manufacture, material compositions, components, methods, or steps.

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

Claims

1. A method, characterized in that, include: Receive the first transport block TB associated with the first process and the second transport block TB associated with the second process; During the decoding of the first TB using resources associated with the first process: at least a portion of the resources associated with the first process are released; At least a portion of the released resources is used to decode the second TB.

2. The method according to claim 1, characterized in that, Also includes: The release of at least a portion of the resources associated with the first process is determined based on at least one of the first resource sharing restriction level of the first process and the second resource sharing restriction level of the second process.

3. The method according to claim 2, characterized in that, Also includes: Receive first configuration information that configures the first resource sharing restriction level of the first process; Receive second configuration information that configures the second resource sharing restriction level of the second process.

4. The method according to claim 2 or 3, characterized in that, The resources include memory space for storing one or more bits associated with the decoding of the first TB code block CB.

5. The method according to claim 4, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, causing the portion of the memory space to be released for decoding the second TB.

6. The method according to claim 5, characterized in that, The portion of the memory space associated with the first process is occupied by one or more CBs of the first TB before being released for decoding the second TB.

7. The method according to claim 5 or 6, characterized in that, The second resource sharing restriction level is higher than or equal to the first resource sharing restriction level.

8. The method according to claim 7, characterized in that, When the second resource sharing restriction level is higher than the first resource sharing restriction level, the determination to release at least a portion of the resources associated with the first process is performed, regardless of the priority of the first process and the priority of the second process.

9. The method according to claim 8, characterized in that, The second resource sharing restriction level corresponds to: restricting the release of memory space associated with the second process during the decoding of the second TB.

10. The method according to claim 7, characterized in that, The second resource sharing restriction level is equal to the first resource sharing restriction level, and the priority of the second process is higher than the priority of the first process.

11. The method according to any one of claims 8 to 10, characterized in that, The priority of the first process is determined based on the Quality of Service (QoS) associated with the data carried in the first TB, and the priority of the second process is determined based on the QoS associated with the data carried in the second TB.

12. The method according to claim 4, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

13. The method according to claim 12, characterized in that, The second resource sharing restriction level is higher than the first resource sharing restriction level.

14. The method according to claim 13, characterized in that, The second resource sharing restriction level corresponds to: Restrict the release of memory space associated with the second process during the decoding of the second TB; or During the decoding of the second TB, when a portion of the memory space associated with the second process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the second TB, the portion of the memory space is released for decoding the TB associated with another process.

15. The method according to claim 14, characterized in that, The portion of the memory space associated with the second process is occupied by one or more decoded CBs of the second TB.

16. The method according to any one of claims 13 to 15, characterized in that, The method further includes the following when at least a portion of the memory space is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB and is released during decoding of the first TB: Generate feedback instructing the removal of the first TB of the one or more undecoded CBs from the memory space; Send the feedback.

17. The method according to claim 2 or 3, characterized in that, The resource includes at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

18. The method according to claim 17, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process are released and used to decode the second TB.

19. The method according to claim 18, characterized in that, The second resource sharing restriction level is higher than the first resource sharing restriction level.

20. The method according to any one of claims 17 to 19, characterized in that, The first configuration information further configures the number of at least one processing unit associated with the first process for decoding the first TB, and the second configuration information further configures the number of at least one processing unit associated with the second process for decoding the second TB.

21. The method according to any one of claims 17 to 20, characterized in that, Also includes: Information indicating the capabilities of the device is sent, the capabilities including the total number of the at least one processing unit that the device can use concurrently.

22. The method according to any one of claims 1 to 21, characterized in that, The first TB is received from the first network device via the first physical downlink shared channel (PDSCH), and the second TB is received from the second network device via a second PDSCH that is different from the first PDSCH.

23. The method according to claim 22, characterized in that, The first PDSCH and the second PDSCH are not time-aligned.

24. The method according to claim 23, characterized in that, The first resource associated with the first PDSCH and the second resource associated with the second PDSCH partially overlap.

25. The method according to any one of claims 22 to 24, characterized in that, The first network device is a terrestrial network device and the second network device is a non-terrestrial network device, or the first network device is a non-terrestrial network device and the second network device is a terrestrial network device.

26. The method according to any one of claims 1 to 25, characterized in that, The first process implements a first framework for managing the retransmission of the TB to be decoded, and the second process implements a second framework for managing the retransmission of the TB to be decoded.

27. The method according to claim 26, characterized in that, The first process is a Hybrid Automatic Repeat Request (HARQ) process, and the second process is either a HARQ process or a Drop Wait Time (TUD) process.

28. The method according to any one of claims 1 to 27, characterized in that, The first process is associated with a first radio access technology (RAT), and the second process is associated with a second RAT.

29. An apparatus, characterized in that, include: A processor coupled to a computer-readable medium having computer-executable instructions stored thereon, which, when executed, cause the device to: Receive the first transport block TB associated with the first process and the second transport block TB associated with the second process; During the decoding of the first TB using resources associated with the first process: at least a portion of the resources associated with the first process are released; At least a portion of the released resources is used to decode the second TB.

30. The apparatus according to claim 29, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: The release of at least a portion of the resources associated with the first process is determined based on at least one of the first resource sharing restriction level of the first process and the second resource sharing restriction level of the second process.

31. The apparatus according to claim 30, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: Receive first configuration information that configures the first resource sharing restriction level of the first process; Receive second configuration information that configures the second resource sharing restriction level of the second process.

32. The apparatus according to claim 30 or 31, characterized in that, The resources include memory space for storing one or more bits associated with the decoding of the first TB code block CB.

33. The apparatus according to claim 32, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, causing the portion of the memory space to be released for decoding the second TB.

34. The apparatus according to claim 33, characterized in that, The portion of the memory space associated with the first process is occupied by one or more CBs of the first TB before being released for decoding the second TB.

35. The apparatus according to claim 33 or 34, characterized in that, The second resource sharing restriction level is higher than or equal to the first resource sharing restriction level.

36. The apparatus according to claim 35, characterized in that, When the second resource sharing restriction level is higher than the first resource sharing restriction level, the determination to release at least a portion of the resources associated with the first process is performed, regardless of the priority of the first process and the priority of the second process.

37. The apparatus according to claim 36, characterized in that, The second resource sharing restriction level corresponds to: restricting the release of memory space associated with the second process during the decoding of the second TB.

38. The apparatus according to claim 35, characterized in that, The second resource sharing restriction level is equal to the first resource sharing restriction level, and the priority of the second process is higher than the priority of the first process.

39. The apparatus according to any one of claims 36 to 38, characterized in that, The priority of the first process is determined based on the Quality of Service (QoS) associated with the data carried in the first TB, and the priority of the second process is determined based on the QoS associated with the data carried in the second TB.

40. The apparatus according to claim 32, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

41. The apparatus according to claim 40, characterized in that, The second resource sharing restriction level is higher than the first resource sharing restriction level.

42. The apparatus according to claim 41, characterized in that, The second resource sharing restriction level corresponds to: Restrict the release of memory space associated with the second process during the decoding of the second TB; or During the decoding of the second TB, when a portion of the memory space associated with the second process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the second TB, the portion of the memory space is released for decoding the TB associated with another process.

43. The apparatus according to claim 42, characterized in that, The portion of the memory space associated with the second process is occupied by one or more decoded CBs of the second TB.

44. The apparatus according to any one of claims 41 to 43, characterized in that, When at least a portion of the memory space is used for bit occupancy in decoding the one or more unsuccessfully decoded CBs of the first TB and is released during decoding of the first TB, the processor-executable instructions further include processor-executable instructions that, when executed, cause the device to perform the following operations: Generate feedback instructing the removal of the first TB of the one or more undecoded CBs from the memory space; Send the feedback.

45. The apparatus according to any one of claims 29 to 31, characterized in that, The resource includes at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

46. ​​The apparatus according to claim 45, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process are released and used to decode the second TB.

47. The apparatus according to claim 46, characterized in that, The second resource sharing restriction level is higher than the first resource sharing restriction level.

48. The apparatus according to any one of claims 45 to 47, characterized in that, The first configuration information further configures the number of at least one processing unit associated with the first process for decoding the first TB, and the second configuration information further configures the number of at least one processing unit associated with the second process for decoding the second TB.

49. The apparatus according to any one of claims 45 to 48, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: Information indicating the capabilities of the device is sent, the capabilities including the total number of the at least one processing unit that the device can use concurrently.

50. The apparatus according to any one of claims 29 to 49, characterized in that, The first TB is received from the first network device via the first physical downlink shared channel (PDSCH), and the second TB is received from the second network device via a second PDSCH that is different from the first PDSCH.

51. The apparatus according to claim 50, characterized in that, The first PDSCH and the second PDSCH are not time-aligned.

52. The apparatus according to claim 51, characterized in that, The first resource associated with the first PDSCH and the second resource associated with the second PDSCH partially overlap.

53. The apparatus according to any one of claims 50 to 52, characterized in that, The first network device is a terrestrial network device and the second network device is a non-terrestrial network device, or the first network device is a non-terrestrial network device and the second network device is a terrestrial network device.

54. The apparatus according to any one of claims 29 to 53, characterized in that, The first process implements a first framework for managing the retransmission of the TB to be decoded, and the second process implements a second framework for managing the retransmission of the TB to be decoded.

55. The apparatus according to claim 54, characterized in that, The first process is a Hybrid Automatic Repeat Request (HARQ) process, and the second process is either a HARQ process or a Drop Wait Time (TUD) process.

56. The apparatus according to any one of claims 29 to 55, characterized in that, The first process is associated with a first radio access technology (RAT), and the second process is associated with a second RAT.

57. A method, characterized in that, include: Send configuration information for a first resource sharing restriction level for the first process, wherein the first resource sharing restriction level is used to determine whether to release at least a portion of the resources associated with the first process for decoding a first TB associated with the first process.

58. The method according to claim 57, characterized in that, Also includes: Determine the first resource sharing restriction level for the first process.

59. The method according to claim 57 or 58, characterized in that, The resources include memory space for storing one or more bits associated with the decoding of the first TB code block CB.

60. The method according to claim 59, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, causing the portion of the memory space to be released for decoding the second TB associated with the second process.

61. The method according to claim 60, characterized in that, The portion of the memory space associated with the first process is occupied by one or more CBs of the first TB before being released for decoding the second TB.

62. The method according to claim 60 or 61, characterized in that, When the first resource sharing restriction level is lower than or equal to the second resource sharing restriction level of the second process, the portion of the memory space associated with the first process is released for decoding the second TB.

63. The method according to claim 62, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level, a portion of the memory space associated with the first process is released for decoding the second TB, regardless of the priority of the first process and the priority of the second process.

64. The method according to claim 63, characterized in that, When the first resource sharing restriction level is equal to the second resource sharing restriction level, and the priority of the second process is higher than that of the first process, the portion of the memory space associated with the first process is released for decoding the second TB.

65. The method according to claim 63 or 64, characterized in that, The priority of the first process is determined based on the Quality of Service (QoS) associated with the data carried in the first TB, and the priority of the second process is determined based on the QoS associated with the data carried in the second TB.

66. The method according to claim 59, characterized in that, The first resource sharing restriction level corresponds to: restricting the release of the memory space associated with the first process during the decoding of the first TB.

67. The method according to claim 59, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB associated with the second process, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

68. The method according to claim 67, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, the portion of the memory space associated with the first process is released for decoding the second TB.

69. The method according to claim 68, characterized in that, Also includes: When at least a portion of the memory space is used for bit occupancy in decoding the one or more undecoded CBs of the first TB and is released during decoding of the first TB, feedback indicating the removal of the one or more undecoded CBs of the first TB from the memory space is received.

70. The method according to claim 57 or 58, characterized in that, The resource includes at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

71. The method according to claim 70, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process are released and used to decode the second TB associated with the second process.

72. The method according to claim 71, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, at least some of the processing units in the at least one processing unit associated with the first process are released and used to decode the second TB.

73. The method according to any one of claims 70 to 72, characterized in that, The configuration information further configures the number of at least one processing unit associated with the first process for decoding the first TB, and the method further includes: Determine the number of the at least one processing unit associated with the first process for decoding the first TB.

74. The method according to any one of claims 70 to 73, characterized in that, Also includes: Receive information indicating the capability of the device executing the first process, the capability including the total number of the at least one processing unit that the device can use concurrently.

75. The method according to any one of claims 57 to 74, characterized in that, The device is either a terrestrial network device or a non-terrestrial network device.

76. The method according to any one of claims 57 to 75, characterized in that, The first process implements a framework for managing the retransmission of TBs to be decoded.

77. The method according to claim 76, characterized in that, The first process is either a Hybrid Automatic Repeat Request (HARQ) process or a Discard Wait Time (TUD) process.

78. A device, characterized in that, include: A processor coupled to a computer-readable medium having computer-executable instructions stored thereon, which, when executed, cause the device to: Send configuration information for a first resource sharing restriction level for the first process, wherein the first resource sharing restriction level is used to determine whether to release at least a portion of the resources associated with the first process for decoding a first TB associated with the first process.

79. The device according to claim 78, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: Determine the first resource sharing restriction level for the first process.

80. The device according to claim 78 or 79, characterized in that, The resources include memory space for storing one or more bits associated with the decoding of the first TB code block CB.

81. The device according to claim 80, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, when a portion of the memory space associated with the first process is not used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB, causing the portion of the memory space to be released for decoding the second TB associated with the second process.

82. The device according to claim 81, characterized in that, The portion of the memory space associated with the first process is occupied by one or more CBs of the first TB before being released for decoding the second TB.

83. The device according to claim 81 or 82, characterized in that, When the first resource sharing restriction level is lower than or equal to the second resource sharing restriction level of the second process, the portion of the memory space associated with the first process is released for decoding the second TB.

84. The device according to claim 83, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level, a portion of the memory space associated with the first process is released for decoding the second TB, regardless of the priority of the first process and the priority of the second process.

85. The device according to claim 83, characterized in that, When the first resource sharing restriction level is equal to the second resource sharing restriction level, and the priority of the second process is higher than that of the first process, the portion of the memory space associated with the first process is released for decoding the second TB.

86. The device according to claim 84 or 85, characterized in that, The priority of the first process is determined based on the Quality of Service (QoS) associated with the data carried in the first TB, and the priority of the second process is determined based on the QoS associated with the data carried in the second TB.

87. The device according to claim 80, characterized in that, The first resource sharing restriction level corresponds to: restricting the release of the memory space associated with the first process during the decoding of the first TB.

88. The device according to claim 80, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least a portion of the memory space associated with the first process is released for decoding the second TB associated with the second process, regardless of whether the at least a portion of the memory space associated with the first process is used for bit occupancy in decoding one or more unsuccessfully decoded CBs of the first TB.

89. The device according to claim 88, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, the portion of the memory space associated with the first process is released for decoding the second TB.

90. The device according to claim 89, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: When at least a portion of the memory space is used for bit occupancy in decoding the one or more undecoded CBs of the first TB and is released during decoding of the first TB, feedback indicating the removal of the one or more undecoded CBs of the first TB from the memory space is received.

91. The device according to claim 78 or 79, characterized in that, The resource includes at least one processing unit for decoding one or more code blocks (CBs) of the first TB.

92. The device according to claim 91, characterized in that, The first resource sharing restriction level corresponds to: during the decoding of the first TB, at least some of the processing units of the at least one processing unit associated with the first process are released and used to decode the second TB associated with the second process.

93. The device according to claim 92, characterized in that, When the first resource sharing restriction level is lower than the second resource sharing restriction level of the second process, at least some of the processing units in the at least one processing unit associated with the first process are released and used to decode the second TB.

94. The device according to any one of claims 91 to 93, characterized in that, The configuration information further configures the number of the at least one processing unit associated with the first process for decoding the first TB, and the processor executable instructions further include processor executable instructions that, when executed, cause the device to perform the following operations: Determine the number of the at least one processing unit associated with the first process for decoding the first TB.

95. The device according to any one of claims 91 to 94, characterized in that, The processor-executable instructions also include processor-executable instructions that, when executed, cause the device to perform the following operations: Receive information indicating the capability of the device executing the first process, the capability including the total number of the at least one processing unit that the device can use concurrently.

96. The device according to any one of claims 78 to 95, characterized in that, The device is either a terrestrial network device or a non-terrestrial network device.

97. The device according to any one of claims 78 to 96, characterized in that, The first process implements a framework for managing the retransmission of TBs to be decoded.

98. The device according to claim 97, characterized in that, The first process is either a Hybrid Automatic Repeat Request (HARQ) process or a Discard Wait Time (TUD) process.

99. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, cause a computer to perform the method according to any one of claims 1 to 28 or 57 to 77.

Images