Channel access method

Abstract

This invention discloses a method for user equipment (UE) to report unused Physical Uplink Shared Channel (PUSCH) occasions within a configured grant (CG) period. The UE receives information about the CG, including the number of consecutive slots within the CG period and the size of a bitmap used for reporting. Based on the received CG configuration, the UE identifies unused PUSCH occasions within the CG period. The UE transmits Uplink Control Information (UCI) in a PUSCH occasion. This UCI includes a bitmap that indicates the identified unused PUSCH occasions.

Description

CHANNEL ACCESS METHOD

[0001] BACKGROUND OF DISCLOSURE

[0002] 1. Field of Disclosure

[0003] The present disclosure relates to the field of communication systems, and more particularly, to a channel access method.

[0004] 2. Description of Related Art

[0005] Extended Reality (XR) applications, as studied in 3GPP TR 38.835, present unique challenges for uplink (UL) traffic. In XR video applications, user equipment (UE) generates various types of video frames (e.g., I-frames or P / B-frames) at specific frame rates (e.g., 60fps or 90fps) . This results in variable packet sizes of protocol data unit (PDU) sets within a transmission period.

[0006] PDUs in a set may require segmentation and delivery via multiple transport blocks (TBs) within a PDU set delay budget (PSDB) . To meet PSDB requirements and achieve low latency for XR traffic, configured grant (CG) resources for CG-PUSCH transmission can be utilized.

[0007] To support multiple TB transmissions within the delay bound, multiple physical uplink shared channel (PUSCH) transmission occasions within a CG period can be created. This multi-PUSCHs CG approach adapts configurations from R16 NR-U CG, using parameters such as:

[0008] 1. cg-nrofPUSCH-InSlot: number of consecutive PUSCH occasions per slot

[0009] 2. cg-nrofSlots: number of consecutive slots for PUSCH transmission

[0010] These parameters allow for varying numbers of PUSCH transmission occasions per CG period.

[0011] However, it's important to note that the NR-U framework primarily focuses on unlicensed spectrum operation, supporting only frequency-division duplex (FDD) frame structures. Furthermore, these parameters are only applicable when the radio resource control (RRC) parameter for autonomous retransmission, cg-RetransmissionTimer, is configured.Technical Problem

[0012] Some technical problems are described in the following:

[0013] Uplink Video Encoding Challenges: The video encoder equipped at the UE side presents significant challenges in the uplink. It generates different sizes of video frames, such as I-frames and P / B-frames, at a specific frame rate. Each of these packets is subject to a tight packet set delay budget (PSDB) , adding complexity to the transmission process.

[0014] XR Service Requirements: Extended Reality (XR) services introduce additional complications due to their larger and unpredictable variable packet sizes. The current configuration of only one CG resource in one CG period fails to adequately reflect the characteristics of XR packets. Consequently, there's a pressing need for an approach that supports a configuration for multi-PUSCHs CG to better accommodate XR traffic patterns.

[0015] Resource Utilization Efficiency: Depending on the fluctuating nature of XR traffic patterns, some CG resources may be over-provisioned or underutilized by a UE. A channel access method is needed to address this inefficiency and improve overall system capacity.

[0016] Coverage Range for UL Video Traffic: Ensuring adequate coverage range for uplink video traffic requires careful consideration of PUSCH transmission repetition for a transport block (TB) in the context of multi-PUSCHs CG configuration. This involves scenarios where a TB may need to be carried across multiple consecutive PUSCH  occasions to maintain reliable transmission.

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

[0018] An object of the present disclosure is to propose a channel access method.

[0019] In a first aspect, an embodiment of the invention provides a channel access method for execution by a user equipment (UE) , comprising:

[0020] receiving a configuration of a number of consecutive slots within a configured grant (CG) period of a CG configuration and a configuration of a size of a bitmap for reporting one or more unused PUSCH occasions of the CG configuration; and

[0021] transmitting uplink control information (UCI) in a PUSCH occasion to convey the bitmap that indicates one or more unused PUSCH occasion, wherein the one or more unused PUSCH occasions are determined based on the received configurations of the CG configuration.

[0022] In a second aspect, an embodiment of the invention provides a channel access method for execution by a base station, comprising:

[0023] transmitting a configuration of a number of consecutive slots within a configured grant (CG) period of a CG configuration and a configuration of a size of a bitmap for reporting one or more unused PUSCH occasions of the CG configuration; and

[0024] receiving uplink control information (UCI) in a PUSCH occasion;

[0025] wherein the UCI conveys the bitmap that indicates one or more unused PUSCH occasion;

[0026] wherein the one or more unused PUSCH occasions are determined based on the configurations of the CG configuration.

[0027] In a third aspect, an embodiment of the invention provides a user equipment (UE) comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method.

[0028] In a fourth aspect, an embodiment of the invention provides a base station comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method.

[0029] The disclosed method may be programmed as computer executable instructions stored in non-transitory computer readable medium. The non-transitory computer readable medium, when loaded to a computer, directs a processor of the computer to execute the disclosed method.

[0030] The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

[0031] The disclosed method may be programmed as a computer program product, that causes a computer to execute the disclosed method.

[0032] The disclosed method may be programmed as a computer program, that causes a computer to execute the disclosed method.Advantageous Effects

[0033] At least one embodiment provides multi-PUSCHs CG configuration to address the identified challenges. The embodiment provides comprehensive parameters and schemes for configuring multi-PUSCHs CG. This solution aims to better accommodate the variable packet sizes and transmission requirements of XR services.

[0034] At least one embodiment provides TB repetitive transmission support. In the embodiment, specific parameters and schemes are provided to support the repetitive transmission of a TB within the structure of multi-PUSCHs CG. This approach will enhance reliability and coverage for uplink video traffic.

[0035] At least one embodiment provides repetition and retransmission schemes. To ensure robust data transmission, dedicated repetition and retransmission schemes are established and tailored for multi-PUSCHs CG. These schemes will address scenarios of initial transmission failures and improve overall reliability.

[0036] At least one embodiment provides unused CG PUSCH occasion reporting. To optimize resource utilization, it is proposed to determine a range of PUSCH occasion candidates for bitmap indication of unused CG PUSCH occasions. Additionally, the development of efficient bit mapping schemes for reporting these unused CG PUSCH occasions to the gNB is proposed. These measures aim to enhance resource allocation efficiency. The determined range of PUSCH occasion candidates provides a framework for indicating which CG PUSCH occasions are unused, while the efficient bit mapping schemes facilitate clear and concise reporting of this information to the gNB.

[0037] Enhanced CG configurations with multiple CG PUSCH occasions within a CG period offer several significant benefits. Primarily, they reflect uplink data transmission more accurately, accommodating various traffic patterns with variable payload sizes. This flexibility is crucial in modern network environments where data demands can fluctuate rapidly. Furthermore, the joint design of repetition in multi-PUSCHs CG enhances the coverage range of uplink data transmission, ensuring more reliable communication over longer distances or in challenging environments. The incorporation of a retransmission mechanism in multi-PUSCHs CG further improves the performance of uplink data transmission, reducing data loss and enhancing overall reliability.

[0038] These enhanced configurations also play a crucial role in preventing additional latency and overhead. They achieve this by eliminating the need for frequent reconfiguration of CG scheduling or the initiation of scheduling request (SR)  / buffer status reporting (BSR) procedures typically required by dynamic grant (DG) scheduling. This streamlined approach contributes to more efficient network operation and improved user experience.

[0039] The ability to indicate unused CG PUSCH occasions to the gNB brings 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 utilized to their full potential. Additionally, this indication mechanism reduces the overhead of blind decoding over unused CG PUSCH resources at the gNB, thereby saving unnecessary power consumption. This energy efficiency is increasingly important in modern network designs.

[0040] Moreover, the feedback provided by this indication allows the gNB to adjust parameters of CG PUSCH configurations more effectively. This adaptive approach improves resource utilization to better meet each UE's uplink traffic needs. It also reduces the overhead associated with consistent reporting of unused CG PUSCH occasions from the UE, striking a balance between network awareness and efficient communication. Collectively, these benefits contribute to a more responsive, efficient, and adaptable network infrastructure.BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present disclosure or related art, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some  embodiments of the present disclosure, a person having ordinary skill in this field may obtain other figures according to these figures without paying the premise.

[0042] FIG. 1 illustrates a schematic view showing a telecommunication system.

