Channel access method

Abstract

The invention discloses a method for a user equipment (UE) to report the opportunity that a physical uplink shared channel (PUSCH) is not used in a configuration grant (CG) period, and relates to a method for the UE to report the opportunity that the physical uplink shared channel (PUSCH) is not used in the CG period. The UE receives information about the CG, including a number of consecutive slots within the CG period and a size of a bitmap for reporting. Based on the received CG configuration, the UE identifies an unused PUSCH occasion within the CG cycle. In one embodiment, the UE transmits uplink control information (UCI) in a physical uplink shared channel (PUSCH) opportunity, and the UE transmits the uplink control information (UCI) in a physical uplink shared channel (PUSCH) opportunity. The UCI includes a bitmap indicating the identified opportunity of unused PUSCH (Physical Uplink Shared Channel).

Description

Channel access method Technical Field

[0001] This disclosure relates to the field of communication systems, and more specifically, to a channel access method. Background Technology

[0002] Extended Reality (XR) applications, such as those studied in 3GPP TR 38.835, present unique challenges in uplink (UL) services. In XR video applications, User Equipment (UE) generates various types of video frames (e.g., I-frames or P / B-frames) at a specific frame rate (e.g., 60fps or 90fps). This results in a variable packet size for the Protocol Data Unit (PDU) set within a transmission cycle.

[0003] Multiple PDUs in a set may need to be segmented within the PDU Set Delay Budget (PSDB) and delivered over multiple Transport Blocks (TBs). To meet PSDB requirements and achieve low latency for XR services, CG-PUSCH transmission can be performed using Configured Grant (CG) resources.

[0004] To support multiple TB transmissions within the aforementioned latency limits, multiple Physical Uplink Shared Channel (PUSCH) transmission opportunities can be created within a CG cycle. This multi-PUSCH CG method adopts a configuration from the R16 NR-U CG, using parameters such as: 1. cg-nrofPUSCH-InSlot: the number of consecutive PUSCH opportunities per slot; 2. cg-nrofSlots: the number of consecutive slots used for PUSCH transmission. These parameters allow the number of PUSCH transmission opportunities to vary per CG cycle.

[0005] However, it should be noted that the NR-U framework primarily focuses on unlicensed spectrum operations and only supports Frequency-Division Duplex (FDD) frame structures. Furthermore, these parameters are only applicable when the Radio Resource Control (RRC) parameter cg-RetransmissionTimer for autonomous retransmission is configured.

[0006] The following describes some technical issues: Uplink video coding challenges: The video encoder equipped on the UE side presents significant challenges in the uplink. It generates video frames of different sizes, such as I-frames and P / B-frames, at a specific frame rate. Each of these packets is subject to a strict PDU set delay budget (PSDB), which increases the complexity of the transmission process.

[0007] XR service requirements: XR services introduce additional complexity due to their larger and unpredictable variable packet sizes. Current configurations that allocate only one CG resource within a single CG cycle fail to adequately reflect the characteristics of XR packets. Therefore, there is an urgent need for a method that supports multi-PUSCH CG configurations to better accommodate XR business models.

[0008] Resource utilization efficiency: Due to the fluctuating nature of the XR service mode, some CG resources may be over-provisioned or underutilized by the UE. A channel access method is needed to address this inefficiency and improve overall system capacity.

[0009] Uplink UL video service coverage: Ensuring adequate uplink video service coverage requires careful consideration of repeated PUSCH transmissions for TBs within the context of a multi-PUSCHCG configuration. This involves scenarios where TBs may need to be carried across multiple consecutive PUSCH events to maintain reliable transmission.

[0010] Retransmission Support: In scenarios where some initial transmissions of multiple TBs fail in a multi-PUSCH CG, robust retransmission support becomes crucial. Specifying this mechanism for the multi-PUSCH CG configuration is essential to ensure reliable data transmission under challenging network conditions. Summary of the Invention

[0011] The purpose of this disclosure is to propose a channel access method.

[0012] In a first aspect, embodiments of the present invention provide a channel access method performed by a user equipment (UE), comprising: receiving a configuration of the number of consecutive time slots within a configuration grant (CG) period of a CG configuration and a bitmap size for reporting one or more unused PUSCH opportunities of the CG configuration; and transmitting uplink control information (UCI) in a PUSCH opportunity to transmit the bitmap, the bitmap indicating one or more unused PUSCH opportunities, wherein the one or more unused PUSCH opportunities are determined based on the received configuration of the CG configuration.

[0013] In a second aspect, embodiments of the present invention provide a channel access method performed by a base station, comprising: configuring the number of consecutive time slots within a CG period of a transmission CG configuration and configuring a bitmap size for reporting one or more unused PUSCH opportunities of the CG configuration; and receiving a UCI during a PUSCH opportunity; wherein the UCI transmits the bitmap, the bitmap indicating one or more unused PUSCH opportunities; wherein the one or more unused PUSCH opportunities are determined based on the configuration of the CG configuration.

[0014] In a third aspect, embodiments of the present invention provide a user equipment (UE) including a processor configured to invoke and run a computer program stored in a memory to cause a device equipped with the processor to perform the disclosed method.

[0015] In a fourth aspect, embodiments of the present invention provide a base station including a processor configured to invoke and run a computer program stored in a memory to cause a device equipped with the processor to perform the disclosed method.

[0016] The disclosed method can be programmed as computer-executable instructions stored in a non-transitory computer-readable medium. When loaded into a computer, the non-transitory computer-readable medium instructs the computer's processor to execute the disclosed method.

[0017] The non-transitory computer-readable medium may include at least one of the following: hard disk, CD-ROM, optical storage device, magnetic storage device, read-only memory, programmable read-only memory, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory, and flash memory.

[0018] The disclosed method can be programmed into a computer program product that causes a computer to execute the disclosed method.

[0019] The disclosed method can be programmed into a computer program that causes a computer to execute the disclosed method. Beneficial Effects: At least one embodiment provides a multi-PUSCH CG configuration to address the identified challenges. This embodiment provides comprehensive parameters and schemes for configuring multi-PUSCH CG. The solution is designed to better accommodate the variable packet size and transmission requirements of XR services.

[0020] At least one embodiment provides support for transport block (TB) retransmission. In this embodiment, specific parameters and schemes are provided to support the retransmission of the TB within the multi-PUSCH CG architecture. This method enhances the reliability and coverage of uplink video services.

[0021] At least one embodiment provides a retransmission and re-transmission scheme. To ensure robust data transmission, a dedicated retransmission and re-transmission scheme is established and customized for multi-PUSCH CG. These schemes will address scenarios where initial transmission fails and improve overall reliability.

[0022] At least one embodiment provides a report of unused CG PUSCH moments. To optimize resource utilization, it is proposed to determine a candidate range of PUSCH moments for bitmap indication of unused CG PUSCH moments. Furthermore, it is proposed to develop an efficient bitmap scheme for reporting these unused CG PUSCH moments to the gNB. These measures aim to enhance resource allocation efficiency. The determined candidate range of PUSCH moments provides a framework for indicating which CG PUSCH moments are unused, while the efficient bitmap scheme helps to report this information to the gNB clearly and concisely.

[0023] Enhanced CG configurations with multiple CG PUSCH opportunities within a CG cycle offer several significant benefits. Primarily, they more accurately reflect uplink data transmission, accommodating various service patterns with variable payload sizes. This flexibility is crucial in modern network environments where data demands can fluctuate rapidly. Furthermore, the joint design of repeated transmissions within multi-PUSCH CGs enhances uplink data transmission coverage, ensuring more reliable communication over longer distances or in challenging environments. The inclusion of the retransmission mechanism in multi-PUSCH CGs further improves uplink data transmission performance, reduces data loss, and enhances overall reliability.

[0024] These enhanced configurations also play a crucial role in preventing additional latency and overhead. This is achieved by eliminating the need to initiate the Scheduling Request (SR) / Buffer Status Reporting (BSR) process, which is typically required for frequent reconfiguration of CG or Dynamic Grant (DG) scheduling. This streamlined approach contributes to more efficient network operation and an improved user experience.

[0025] The ability to indicate to the gNB when CG PUSCH is not used offers its own set of advantages. Primarily, it improves system capacity and resource efficiency by allowing over-provisioned CG resources to be reallocated to other UEs. This dynamic resource management ensures that network resources are fully utilized. Furthermore, this indication mechanism reduces the blind decoding overhead of the gNB on unused CG PUSCH resources, thereby saving unnecessary power consumption. This energy efficiency is increasingly important in modern network design.

[0026] Furthermore, the feedback provided by this instruction allows the gNB to more effectively adjust the parameters of the CG PUSCH configuration. This adaptive approach improves resource utilization to better meet the uplink traffic needs of each UE. It also reduces the overhead associated with the UE's continuous reporting of instances where CGPUSCH is not used, striking a balance between network awareness and efficient communication. Overall, these benefits contribute to a more responsive, efficient, and adaptive network infrastructure. Attached Figure Description

[0027] To more clearly illustrate the embodiments or related technologies of this disclosure, the accompanying drawings described in the embodiments will be briefly introduced below. Obviously, the drawings are only some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any prior knowledge.