[0043] FIG. 2 illustrates a schematic view showing an embodiment of the disclosed channel access method.

[0044] FIG. 3 illustrates a schematic view showing an example of multi-PUSCHs CG configured with M=2, N =3, and repetition factor K=2.

[0045] FIG. 4 illustrates a schematic view showing an example of multi-PUSCHs CG configured with M=2, N =3, and repetition factor K=3.

[0046] FIG. 5 illustrates a schematic view showing an example of multi-PUSCHs CG configured with M=N=3, and K =4.

[0047] FIG. 6 illustrates a schematic view showing an example multi-PUSCHs CG configured with M=2, N =3, repetition factor K=2, and RV pattern = {0, 2, 3, 1} .

[0048] FIG. 7 illustrates a schematic view showing timer association with a TB group.

[0049] FIG. 8 illustrates a schematic view showing an example of unused PUSCH occasion indication according to an indication period.

[0050] FIG. 9 illustrates a schematic view showing an example of unused PUSCH occasion indication according to a set of PUSCH occasions.

[0051] FIG. 10 illustrates a schematic view showing an example of bitmap indication with TB repetition.

[0052] FIG. 11 illustrates a schematic view showing an example of bitmap indication with TB repetition based on Scheme 2 of Embodiment F.

[0053] FIG. 12 illustrates a schematic view showing a procedure of configuring multiple CG PUSCH occasions within a CG by gNB and reporting unused CG PUSCH occasions by UE.

[0054] FIG. 13 illustrates a schematic view showing a user equipment (UE) .

[0055] FIG. 14 illustrates a schematic view showing a network node.

[0056] FIG. 15 illustrates a schematic view showing a chip or executing the disclosed method in a UE.

[0057] FIG. 16 illustrates a schematic view showing a chip or executing the disclosed method in a network node.DETAILED DESCRIPTION OF EMBODIMENTS

[0058] Embodiments of the disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure. In this disclosure, the term " / "should be interpreted to indicate "and / or. "

[0059] With reference to FIG. 1, a telecommunication system including a user equipment (UE) 10a, a UE 10b, a base station (BS) 20a, and a network entity device 30 executes the disclosed method according to an embodiment of the present disclosure. FIG. 1 is shown for illustrative not limiting, and the system may comprise more UEs, BSs, and core network (CN) entities. Connections between devices and device components are shown as lines and arrows in the FIGs. The UE 10a may include a processor 11a, a memory 12a, and a transceiver 13a. The UE 10b may include a processor 11b, a memory 12b, and a transceiver 13b. The base station 20a may include a processor 21a, a memory 22a, and a transceiver 23a. The network entity device 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 proposed functions, procedures  and / or methods described in the description. Layers of radio interface protocol may be implemented in the processors 11a, 11b, 21a, and 31. Each of the memory 12a, 12b, 22a, and 32 operatively stores a variety of programs and information to operate a connected processor. Each of the transceivers 13a, 13b, 23a, and 33 is operatively coupled with a connected processor, and transmits and / or receives radio signals or wireline signals. The UE 10a may be in communication with the UE 10b through a sidelink. The base station 20a may be an eNB, a gNB, or one of other types of radio nodes, and may configure radio resources for the UE 10a and UE 10b.

[0060] Each of the processors 11a, 11b, 21a, and 31 may include an application-specific integrated circuit (ASICs) , other chipsets, logic circuits and / or data processing devices. Each of the memory 12a, 12b, 22a, and 32 may include read-only memory (ROM) , a random access memory (RAM) , a flash memory, a memory card, a storage medium 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 may be implemented with modules, procedures, functions, entities, and so on, that perform the functions described herein. The modules may be stored in a memory and executed by the processors. The memory may be implemented within a processor or external to the processor, in which those may be communicatively coupled to the processor via various means are known in the art.

[0061] The network entity device 30 may be a node in a CN. CN may include LTE CN or 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 (AUSF) , network slice selection function (NSSF) , and the network exposure function (NEF) .

[0062] An example of the UE in the description may include one of the UE 10a or UE 10b. An example of the base station in the description may include the base station 20a. Sidelink (SL) transmission of a control signal or data may be a transmission operation from a UE to another UE. Uplink (UL) transmission of a control signal or data may be a transmission operation from a UE to a base station. Downlink (DL) transmission of a control signal or data may be a transmission operation from a base station to a UE. A DL control signal may comprise a medium access control (MAC) control element (CE) , downlink control information (DCI) or a radio resource control (RRC) signal, from a base station to a UE.

[0063] With reference to FIG. 2, an embodiment of the disclosed channel access method is illustrated. The base station 20a transmits a configuration of a number of consecutive slots within a configured grant (CG) period of a CG configuration and a configuration of a size of a bitmap for reporting one or more unused PUSCH occasions of the CG configuration (A001) .

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

[0065] The UE 10a transmits uplink control information (UCI) in a PUSCH occasion to convey the bitmap that indicates one or more unused PUSCH occasion, wherein the one or more unused PUSCH occasions are determined based on the received configurations of the CG configuration (B003) .

[0066] The base station 20a receives uplink control information (UCI) in a PUSCH occasion (A004) .

[0067] The UCI conveys the bitmap that indicates one or more unused PUSCH occasion. The one or more unused PUSCH occasions are determined based on the configurations of the CG configuration.

[0068] In some embodiments of the disclosure, the configurations are applicable in Type 1 or Type 2 CG.

[0069] In some embodiments of the disclosure, at least one slot of the configured consecutive slots includes a downlink (DL) symbol.

[0070] In some embodiments of the disclosure, an initial slot location of the configured consecutive slots is determined based on an offset value relative to a reference SFN for Type1 CG.

[0071] In some embodiments of the disclosure, an initial slot location of the configured consecutive slots is determined based on an offset value relative to a slot location carrying activation downlink control information (DCI) for Type 2 CG.

[0072] In some embodiments of the disclosure, one or more symbol locations in a slot having a PUSCH occasion are determined based on a start and length indicator value (SLIV) value derived from radio resource control (RRC) signaling in for Type 1 CG.

[0073] In some embodiments of the disclosure, the one or more symbol locations in the slot having a PUSCH occasion are applied to other slots within the CG period, and the one or more symbol locations of the PUSCH occasion for the UCI does not collide with a DL symbol or synchronization signal block (SSB) .

[0074] In some embodiments of the disclosure, a frequency location or modulation and coding scheme (MCS) of the slot having a PUSCH occasion is applied to other slots within the CG period.

[0075] In some embodiments of the disclosure, one or more symbol locations in a slot having a PUSCH occasion are determined based on an SLIV value derived from an activation DCI for Type 2 CG.

[0076] In some embodiments of the disclosure, the one or more symbol locations having a PUSCH occasion in the slot are applied to all slots within the CG period, and the one or more symbol locations of the PUSCH occasion for the UCI does not collide with a DL symbol or SSB.

[0077] In some embodiments of the disclosure, a frequency location or MCS of the slot having a PUSCH occasion is applied to other slots within the CG period.

[0078] In some embodiments of the disclosure, at least one value of the number of consecutive slots within the CG period is an integer multiple of the size of the bitmap for reporting one or more unused PUSCH occasions.

[0079] In some embodiments of the disclosure, the PUSCH occasion in which the UCI is received is a PUSCH occasion not declared as unused.

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

[0081] In some embodiments of the disclosure, the bitmap comprises a sequence of bits, each bit in the sequence is associated with a respective corresponding PUSCH occasion, wherein the bits are arranged in the sequence from left to right in an order corresponding to a chronological order of the PUSCH occasions from earliest to latest.

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

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

[0084] In some embodiments of the disclosure, at least one bit of the bitmap indicates a PUSCH occasion in another CG period which is different from the CG period in which the bitmap in the UCI is conveyed.

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

[0086] In some embodiments of the disclosure, the one or more symbol locations having a PUSCH occasion in the slot are applied to all slots within the CG period, and the one or more symbol locations of the PUSCH occasion for transmitting the UCI does not collide with a DL symbol or SSB.

[0087] In some embodiments of the disclosure, a frequency location or MCS of the slot having a PUSCH occasion is applied to other slots within the CG period.

[0088] To support licensed band operation with multiple PUSCH occasions per CG period, modifications to the NR-U CG framework are necessary. These modifications may include:

[0089] ● Support for non-contiguous UL slots in TDD frame structures;

[0090] ● Adaptation of repetition types and retransmission schemes for multiple TB transmissions per CG period; and / or

[0091] ● Introduction of new RRC parameters to enable these enhanced functions.

[0092] While configuring multiple CG PUSCH transmission occasions within a CG period can accommodate larger UL video packet sizes, the variable nature of these packets means the actual number of TBs transmitted within a CG period is uncertain for gNB (e.g., one or more BSs as shown in FIG. 1) . To improve resource efficiency in cases of over-provision, the UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) can dynamically indicate unused CG occasions among the configured CG PUSCH occasions to the gNB.

[0093] Once the gNB acknowledges the unused occasions reported by the UE, these resources can be released and reallocated either to the same UE or to other UEs, thereby enhancing overall resource utilization.

[0094] Embodiment A: Information setting associated with multi-PUSCHs CG configuration within a CG period.

[0095] This embodiment describes the information provided by the gNB (e.g., one or more BSs as shown in FIG. 1) to the UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) for configuring multiple PUSCH occasions within a Configured Grant (CG) period. The information can be provided via RRC signaling or activation DCI, depending on whether Type 1 or Type 2 CG is used. Key aspects of this configuration include:

[0096] 1. Location of PUSCH occasions

[0097] 2. TB Repetition settings

[0098] 3. Symbol location of the first PUSCH occasion

[0099] 4. MCS and frequency domain resource allocation settings

[0100] These configurations apply to multi-PUSCHs CG operation even when cgRetransmissionTimer is not configured. The following sub-sections (Embodiments A-1, A-2, A-3) will provide more detailed information on specific aspects of this configuration.

[0101] Embodiment A-1: Location of PUSCH occasions.

[0102] The gNB provides a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) with at least one of following information for determining locations of PUSCH occasions of multi-PUSCHs CG per CG configuration:

[0103] 1. Number of consecutive slots for multi-PUSCHs CG;

[0104] 2. Number of consecutive and valid PUSCH occasions within a slot for multi-PUSCHs CG (denoted as parameter M) ;

[0105] 3. An initial slot location of the consecutive slots for multi-PUSCHs CG within a CG period;

[0106] 4. Symbol location (s) in the first PUSCH occasion within the initial slot of the multi-PUSCHs CG; and

[0107] 5. Modulation and coding scheme (MCS) and frequency domain resource allocation (FDRA) setting.

[0108] 1. Number of consecutive slots for multi-PUSCHs CG (denoted as parameter N) .

[0109] i. Interpretation of parameter N can be one of the following:

[0110] ■ The value of consecutive slots N refers to valid slots for UL transmission within the CG period, i.e., only applicable to UL slot.

[0111] ■ The value of consecutive slots N refers to any slot type, including both DL and UL within the CG period, e.g., if TDD frame structure is configured. However, only slots configured as UL are valid slots for PUSCH transmission. In this case, if parameter N’ is defined as the number of valid slots for PUSCH transmission, then N’ <= N. For ease of explanation, we assume N’ =N in the following embodiments if otherwise stated.

[0112] 2. Number of consecutive and valid PUSCH occasions within a slot for multi-PUSCHs CG (denoted as parameter M) .

[0113] i. The first PUSCH symbol occasions within a slot is determined based on a start and length indicator value (SLIV) value in a time domain resource assignment (TDRA) table configured by the gNB. Subsequent PUSCH occasions within the same slot follow the first one consecutively, each having the same symbol length (i.e., number of symbols) as defined by the SLIV.

[0114] ii. The parameter M accounts for valid PUSCH occasions within a slot wherein only UL symbols are included in the PUSCH occasions.

[0115] ■ The number of consecutive and valid PUSCH occasions M may vary across N slots configured for multi-PUSCHs CG due to time-division duplex (TDD) frame structure configuration e.g., tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or due to collision with a synchronization signal block (SSB) . Thus, different slot in the N consecutive slots may have different number of consecutive and valid PUSCH occasions.

[0116] ■ In order to have consistent value of M among N slots, at least one of following schemes can be implemented.

[0117] ◆ Selective N: The parameter N only counts slots that can accommodate the full number M of PUSCH occasions. For example, slots with fewer than M PUSCH occasions are excluded.

[0118] ◆ Adaptive M: The gNB configures M to a value that all N slots can accommodate, ensuring consistency across all slots.

[0119] ◆ Maximum M interpretation: The value of M is interpreted as the maximum allowable number of PUSCH occasions for each of N slots. For any slot that cannot accommodate M PUSCH occasions, then available PUSCH occasions less than M within this slot are used.

[0120] 3. Determination of an initial slot location of the consecutive slots for multi-PUSCHs CG within a CG period.

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

[0122] ● For Type 2 CG, the initial slot is determined based on an offset value relative to the slot carrying activation DCI.

[0123] 4. Symbol location (s) of the first PUSCH occasion within the initial slot of the multi-PUSCHs CG.

[0124] ● The symbol location (s) is determined based on an SLIV value associated with a row index of a TDRA table. The row index may be specified differently for Type 1 and Type 2 CG:

[0125] ■ For Type 1 CG, the row index is configured by the gNB via RRC signaling.

[0126] ■ For Type 2 CG, the row index is determined based on an indication in activation DCI.

[0127] 5. Modulation and coding scheme (MCS) and frequency domain resource allocation (FDRA) setting: The  same MCS and FDRA setting per CG configuration is applied to all PUSCH occasions of corresponding CG configuration.

[0128] ● For Type 1 CG, same MCS and FDRA are configured by the gNB via RRC signaling and is applied to all PUSCH occasions within a CG period.

[0129] ● For Type 2 CG, MCS and FDRA can be indicated in the activation DCI and is applied to all PUSCH occasions within a CG period.

[0130] Above parameters related to multi-PUSCHs CG can be applied to the operation of multi-PUSCHs CG operation even when cgRetransmissionTimer is not configured.

[0131] In some embodiments of the disclosure, the received configurations are applicable in Type 1 or Type 2 CG.

[0132] In some embodiments of the disclosure, at least one slot of the configured consecutive slots includes a downlink (DL) symbol.

[0133] In some embodiments of the disclosure, an initial slot location of the configured consecutive slots is determined based on an offset value relative to a reference SFN for Type1 CG.

[0134] In some embodiments of the disclosure, an initial slot location of the configured consecutive slots is determined based on an offset value relative to a slot location carrying activation downlink control information (DCI) for Type 2 CG.

[0135] In some embodiments of the disclosure, one or more symbol locations in a slot having a PUSCH occasion are determined based on a start and length indicator value (SLIV) value derived from radio resource control (RRC) signaling for Type 1 CG.

[0136] In some embodiments of the disclosure, the one or more symbol locations in the slot having a PUSCH occasion are applied to other slots within the CG period, and the one or more symbol locations of the PUSCH occasion for transmitting the UCI does not collide with a DL symbol or synchronization signal block (SSB) .

[0137] In some embodiments of the disclosure, a frequency location or modulation and coding scheme (MCS) of the slot having a PUSCH occasion is applied to other slots within the CG period.

[0138] In some embodiments of the disclosure, one or more symbol locations in a slot having a PUSCH occasion are determined based on an SLIV value derived from an activation DCI for Type 2 CG.

[0139] Embodiment A-2: TB Repetition in some of PUSCH occasions.

[0140] To support TB repetition in multi-PUSCHs CG, i.e., one TB is transmitted in more than one PUSCH occasions, the gNB (e.g., one or more BSs as shown in FIG. 1) provides a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) with at least one of following information for determining whether TB repetition is applied to multi-PUSCHs CG per CG configuration.

[0141] 1. A parameter indicating whether TB transmission is with or without repetition:

[0142] ■ Without repetition: One TB per PUSCH occasion

[0143] ■ With repetition: One TB associated with multiple PUSCH occasions

[0144] 2. A number of available TBs (denoted as parameter B) for transmission in the configured PUSCH occasions within a CG period.

[0145] 3. A repetition factor, i.e., the number of repetitions (denoted as parameter K) per CG configuration, for each TB transmitted in the CG period.

[0146] ■ Same repetition factor is applied to each of the TBs within a CG period if repetition is configured by gNB.

[0147] ◆ For Type 1 CG, the repetition factor can be configured by gNB via RRC.

[0148] ◆ For Type 2 CG, the repetition factor can be indicated in an activation DCI.

[0149] 4. Note that in addition to explicit indication, implicit indication of above information can be derived by the UE, for example:

[0150] ■ The number of available TBs for transmission in the configured PUSCH occasions within a CG period can be derive from the repetition factor K and parameters M and N, e.g., B= (M × N)  / K.

[0151] ■ The repetition factor K can be derived from the number of available TBs B within a CG period and parameters M and N, e.g., K= (M × N)  / B.

[0152] Note that additional predefined rules or additional configurations can be adopted to derive above information, for example:

[0153] ● The repetition factor K is predefined or configured to be the same as parameter M, i.e., the repetition is performed within a slot.

[0154] ■ The number of available TBs, denoted as B, equals to or less than the parameter N, i.e., different TBs are transmitted across different consecutive UL slots.

[0155] ● The repetition factor K is predefined or configured to be equal to or less than the parameter N, i.e., the repetition is performed across slots, and number of available TBs, denoted as B, equals to or less than the parameter M, i.e., different TBs are transmitted within a slot, and they are repeated across different slots.

[0156] Embodiment A-3: Example of TB repetition in multi-PUSCHs CG.

[0157] With reference to FIG. 3, in an example, multi-PUSCHs CG is configured with M=2, N =3, and repetition factor K=2. In this setting, the number of consecutive PUSCH occasions within a CG is given as M × N, and M × N = 6, totally 3 TBs are transmitted within the CG period, and 2 repetitions are performed within a slot for each TB.

[0158] With reference to FIG. 4, in another example, multi-PUSCHs CG is configured with M=2, N =3, and repetition factor K=3. In this setting, the number of consecutive PUSCH occasions within a CG is given as M × N, and M × N = 6, totally 2 TBs are transmitted within the slot, and 3 repetitions are performed across slots for each TB.

[0159] Embodiment B: TB Repetition scheme in multi-PUSCHs CG.

[0160] Embodiment B-1: Configuration restriction for TB Repetition.

[0161] For example, the UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) performs TB repetition in multi-PUSCHs CG configuration according to at least one of following configuration restrictions.

[0162] 1. Total PUSCH occasions constraint: The total number of PUSCH occasions in a CG period, i.e., M multiplied by N, M × N, as indicated in Embodiment A-1, is larger than the repetition factor as indicated in Embodiment A-2. Note that M is the number of consecutive valid PUSCH occasions within a slot, and N is the number of valid consecutive slots for PUSCH transmission.

[0163] 2. Integer multiple constraint: The total number of PUSCH occasions in a CG period, i.e., M × N as indicated in Embodiment A-1, can be an integer multiple of the repetition factor as indicated in Embodiment A-2.

[0164] If the value of M × N is not an integer multiple of the repetition factor, then the earliest PUSCH occasions with a total number equal to an integer multiple of the repetition factor can be adopted for full repetitions of one or more than one TB.

[0165] With reference to FIG. 5, an example with M=N=3, and K =4. In this case, at most 2 TBs can be transmitted with full repetitions within the CG period. This leaves one unused PUSCH occasion.

[0166] The processing of the last PUSCH occasions (unused PUSCH occasions) can encompass at least one of the following options:

[0167] 1. The last PUSCH occasion is not used by the UE, the UE can declare it as unused based on a bitmap in the uplink control information (UCI) ,

[0168] 2. The UE just ignores it and does not use this PUSCH occasion for data transmission.

[0169] 3. The third TB can be transmitted in the last PUSCH occasion without repetition.

[0170] Embodiment B-2: HARQ ID setting for TB Repetition.

[0171] For example, UE or gNB (as shown in FIG. 1) determines HARQ process IDs in multi-PUSCHs CG according to at least one of following rules considering TB repetition, i.e., one TB is associated with more than one PUSCHs.

[0172] 1. Consistent ID for repetitions: Each ID value of HARQ process in the PUSCH occasions for carrying repetitions of a TB are the same, i.e., more than one CG PUSCH occasions carrying one TB shares the same HARQ process ID.

[0173] 2. Sequential ID assignment: After the HARQ process ID for the first valid PUSCH occasion in a CG period is determined based on a rule, the HARQ process ID of the following valid PUSCHs remains the same if repetitions associated with a TB is transmitted over these PUSCHs. The HARQ process ID increments by one for each new TB.It remains constant for all PUSCH occasions carrying repetitions of the same TB, then increases for the PUSCH occasions of the next TB. For subsequent valid PUSCHs:

[0174] i. If carrying repetitions of the same TB: HARQ process ID remains the same.

[0175] ii. If carrying a new TB: HARQ process ID increases by one.

[0176] 3. The HARQ process ID derived from above procedure can only applies to PUSCH occasions which are valid or not indicated as unused by the UE.

[0177] For a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) determining redundancy version (RV) value of each repetition for a TB transmitted in associated PUSCH occasions, at least one of the following schemes can be implemented:

[0178] 1. Fixed RV patterns are preconfigured by the gNB in the standard. For example, four RVs are supported, and the RV pattern {RV0, RV1, RV2, RV3} includes {0, 0, 0, 0} , {0, 3, 0, 3} and {0, 2, 3, 1} .

[0179] 2. For Type 1 or Type 2 CG, one of the RV patterns can be configured by the gNB via RRC signaling per CG configuration, and the RV value of each repetition can be derived from the RV pattern. The same RV pattern applies to different sets of PUSCH occasions configured for repetitive transmissions of a TB, wherein a set of PUSCH occasions corresponds to repetitions associated with a TB. For Type 2 CG, the selected RV pattern can also be indicated in the activation DCI.

[0180] The gNB can configure UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) via RRC per CG configuration to determine starting location of a TB transmission within a CG period based on at least one of following schemes, the configuration can be applied to transmissions of each of TB within a CG period.

[0181] 1. The starting location of a TB transmission is the first PUSCH occasion of the set of PUSCH occasions configured for repetitive transmissions of the TB.

[0182] 2. The starting location of a TB transmission is the PUSCH occasion mapped to earliest PUSCH occasion with RV0 in the set of PUSCH occasions configured for repetitive transmissions of the TB.

[0183] 3. For Type 2 CG, the starting location of a TB and the RV value associated with the PUSCH occasion at the stating location can be indicated in the activation DCI.

[0184] i. The first RV value indicated in the activation DCI is selected from one value of a pre-configured RV pattern, and the RV value of the remaining repetitions follows the order of the pre-configured  RV pattern from the first RV value.

[0185] Embodiment B-3: Example of HARQ process ID value determination with repetitive transmission in multi-PUSCHs CG.

[0186] With reference to FIG. 6, an example of multi-PUSCHs CG is configured with M=2, N =3, repetition factor K=2, and RV pattern = {0, 2, 3, 1} .

[0187] In this setting, it is assumed that the first TB (denoted as TB1) is transmitted from the first PUSCH occasion in the CG period.

[0188] According to a HARQ process ID determination rule, it is assumed that the HARQ process ID of the first PUSCH occasion for TB1 is 0. The HARQ process ID remains the same for the PUSCH occasions belonging to the same TB.

[0189] The HARQ process ID increments by one at the first PUSCH occasion of the next TB transmission.

[0190] Embodiment C: Retransmission scheme in multi-PUSCHs CG.

[0191] Embodiment C-1: Retransmission of multi-PUSCHs CG is based on configured grant timer and dynamic UL grant.

[0192] For a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) , the retransmission assumption of multi-PUSCHs CG relies on configured grant timer. The timer is a timer associated with ACK assumption of previous TB transmission. The timer is different to a timer related to NACK assumption of previous TB transmission, wherein retransmission is autonomously performed at the UE after the expiry of the timer.

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

[0194] If the UE does not receive a DCI with dynamic UL grant for retransmission of a TB initially transmitted at a latest PUSCH occasion associated with an HARQ process ID before the expiry of corresponding configured grant timer, the UE assumes ACK for the initial TB transmission and flushes the HARQ buffer of associated HARQ process ID.Otherwise, the UE assumes NACK for the initial TB transmission, and performs retransmission based on the dynamic UL grant indicated in the DCI.

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

[0196] Code block group (CBG) based retransmission can be supported, if a CBGTI field in the UL grant DCI is configured by the gNB.

[0197] Embodiment C-2: Configured grant timer association.

[0198] The association of configured grant timer with a TB can be one of the two schemes:

[0199] Scheme 1-Single TB Timer Association:

[0200] 1. Timer setting: A timer setting is associated with only one TB, and the timer resets and starts counting after transmitting the TB in the latest PUSCH occasion associated with an HARQ process ID of the TB.