[0028] Figure 1 shows a schematic diagram of a telecommunications system.

[0029] Figure 2 shows a schematic diagram illustrating one embodiment of the disclosed channel access method.

[0030] Figure 3 shows a schematic diagram of an example of a multi-PUSCH CG configured with M=2, N=3 and a repetition transfer factor K=2.

[0031] Figure 4 shows a schematic diagram of an example of a multi-PUSCH CG configured with M=2, N=3 and a repetition transfer factor K=3.

[0032] Figure 5 shows a schematic diagram of an example of a multi-PUSCH CG configured with M=N=3 and K=4.

[0033] Figure 6 shows a schematic diagram of an example of a multi-PUSCHCG configured with M=2, N=3, repetition transfer factor K=2, and RV mode={0,2,3,1}.

[0034] Figure 7 shows a schematic diagram of the timers associated with the TB group.

[0035] Figure 8 shows a schematic diagram illustrating an example of an unused PUSCH timing indication based on the indication cycle.

[0036] Figure 9 shows a schematic diagram illustrating an example of an unused PUSCH timing indication based on the PUSCH timing set.

[0037] Figure 10 shows a schematic diagram illustrating an example of a bitmap indication with TB repeat transmissions.

[0038] Figure 11 shows a schematic diagram illustrating an example of a bitmap indication with TB repetitive transmission based on embodiment F of scheme 2.

[0039] Figure 12 illustrates the process of configuring multiple CG PUSCH opportunities within the CG by the gNB and having the UE report unused CG PUSCH opportunities.

[0040] Figure 13 shows a schematic diagram of the display user equipment (UE).

[0041] Figure 14 shows a schematic diagram of network nodes.

[0042] Figure 15 shows a schematic diagram of a chip performing the disclosed method in a UE.

[0043] Figure 16 shows a schematic diagram of a chip executing the disclosed method in a network node. Detailed Implementation

[0045] The technical aspects, structural features, implementation objectives, and effects of embodiments of this disclosure are described in detail below with reference to the accompanying drawings. Specifically, the terminology used in the embodiments of this disclosure is only used to describe the purpose of the specific embodiments and is not intended to limit this disclosure. In this disclosure, the term " / " should be interpreted as indicating "and / or".

[0046] Referring to Figure 1, according to one embodiment of this disclosure, a telecommunications system including User Equipment (UE) 10a, UE 10b, Base Station (BS) 20a, and Network Entity Equipment 30 performs the disclosed method. Figure 1 is illustrated for illustrative purposes and is not restrictive, and the system may include further UEs, BSs, and Core Network (CN) entities. Connections between devices and device components are shown as lines and arrows in the figure. UE 10a may include a processor 11a, a memory 12a, and a transceiver 13a. UE 10b may include a processor 11b, a memory 12b, and a transceiver 13b. Base Station 20a may include a processor 21a, a memory 22a, and a transceiver 23a. Network Entity Equipment 30 may include a processor 31, a memory 32, and a transceiver 33. Each of the processors 11a, 11b, 21a, and 31 may be configured to implement the functions, processes, and / or methods presented in the description. The wireless interface protocol layer can be implemented in the processors 11a, 11b, 21a, and 31. Each of the memories 12a, 12b, 22a, and 32 is operatively storing various programs and information to operate the connected processor. Each of the transceivers 13a, 13b, 23a, and 33 is operatively coupled to the connected processor and transmits and / or receives radio or wired signals. The UE 10a can communicate with the UE 10b via a sidelink. The base station 20a can be an eNB, gNB, or other type of radio node and can configure radio resources for the UE 10a and UE 10b.

[0047] Each of the processors 11a, 11b, 21a, and 31 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. Each of the memories 12a, 12b, 22a, and 32 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices. Each of the transceivers 13a, 13b, 23a, and 33 may include baseband circuitry and radio frequency (RF) circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented using modules, procedures, functions, entities, etc., that perform the functions described herein. The modules may be stored in memory and executed by the processor. The memory may be implemented within the processor or external to the processor; if implemented externally, it may be communicatively coupled to the processor by various means known in the art.

[0048] The network entity device 30 can be a node in the CN. The CN can include an LTE CN or a 5G Core (5GC), which includes User Plane Function (UPF), Session Management Function (SMF), Mobility Management Function (AMF), Unified Data Management (UDM), Policy Control Function (PCF), Control Plane (CP) / User Plane (UP) Separation (CUPS), Authentication Server Function (AUSF), Network Slice Selection Function (NSSF), and Network Exposure Function (NEF).

[0049] Examples of the UE described herein may include one of UE 10a or UE 10b. Examples of the base station described herein may include base station 20a. Sidelink (SL) transmission of control signals or data may be a transmission operation from one UE to another. Uplink (UL) transmission of control signals or data may be a transmission operation from the UE to the base station. Downlink (DL) transmission of control signals or data may be a transmission operation from the base station to the UE. DL control signals may include Medium Access Control (MAC) control element (CE), Downlink Control Information (DCI), or Radio Resource Control (RRC) signals from the base station to the UE.

[0050] Referring to FIG2, an embodiment of the disclosed channel access method is shown. The configuration of the number of consecutive time slots within a Configured Grant (CG) period for transmitting CG configuration by base station 20a, and the configuration of the bitmap size for reporting one or more unused PUSCH opportunities of the CG configuration (A001).

[0051] The UE 10a receives the configuration of the number of consecutive time slots within the CG period of the CG configuration and the configuration (B002) of the size of a bitmap for reporting one or more unused PUSCH opportunities of the CG configuration.

[0052] The UE 10a transmits Uplink Control Information (UCI) during a PUSCH timing to transmit the bitmap, the bitmap indicating one or more unused PUSCH timings, wherein the one or more unused PUSCH timings are determined based on the received configuration of the CG configuration (B003). The base station 20a receives the UCI during the PUSCH timing (A004).

[0053] The UCI transmits the bitmap, which indicates one or more unused PUSCH moments. These one or more unused PUSCH moments are determined based on the configuration of the CG configuration.

[0054] In some embodiments of this disclosure, the configuration is applicable to type 1 or type 2 CG.

[0055] In some embodiments of this disclosure, at least one of the consecutive time slots of the configuration includes a downlink (DL) symbol.

[0056] In some embodiments of this disclosure, the initial slot position of the consecutive slots for the configuration of Type 1 CG is determined based on an offset relative to the reference system frame number (SFN).

[0057] In some embodiments of this disclosure, the initial slot position of the consecutive slots for the configuration of type 2 CG is determined based on an offset value relative to the slot position carrying the activated DCI.

[0058] In some embodiments of this disclosure, the position of one or more symbols in a slot with a PUSCH timing is determined based on the Start and Length IndicatorValue (SLIV) value derived from RRC signaling for Type 1 CG.

[0059] In some embodiments of this disclosure, the one or more symbol positions with PUSCH timing in the time slot are applied to other time slots within the CG period, and the one or more symbol positions with PUSCH timing for the UCI do not collide with DL symbols or Synchronization Signal Blocks (SSBs).

[0060] In some embodiments of this disclosure, the frequency position or modulation and coding scheme (MCS) of the time slot with PUSCH timing is applied to other time slots within the CG cycle.

[0061] In some embodiments of this disclosure, one or more symbol positions in a slot with PUSCH timing are determined based on SLIV values ​​derived from the activation DCI for type 2 CG.

[0062] In some embodiments of this disclosure, the one or more symbol positions with PUSCH timing in the time slot are applied to all time slots within the CG period, and the one or more symbol positions with PUSCH timing for the UCI do not collide with DL symbols or SSBs.

[0063] In some embodiments of this disclosure, the frequency position of the time slot with PUSCH timing or the MCS is applied to other time slots within the CG cycle.

[0064] In some embodiments of this disclosure, at least one value of the number of consecutive time slots within the CG cycle is an integer multiple of the size of the bitmap used to report one or more unused PUSCH moments.

[0065] In some embodiments of this disclosure, the PUSCH timing for receiving the UCI is a PUSCH timing that has not been declared as unused.

[0066] In some embodiments of this disclosure, each bit of the bitmap is associated with a PUSCH timing in a time slot, and each PUSCH timing indicated by the bitmap does not collide with a DL symbol or SSB.

[0067] In some embodiments of this disclosure, the bitmap includes a sequence of bits, each bit in the sequence being associated with a corresponding PUSCH timing, wherein the bits are arranged from left to right, corresponding to the PUSCH timing in chronological order from earliest to latest.

[0068] In some embodiments of this disclosure, the first PUSCH timing is located in a time slot after a time offset relative to the end of the time slot carrying the bitmap in the UCI.

[0069] In some embodiments of this disclosure, the value of the time offset is 0, or is assumed to be 0 if the time offset is not configured in the CG configuration.

[0070] In some embodiments of this disclosure, at least one bit of the bitmap indicates a PUSCH timing in another CG cycle, which is different from the CG cycle used to transmit the bitmap in the UCI.

[0071] In some embodiments of this disclosure, bit value 1 in the bitmap indicates that the corresponding PUSCH timing is an unused PUSCH timing in a PUSCH transmission.

[0072] In some embodiments of this disclosure, the one or more symbol positions with PUSCH timing in the time slot are applied to all time slots within the CG period, and the one or more symbol positions with PUSCH timing for transmitting the UCI do not collide with DL symbols or SSBs.

[0073] In some embodiments of this disclosure, the frequency position of the time slot with PUSCH timing or the MCS is applied to other time slots within the CG cycle.

[0074] To support licensed band operation with multiple PUSCH opportunities per CG cycle, modifications to the NR-U CG framework are necessary. These modifications may include: Supports non-continuous UL time slots in Time-Division Duplex (TDD) frame structures; Adaptation of retransmission types and retransmission schemes for multiple TB transmissions in each CG cycle; and / or New RRC parameters are introduced to enable these enhancements.

[0075] While configuring multiple CG PUSCH transmission opportunities within a CG cycle can accommodate larger UL video packet sizes, the variability of these packets means that the actual number of TBs transmitted within a CG cycle is uncertain for the gNB (e.g., one or more BSs shown in Figure 1). To improve resource efficiency in the event of over-configuration, the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) can dynamically indicate to the gNB unused CG PUSCH opportunities within the configured CG PUSCH opportunities.

[0076] Once the gNB confirms the unused time reported by the UE, these resources can be released and reallocated to the same UE or other UEs, thereby improving overall resource utilization.

[0077] Example A: Information settings associated with multi-PUSCH CG configuration within the CG cycle.

[0078] This embodiment describes the information provided by the gNB (e.g., one or more BSs shown in Figure 1) to the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) for configuring multiple PUSCH timings within a CG cycle. This information can be provided via RRC signaling or activated DCI, depending on whether Type 1 or Type 2 CG is used. Key aspects of this configuration include: 1. PUSCH timing location; 2. TB retransmission settings; 3. Symbol location of the first PUSCH timing; 4. MCS and frequency domain resource allocation settings. These configurations apply to multi-PUSCH CG operation, even if cgRetransmissionTimer is not configured. The following subsections (Examples A-1, A-2, A-3) provide more detailed information about specific aspects of this configuration.

[0079] Example A-1: ​​Location of PUSCH timing.

[0080] The gNB provides at least one of the following information to the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) to determine the location of the PUSCH timing for each CG configuration: 1. The number of consecutive time slots for the multi-PUSCH CG; 2. The number of consecutive and valid PUSCH timings within a time slot for the multi-PUSCH CG (denoted by parameter M); 3. The initial time slot position of the consecutive time slots for the multi-PUSCH CG within the CG period; 4. The symbol position in the first PUSCH timing within the initial time slot of the multi-PUSCH CG; and 5. Modulation and Coding Scheme (MCS) and Frequency Domain Resource Allocation (FDRA) settings. 1. The number of consecutive time slots for the multi-PUSCH CG (denoted by parameter N).

[0081] i. The parameter N can be interpreted in one of the following ways: The value of continuous time slot N refers to the effective time slot used for UL transmission within the CG period, that is, it is only applicable to UL time slots.

[0082] The value of consecutive time slot N refers to any time slot type, including DL and UL within the CG period, for example, if a Time Division Duplex (TDD) frame structure is configured. However, only time slots configured as UL are valid time slots for PUSCH transmission. In this case, if parameter N' is defined as the number of valid time slots for PUSCH transmission, then N' <= N. For ease of explanation, unless otherwise stated, we assume N' = N in the following embodiments.

[0083] 2. The number of consecutive and valid PUSCH opportunities within a time slot used for multi-PUSCH CG (denoted by parameter M).

[0084] i. The timing of the first PUSCH symbol within a time slot is determined based on the start and length indicator (SLIV) value in the Time Domain Resource Assignment (TDRA) table configured by the gNB. Subsequent PUSCH timings within the same time slot follow the first one consecutively, each having the same symbol length (i.e., number of symbols) as defined by the SLIV.

[0085] ii. The parameter M considers the valid PUSCH timing within the time slot, wherein the PUSCH timing includes only the UL symbol.

[0086] The number M of consecutive and valid PUSCH opportunities in the N time slots used for multi-PUSCH CG configuration may vary due to Time-Division Duplex (TDD) frame structure configurations (e.g., tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated) or due to SSB collisions. Therefore, different time slots in the N consecutive time slots may have different numbers of consecutive and valid PUSCH opportunities.

[0087] To achieve a consistent M value across N time slots, at least one of the following schemes can be implemented.

[0088] Selectivity N: The parameter N only counts slots that can accommodate the full number M of PUSCH opportunities. For example, slots with fewer than M PUSCH opportunities are excluded.

[0089] Adaptive M: The gNB configures M to a value that can be accommodated by all N time slots, ensuring consistency across all time slots.

[0090] Maximum M Interpretation: The value of M is interpreted as the maximum allowed number of PUSCH opportunities per N time slots. For any time slot that cannot accommodate M PUSCH opportunities, fewer than M available PUSCH opportunities within that time slot are used.

[0091] 3. Determine the initial time slot position of the consecutive time slots used for multi-PUSCH CG within the CG cycle.

[0092] For Type 1 CG, the initial time slot is determined based on an offset value relative to the reference SFN.

[0093] For type 2 CG, the initial time slot is determined based on an offset value relative to the time slot carrying the activation DCI.

[0094] 4. The symbol position of the first PUSCH timing within the initial time slot of the multi-PUSCH CG.

[0095] The symbol position is determined based on the SLIV value associated with the row index of the TDRA table. The row index may be specified differently for Type 1 and Type 2CG: For type 1 CG, the row index is configured by the gNB via RRC signaling.

[0096] For type 2 CG, the row index is determined based on the indication in the activated DCI.

[0097] 5. MCS and FDRA settings: The same MCS and FDRA settings for each CG configuration are applied to all PUSCH events for the corresponding CG configuration.

[0098] For Type 1 CG, the same MCS and FDRA are configured by the gNB via RRC signaling and applied to all PUSCH timings within the CG cycle.

[0099] For type 2 CG, MCS and FDRA can be indicated in the activated DCI and applied to all PUSCH timings within the CG cycle.

[0100] The parameters mentioned above related to multi-PUSCH CG can be applied to multi-PUSCH CG operations, even if cgRetransmissionTimer is not configured.

[0101] In some embodiments of this disclosure, the received configuration is applicable to type 1 or type 2 CG.

[0102] In some embodiments of this disclosure, at least one time slot of the configured consecutive time slots includes a DL symbol.

[0103] In some embodiments of this disclosure, the initial slot position of the consecutive slots for the configuration of Type 1 CG is determined based on an offset value relative to a reference SFN.

[0104] In some embodiments of this disclosure, the initial slot position of the consecutive slots for the configuration of type 2 CG is determined based on an offset value relative to the slot position carrying the activated DCI.

[0105] In some embodiments of this disclosure, the position of one or more symbols in a slot with PUSCH timing is determined based on SLIV values ​​derived from RRC signaling for Type 1 CG.

[0106] In some embodiments of this disclosure, the one or more symbol positions with PUSCH timing in the time slot are applied to other time slots within the CG period, and the one or more symbol positions with PUSCH timing for transmitting the UCI do not collide with DL symbols or SSBs.

[0107] In some embodiments of this disclosure, the frequency position of the time slot with PUSCH timing or the MCS is applied to other time slots within the CG cycle.

[0108] In some embodiments of this disclosure, one or more symbol positions in a slot with PUSCH timing are determined based on SLIV values ​​derived from the activation DCI for type 2 CG.

[0109] Example A-2: TB retransmission in certain PUSCH moments.

[0110] To support repeated transmission of TBs in a multi-PUSCH CG, i.e., a TB being transmitted in multiple PUSCH moments, the gNB (e.g., one or more BSs shown in Figure 1) provides at least one of the following information to the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) to determine whether repeated transmission of TBs is applied to the multi-PUSCH CG for each CG configuration. 1. Parameters indicating whether TB transmissions involve repeated transmissions: No duplicate transfers: One TB per push time 1. There are repeated transmissions: One TB is associated with multiple PUSCH opportunities. 2. The number of available TBs for transmission in the configured PUSCH opportunities within a CG cycle (denoted by parameter B). 3. The repeated transmission factor, i.e., the number of repeated transmissions per CG configuration (denoted by parameter K), used for each TB transmitted within the CG cycle.

[0111] If retransmission is configured by gNB, the same retransmission factor applies to each TB within the CG cycle.

[0112] For type 1 CG, the repeat transmission factor can be configured via RRC through gNB.

[0113] For Type 2 CG, the repetition transmission factor can be indicated in the activated DCI. 4. Note that in addition to explicit indication, the UE can deduce implicit indications of the above information, for example: The number of available TBs used for transmission in the configured PUSCH timing within a CG cycle can be derived from the repetition transmission factor K and parameters M and N, for example, B = (M × N) / K.

[0114] The repetitive transfer factor K can be derived from the number of available TBs B and parameters M and N within a CG cycle, for example, K = (M × N) / B.