[0201] 2. Latest PUSCH occasion definition:

[0202] i. For TB transmission configured without repetition, the latest PUSCH occasion corresponds to the PUSCH occasion for previous transmission (e.g., an initial transmission) of the TB.

[0203] ii. For TB transmission configured with repetition, the latest PUSCH occasion corresponds to the last transmission occasion of a TB among a set of PUSCH occasions configured for TB repetitions.

[0204] 3. Dynamic UL grant behavior: The dynamic UL grant indicated in the DCI for PUSCH retransmission is only  targeted for a single TB before the expiry of configured grant timer associated with the TB.

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

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

[0207] Scheme 2-TB Group Timer Association:

[0208] 1. Timer setting: A timer setting is associated with a group of TBs (denoted as a TB group) . The timer resets and starts counting after the latest PUSCH occasion associated with one of the HARQ process IDs of the TB group.

[0209] 2. TB grouping configuration: TBs grouping or number of TB groups transmitted in the CG period multi-PUSCHs CG configuration can be preconfigured by the gNB per CG configuration.

[0210] i. TBs grouping can be regarded as HARQ process IDs grouping. Association of some HARQ process IDs into a group can be configured by gNB.

[0211] ii. In this document, a TB group and a HARQ process ID group can be interchangeable. A TB group can be referred to a HARQ process ID group. A TB associated with TB group can also be rephrased as a HARQ process ID associated with a HARQ process ID group.

[0212] iii. A TB group index can be assigned for each TB group during the configuration.

[0213] iv. Each of TB groups is associated with independent timers.

[0214] v. The TBs within a TB group are transmitted in consecutive PUSCH occasions.

[0215] vi. If the number of TB groups equals to one, then all the TBs transmitted within the CG period belong to the same TB group.

[0216] 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 necessary. In this sense, a TB group corresponds to a TB, and the following operation scheme is applicable for either Scheme 1 or Scheme 2.

[0217] Embodiment C-3: Retransmission scheduling in DCI.

[0218] For Scheme 1 or Scheme 2 in Embodiment C-2, the gNB may use dynamic UL grant in the DCI to schedule at least one PUSCH for retransmission of at least one TB in the TB group before the expiry of configured grant timer associated with the TB group.

[0219] 1. Retransmission indication: The DCI carrying dynamic UL grant indicates at least one TB group or at least one TB within a TB group for retransmission based on a bit indication (referred to as retransmission indication) . The field used for retransmission indication can be one of the following:

[0220] i. Using the bit field carrying more than one new data indication (NDI) in the DCI, wherein the DCI can schedule multiple PUSCHs.

[0221] ii. Using the bit field carrying one NDI in the DCI, wherein the DCI can schedule only one PUSCH. In this case, more than one DCI is necessary for retransmitting more than one TB.

[0222] iii. Using a configurable bitmap in the DCI, wherein the DCI can schedule one or more than one PUSCHs, the size of bitmap can be configurable.

[0223] 2. Bit mapping for retransmission indication: Each bit of the retransmission indication in the DCI can be mapped to at least one of following HARQ process ID (s) .

[0224] i. At least one TB group (or HARQ process ID group) within a CG period. In this case, a bit indication can be associated with at least one TB group index. The TB group index can be preconfigured by the gNB after the TB group have been formed based on TB grouping configuration for a CG configuration.

[0225] ii. At least one TB (or HARQ process ID) within a TB group (or within HARQ process ID group) . In this case, a bit indication can be associated with at least one TB (or HARQ process ID) within a TB group (or within HARQ process ID group) .

[0226] 3. Activation of multi-PUSCH scheduling: Activation of using an UL grant DCI that schedules more than one PUSCH for retransmission of more than one TB may be preconfigured by the gNB via RRC signaling. The configuration can be per CG. If an UL grant can only schedule one PUSCH, then more than one UL grant is necessary for retransmitting more than one TBs in the TB group.

[0227] 4. Redundancy Version (RV) determination for retransmission: For a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) , determination of RVs for retransmission can be based on at least one of following scheme.

[0228] i. Each of the RVs used for retransmission of each of one or more than one TB within the TB group can be predefined, e.g., using RV0 for each retransmitted TB within the TB group.

[0229] ii. The RV value of each retransmitted TB can be indicated in an RV field of the DCI in case the DCI can schedule multiple PUSCHs.

[0230] ● If only one RV field is available in the DCI,

[0231] ■ the RV value can be applied to all the retransmitted TBs or

[0232] ■ more than one DCI is necessary to indicate RV of each retransmitted TB.

[0233] 5. Settings for multi-TB retransmission scheduling: For a dynamic UL grant DCI that schedules more than one TB retransmission, at least one of following setting is adopted.

[0234] i. The same MCS or FDRA indicated in the DCI applies to scheduled retransmissions of each TB.

[0235] ii. For determining time domain location of each TB:

[0236] ● The TDRA information (such as K2 slot offset, PUSCH mapping type, and SLIV) are preconfigured in a TDRA table by gNB via RRC signaling.

[0237] ● The DCI indicates a row index of the TDRA table.

[0238] ● The row index is mapped to TDRA information for each of the TB retransmission (e.g., each row of the TDRA table contains more than one SLIV) .

[0239] 6. Repetition for retransmitted TBs: The dynamic UL grant in DCI can indicate Type A or Type B repetition for at least one retransmitted TB.

[0240] Embodiment C-4: Example of timer association with a TB group.

[0241] With reference to FIG. 7, PUSCH occasions configured in the CG period with a length of 16 slots. Each of the PUSCH occasions is transmitted within a slot. Two TB groups are defined, each TB group covering four consecutive PUSCH occasions. Each PUSCH occasion is associated with a HARQ process ID.

[0242] ● Timer #1 resets and starts counting after the fourth TB (i.e., TB 4) is transmitted in the last PUSCH occasion (i.e., fourth PUSCCH occasion) in the first TB group (i.e., TB group #1) . Timer #1 is counting down and expired after 8 slots.

[0243] ■ An UL grant in DCI #1 is received at the 9th slot before expiry of Timer #1. The UL grant indicates that TB 2 associated with an HARQ process ID in the TB group #1 needs to be retransmitted, and the DCI#1 schedules TB 2 to be retransmitted in the 11th slot. The RV value of the retransmitted TB 2 is also indicated in DCI #1.

[0244] ● Timer #2 resets and starts counting after the fourth TB (i.e., TB 8) is transmitted in the last PUSCH occasion (i.e., fourth PUSCCH occasion) in the second TB group (i.e., TB group #2) . Timer #2 is counting down and  expired after 8 slots.

[0245] ■ An UL grant in DCI #2 is received at the 13th slot before expiry of Timer #2. The UL grant indicates that TB 5 associated with an HARQ process ID in the TB group #2 needs to be retransmitted, and schedules TB 5 to be retransmitted in the 12th slot. The RV value of the retransmitted TB 5 is also indicated in DCI #2.

[0246] Embodiment D: UE can indicate unused CG PUSCH occasions within a range using a bitfield in the UCI.

[0247] Embodiment D-1: Indication according to a range defined as an indication period

[0248] 1. Indication Period Determination: The UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) determines an indication period during which at least one of the CG PUSCH occasions can be indicated as unused.

[0249] 2. Range Configuration: The range of indication period is configured by gNB (e.g., one or more BSs as shown in FIG. 1) via RRC per CG configuration.

[0250] i. The range of indication period can be expressed based on at least one of the following:

[0251] ■ An absolute value expressed in unit of slot or symbols.

[0252] ■ A value related to a length of a CG period. The value is an integer multiple of a CG period or the CG period is divisible by the value.

[0253] 3. Start Time of Indication Period: The start time of the indication period can be a start slot or start symbol determined based on a time offset relative to the end of a UL symbol or UL slot of a transmitted CG PUSCH that carries the UCI.

[0254] 4. Time offset configuration: A time offset can be configured by the gNB via RRC signaling or pre-defined in the standard.

[0255] i. The configuration of the time offset can be per CG configuration.

[0256] ■ If a parameter related to the time offset is not configured in the CG configuration, then the value of the time offset is assumed to be 0.

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

[0258] iii. If the value of the time offset is not configured or is configured to be 0, then the start time of the indication period is immediately after the end of the CG PUSCH carrying the UCI.