[0115] Note that additional predefined rules or additional configurations can be used to derive the above information, for example: The repetitive transmission factor K is predefined or configured to be the same as parameter M, meaning that the repetitive transmission is performed within a time slot.

[0116] The number of available TBs, denoted by B, is equal to or less than the parameter N, meaning that different TBs are transmitted across different consecutive UL time slots.

[0117] The repetition factor K is predefined or configured to be equal to or less than the parameter N, meaning that the repetition is performed across time slots, and the number of available TBs, denoted as B, is equal to or less than the parameter M, meaning that different TBs are transmitted within time slots and they repeat across different time slots.

[0118] Example A-3: Example of TB repeated transmission in multi-PUSCH CG.

[0119] Referring to Figure 3, in one example, the multi-PUSCH CG is configured with M=2, N=3, and a repetition factor K=2. In this setup, the number of consecutive PUSCH opportunities within the CG is given as M × N, and M × N = 6, for a total of 3 TBs transmitted within the CG cycle, with each TB performing 2 repetitions within a time slot.

[0120] Referring to Figure 4, in another example, the multi-PUSCH CG is configured with M=2, N=3, and a repetition factor K=3. In this setup, the number of consecutive PUSCH opportunities within the CG is given as M × N, and M × N = 6, for a total of 2 TBs transmitted within the time slot, with each TB performing 3 repetitions across the time slot.

[0121] Example B: TB retransmission scheme in multi-PUSCH CG.

[0122] Example B-1: Configuration limitations for TB retransmission.

[0123] For example, the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) performs TB repetition transmission in a multi-PUSCH CG configuration according to at least one of the following configuration constraints: 1. Total PUSCH Timing Constraint: The total number of PUSCH timings within a CG period, i.e., M multiplied by N, M × N, as shown in Example A-1, is greater than the repetition transmission factor shown in Example A-2. Note that M is the number of consecutive valid PUSCH timings within a time slot, and N is the number of valid consecutive time slots used for PUSCH transmission. 2. Integer Multiple Constraint: The total number of PUSCH timings within a CG period, i.e., M × N as shown in Example A-1, can be an integer multiple of the repetition transmission factor shown in Example A-2.

[0124] If the value of M × N is not an integer multiple of the repeat transfer factor, then the earliest PUSCH timing, whose total number is an integer multiple of the repeat transfer factor, can be used for a complete repeat transfer of one or more TBs.

[0125] Referring to Figure 5, an example with M=N=3 and K=4. In this case, up to 2 TB can be transferred in a complete repeat within the stated CG cycle. This leaves an unused PUSCH opportunity.

[0126] The processing of the last PUSCH timing (unused PUSCH timing) may include at least one of the following options: 1. The last PUSCH timing is not used by the UE, and the UE may declare it as unused based on the bitmap in the Uplink Control Information (UCI); 2. The UE simply ignores and does not use the PUSCH timing for data transmission; 3. The third TB may be transmitted in a non-duplicated manner during the last PUSCH timing.

[0127] Example B-2: HARQ ID settings for TB retransmission.

[0128] For example, the UE or gNB (as shown in Figure 1) determines the HARQ procedure ID in a multi-PUSCH CG based on at least one of the following rules, considering TB retransmissions, i.e., one TB is associated with multiple PUSCHs. 1. Consistent ID for Retransmissions: Each ID value of the HARQ procedure used for the PUSCH timing carrying a TB retransmission is the same, i.e., multiple CG PUSCH timings carrying one TB share the same HARQ procedure ID. 2. Sequential ID Allocation: After determining the HARQ procedure ID for the first valid PUSCH timing in the CG cycle based on the rules, if retransmissions associated with a TB are transmitted on these PUSCHs, the HARQ procedure ID for subsequent valid PUSCHs remains the same. The HARQ procedure ID increments by 1 for each new TB. It remains constant for all PUSCH timings carrying the same TB retransmission, and then increments for the next TB PUSCH timing. For subsequent valid PUSCHs: i. If retransmissions carrying the same TB: the HARQ procedure ID remains the same.

[0129] ii. If a new TB is carried: the HARQ procedure ID is incremented by 1. 3. The HARQ procedure ID derived from the above procedure applies only to valid PUSCH times that have not been indicated as unused by the UE.

[0130] For a UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) to determine the Redundancy Version (RV) value for each repeated transmission of a TB transmitted in an associated PUSCH timing, at least one of the following schemes can be implemented: 1. A fixed RV mode is pre-configured by the gNB in ​​the standard. For example, four RVs are supported, and the RV modes {RV0, RV1, RV2, RV3} include {0, 0, 0, 0}, {0, 3, 0, 3}, and {0, 2, 3, 1}. 2. For Type 1 or Type 2 CG, one of the RV modes can be configured by the gNB via RRC signaling configured for each CG, and the RV value for each repeated transmission can be derived from the RV mode. The same RV mode is applied to different sets of PUSCH timings configured for repeated transmissions of the TB, where the PUSCH timing sets correspond to repeated transmissions associated with the TB. For Type 2 CG, the selected RV mode can also be indicated in the active DCI.

[0131] The gNB can configure the RRC of each CG configuration to the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) to determine the start position of TB transmission within a CG cycle based on at least one of the following schemes, which can be applied to the transmission of each TB within a CG cycle: 1. The start position of the TB transmission is the first PUSCH timing in the PUSCH timing set for the TB repetition transmission configuration. 2. The start position of the TB transmission is the PUSCH timing mapped to the earliest PUSCH timing with RV0 in the PUSCH timing set for the TB repetition transmission configuration. 3. For Type 2 CG, the start position of the TB and the RV value associated with the PUSCH timing at the start position can be indicated in the activated DCI.

[0132] i. The first RV value indicated in the activated DCI is selected from a value of the pre-configured RV mode, and the remaining repeated RV values ​​follow the order of the pre-configured RV mode starting from the first RV value.

[0133] Example B-3: Example of determining the HARQ process ID value with repeated transmissions in a multi-PUSCH CG.

[0134] Referring to Figure 6, an example configuration of a multi-PUSCH CG is M=2, N=3, repetition factor K=2, and RV mode={0,2,3,1}.

[0135] In this setup, it is assumed that the first TB (denoted as TB1) is transmitted from the first PUSCH timing in the CG cycle.

[0136] According to the HARQ process ID determination rules, it is assumed that the HARQ process ID for the first PUSCH timing of TB1 is 0. The HARQ process ID remains the same for PUSCH timings belonging to the same TB.

[0137] The HARQ process ID is incremented by 1 at the first PUSCH timing of the next TB transmission.

[0138] Example C: Retransmission scheme in a multi-PUSCH CG.

[0139] Example C-1: Retransmission of multiple PUSCH CGs is based on configuration grant timers and dynamic UL grants.

[0140] For a UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b), the retransmission assumption of the multi-PUSCH CG depends on a configuration grant timer. This timer is associated with an ACK assumption for a previous TB transmission. This timer differs from the timer associated with a NACK assumption for a previous TB transmission, wherein a retransmission is autonomously performed at the UE after the expiration of this timer.

[0141] The retransmission scheduling is based on dynamic scheduling in the DCI received by the UE. The resources used for retransmission are based on the received uplink grant in the DCI, rather than using CG resources in the multi-PUSCH CG configuration.

[0142] If the UE does not receive a DCI with a dynamic UL grant for retransmission of a TB initially transmitted at the latest PUSCH timing associated with the HARQ procedure ID before the expiration of the corresponding configuration grant timer, the UE assumes an ACK for the initial TB transmission and refreshes the HARQ buffer associated with the HARQ procedure ID. Otherwise, the UE assumes a NACK for the initial TB transmission and performs a retransmission based on the dynamic UL grant indicated in the DCI.

[0143] The proposed retransmission scheme can be applied to both Type 1 and Type 2 CG.

[0144] If the CBGTI field in the UL-authorized DCI is configured by the gNB, then retransmission based on CodeBlock Group (CBG) can be supported.

[0145] Example C-2: Configuring authorization timer association.

[0146] The association between the configured authorization timer and the TB can be one of the two schemes: Scheme 1 - Single TB Timer Association: 1. Timer Setting: A timer setting is associated with only one TB, and the timer is reset and starts counting after the TB is transmitted in the latest PUSCH timing associated with the HARQ procedure ID of the TB. 2. Definition of Latest PUSCH Timing: i. For TB transmissions configured to have no duplicate transmissions, the latest PUSCH timing corresponds to the PUSCH timing of the previous transmission (e.g., the initial transmission) of the TB.

[0147] ii. For TB transmissions configured for retransmission, the latest PUSCH timing corresponds to the last transmission timing of the TB in the PUSCH timing set used for TB retransmission configuration. 3. Dynamic UL Authorization Behavior: The dynamic UL authorization for PUSCH retransmission indicated in the DCI applies only to a single TB before the configuration authorization timer associated with the TB expires.

[0148] i. The RV used for the TB retransmission is predetermined (e.g., RV0) or indicated in the RV field of the DCI.

[0149] ii. Different TBs have independent timers for timer reset and counting. The timer reset value and counting interval can be configured independently by the gNB.

[0150] Option 2 - TB Group Timer Association: 1. Timer Settings: Timer settings are associated with TB groups (represented as TB groups). The timer is reset and begins counting after the latest PUSCH timing associated with one of the HARQ process IDs of the TB group. 2. TB Grouping Configuration: The number of TB groups or TB groups transmitted in the CG cycle multi-PUSCH CG configuration can be pre-configured by the gNB for each CG configuration.

[0151] i. TB groups can be viewed as HARQ procedure ID groups. Certain HARQ procedure IDs can be associated with these groups via gNB configuration.

[0152] ii. In this document, TB groups and HARQ process ID groups are used interchangeably. A TB group can be referred to as a HARQ process ID group. A TB associated with a TB group can also be described as a HARQ process ID associated with a HARQ process ID group.

[0153] iii. During the configuration, a TB group index can be assigned to each TB group.

[0154] iv. Each TB in a TB group is associated with an independent timer. v. The TBs within a TB group are transmitted during consecutive PUSCH events. vi. If the number of TB groups is equal to 1, then all TBs transmitted within the CG period belong to the same TB group. vii. If the number of TBs associated with a TB group is one, then Scheme 1 is a special case of Scheme 2, i.e., no TB grouping configuration is required. In this sense, TB groups correspond to TBs, and the following operational schemes apply to Scheme 1 or Scheme 2.

[0155] Example C-3: Retransmission scheduling in DCI.

[0156] For Scheme 1 or Scheme 2 in Implementation C-2, the gNB may schedule at least one PUSCH for retransmission of at least one TB in the TB group using the dynamic UL grant in the DCI before the expiration of the configuration grant timer associated with the TB group. 1. Retransmission Indication: The DCI carrying the dynamic UL grant indicates, based on a bit indication (referred to as the retransmission indication), at least one TB group or at least one TB within a TB group for retransmission. The field used for the retransmission indication may be one of the following: i. using a bit field in the DCI carrying multiple New Data Indications (NDIs), wherein the DCI may schedule multiple PUSCHs.

[0157] ii. Use the bit field of the DCI that carries an NDI, where the DCI can only schedule one PUSCH. In this case, retransmitting multiple TBs requires multiple DCIs.

[0158] iii. Using a configurable bitmap in the DCI, wherein the DCI can schedule one or more PUSCHs, and the size of the bitmap can be configurable. 2. Bit mapping for retransmission indication: Each bit of the retransmission indication in the DCI can be mapped to at least one of the following HARQ procedure IDs.

[0159] i. At least one TB group (or HARQ process ID group) within a CG cycle. In this case, a bit indication can be associated with at least one TB group index. The TB group index can be pre-configured by the gNB after the TB group is formed based on the TB grouping configuration for the CG configuration.

[0160] ii. At least one TB (or HARQ procedure ID) within a TB group (or HARQ procedure ID group). In this case, the bit indication can be associated with at least one TB (or HARQ procedure ID) within a TB group (or HARQ procedure ID group). 3. Activation of multi-PUSCH scheduling: The gNB can be pre-configured via RRC signaling to activate the use of UL-authorized DCI for scheduling multiple PUSCHs for retransmitting multiple TBs. The configuration can be per CG. If the UL authorization can only schedule one PUSCH, then retransmitting multiple TBs in the TB group requires multiple UL authorizations. 4. Redundancy Version (RV) determination for retransmission: For a UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b), the determination of the RV for retransmission can be based on at least one of the following schemes.

[0161] i. Each of the RVs used for each retransmission of one or more TBs within the TB group can be predefined, for example, RV0 is used for each retransmission TB within the TB group.

[0162] ii. In cases where the DCI can schedule multiple PUSCHs, the RV value for each retransmission TB can be indicated in the RV field of the DCI.

[0163] If only one RV field is available in the DCI. The RV value can be applied to all of the retransmission TBs, or Multiple DCIs are required to indicate the RV for each retransmission TB. 5. Settings for multi-TB retransmission scheduling: For dynamic UL-authorized DCIs that schedule multiple TB retransmissions, use at least one of the following settings.

[0164] i. The same MCS or FDRA indicated in the DCI is applied to the scheduled retransmission for each TB.

[0165] iii. Used to determine the time-domain location of each TB: The TDRA information (such as K2 slot offset, PUSCH mapping type, and SLIV) is pre-configured in the TDRA table by the gNB via RRC signaling.

[0166] The DCI indicates the row index of the TDRA table.

[0167] The row index is mapped to TDRA information for each TB retransmission (e.g., each row of the TDRA table contains multiple SLIVs).

[0168] 6. Repeat transmission for retransmission TB: The dynamic UL authorization in DCI can be at least one retransmission TB indicating type A or type B repeat transmission.

[0169] Example C-4: An example of a timer associated with a TB group.

[0170] Referring to Figure 7, the PUSCH timings configured within the CG cycle are 16 time slots in length. Each PUSCH timing is transmitted within one time slot. Two TB groups are defined, each covering four consecutive PUSCH timings. Each PUSCH timing is associated with a HARQ procedure ID.

[0171] After Timer #1 transmits the fourth TB (TB 4) during the last PUSCH timing (i.e., the fourth PUSCH timing) in the first TB group (i.e., TB group #1), it is reset and begins counting. Timer #1 counts down and expires after 8 time slots.

[0172] The UL grant from DCI #1 is received in the ninth time slot before timer #1 expires. The UL grant indicates that TB 2 associated with the HARQ procedure ID in TB group #1 needs to be retransmitted, and DCI #1 schedules TB 2 to be retransmitted in the eleventh time slot. The RV value of the retransmitted TB 2 is also indicated in DCI #1.

[0173] After Timer #2 transmits the fourth TB (TB 8) during the last PUSCH timing (i.e., the fourth PUSCH timing) in the second TB group (i.e., TB group #2), it resets and begins counting. Timer #2 counts down and expires after 8 time slots. The UL authorization from DCI #2 is received in the thirteenth time slot before timer #2 expires. The UL authorization indicates that TB 5 associated with the HARQ procedure ID in TB group #2 needs to be retransmitted, and TB 5 is scheduled to be retransmitted in the twelfth time slot. The RV value of the retransmitted TB 5 is also indicated in DCI #2.

[0174] Example D: The UE can use the bit field in the UCI to indicate the timing of unused CG PUSCH within the range.

[0175] Example D-1: Indication based on a range defined as an indication period. 1. Indication period determination: The UE (e.g., one or more UEs shown in FIG. 1, such as UE 10a and UE 10b) determines the indication period during which at least one of the CG PUSCH timings can be indicated as unused. 2. Range configuration: The range of the indication period is configured by the gNB (e.g., one or more BSs shown in FIG. 1) via the RRC of each CG configuration.

[0176] i. The range of the indication period can be based on at least one of the following representations: Absolute value in units of time slots or symbols.

[0177] A value associated with the length of a CG cycle. The value is an integer multiple of the CG cycle, or the CG cycle is divisible by the value. 3. Indicator cycle start time: The start time of the indicator cycle can be a start timeslot or a start symbol, which is determined based on a time offset relative to the end of the UL symbol or UL timeslot carrying the UCI transmission CG PUSCH. 4. Time offset configuration: The time offset can be configured by the gNB via RRC signaling or predefined in the standard.

[0178] i. The time offset configuration can be configured for each CG.

[0179] If the parameter associated with the time offset is not configured in the CG configuration, the value of the time offset is assumed to be 0.

[0180] ii. The range of the time offset may be expressed in units of symbols or time slots.

[0181] iii. If the value of the time offset is not configured or is configured to 0, the start time of the indication period immediately follows the end of the CG PUSCH carrying the UCI. 5. Time Offset Determination: The value of the time offset may be determined based on at least one of the following: i. The processing time required for the gNB to process and respond to the indication of the unused CG PUSCH timing.

[0182] ii. The preparation time required for rescheduling uplink grants for unused PUSCH resources for the same UE or other UEs. 6. End time of the indication period: The end time of the indication period can be derived from the start time and length of the indication period. The end time of the indication period can be located in at least one of the following: i. A slot or symbol within a CG period having a CG PUSCH carrying an indication of when the PUSCH was not used in the indication period. In this case, the indication period can be less than or equal to the CG period.

[0183] ii. A slot or symbol within a CG cycle, wherein the CG cycle is different from the CG cycle having a CGPUSCH carrying the indication used to indicate unused PUSCH moments within the cycle. In this case, an indication of unused PUSCH moments spanning CG cycles is applied, and the indication period may be longer than the CG cycle.

[0184] In some embodiments of this disclosure, at least one value of the number of consecutive time slots within the CG period is an integer multiple of the size of the bitmap used to report one or more unused PUSCH moments. Example D-2: An example of an indication of unused PUSCH moments according to an indication period.

[0185] Referring to Figure 8, in one example, the multi-PUSCH CG is configured to include a total of 4 PUSCH opportunities within a CG cycle, wherein 2 UL slots are available according to the DL / UL TDD configuration with DDDSU, and each UL slot (U) includes 2 PUSCH opportunities.

[0186] The indication period begins with an offset relative to the end of the latest PUSCH (i.e., PUSCH y) carrying the UCI, and ends at the end time of the indication period. The length of the indication period is assumed to be 2 CG periods.