[0259] 5. Time Offset Determination: The value of time offset can be determined based on at least one of the following:

[0260] i. The processing time required by the gNB to process and respond to the indication of unused CG PUSCH occasions.

[0261] ii. The preparation time required to transmit uplink grant in order to re-schedule unused PUSCH resources for the same UE or other UEs.

[0262] 6. End Time of Indication Period: The end time of the indication period can be derived from the start time of the indication period and the length of the indication period. The end time of the indication period can be located in at least one of the following locations:

[0263] i. A slot or symbol within a CG period with a CG PUSCH carrying an indication of unused PUSCH occasions in the indication period in the UCI. In this case, the indication period can be smaller or the same as the CG period.

[0264] ii. A slot or symbol within a CG period other than the CG period with a CG PUSCH carrying an indication of unused PUSCH occasions in the indication period in the UCI. In this case, cross CG period indication of  unused PUSCH occasions is applied, and the indication period can be greater than the CG period.

[0265] In some embodiments of the disclosure, at least one value of the number of consecutive slots within the CG period is an integer multiple of the size of the bitmap for reporting one or more unused PUSCH occasions.

[0266] Embodiment D-2: Example of unused PUSCH occasion indication according to an indication period.

[0267] With reference to FIG. 8, in an example, the multi-PUSCHs CG is configured to includes totally 4 PUSCH occasions within a CG period, wherein 2 UL slots are available according to a DL / UL TDD configuration with DDDSU, and each UL slot (U) includes 2 PUSCH occasions.

[0268] The indication period starts after an offset value relative to the end of the latest PUSCH carrying UCI (i.e., PUSCH y) , and ends at the end of the indication period. The length of the indication period is assumed to be 2 CG period.

[0269] The indication period can cover 6 PUSCH occasions, from which the UE determines the 3rd and the 4th PUSCH occasions (i.e., PUSCH 3 and PUSCH 4) are unused. The unused PUSCH occasions are indicated in the UCI using a 6-bit bitmap, of which each bit is associated with a PUSCH occasion, and 6 bits are sequentially indicated, i.e., {001100} , according to a time order within the indication period. In this example, only valid PUSCH occasions are indicated in the bitmap of corresponding indication period, and bit value of 1 indicates the associated PUSCH occasion is unused.

[0270] Embodiment D-3: Indication according to a range defined as a set of PUSCH occasions.

[0271] The UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) determines a set of PUSCH occasions (refer to as PUSCH set) among which at least one of the CG PUSCH occasions can be indicated as unused.

[0272] 1. Number of PUSCH occasions: A fixed number of PUSCH occasions in a PUSCH set is configured by gNB (e.g., one or more BSs as shown in FIG. 1) via RRC per CG configuration.

[0273] 2. Bitmap indication: Each of the PUSCH occasions is associated with a bit indication represented by a bit in a bitmap.

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

[0275] ii. The size of the bitmap is related to the number of PUSCH occasions in the set, and size of the bitmap can be configured by the gNB via RRC per CG configuration.

[0276] iii. The mapping between PUSCH occasions and bitmap bits can be configured by the gNB. The gNB can configure, via RRC signaling per CG configuration, either:

[0277] a) A one-to-one mapping where each bit corresponds to exactly one PUSCH occasion, or

[0278] b) A many-to-one mapping where multiple PUSCH occasions are mapped to a single bit in the bitmap.

[0279] 3. PUSCH occasion characteristics: The PUSCH occasions of the set are consecutive and valid PUSCH occasions.

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

[0281] ii. In an embodiment, each PUSCH occasion in the set is a valid PUSCH occasion (e.g., not collide with SSB or DL slot / symbol, e.g., tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated) .

[0282] 4. Start PUSCH Occasion of the Set: The start PUSCH occasion of the set of PUSCH occasions associated with a bitmap is the first PUSCH occasion whose first valid PUSCH slot or first valid PUSCH symbol is located after a time offset relative to the end of a UL symbol or UL slot of a transmitted CG PUSCH in which the UCI is carried in the CG PUSCH.

[0283] 5. Time offset configuration: The time offset can be configured by the gNB via RRC signaling or pre-defined in the standard.

[0284] i. The configuration of time offset can be per CG configuration. If a parameter related to the time offset is not configured in the CG configuration, then the value of the time offset is assumed to be 0 .

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

[0286] iii. If the value of the time offset is not configured or is configured to be 0, then the start PUSCH occasion of set of PUSCH occasions is the first PUSCH occasion after the end of the CG PUSCH carrying the UCI.

[0287] 6. Time Offset Determination: The time offset can be determined based on at least one of the following:

[0288] i. The processing time required by the gNB to process and respond to the indication of unused CG PUSCH occasions.

[0289] ii. The preparation time required to transmit uplink grant in order to re-schedule unused PUSCH resources for the same UE other UEs.

[0290] 7. Last PUSCH Occasion of the Set: The last PUSCH occasion of the set of PUSCH occasions can be derived from the start PUSCH occasion of the set of PUSCH occasions and the number of the set of PUSCH occasions. The last PUSCH occasion of the set of PUSCH occasions associated with a bitmap can be:

[0291] i. A PUSCH occasion within a CG period with a CG PUSCH carrying an indication of unused PUSCH occasions in the set of PUSCH occasions in the UCI.

[0292] ii. A PUSCH occasion within a CG period other than the CG period with a CG PUSCH carrying an indication of unused PUSCH occasions in the set of PUSCH occasions in the UCI.

[0293] ● In this case, cross CG period indication of unused PUSCH occasion is operated.

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

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

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

[0297] In some embodiments of the disclosure, at least one bit of the bitmap indicates a PUSCH occasion in another CG period which is different from the CG period in which the bitmap in the UCI is conveyed.

[0298] Embodiment D-4: An example of unused PUSCH occasion indication according to a set of PUSCH occasions.

[0299] With reference to FIG. 9, the multi-PUSCHs CG is configured to includes totally 4 PUSCH occasions within a CG period, wherein 2 UL slots are available according to a DL / UL TDD configuration with DDDSU, and each UL slot (U) includes 2 PUSCH occasions.

[0300] The first PUSCH occasion is the valid PUSCH occasion starts after an offset value relative to the end of the latest PUSCH carrying UCI (i.e., PUSCH y) . The last PUSCH occasion is the 6th valid PUSCH occasion of the set of PUSCH occasions. The number of the set of PUSCH occasions (refer to as PUSCH set) is assumed to be 6.

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

[0302] Embodiment E: Bitmap indication

[0303] Embodiment E-1: Bitmap indication scheme

[0304] The UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) determines an unused CG PUSCH occasions based on a bitmap and transmits the bitmap to gNB (e.g., one or more BSs as shown in FIG. 1) in an UCI.

[0305] In an embodiment, each bit of the bitmap corresponds to one PUSCH occasion.

[0306] In an embodiment, the bitmap's bit order, from left to right, corresponds to the chronological sequence of PUSCH occasions, with earlier occasions represented by leftmost bits and later occasions by rightmost bits.

[0307] In an embodiment, the bit value of 0 corresponds to used PUSCH occasion, and bit value of 1 corresponds to unused PUSCH occasion.

[0308] The bitmap can indicate at least one of unused PUSCH occasions according to a duration of an indication period as defined in Embodiment D1 or according to a PUSCH set with a preconfigured number of PUSCH occasions as defined in Embodiment D3.

[0309] Based on embodiments D3 and E-1, the bitmap comprises a sequence of bits, each bit in the sequence is associated with a respective corresponding PUSCH occasion, wherein the bits are arranged in the sequence from left to right in an order corresponding to a chronological order of the PUSCH occasions from earliest to latest.

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

[0311] Embodiment E-2: Bitmap indication scheme according to configuration in Embodiment D1.

[0312] In the case of indication of unused PUSCH occasions by UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) according to indication period in Embodiment D1, at least one of following indication scheme can be adopted.

[0313] 1. The PUSCH occasion associated to a bit of the bitmap could be either a valid PUSCH occasion or a non-valid PUSCH occasion configured within the indication period.

[0314] i. The size of the bitmap can be flexible if only valid PUSCH occasions are indicated in the bitmap. The size of the bitmap corresponds to number of valid PUSCH occasions in an indication period.

[0315] ii. The size of the bitmap can be fixed if both valid and non-valid PUSCH occasions are indicated in the bitmap.

[0316] ■ The size of the bitmap corresponds to number of valid and non-valid PUSCH occasions in each indication period.