[0187] The indication period can cover six PUSCH opportunities, from which the UE determines that the third and fourth PUSCH opportunities (i.e., PUSCH 3 and PUSCH 4) are unused. The unused PUSCH opportunities are indicated in the UCI using a 6-bit bitmap, where each bit is associated with a PUSCH opportunity, and the six bits are indicated sequentially in chronological order within the indication period, i.e., {001100}. In this example, only valid PUSCH opportunities are indicated in the bitmap for the corresponding indication period, and a bit value of 1 indicates that the associated PUSCH opportunity is unused.

[0188] Example D-3: Based on the indication of the range defined as the PUSCH timing set.

[0189] The UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) determines a set of PUSCH opportunities (referred to as the PUSCH set), wherein at least one of the CG PUSCH opportunities can be indicated as unused. 1. Number of PUSCH opportunities: A fixed number of PUSCH opportunities in the PUSCH set are configured by the gNB (e.g., one or more BSs shown in Figure 1) via the RRC configured for each CG. 2. Bitmap indication: Each PUSCH opportunity is associated with a bit indication represented by bits in a bitmap.

[0190] i. Each PUSCH timing is associated with a single bit indication. Each bit in the bitmap corresponds to at least one valid PUSCH timing in the set.

[0191] ii. The size of the bitmap is related to the number of PUSCH moments in the set, and the size of the bitmap can be configured by the gNB through the RRC configured for each CG.

[0192] iii. The mapping between PUSCH timings and bitmap bits can be configured by the gNB. The gNB can configure one of the following via RRC signaling configured for each CG: a) a one-to-one mapping, where each bit corresponds exactly to one PUSCH timing, or b) a many-to-one mapping, where multiple PUSCH timings are mapped to a single bit in the bitmap. 3. PUSCH Timing Characteristics: The PUSCH timings in the set are consecutive and valid PUSCH timings.

[0193] i. PUSCH timing indicated by the same bitmap can be within the same CG period or different CG periods (i.e., cross-CG period indication is possible).

[0194] ii. In one embodiment, each PUSCH timing in the set is a valid PUSCH timing (e.g., not colliding with SSB or DL ​​slots / symbols, such as tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated). 4. Starting PUSCH timing of the set: The starting PUSCH timing of the PUSCH timing set associated with the bitmap is the first PUSCH timing whose first valid PUSCH slot or first valid PUSCH symbol is located after the time offset relative to the end of the UL symbol or UL slot transmitting CGPUSCH, wherein the UCI is carried in the CG PUSCH. 5. Time offset configuration: The time offset may be configured by the gNB via RRC signaling or predefined in the standard.

[0195] i. The configuration of the time offset can be per CG configuration. If the parameter associated with the time offset is not configured in the CG configuration, the value of the time offset is assumed to be 0.

[0196] ii. The range of the time offset may be expressed in units of symbols or time slots.

[0197] iii. If the value of the time offset is not configured or is configured to 0, then the starting PUSCH timing of the PUSCH timing set is the first PUSCH timing after the end of the CG PUSCH carrying the UCI. 6. Time Offset Determination: The time offset may be determined based on at least one of the following: i. The processing time required for the gNB to process and respond to the indication of the unused CG PUSCH timing.

[0198] ii. Preparation time required to reschedule uplink grants for the same UE or other UEs to reschedule unused PUSCH resources. 7. The last PUSCH timing of the set: The last PUSCH timing of the PUSCH timing set can be derived from the starting PUSCH timing of the PUSCH timing set and the number of PUSCH timing sets. The last PUSCH timing of the PUSCH timing set associated with the bitmap can be: i. A PUSCH timing within a CG period, the CG period having one PUSCH timing carrying an indication of unused PUSCH timings in the PUSCH timing set in the UCI.

[0199] ii. A PUSCH timing within a CG cycle, wherein the CG cycle is different from the CG cycle carrying the indication, which is carried in the UCI to indicate that a PUSCH timing has not been used in the PUSCH timing set.

[0200] In this case, execute cross-CG cycle indications without using PUSCH timing.

[0201] In some embodiments of this disclosure, each bit of the bitmap is associated with a PUSCH timing in a time slot, and each PUSCH timing indicated by the bitmap does not collide with a DL symbol or SSB.

[0202] In some embodiments of this disclosure, the first PUSCH timing is located in a time slot after a time offset relative to the end of the time slot carrying the bitmap in the UCI.

[0203] In some embodiments of this disclosure, the value of the time offset is 0, or is assumed to be 0 if the time offset is not configured in the CG configuration.

[0204] In some embodiments of this disclosure, at least one bit of the bitmap indicates a PUSCH timing in another CG cycle, which is different from the CG cycle used to transmit the bitmap in the UCI.

[0205] Example D-4: An example of an unused PUSCH timing indication based on the PUSCH timing set.

[0206] Referring to Figure 9, the multi-PUSCH CG is configured to include a total of 4 PUSCH opportunities within a CG cycle, wherein 2 UL slots are available according to the DL / UL TDD configuration with DDDSU, and each UL slot (U) includes 2 PUSCH opportunities.

[0207] The first PUSCH timing is a valid PUSCH timing that begins after the end of the latest PUSCH carrying the UCI (i.e., PUSCH y). The last PUSCH timing is the sixth valid PUSCH timing in the set of PUSCH timings. The number of the set of PUSCH timings (referred to as the PUSCH set) is assumed to be 6.

[0208] In the set of six PUSCH opportunities, the UE (e.g., one or more UEs shown in FIG. 1, such as UE 10a and UE 10b) determines that the third and fourth PUSCH opportunities (i.e., PUSCH 3 and PUSCH 4) in the PUSCH set are unused. The unused PUSCH opportunities are indicated in the UCI using a 6-bit bitmap, where each bit is associated with a valid PUSCH opportunity, and the 6 bits are indicated sequentially according to the chronological order of the PUSCH opportunity set, i.e., {001100}. Only valid PUSCH opportunities are counted and indicated in the bitmap of the corresponding PUSCH set. In the bitmap, a bit value of 1 indicates that the associated PUSCH opportunity is unused.

[0209] Example E: Bitmap Indication Example E-1: Bitmap Indication Scheme The UE (e.g., one or more UEs shown in FIG. 1, such as UE 10a and UE 10b) determines the timing of unused CG PUSCH based on a bitmap and transmits the bitmap to the gNB (e.g., one or more BSs shown in FIG. 1) in the UCI.

[0210] In one embodiment, each bit of the bitmap corresponds to a PUSCH timing.

[0211] In one embodiment, the bit order of the bitmap, from left to right, corresponds to the time sequence of PUSCH timings, with the earliest timing represented by the leftmost bit and subsequent timings represented by the rightmost bit.

[0212] In one embodiment, bit value 0 corresponds to a time when PUSCH has been used, and bit value 1 corresponds to a time when PUSCH has not been used.

[0213] The bitmap can indicate at least one of the unused PUSCH timings based on the duration of the indication period defined in Embodiment D1 or the PUSCH set with a pre-configured number of PUSCH timings defined in Embodiment D3.

[0214] Based on embodiments D3 and E-1, the bitmap includes a bit sequence, each bit in the sequence being associated with its corresponding PUSCH timing, wherein the bits are arranged in a left-to-right order corresponding to the PUSCH timing from the earliest to the latest time.

[0215] In some embodiments of this disclosure, bit value 1 in the bitmap indicates that the corresponding PUSCH timing is an unused PUSCH timing in a PUSCH transmission.

[0216] Example E-2: According to the bitmap indication scheme configured in Example D1.

[0217] In the case where a UE (e.g., one or more UEs shown in FIG. 1, such as UE 10a and UE 10b) indicates a period of inactivity in accordance with embodiment D1 to indicate when PUSCH is not used, at least one of the following indication schemes may be adopted.

[0218] 1. The PUSCH timing associated with a bit of the bitmap can be a valid PUSCH timing or an invalid PUSCH timing configured within the indication period.

[0219] i. If the bitmap only indicates valid PUSCH opportunities, the size of the bitmap can be flexible. The size of the bitmap corresponds to the number of valid PUSCH opportunities in the indicated period.

[0220] ii. If the bitmap indicates valid and invalid PUSCH timings, then the size of the bitmap may be fixed.

[0221] The size of the bitmap corresponds to the number of valid and invalid PUSCH events in each indication cycle.

[0222] The value 1 in the bitmap can indicate that the PUSCH timing is unused or invalid.

[0223] If the bit value is 0 and the bit is associated with the position of an invalid PUSCH, then the PUSCH timing is still unused.

[0224] Example E-3: The bitmap indication scheme configured in Example D3.

[0225] In the case where a UE (e.g., one or more UEs shown in FIG. 1, such as UE 10a and UE 10b) has a PUSCH set indicating a pre-configured number of PUSCH opportunities according to embodiment D3, indicating that no PUSCH opportunities are used, at least one of the following indication schemes may be adopted.

[0226] In the PUSCH timing set, the PUSCH timing associated with the bits in the bitmap is the valid PUSCH timing. The bitmap only represents valid PUSCH timings within the pre-configured set.