[0317] ■ The value of 1 in the bitmap can represent either the PUSCH occasion is unused or the PUSCH occasion is non-valid.

[0318] ■ The PUSCH occasion is still unused if a bit value is 0 and the bit is associated with a location of non-valid PUSCH.

[0319] Embodiment E-3: Bitmap indication scheme according to configuration in Embodiment D3.

[0320] In the case of indication of unused PUSCH occasions by UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) according to a PUSCH set with preconfigured number of PUSCH occasions in Embodiment D3, at least one of following indication scheme can be adopted.

[0321] In the set of PUSCH occasions, a PUSCH occasion associated to a bit of the bitmap is a valid PUSCH occasion. Only valid PUSCH occasions within the preconfigured set are represented in the bitmap.

[0322] The size of the bitmap is configured to be a fixed value per CG configuration.

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

[0324] Embodiment F: Bitmap indication for unused PUSCH occasions with TB repetition

[0325] Embodiment F-1: Bitmap indication scheme for unused PUSCH occasions with TB repetition

[0326] In case TB repetition is configured in multi-PUSCHs CG by gNB (e.g., one or more BSs as shown in FIG. 1) , the bitmap indication scheme of unused PUSCH occasions in Embodiment D and Embodiment E can be modified based on at least one of following schemes.

[0327] 1. Scheme 1 -Group-based Bitmap Indication: Each bit of the bitmap associated with a group of PUSCH occasions belonging to the same TB. The group of PUSCH occasions carries repetitions of the same TB. When the corresponding bit value is 1, all PUSCH occasions in the group associated with a bit of the bitmap are unused.

[0328] 2. Scheme 2-Individual PUSCH Occasion Bitmap Indication: Each bit of the bitmap associated with a PUSCH occasion, without considering whether TB repetition is configured or not.

[0329] ● UE can indicate at least one of following information to the gNB in the UCI based on the bitmap indication.

[0330] ■ Activate or deactivate repetitions for certain TB.

[0331] ■ The number of repetitions for a certain TB.

[0332] Embodiment F-2: Example of bitmap indication with TB repetition based on Scheme 1 of Embodiment F1 according to a PUSCH set with preconfigured number of PUSCH occasions in Embodiment D3

[0333] With reference to FIG. 10, according to DL / UL TDD configuration with DDDSU (D: Downlink, S: Special, U: Uplink) , the setting of multi-PUSCHs CG configuration is 2 PUSCH occasions within an UL slot (i.e., M=2) , totally 4 PUSCH occasions in the 2 UL slots (i.e., N=2) of a CG period. The repetition factor K is set to 2.

[0334] The number of the set of PUSCH occasions (refer to as PUSCH set) is configured to be 6.

[0335] Within the set of 6 PUSCH occasions, 3 TBs are transmitted. Each of the TBs is configured to be repetitively transmitted in the 2 PUSCH occasions of a UL slot. In this case, the PUSCH set includes 3 TBs. Consequently, the unused PUSCH occasions are indicated in the UCI using a 3-bit bitmap. Each bit is associated with a group of PUSCH occasions associated with a TB. The group of PUSCH occasions are used for repetitive transmissions of a TB. The Bitmap {010} indicates PUSCH occasions associated with the second TB, i.e., TB2, are unused.

[0336] Embodiment F-3: Example of bitmap indication with TB repetition based on Scheme 2 of Embodiment F1 according to a PUSCH set with a preconfigured number of PUSCH occasions in Embodiment D3

[0337] With reference to FIG. 11, according to DL / UL TDD configuration with DDDSU (D: Downlink, S: Special, U: Uplink) , the setting of multi-PUSCHs CG configuration is 2 PUSCH occasions within an UL slot (i.e., M=2) , and totally 4 PUSCH occasions in the 2 UL slots (i.e., N=2) of a CG period. The repetition factor K is set to 2.

[0338] The number of the set of PUSCH occasions (refer to as PUSCH set) is configured to be 6.

[0339] Within the set of 6 PUSCH occasions, 3 TBs are transmitted, each of the TBs is configured to be repetitively transmitted in the 2 PUSCH occasions of a UL slot. In this case, each bit associated with a PUSCH occasion, i.e., without considering repetition. Since the PUSCH set includes 6 PUSCH occasions, the unused PUSCH occasions are  indicated in the UCI using 6-bit bitmap.

[0340] In Scheme 2, the UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) can determine whether a TB is repetitively transmitted or the actual repetition factor (K) of each TB. The Bitmap {000111} indicates that the PUSCH occasions associated the first TB, i.e., TB1, is repetitively transmitted with repetition factor 2, the PUSCH occasions associated the second TB, i.e., TB2, is transmitted once in one PUSCH occasion, i.e., without repetition, and PUSCH occasions associated the third TB are unused, i.e., TB 3 is not transmitted.

[0341] Embodiment G: Transmission occasion of CG PUSCH carrying an UCI indicating unused PUSCH occasions with or without TB repetition.

[0342] UCI Transmission in CG PUSCH: For a UE (e.g., one or more UEs, such as UE 10a and UE 10b, as shown in FIG. 1) transmitting an UCI indicating unused PUSCH occasions in a CG PUSCH, the following may apply: The transmission occasion of CG PUSCH carrying the UCI is at any configured CG PUSCH occasion in which a PUSCH is transmitted.

[0343] Eligibility of PUSCH Occasions: The transmission occasion of the CG PUSCH carrying the UCI are PUSCH occasions not being declared as unused by the UE in a previously transmitted UCI.

[0344] TB Repetition Scenario: In an embodiment, if TB repetition is configured, then the UCI is transmitted in each repetition of a TB in the associated CG PUSCH occasions.

[0345] In some embodiments of the disclosure, the PUSCH occasion in which the UCI is transmitted is a PUSCH occasion not declared as unused.

[0346] Embodiment H: A procedure of configuring multiple CG PUSCH occasions within a CG by gNB and reporting unused CG PUSCH occasions by UE.

[0347] FIG. 12 shows an example of a signaling flow to demonstrate the operation roles between base station 20a (e.g., a gNB) , UE 10a, and UE B for supporting multi-PUSCHs CG with TB repetition and re-transmission of a TB.

[0348] 1. The base station 20a starts by sending CG configurations with multiple CG PUSCH occasions to UE 10a via RRC (Radio Resource Control) signaling.

[0349] 2. For Type 2 CG, the base station 20a transmits an activation DCI to UE 10a.

[0350] 3. When an uplink packet arrives at UE 10a, it determines unused CG PUSCH occasions.

[0351] 4. UE 10a then determines the HARQ ID and RV for non-unused PUSCH occasions or valid CG PUSCH occasions.

[0352] 5. UE 10a transmits to the base station 20a CG PUSCH with or without repetition along with UCI indicating unused CG PUSCH occasions.

[0353] 6. The base station 20a derives unused CG PUSCH occasions from the UCI and performs re-scheduling.

[0354] 7. The base station 20a then schedules the unused CG PUSCH resources for UE 10b.

[0355] 8. For retransmission, the base station 20a sends a re-transmission request for one or more TBs using UL grant DCI to UE 10a.

[0356] 9. UE 10a determines the HARQ ID and RV for retransmission of one or more TBs.

[0357] 10. Finally, UE 10a re-transmits PUSCH based on the UL grant.

[0358] The embodiment demonstrates how the system manages resource allocation, handles unused PUSCH occasions, and manages retransmissions in a multi-PUSCH CG environment, involving communication between the gNB and multiple UEs.

[0359] With reference to FIG. 13, the UE 100 may include a processor 11a, a memory 12a, and a transceiver 13a. The processor 11a is configured to call and run a computer program stored in the memory 12a, to cause UE 100 in  which the processor 11 is installed to execute the disclosed method, steps, and / or functions of a UE. The UE 100 is an example of the UE in the description (e.g., UE 10a or UE 10b) . The transceiver 13a may include baseband circuitry and radio frequency (RF) circuitry.

[0360] With reference to FIG. 14, 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 call and run a computer program stored in the memory 22a, to cause network node 200 in which the processor 11 is installed to execute the method, steps, and / or functions of a network node. The network node 200 is an example of CN network entity, network node, radio node, the base station, or gNB in the description. The transceiver 23a may include baseband circuitry and radio frequency (RF) circuitry.

[0361] With reference to FIG. 15, the embodiment of the disclosure also provides a chip 70 that may correspond to a UE in the embodiments of the disclosure. The chip 70 may implement a corresponding process realized by the UE in various methods of the embodiments of the disclosure. The chip 70 includes a processor 71, and the processor 71 may call and run a computer program from memory to implement the methods in the embodiments of the present application.

[0362] Optionally, the chip 70 may also include a memory 72. In particular, the processor 71 may call and run the computer program from the memory 72 to implement the methods in the embodiments of the present application.

[0363] Moreover, the memory 72 may be a separate device from the processor 71 or may be integrated into the processor 71.

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

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

[0366] With reference to FIG. 16, the embodiment of the disclosure also provides another chip 80 that may correspond to a network device (e.g., CN network entity, network node, radio node, the base station, or gNB) in the description, and the chip 80 may implement the corresponding processes implemented by the network device in the various methods of the embodiments of the 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 the present application.

[0367] Optionally, the chip 80 may further include a memory 82. In particular, the processor 81 may call and run the computer program from the memory 82 to implement the methods in the embodiments of the present application.

[0368] Wherein the memory 82 may be a separate device from the processor 81 or may be integrated into the processor 81.

[0369] Optionally, the chip 80 may also include an input interface 83. In particular, the processor 81 may control the input interface 83 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

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

[0371] The embodiment of the present disclosure is a combination of techniques / processes that may be adopted in 3GPP specification to create an end product.

[0372] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present 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 for execution by a user equipment (UE) , comprising:receiving a configuration of a number of consecutive slots within a configured grant (CG) period of a CG configuration and a configuration of a size of a bitmap for reporting one or more unused PUSCH occasions of the CG configuration; andtransmitting uplink control information (UCI) in a PUSCH occasion to convey the bitmap that indicates one or more unused PUSCH occasion, wherein the one or more unused PUSCH occasions are determined based on the received configurations of the CG configuration.2.The channel access method of claim 1, wherein the received configurations are applicable in Type 1 or Type 2 CG.3.The channel access method of claim 2, wherein at least one slot of the configured consecutive slots includes a downlink (DL) symbol.4.The channel access method of claim 2, wherein an initial slot location of the configured consecutive slots is determined based on an offset value relative to a reference SFN for Type1 CG.5.The channel access method of claim 2, wherein an initial slot location of the configured consecutive slots is determined based on an offset value relative to a slot location carrying activation downlink control information (DCI) for Type 2 CG.6.The channel access method of claim 2, wherein one or more symbol locations in a slot having a PUSCH occasion are determined based on a start and length indicator value (SLIV) value derived from radio resource control (RRC) signaling for Type 1 CG.7.The channel access method of claim 6, wherein the one or more symbol locations in the slot having a PUSCH occasion are applied to other slots within the CG period, and the one or more symbol locations of the PUSCH occasion for transmitting the UCI does not collide with a DL symbol or synchronization signal block (SSB) .8.The channel access method of claim 6, wherein a frequency location or modulation and coding scheme (MCS) of the slot having a PUSCH occasion is applied to other slots within the CG period.9.The channel access method of claim 2, wherein one or more symbol locations in a slot having a PUSCH occasion are determined based on an SLIV value derived from an activation DCI for Type 2 CG.10.The channel access method of claim 9, wherein the one or more symbol locations having a PUSCH occasion in the slot are applied to all slots within the CG period, and the one or more symbol locations of the PUSCH occasion for transmitting the UCI does not collide with a DL symbol or SSB.11.The channel access method of claim 9, wherein a frequency location or MCS of the slot having a PUSCH occasion is applied to other slots within the CG period.12.The channel access method of claim 1, wherein at least one value of the number of consecutive slots within the CG period is an integer multiple of the size of the bitmap for reporting one or more unused PUSCH occasions.13.The channel access method of claim 1, wherein the PUSCH occasion in which the UCI is transmitted is a PUSCH occasion not declared as unused.14.The channel access method of claim 1, wherein each bit of the bitmap is associated with a PUSCH occasion in a slot, and each PUSCH occasion 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 sequence of bits, each bit in the sequence is associated with a respective corresponding PUSCH occasion, wherein the bits are arranged in the sequence from  left to right in an order corresponding to a chronological order of the PUSCH occasions from earliest to latest.16.The channel access method of claim 14, wherein a first PUSCH occasion is located in a slot after a time offset relative to an end of the slot carrying the bitmap in the UCI.17.The channel access method of claim 16, wherein a 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 occasion in another CG period which is different from the CG period in which the bitmap in the UCI is conveyed.19.The channel access method of claim 14, wherein a bit value of 1 in the bitmap indicates that a corresponding PUSCH occasion of the bit value is an unused PUSCH occasion for PUSCH transmission.20.A user equipment (UE) comprising:a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the method of any of claims 1 to 19.21.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any of claims 1 to 19.22.A computer-readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any of claims 1 to 19.23.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 19.24.A computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 19.25.A channel access method for execution by a base station, comprising:transmitting a configuration of a number of consecutive slots within a configured grant (CG) period of a CG configuration and a configuration of a size of a bitmap for reporting one or more unused PUSCH occasions of the CG configuration; andreceiving uplink control information (UCI) in a PUSCH occasion;wherein the UCI conveys the bitmap that indicates one or more unused PUSCH occasion;wherein the one or more unused PUSCH occasions are determined based on the configurations of the CG configuration.26.The channel access method of claim 25, wherein the configurations are applicable in Type 1 or Type 2 CG.27.The channel access method of claim 26, wherein at least one slot of the configured consecutive slots includes a downlink (DL) symbol.28.The channel access method of claim 26, wherein an initial slot location of the configured consecutive slots is determined based on an offset value relative to a reference SFN for Type1 CG.29.The channel access method of claim 26, wherein an initial slot location of the configured consecutive slots is determined based on an offset value relative to a slot location carrying activation downlink control information (DCI) for Type 2 CG.30.The channel access method of claim 26, wherein one or more symbol locations in a slot having a PUSCH occasion are determined based on a start and length indicator value (SLIV) value derived from radio resource control (RRC) signaling in for Type 1 CG.31.The channel access method of claim 30, wherein the one or more symbol locations in the slot having a PUSCH occasion are applied to other slots within the CG period, and the one or more symbol locations of the PUSCH occasion  for the UCI does not collide with a DL symbol or synchronization signal block (SSB) .32.The channel access method of claim 30, wherein a frequency location or modulation and coding scheme (MCS) of the slot having a PUSCH occasion is applied to other slots within the CG period.33.The channel access method of claim 26, wherein one or more symbol locations in a slot having a PUSCH occasion are determined based on an SLIV value derived from an activation DCI for Type 2 CG.34.The channel access method of claim 33, wherein the one or more symbol locations having a PUSCH occasion in the slot are applied to all slots within the CG period, and the one or more symbol locations of the PUSCH occasion for the UCI does not collide with a DL symbol or SSB.35.The channel access method of claim 33, wherein a frequency location or MCS of the slot having a PUSCH occasion is applied to other slots within the CG period.36.The channel access method of claim 25, wherein at least one value of the number of consecutive slots within the CG period is an integer multiple of the size of the bitmap for reporting one or more unused PUSCH occasions.37.The channel access method of claim 25, wherein the PUSCH occasion in which the UCI is received is a PUSCH occasion not declared as unused.38.The channel access method of claim 25, wherein each bit of the bitmap is associated with a PUSCH occasion in a slot, and each PUSCH occasion 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 sequence of bits, each bit in the sequence is associated with a respective corresponding PUSCH occasion, wherein the bits are arranged in the sequence from left to right in an order corresponding to a chronological order of the PUSCH occasions from earliest to latest.40.The channel access method of claim 38, wherein a first PUSCH occasion is located in a slot after a time offset relative to an end of the slot carrying the bitmap in the UCI.41.The channel access method of claim 40, wherein a 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 occasion in another CG period which is different from the CG period in which the bitmap in the UCI is conveyed.43.The channel access method of claim 38, wherein a bit value of 1 in the bitmap indicates that a corresponding PUSCH occasion of the bit value is an unused PUSCH occasion for PUSCH transmission.44.A base station comprising:a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the method of any of claims 25 to 43.45.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any of claims 25 to 43.46.A computer-readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any of claims 25 to 43.47.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any of claims 25 to 43.48.A computer program, wherein the computer program causes a computer to execute the method of any of claims 25 to 43.

Images