[0227] The size of the bitmap is configured to a fixed value for each CG configuration.

[0228] There is a direct correspondence between the size of the bitmap and the number of valid PUSCH opportunities in the set. The size of the bitmap corresponds to the number of valid PUSCH opportunities in the set of PUSCH opportunities.

[0229] Example F: Bitmap Indication of Unused PUSCH Timings with TB Repeated Transmissions Example F-1: Bitmap Indication Scheme for Unused PUSCH Timings with TB Repeated Transmissions In cases where gNBs (e.g., one or more BSs shown in FIG. 1) are configured with TB repeated transmissions in a multi-PUSCH CG, the bitmap indication scheme for unused PUSCH timings in Examples D and E can be modified based on at least one of the following schemes: 1. Scheme 1 - Group-based Bitmap Indication: Each bit of the bitmap is associated with a PUSCH timing group belonging to the same TB. The PUSCH timing group carries repeated transmissions of the same TB. When the corresponding bit value is 1, all PUSCH timings in the group associated with the bit of the bitmap are unused. 2. Scheme 2 - Single PUSCH Timing Bitmap Indication: Each bit of the bitmap is associated with one PUSCH timing, regardless of whether TB repeated transmissions are configured.

[0230] The UE may indicate at least one of the following information to the gNB in ​​the UCI based on the bitmap indication.

[0231] Activate or deactivate certain TB of repeated transfers.

[0232] The number of repeated transmissions for a certain TB.

[0233] Example F-2: Based on the PUSCH set with a pre-configured number of PUSCH opportunities in Example D3, and referring to Figure 10 as an example of a bitmap indication with TB repetition transmission according to Scheme 1 of Example F1, the setting of the multi-PUSCH CG configuration is as follows: Based on the DL / UL TDD configuration with DDDSU (D: Downlink; S: Special; U: Uplink), the multi-PUSCH CG configuration has 2 PUSCH opportunities within one UL slot (i.e., M=2), and a total of 4 PUSCH opportunities in the 2 UL slots of one CG cycle (i.e., N=2). The repetition transmission factor K is set to 2.

[0234] The number of PUSCH timing sets (referred to as PUSCH sets) is configured to be 6.

[0235] In the set of the six PUSCH opportunities, three TBs are transmitted. Each TB is configured to be transmitted repeatedly in the two PUSCH opportunities of the UL time slot. In this case, the PUSCH set comprises three TBs. Therefore, the unused PUSCH opportunities are indicated in the UCI using a 3-bit bitmap. Each bit is associated with a PUSCH opportunity group associated with the TB. The PUSCH opportunity group is used for the repeated transmission of the TB. The bitmap {010} indicates that the PUSCH opportunity associated with the second TB, TB2, is unused.

[0236] Example F-3: Based on the PUSCH set with a pre-configured number of PUSCH opportunities in Example D3, and referring to Figure 11 as an example of a bitmap indication with TB repetition transmission according to Scheme 2 of Example F1, the setting of the multi-PUSCH CG configuration is as follows: Based on the DL / UL TDD configuration with DDDSU (D: Downlink; S: Special; U: Uplink), the multi-PUSCH CG configuration has 2 PUSCH opportunities within one UL slot (i.e., M=2), and a total of 4 PUSCH opportunities in the 2 UL slots (i.e., N=2) of one CG cycle. The repetition transmission factor K is set to 2.

[0237] The number of the PUSCH timing set (referred to as the PUSCH set) is configured to be 6.

[0238] Within the set of six PUSCH opportunities, three TBs are transmitted, each TB configured to be repeatedly transmitted within two PUSCH opportunities in the UL time slot. In this case, each bit is associated with a PUSCH opportunity, i.e., repeated transmissions are not considered. Since the PUSCH set comprises six PUSCH opportunities, the unused PUSCH opportunities are indicated in the UCI using a 6-bit bitmap.

[0239] In scheme 2, the UE (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b) can determine whether a TB is repeatedly transmitted or the actual retransmission factor (K) of each TB. The bitmap {000111} indicates that the PUSCH timing associated with the first TB, i.e., TB1, is repeatedly transmitted with a retransmission factor of 2, the PUSCH timing associated with the second TB, i.e., TB2, is transmitted once in a PUSCH timing, i.e., no retransmission, and the PUSCH timing associated with the third TB is unused, i.e., TB3 is not transmitted.

[0240] Example G: CG PUSCH transmission timing carrying a UCI indicating that a PUSCH timing was not used, with or without TB repeated transmission.

[0241] UCI transmission in CG PUSCH: For UEs that transmit a UCI in CG PUSCH indicating when a PUSCH is not used (e.g., one or more UEs shown in Figure 1, such as UE 10a and UE 10b), the following may apply: The transmission timing of the CG PUSCH carrying the UCI is any CG PUSCH timing in which the PUSCH is transmitted.

[0242] Eligibility of PUSCH timing: The transmission timing of the CG PUSCH carrying the UCI is a PUSCH timing that was not declared as unused by the UE in a previously transmitted UCI.

[0243] TB Repeat Transmission Scenario: In one embodiment, if TB repeat transmission is configured, the UCI is transmitted in each repeat transmission of the TB in the associated CG PUSCH timing.

[0244] In some embodiments of this disclosure, the PUSCH timing for transmitting the UCI is a PUSCH timing that is not declared as unused.

[0245] Example H: The process by which the gNB configures multiple CG PUSCH opportunities within the CG and the UE reports unused CG PUSCH opportunities.

[0246] Figure 12 illustrates an example of the signaling flow to demonstrate the operational roles of a multi-PUSCH CG with TB retransmissions and TB repeats between base station 20a (e.g., gNB), UE 10a, and UE B. 1. At the outset, base station 20a sends a CG configuration with multiple CG PUSCH opportunities to UE 10a via Radio Resource Control (RRC) signaling. 2. For Type 2 CG, base station 20a transmits an activation DCI to UE 10a. 3. When uplink packets arrive at UE 10a, it determines unused CG PUSCH opportunities. 4. UE 10a then determines the HARQ ID and RV for either unused or valid CG PUSCH opportunities. 5. UE 10a transmits to base station 20a the CG PUSCH with or without retransmissions and a UCI indicating unused CG PUSCH opportunities. 6. Base station 20a derives the unused CG PUSCH opportunities from the UCI and performs rescheduling. 7. The base station 20a then schedules the unused CG PUSCH resource for UE 10b. 8. For retransmissions, the base station 20a sends one or more TB retransmission requests to UE 10a using the UL-authorized DCI. 9. UE 10a determines the HARQ ID and RV for the one or more TB retransmissions. 10. Finally, UE 10a retransmits the PUSCH based on the UL-authorized DCI.

[0247] The embodiments described demonstrate how the system manages resource allocation, handles unused PUSCH moments, and manages retransmissions in a multi-PUSCH CG environment, involving communication between the gNB and multiple UEs.

[0248] Referring to FIG13, the UE 100 may include a processor 11a, a memory 12a, and a transceiver 13a. The processor 11a is configured to invoke and run a computer program stored in the memory 12a to cause the UE 100, on which the processor 11a is installed, to perform the disclosed methods, steps, and / or functions of the UE. The UE 100 is an example of the UE described herein (e.g., UE 10a or UE 10b). The transceiver 13a may include baseband circuitry and radio frequency (RF) circuitry.

[0249] Referring to FIG14, the network node 200 is a network device and may include a processor 21a, a memory 22a, and a transceiver 23a. The processor 21a is configured to invoke and run a computer program stored in the memory 22a to cause the network node 200, on which the processor 21a is installed, to perform the methods, steps, and / or functions of the network node. The network node 200 is an example of a CN network entity, network node, radio node, base station, or gNB described herein. The transceiver 23a may include baseband circuitry and RF circuitry.

[0250] Referring to FIG15, the embodiments of this disclosure also provide a chip 70, which may correspond to the UE in the embodiments of this disclosure. The chip 70 can implement the corresponding processes implemented by the UE in various methods of the embodiments of this disclosure. The chip 70 includes a processor 71, and the processor 71 can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0251] Optionally, the chip 70 may further include a memory 72. Specifically, the processor 71 can retrieve and run the computer program from the memory 72 to implement the method described in the embodiments of this application.

[0252] Furthermore, the memory 72 may be a separate device independent of the processor 71, or it may be integrated into the processor 71.

[0253] Optionally, the chip 70 may further include an input interface 73. Note that the processor 71 can control the input interface 73 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0254] Optionally, the chip 70 may further include an output interface 74. Note that the processor 71 can control the output interface 74 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0255] Referring to FIG16, the embodiments of this disclosure also provide another chip 80, which may correspond to the network device described (e.g., a CN network entity, network node, radio node, base station, or gNB), and the chip 80 may implement the corresponding processes implemented by the network device in the various methods of the embodiments of this disclosure. The chip 80 includes a processor 81, and the processor 81 may call and run a computer program from the memory 82 to implement the methods in the embodiments of this application.

[0256] Optionally, the chip 80 may further include a memory 82. Specifically, the processor 81 can retrieve and run the computer program from the memory 82 to implement the method described in the embodiments of this application.

[0257] The memory 82 may be a separate device independent of the processor 81, or it may be integrated into the processor 81.

[0258] Optionally, the chip 80 may further include an input interface 83. Specifically, the processor 81 can control the input interface 83 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0259] Optionally, the chip may further include an output interface 84. Specifically, the processor 81 can control the output interface 84 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0260] The embodiments described in this disclosure are combinations of technologies / processes that can be employed in 3GPP specifications to create a final product.

[0261] While this disclosure has been described in conjunction with what are considered to be the most practical and preferred embodiments, it is to be understood that this disclosure is not limited to the disclosed embodiments, but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1. A channel access method, executed by a user equipment (UE), comprising: The configuration includes receiving the configuration of the number of consecutive time slots within a CG period of the CG configuration and the configuration of the bitmap size for reporting one or more unused PUSCH opportunities of the CG configuration; and transmitting uplink control information (UCI) in a PUSCH opportunity to transmit the bitmap, the bitmap indicating one or more unused PUSCH opportunities, wherein the one or more unused PUSCH opportunities are determined based on the received configuration of the CG configuration.

2. The channel access method according to claim 1, wherein the received configuration is applicable to type 1 or type 2CG.

3. The channel access method according to claim 2, wherein at least one time slot of the configured continuous time slots includes a downlink (DL) symbol.

4. The channel access method according to claim 2, wherein the initial time slot position of the consecutive time slots for the configuration of type 1 CG is determined based on an offset value relative to a reference SFN.

5. The channel access method according to claim 2, wherein the initial time slot position of the consecutive time slots for the configuration of type 2 CG is determined based on an offset value relative to the time slot position carrying active downlink control information (DCI).

6. The channel access method of claim 2, wherein the position of one or more symbols in a time slot with PUSCH timing is determined based on start and length indicator (SLIV) values ​​derived from Radio Resource Control (RRC) signaling for Type 1 CG.

7. The channel access method according to claim 6, wherein the one or more symbol positions with PUSCH timing in the time slot are applied to other time slots within the CG period, and the one or more symbol positions with PUSCH timing for transmitting the UCI do not collide with DL symbols or synchronization signal blocks (SSBs).

8. The channel access method of claim 6, wherein the frequency position or modulation and coding scheme (MCS) of the time slot with PUSCH timing is applied to other time slots within the CG period.

9. The channel access method of claim 2, wherein one or more symbol positions in a time slot with PUSCH timing are determined based on SLIV values ​​derived from the activation DCI for type 2 CG.

10. The channel access method of claim 9, wherein the one or more symbol positions with PUSCH timing in the time slot are applied to all time slots within the CG period, and the one or more symbol positions with PUSCH timing for transmitting the UCI do not collide with DL symbols or SSBs.

11. The channel access method of claim 9, wherein the frequency position of the time slot with the PUSCH timing or the MCS is applied to other time slots within the CG period.

12. The channel access method of claim 1, wherein at least one value of the number of consecutive time slots within the CG period is an integer multiple of the size of the bitmap used to report one or more unused PUSCH moments.

13. The channel access method according to claim 1, wherein the PUSCH timing for transmitting the UCI is a PUSCH timing that has not been declared as unused.

14. The channel access method of claim 1, wherein each bit of the bitmap is associated with a PUSCH timing in a time slot, and each PUSCH timing indicated by the bitmap does not collide with a DL symbol or SSB.

15. The channel access method of claim 14, wherein the bitmap comprises a bit sequence, each bit in the sequence being associated with a corresponding PUSCH timing, wherein the bits are arranged in a left-to-right order corresponding to the PUSCH timings in a time order from earliest to latest.

16. The channel access method of claim 14, wherein the first PUSCH timing is located in a time slot after a time offset relative to the end of the time slot carrying the bitmap in the UCI.

17. The channel access method of claim 16, wherein the value of the time offset is 0, or is assumed to be 0 if the time offset is not configured in the CG configuration.

18. The channel access method of claim 14, wherein at least one bit of the bitmap indicates a PUSCH timing in another CG cycle, the other CG cycle being different from the CG cycle used to transmit the bitmap in the UCI.

19. The channel access method according to claim 14, wherein the bit value 1 in the bitmap indicates that the corresponding PUSCH timing is an unused PUSCH timing in PUSCH transmission.

20. A user equipment (UE), comprising: A processor is configured to invoke and run a computer program stored in memory to cause a device equipped with the processor to perform the method of any one of claims 1 to 19.

21. A chip, comprising: The processor is configured to invoke and run a computer program stored in memory to cause a device on which the chip is mounted to perform the method of any one of claims 1 to 19.

22. A computer-readable storage medium storing a computer program, wherein the computer program causes a computer to perform the method of any one of claims 1 to 19.

23. A computer program product comprising a computer program, wherein the computer program causes a computer to perform the method of any one of claims 1 to 19.

24. A computer program that causes a computer to perform the method of any one of claims 1 to 19.

25. A channel access method, executed by a base station, comprising: The configuration includes the number of consecutive time slots within a CG period of the transmission CG configuration and the configuration of a bitmap size for reporting one or more unused PUSCH opportunities of the CG configuration; and receiving uplink control information (UCI) in a PUSCH opportunity; wherein the UCI transmits the bitmap, the bitmap indicating one or more unused PUSCH opportunities; wherein the one or more unused PUSCH opportunities are determined based on the configuration of the CG configuration.

26. The channel access method of claim 25, wherein the configuration is applicable to type 1 or type 2 CG.

27. The channel access method according to claim 26, wherein at least one time slot of the configured consecutive time slots includes a downlink (DL) symbol.

28. The channel access method of claim 26, wherein the initial time slot position of the consecutive time slots for the configuration of type 1 CG is determined based on an offset value relative to a reference SFN.

29. The channel access method of claim 26, wherein the initial time slot position of the consecutive time slots for the configuration of type 2 CG is determined based on an offset value relative to the time slot position carrying the active DCI.

30. The channel access method of claim 26, wherein the position of one or more symbols in a time slot with PUSCH timing is determined based on SLIV values ​​derived from RRC signaling for Type 1 CG.

31. The channel access method of claim 30, wherein the one or more symbol positions with PUSCH timing in the time slot are applied to other time slots within the CG period, and the one or more symbol positions with PUSCH timing for the UCI do not collide with DL symbols or synchronization signal blocks (SSBs).

32. The channel access method of claim 30, wherein the frequency position or modulation and coding scheme (MCS) of the time slot with PUSCH timing is applied to other time slots within the CG period.

33. The channel access method of claim 26, wherein one or more symbol positions in a time slot with PUSCH timing are determined based on SLIV values ​​derived from the activation DCI for type 2 CG.

34. The channel access method of claim 33, wherein the one or more symbol positions with PUSCH timing in the time slot are applied to all time slots within the CG period, and the one or more symbol positions for the PUSCH timing of the UCI do not collide with DL symbols or SSBs.

35. The channel access method of claim 33, wherein the frequency position of the time slot with the PUSCH timing or the MCS is applied to other time slots within the CG period.

36. The channel access method of claim 25, wherein at least one value of the number of consecutive time slots within the CG period is an integer multiple of the size of the bitmap used to report one or more unused PUSCH moments.

37. The channel access method of claim 25, wherein the PUSCH timing for receiving the UCI is a PUSCH timing that has not been declared as unused.

38. The channel access method of claim 25, wherein each bit of the bitmap is associated with a PUSCH timing in a time slot, and each PUSCH timing indicated by the bitmap does not collide with a DL symbol or SSB.

39. The channel access method of claim 38, wherein the bitmap comprises a bit sequence, each bit in the sequence being associated with a corresponding PUSCH timing, wherein the bits are arranged in a left-to-right order corresponding to the earliest to latest PUSCH timing.

40. The channel access method of claim 38, wherein the first PUSCH timing is located in a time slot after a time offset relative to the end of the time slot carrying the bitmap in the UCI.

41. The channel access method of claim 40, wherein the value of the time offset is 0, or is assumed to be 0 if the time offset is not configured in the CG configuration.

42. The channel access method of claim 38, wherein at least one bit of the bitmap indicates a PUSCH timing in another CG cycle, the other CG cycle being different from the CG cycle used to transmit the bitmap in the UCI.

43. The channel access method according to claim 38, wherein the bit value 1 in the bitmap indicates that the corresponding PUSCH timing is an unused PUSCH timing in PUSCH transmission.

44. A base station, comprising: A processor is configured to invoke and run a computer program stored in memory to cause a device equipped with the processor to perform the method of any one of claims 25 to 43.

45. A chip, comprising: The processor is configured to invoke and run a computer program stored in memory to cause a device on which the chip is mounted to perform the method of any one of claims 25 to 43.

46. ​​A computer-readable storage medium storing a computer program, wherein the computer program causes a computer to perform the method of any one of claims 25 to 43.

47. A computer program product comprising a computer program, wherein the computer program causes a computer to perform the method of any one of claims 25 to 43.

48. A computer program that causes a computer to perform the method of any one of claims 25 to 43.

Images