System and method for multi-PUSCH configuration grant

Abstract

A transmission opportunity in a multi-PUSCH CG cycle may be identified as an unused transmission opportunity (UTO) or a used transmission opportunity. A HARQ PID for a transmission opportunity of a multi-PUSCH CG cycle may be determined prior to processing the first PUSCH. The UTO in all transmission opportunities of the multi-PUSCH CG cycle may be determined based on a CG timer associated with the HARQ PID, a state of a logical channel buffer associated with the multi-PUSCH CG, and a prioritization of additional grants. The HARQ PID may be remapped or changed to no longer be blocked by the CG timer. The overlapping transmission opportunities based on other grants may be prioritized or may not be prioritized with the multi-PUSCH CG transmission opportunities that have been identified as UTO or not overlapping with the multi-PUSCH CG transmission opportunities that have been identified as UTO. When certain conditions are met, the use state of the sending opportunity can be re-evaluated. The base station may automatically avoid decoding the multi-PUSCH CG transmission opportunity blocked by the CG timer.

Description

Background Technology

[0001] This application relates to wireless communications, including, for example, uplink communications permitted to be performed according to a multi-PUSCH configuration during 5G NR communications.

[0002] The use of wireless communication systems is growing rapidly. In recent years, wireless devices, such as smartphones and tablets, have become increasingly sophisticated. In addition to supporting telephone calls, many mobile devices (i.e., user equipment or UE) now offer access to the internet, email, text messaging, and navigation using the Global Positioning System (GPS), and are capable of operating complex applications that utilize these functionalities. Furthermore, many different wireless communication technologies and standards exist. Some examples of wireless communication standards include LTE, LTE-A (LTE-Advanced), IEEE 802.11 (WLAN or Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.15 (Ultra-Wideband, UWB), and Bluetooth. ™ The current telecommunications standard that surpasses previous standards is called the fifth-generation mobile network or fifth-generation wireless system, known as 3GPP NR (also called 5G-NR or NR-5G, meaning 5G New Radio, or simply NR). NR provides higher capacity for higher density mobile broadband users while supporting device-to-device, ultra-reliable and massive machine-type communications, as well as lower latency and lower battery consumption than the LTE standard.

[0003] One aspect of wireless communication (e.g., NR cellular wireless communication) is the handover by wireless communication devices / user equipment (UEs) between uplink and downlink communication, or between transmitting and receiving signals. Uplink communication by the device utilizes specific resources, including time and frequency resources, collectively referred to as radio resources, which are typically allocated / assigned to the UE by the serving base station. Efficient scheduling of uplink communication presents ongoing challenges, for example, for providing extended reality services. Summary of the Invention

[0004] This document presents embodiments of methods and procedures, particularly for determining unused transmission opportunities in multiple PUSCH (Multiple Physical Uplink Shared Channel) configuration grants (CGs) during wireless cellular communications, such as 3GPP New Radio (NR) communications. This document also presents embodiments of wireless communication systems, which at least include wireless communication devices or user equipment (UEs) and / or base stations communicating with each other within the wireless communication system.

[0005] Transmission opportunities within a multi-PUSCH CG cycle can be identified as unused transmission opportunities (UTOs) / invalid PUSCH transmission opportunities (ITOs) or used transmission opportunities. Two overall approaches can be considered to identify UTOs / ITOs among all transmission opportunities in a multi-PUSCH CG cycle. According to a first overall approach, the UE may first determine the Hybrid Automatic Repeat Request Process Identifier (HARQ PID) of one or more transmission opportunities in a multi-PUSCH CG, and then identify the UTOs where applicable. According to a second overall approach, the UE may first identify the UTOs of a multi-PUSCH CG (cycle) where applicable, and then determine the HARQ PID of one or more transmission opportunities within that multi-PUSCH CG (cycle). Within the scope of the first and / or second approaches, various proposals for characterizing and identifying transmission opportunities in a multi-PUSCH CG (cycle) can be considered.

[0006] Given the above, the HARQ PID for one or more transmission opportunities in a multi-PUSCH CG cycle can be determined before processing the first PUSCH of that multi-PUSCH CG cycle. The UTO / ITO in the transmission opportunities of that multi-PUSCH CG cycle can be determined based on the state of one or more CG timers associated with the HARQ PID, the state of the logical channel buffer associated with the multi-PUSCH CG, and additional permitted priority ordering. In some cases, the HARQ PID can be remapped or changed so that it is no longer blocked by the corresponding CG timer. These overlapping transmission opportunities can be prioritized based on whether they overlap with multi-PUSCH CG transmission opportunities already identified as UTO / ITO. The usage status of the transmission opportunity can be reassessed when certain conditions are met. The base station can automatically avoid decoding multi-PUSCH CG transmission opportunities blocked by CG timers.

[0007] HARQ PID and UTO determination based on CG timer In some implementations, the UE may determine the corresponding HARQ PID for the timing of one or more PUSCH transmissions in a multi-PUSCH CG cycle before processing the first PUSCH transmission in the multi-PUSCH CG cycle, and may subsequently perform UL communication based at least on the determined one or more HARQ PIDs.

[0008] The UE can assess the state of the CG timer associated with one or more corresponding HARQ PIDs among the determined corresponding HARQ PIDs, and at least based on the state of the CG timer, identify a specific PUSCH transmission timing among the one or more PUSCH transmission timings as an unused transmission timing (UTO) or an invalid PUSCH transmission timing (ITO). Assessing the state of the CG timer may include determining that a specific PUSCH transmission timing can be blocked by the CG timer running for the determined HARQ PID corresponding to the specific PUSCH transmission timing.

[0009] In some implementations, the UE may further identify UTOs and ITOs based on buffer states. This may include: determining a subset of remaining PUSCH transmission opportunities that are not identified as UTOs or ITOs among multiple PUSCH transmission opportunities to accommodate data buffered in one or more logical channels (LCHs) with resources allowed to use the subset of PUSCH transmission opportunities, and identifying the PUSCH transmission opportunities not included in the subset of remaining PUSCH transmission opportunities as UTOs or ITOs. The UE may send UTO uplink control information (UTO-UCI) to the base station, which includes information identifying UTOs and / or ITOs to the base station, and may perform UL communication without using UTOs and ITOs.

[0010] In some implementations, the process described herein can be performed by a Media Access Control (MAC) entity in the UE, whereby the MAC entity can provide information identifying the UTO and / or ITO to the Physical Layer (PHY) in the UE, so that the UE can send UTO-UCI accordingly.

[0011] UTO determination based on priority sorting In some implementations, the UE may determine that the PUSCH transmission timing of a multi-PUSCH CG cycle overlaps temporally with a second transmission timing, wherein the second transmission timing has a higher priority than the PUSCH transmission timing. The UE may then identify the PUSCH transmission timing as UTO and / or ITO, at least in response to determining that the second transmission timing should be performed. The UE may subsequently transmit the UTO-UCI identifying the UTO and / or ITO to the base station. The UE may use a MAC entity to perform these procedures, and the MAC entity may deliver the information identifying the UTO and / or ITO to the UE's PHY. The UTO-UCI may then be determined at least based on the information provided to the PHY.

[0012] Determining when to perform a second transmission may include determining that the data to be transmitted via the second transmission opportunity exists in the transmission buffer. The second transmission opportunity may be a second PUSCH transmission opportunity that is not part of a multi-PUSCH CG cycle, or it may be a Physical Uplink Control Channel (PUCCH) transmission opportunity.

[0013] In some implementations, the UE may send a UTO-UCI to the base station indicating a PUSCH transmission opportunity of multiple PUSCH CG cycles as a used transmission opportunity, and may determine that data to be transmitted via a second transmission opportunity exists in the transmission buffer, wherein the second transmission opportunity overlaps with the PUSCH transmission opportunity in time and has a higher priority than the PUSCH transmission opportunity. In response to determining that data exists in the transmission buffer, the UE may de-prioritize the PUSCH transmission opportunity accordingly, and may perform UL communication accordingly.

[0014] HARQ PID remapping In some implementations, the UE may determine whether one or more PUSCH transmission opportunities in a multi-PUSCH CG cycle can be blocked by one or more CG timers running for a HARQ PID corresponding to the one or more PUSCH transmission opportunities, wherein the HARQ PID is determined based on a default method. In response to determining that the one or more PUSCH transmission opportunities can be blocked by the one or more CG timers, the UE may switch, remap, or change the corresponding HARQ PID corresponding to at least one of the one or more PUSCH transmission opportunities to a corresponding alternative HARQ PID. The UE may perform UL communication at least based on the changed corresponding HARQ PID.

[0015] The UE may determine whether the HARQ PID corresponding to the at least one PUSCH transmission timing in the one or more PUSCH transmission timings should be changed to the corresponding alternative HARQ PID based at least on whether at least one PUSCH transmission timing in the one or more PUSCH transmission timings has been indicated as an unused transmission timing (UTO) and / or an invalid PUSCH transmission timing (ITO). In some embodiments, the UE may repeat the following operation a specified number of times N>=1: determining whether one or more HARQ PIDs can be blocked by a running CG timer. Alternatively, the UE may continue to: determining whether one or more HARQ PIDs can be blocked by a running CG timer, and changing / switching / remapping the previously determined HARQ PIDs until none of the determined corresponding HARQ PIDs associated with a PUSCH transmission timing in the one or more PUSCH transmission timings that is not identified as UTO and / or ITO are blocked by a running CG timer.

[0016] Changing / switching / remapping the corresponding HARQ PID may include using a second method different from the default method. In some implementations, the default method may include: assigning a value to a first HARQ PID, and obtaining each subsequent HARQ PID by incrementing the immediately preceding HARQ PID by a specified value Y, until all corresponding HARQ PIDs have been determined. The second method may include obtaining a corresponding alternative HARQ PID by incrementing the immediately preceding HARQ PID by a specified value Y' different from the specified value Y. The UE may indicate the specified value Y' to the base station.

[0017] Consider UTO approval priority ordering In some implementations, the UE may determine that the timing of a first PUSCH transmission corresponding to a first grant overlaps in time with the timing of a second PUSCH transmission corresponding to a second grant, and may further determine whether the second PUSCH transmission timing has been identified or indicated as UTO. The UE may not de-prioritize the first grant in response to determining that the second PUSCH transmission timing has been identified or indicated as UTO. The second grant may be a multi-PUSCH CG.

[0018] Event-triggered UTO update In some implementations, the UE may reassess the usage status of PUSCH transmission timing in multi-PUSCH CG cycles in response to any one or more of the following conditions: • A portion of the buffered data in at least one logical channel (LCH) is discarded; • All data buffered in the LCH is discarded; • The amount of discarded data in LCH meets the threshold; • The amount of remaining data in LCH after discarding data from LCH meets the threshold; • A portion of the data buffered in the LCH is multiplexed to another transmission resource; • All data buffered in the LCH is multiplexed to another transmission resource; • The amount of data in the LCH that is multiplexed to another transmission resource meets the threshold; • The amount of remaining data in the LCH meets the threshold after a portion of the data in the LCH has been multiplexed to another transmission resource; • The remaining time until the discard timer for data in the LCH expires or the delivery deadline expires meets the threshold; • Some radio resources are unavailable due to the following reasons: ○ The CG timer associated with the HARQ process of the CG PUSCH timing may be running when the CG PUSCH timing is about to occur or be processed; ○ CG PUSCH is de-prioritized because another transmission partially overlaps with it in time.

[0019] The UE can perform UL communication based on the reassessed usage status of the PUSCH transmission timing. Reassessing the usage status of the PUSCH transmission timing may include changing the usage status from "used" to "unused". The LCH can be restricted to radio resources mapped to a CG configuration of multiple PUSCH CGs.

[0020] CG timer-sensing base station operation In some implementations, the base station may receive a UTO-UCI carrying information indicating that a transmission timing is to be used by a UE. The base station may determine whether the CG timer associated with the HARQ of the transmission timing is likely to be running when the transmission timing is to be used or processed, and may decode the transmission timing at least in response to determining that the CG timer may not be running, or at least in response to determining that the CG timer may be running without decoding the transmission timing and reallocate the radio resources associated with the transmission timing to another UE.

[0021] It should be noted that the technologies described herein can be implemented in and / or used with multiple different types of devices, including but not limited to base stations, access points, cellular phones, portable media players, tablet computers, wearable devices, and various other computing devices.

[0022] The present invention is intended to provide a brief overview of some of the subjects described in this document. Therefore, it should be understood that the above features are merely illustrative and should not be construed as narrowing the scope or substance of the subjects described herein in any way. Other features, aspects, and advantages of the subjects described herein will become apparent from the following detailed description, drawings, and claims. Attached Figure Description

[0023] Figure 1 Examples of simplified wireless communication systems according to some implementation schemes are illustrated; Figure 2 An example base station communicating with an example wireless user equipment (UE) according to some implementation schemes is illustrated; Figure 3 Example block diagrams of a UE according to some implementation schemes are shown; Figure 4 Example block diagrams of base stations according to some implementation schemes are shown; Figure 5 A simplified block diagram of an example cellular communication circuit according to some implementation schemes is shown; Figure 6 An example timing diagram is shown to illustrate a packet service with a packet arrival rate of "1 / T"; Figure 7 An example timing diagram illustrating a pre-configured resource allocation with a periodicity of "T" is shown; Figure 8 An example diagram illustrating the corresponding groups of corresponding video frames belonging to a video stream is shown; Figure 9 An example diagram is shown illustrating a configuration grant (CG) with multiple PUSCH opportunities per CG cycle; Figure 10 An example timing diagram is shown illustrating the CG cycle in which the UE provides UTO-UCI to the base station; Figure 11 An example diagram is shown illustrating a transmission timing that cannot be used by the UE due to a running CG timer; Figure 12 An example diagram illustrating that higher priority grants take precedence over lower priority grants is shown; Figure 13 An example timing diagram is shown illustrating the unnecessarily de-prioritized grant (low-priority grant) of resources that overlap with the transmission timing of multi-PUSCH CGs that have already been identified as UTOs; Figure 14 An example timing diagram illustrating the transmission timing of a multi-PUSCH CG is shown, during which the target is carrying lower-priority data, and transmission timings that overlap with different higher-priority permitted transmission timings are not used; Figure 15 An example timing diagram with four transmission opportunities with multiple PUSCH CG is shown, during which the target is carrying lower priority data, and the usage status of transmission opportunities that overlap with different higher priority permitted transmission opportunities needs to be determined; Figure 16 An example flowchart for wireless communication according to some implementations is shown, in which the transmission status of PUSCH transmission timing for multiple PUSCH CG cycles is determined based at least on the CG timer during the wireless communication. Figure 17 An example flowchart for wireless communication according to some implementations is shown, in which the transmission status of the PUSCH transmission timing for multiple PUSCH CG cycles is determined at least based on the granted priority ordering during the wireless communication. Figure 18 An example flowchart for wireless communication according to some implementations is shown, in which the transmission status of PUSCH transmission timing for multiple PUSCH CG cycles is determined at least based on the granted priority ordering and the PUSCH transmission timing for multiple PUSCH CG cycles is de-prioritized. Figure 19 An example flowchart for wireless communication is shown according to some implementations, during which at least one HARQ PID associated with the timing of PUSCH transmission in multiple PUSCH CG cycles is modified. Figure 20 An example flowchart for wireless communication according to some implementations is shown, in which uplink granting is prioritized by considering the transmission status of PUSCH transmission timings over multiple PUSCH CG cycles during the wireless communication; and Figure 21 An example flowchart for wireless communication according to some implementations is shown, during which a base station may decode or not decode a PUSCH transmission timing based at least on the state of one or more CG timers associated with the PUSCH transmission timing of a multi-PUSCH CG cycle.

[0024] While the features described herein are susceptible to various modifications and alternatives, specific embodiments thereof are illustrated by way of example in the accompanying drawings and described in detail herein. However, it should be understood that the drawings and their detailed description are not intended to limit one to the specific forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the substance and scope of the subject matter as defined by the appended claims. Detailed Implementation

[0025] acronym Various acronyms are used throughout this patent application. The definitions of the most prominent acronyms that may appear throughout this patent application are as follows: • 5GMM: 5G Mobility Management • AC: Application Client • AF: Application Function • AMF: Access and Mobility Management Function • AMR: Adaptive Multirate • AP: Access Point • APN: Access Point Name • APR: Application Processor • BS: Base Station • BSF: Binding support function • BSSID: Basic Service Set Identifier • CA: Carrier Aggregation • CE: Control Element • CBG: Code Block Group • CBRS: Citizens' Broadband Radio Service • CBSD: Citizen Broadband Radio Service Equipment • CBW: Channel bandwidth • CCA: Free Channel Assessment • CMR: Change Mode Request • CORESET: Control Resource Set • CS: Circuit Switching • CSI: Channel State Information • DC: Biconnectivity • DCI: Downlink Control Information • DL: Downlink (from BS to UE) • DMRS: Demodulation Reference Signal • DN: Data Network • DNN: Data Network Name • DSDS: Dual SIM Dual Standby • DYN: Dynamic • E-UTRA: Evolved UTRA • EDCF: Enhanced Distributed Coordination Function • EN-DC: E-UTRA NR Bi-connectivity • ETSI: European Telecommunications Standards Institute • FDD: Frequency Division Duplex • FT: Frame Type • GAA: General Authorization Access • GPSI: General Public Subscription Identifier • GPRS: General Packet Radio Service • GSM: Global System for Mobile Communications • GTP: GPRS Tunneling Protocol • HARQ: Hybrid Automatic Repeat Request • HPLMN: Home Public Land Mobile Network • ICBM: Inter-cell beam management • Ich: Within the channel • IMS: Internet Protocol Multimedia Subsystem • IoT: Internet of Things • IP: Internet Protocol • ITS: Intelligent Transportation System • LAN: Local Area Network • LBT: Listen before you speak • LCID: Logical Channel ID • LCS: Location Services • LMF: Location Management Function • LPP: LTE Location Protocol • LQM: Link Quality Metric • LTE: Long Term Evolution • MAC: Media Access Controller • MCC: Country Code for Mobile • MCS: Modulation and Decoding Scheme • MNO: Mobile Network Operator • MO-LR: Location Request from Mobile Station Caller • MT-LR: Location Request for Called Mobile Station • NAT: Network Address Translation • NAS: Non-access tier • NDI: New Data Indicator • NEF: Network Exposure Function • NF: Network Functions • NG-RAN: Next Generation Radio Access Network • NID: Network Identifier • NMF: Network Identifier Management Function • NPN: Non-public (cellular) network • NR: New Radio • NRF: Network Repository Functionality • NSI: Network Slice Instance • NSSAI: Network Slice Selection Auxiliary Information • OFDM: Orthogonal Frequency Division Multiplexing • OOC: Outside the coverage area • PAL: Preferred Access Licensing Party • PBCH: Physical Broadcast Channel • PDCCH: Physical Downlink Control Channel • PDCP: Packet Data Convergence Protocol • PDN: Packet Data Network • PDSCH: Physical Downlink Shared Channel • PDU: Protocol Data Unit • PGW: PDN Gateway • PID: Process Identifier • PLMN: Public Land Mobile Network • ProSe: Proxies • PRS: Positioning Reference Signal • PSCCH: Physical Side Link Control Channel • PSFCH: Physical Side Link Feedback Channel • PSSCH: Physical Side Link Shared Channel • PSD: Power spectral density • PSS: Master Synchronization Signal • PT: Payload Type • PTRS: Phase Tracking Reference Signal • PUCCH: Physical Uplink Control Channel • PUSCH: Physical Uplink Shared Channel • QBSS: Basic Service Set for Quality of Service Enhancement • QI: Quality Indicator • RA: Registration Accepted • RAN: Radio Access Network • RAT: Radio Access Technology • RF: Radio Frequency • RLM: Radio Link Monitoring • RNTI: Temporary Identifier for Radio Networks • ROHC: Robust Head Compression • RR: Registration Request • RRC: Radio Resource Control • RRM: Radio Resource Management • RS: Reference signal • RSRP: Reference Signal Received Power • RTP: Real-time Transport Protocol • RV: Redundant Version • RX: Receive • SAS: Spectrum Allocation Server • SCS: Subcarrier Spacing • SD: Slice Descriptor • SI: System Information • SIB: System Information Block • SID: System Identifier • SIM: Subscriber Identity Module • SINR: Signal-to-Interference-plus-Noise Ratio • SGW: Service Gateway • SMF: Session Management Function • SNPN: Independent Non-Public Network • SR: Scheduling Request • SRS: Detection Reference Signal • SSB: Synchronization Signal Block • SSS: Secondary Synchronization Signal • SUPI: Subscription Permanent Identifier • TBS: Transport Block Size • TCP: Send Control Protocol • TDD: Time Division Duplex • TDRA: Time Domain Resource Allocation • TPC: Transmit Power Control • TRP: Transmitter / Receiver Point • TX: Send • UAC: Unified Access Control • UDM: Unified Data Management • UDR: User Data Repository • UE: User Equipment • UI: User Input • UL: Uplink (from UE to BS) • UMTS: Universal Mobile Telecommunications System • UPF: User-Face Functionality • URLLC: Ultra-Reliable Low-Latency Communication • URM: Universal Resource Management • URSP: UE routing strategy • USIM: User Subscriber Identity Module • UTO: Unused transmission opportunity • UTRA: Universal Mobile Telecommunications System Terrestrial Radio Access • Wi-Fi: Wireless Local Area Network (WLAN) RAT based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard • WLAN: Wireless LAN • ZP: Zero Power the term The following is a glossary of terms that may appear in this application: memory media —Any of various types of memory devices or storage devices. The term "memory medium" is intended to include mounting media, such as CD-ROMs, floppy disks, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory; magnetic media, such as hard disk drives or optical storage devices; registers, or other similar types of memory elements, etc. Memory media may also include other types of memory or combinations thereof. Furthermore, memory media may reside in a first computer system executing a program, or may reside in a different second computer system connected to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide program instructions to the first computer system for execution. The term "memory medium" may include two or more memory media that may reside in different locations on different computer systems connected via a network, for example. Memory media may store program instructions (e.g., embodied in a computer program) that can be executed by one or more processors.

[0026] carrier medium —Memory media as described above, and physical transmission media, such as buses, networks and / or other physical transmission media for transmitting signals (such as electrical signals, electromagnetic signals or digital signals).

[0027] Programmable hardware components —This includes a variety of hardware devices comprising multiple programmable functional blocks connected via programmable interconnects. Examples include FPGAs (Field-Programmable Gate Arrays), PLDs (Programmable Logic Devices), FPOAs (Field-Programmable Object Arrays), and CPLDs (Complex PLDs). Programmable functional blocks can range from fine-grained (combinational logic or lookup tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements can also be referred to as “reconfigurable logic units.”

[0028] Computer system (or computer)—Any of any type of computing or processing system, including personal computer systems (PCs), mainframe computer systems, workstations, network appliances, internet-connected appliances, personal digital assistants (PDAs), television systems, grid computing systems, or other devices or combinations thereof. Generally, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0029] User Equipment (UE) (or "UE device") —Any of various types of computer system devices that perform wireless communication. Also known as wireless communication devices, many of which can be mobile and / or portable. Examples of UE devices include mobile phones or smartphones (e.g., iPhone). ™ Based on Android ™ (phones) and tablet computers such as iPads ™ Samsung Galaxy ™ etc., gaming devices (such as Sony PlayStation) ™ Microsoft Xbox ™ etc.), portable gaming devices (e.g., Nintendo DS) ™ PlayStation Portable ™ Gameboy Advance ™ iPod ™ This includes laptops, wearable devices (e.g., smartwatches, smart glasses), PDAs, portable internet devices, music players, data storage devices or other handheld devices, unmanned aerial vehicles (e.g., drones), and drone controllers. Various other types of devices that include Wi-Fi communication capabilities or both cellular and Wi-Fi communication capabilities and / or other wireless communication capabilities (e.g., via Short Range Radio Access Technology (SRAT) such as Bluetooth). ™ (etc.) can fall into this category. Generally speaking, the term "UE" or "UE device" can be broadly defined to cover any electronic, computing and / or telecommunications device (or combination of devices) capable of wireless communication and can also be portable / mobile.

[0030] Wireless devices (or wireless communication devices)—Any type of computer system device that performs wireless communication using WLAN communication, SRAT communication, Wi-Fi communication, etc. As used herein, the term "wireless device" may refer to a UE device as defined above or a fixed device such as a fixed wireless client or a wireless base station. For example, a wireless device can be a wireless station of any type of 802.11 system, such as an access point (AP) or client site (UE), or a wireless station of any type of cellular communication system that communicates according to cellular radio access technologies (e.g., 5G NR, LTE), such as a base station or cellular phone.

[0031] Communication equipment —Any of various types of computer systems or devices that perform communication, where the communication can be wired or wireless. The communication device can be portable (or mobile), or it can be stationary or fixed in a location. A wireless device is one example of a communication device. A UE is another example of a communication device.

[0032] Base station (BS) The term “base station” has the full range of its usual meaning and includes at least a wireless communication station that is installed in a fixed location and used for communication as part of a wireless telephone system or radio system.

[0033] processor —Refers to various elements (e.g., circuits) or combinations of elements capable of performing the functions of a device (e.g., in a user equipment device or in a cellular network device). A processor may include, for example: a general-purpose processor and associated memory, portions or circuits of individual processor cores, an entire processor core or processing circuit core, an array of processing circuits or a processor array, circuits such as ASICs (Application-Specific Integrated Circuits), programmable hardware elements such as field-programmable gate arrays (FPGAs), and any combination thereof.

[0034] Channel —A medium used to transmit information from a transmitter (sender) to a receiver. It should be noted that because the characteristics of the term "channel" can vary depending on different wireless protocols, the term "channel" as used herein can be considered to be used in a standard manner consistent with the type of device to which the term is referenced. In some standards, channel width can be variable (e.g., depending on device capabilities, band conditions, etc.). For example, LTE can support scalable channel bandwidths from 1.4 MHz to 20 MHz. In contrast, WLAN channels can be 22 MHz wide, while Bluetooth channels can be 1 MHz wide. Other protocols and standards may include different definitions of channels. Furthermore, some standards may define and use multiple types of channels, such as different channels for uplink or downlink and / or different channels for different purposes such as data, control information, etc.

[0035] Band (or frequency band) The term "band" encompasses the full range of its usual meaning and includes at least a segment of spectrum (e.g., radio frequency spectrum) in which channels are used or reserved for the same purpose. Furthermore, "band" is used to refer to any interval in the frequency domain defined by lower and higher frequencies. The term can refer to radio bands or intervals of some other spectrum. Radio communication signals may occupy a frequency range carrying the signal (or the frequency range in which the signal is carried). Such a frequency range is also called the bandwidth of the signal. Therefore, bandwidth refers to the difference between the upper and lower frequencies in a continuous band. A band can represent a single communication channel, or it can be subdivided into multiple communication channels. The allocation of radio frequency ranges for different uses is a primary function of radio spectrum allocation. For example, in 5G NR, operating bands are classified into two groups. More specifically, according to 3GPP Release 15, bands are designated for different frequency ranges (FRs) and are defined as FR1 and FR2, where FR1 covers the range of 410MHz–7125MHz and FR2 covers the range of 24250MHz–52600MHz.

[0036] Wi-Fi The term "Wi-Fi" has the full range of its usual meaning and includes at least a wireless communication network or RAT that is served by and provides connectivity to the Internet through wireless LAN (WLAN) access points. Most modern Wi-Fi networks (or WLAN networks) are based on the IEEE 802.11 standard and are marketed under the name "Wi-Fi". Wi-Fi (WLAN) networks are different from cellular networks.

[0037] Automatically— This refers to an action or operation performed automatically by a computer system (e.g., software executed by the computer system) or device (e.g., circuits, programmable hardware elements, ASICs, etc.) without requiring direct user input to specify or perform the action or operation. Therefore, the term "automatically" is the opposite of an operation performed or specified manually by a user, where the user provides input to directly perform the operation. An automated procedure can be initiated by user-provided input, but the subsequent actions performed "automatically" are not specified by the user; that is, they are not performed "manually," where the user specifies each action to be performed. For example, a user filling out a form by selecting each field and providing input specifying information (e.g., by typing information, selecting a checkbox, radio selection, etc.) is considered manually filling out the form, even if the computer system can update the form in response to the user's actions. The form can be automatically filled out by a computer system (e.g., software executed on the computer system) which analyzes the fields of the form and fills it out without any user input specifying answers for the fields. As indicated above, the user can invoke the automatic filling of the form but does not participate in the actual filling of the form (e.g., the user does not manually specify answers for the fields, but they are completed automatically). This manual provides various examples of operations that can be performed automatically in response to actions taken by the user.

[0038] About —This refers to a value that is close to the correct or precise value. For example, "approximately" could mean a value within 1% to 10% of the precise (or expected) value. However, it should be noted that the actual threshold (or tolerance) can vary depending on the application. For example, in some implementations, "approximately" may mean within 0.1% of some specified or expected value, while in various other implementations, the threshold may be, for example, 2%, 3%, 5%, etc., depending on the specific application.

[0039] concurrent —This refers to parallel execution or implementation, in which tasks, processes, or programs are executed in a manner that is at least partially overlapping. For example, concurrency can be achieved using “strong” or strict parallelism, in which tasks are executed in parallel (at least partially) on corresponding computing elements; or concurrency can be achieved using “weak parallelism,” in which tasks are executed in an interleaved manner (e.g., by time multiplexing of execution threads).

[0040] Site (STA)—The term “site” in this document refers to any device that has the ability to communicate wirelessly (e.g., using the 802.11 protocol). A site can be a laptop computer, desktop PC, PDA, access point, or Wi-Fi phone, or any type of device similar to a UE. A STA can be fixed, mobile, portable, or wearable. Generally, in wireless networking terminology, the term site (STA) broadly encompasses any device with wireless communication capabilities, and the terms site (STA), wireless client (UE), and node (BS) are therefore often used interchangeably.

[0041] Configured as Various components can be described as being "configured" to perform one or more tasks. In this context, "configured" is a broad expression generally meaning "having" a "structure" that performs one or more tasks during operation. Therefore, a component can be configured to perform a task even when it is not currently performing one (e.g., a set of electrical conductors can be configured to electrically connect one module to another, even when the two modules are not connected). In some contexts, "configured" can be a broad expression generally meaning a structure that "has" a "circuit" that performs one or more tasks during operation. Therefore, a component can be configured to perform a task even when it is not currently powered on. Generally, the circuit forming the structure corresponding to "configured" can include hardware circuitry.

[0042] Send scheduling — This refers to the scheduling of transmissions (such as wireless transmissions). In some specific implementations of cellular radio communications, signal and data transmissions can be organized according to designated time units of a specific duration during a transmission. As used herein, the term "slot" has the full range of its usual meaning and at least refers to the smallest (or shortest) scheduling time unit in wireless communications. For example, in 3GPP LTE, transmissions are divided into radio frames, each with an equal (time) duration (e.g., 10 ms). Radio frames in 3GPP LTE can be further divided into a specified number (e.g., ten) subframes, each with an equal duration, which are designated as the smallest (shortest) scheduling unit, or the designated time unit for transmission. Thus, in the 3GPP LTE example, a "subframe" can be considered an example of a "slot" as defined above. Similarly, the smallest (or shortest) scheduling time unit for 5G NR (or simply NR) transmissions is called a "slot." The smallest (or shortest) scheduling time unit may also be named differently in different communication protocols.

[0043] resourceThe term "resource" has the full range of its usual meaning and can refer to both frequency and time resources used during wireless communication. As used herein, a resource element (RE) refers to a specific quantity or number of resources. For example, in the context of time resources, a resource element can be a time period of a specific length. In the context of frequency resources, a resource element can be a specific frequency bandwidth or a specific amount of frequency bandwidth centered at a specific frequency. As a concrete example, a resource element can refer to a resource unit with one symbol (reference time resource, such as a specific frequency bandwidth centered at a specific frequency) for each subcarrier (reference frequency resource). A group of resource elements (REG) has the full range of its usual meaning and refers to at least a specified number of consecutive resource elements. In some specific implementations, a group of resource elements may not include resource elements reserved for a reference signal. A control channel element (CCE) refers to a specified number of consecutive REGs. A resource block (RB) refers to a specified number of resource elements consisting of a specified number of subcarriers per specified number of symbols. Each RB may include a specified number of subcarriers. A group of resource blocks (RBG) refers to a unit comprising multiple RBs. The number of RBs within an RBG can vary depending on the system bandwidth.

[0044] Bandwidth Component (BWP) —The carrier bandwidth portion (BWP) is a contiguous set of physical resource blocks selected from a contiguous subset of common resource blocks on a given carrier with a given set of parameters. For the downlink, the UE can be configured using up to a specified number of carrier BWPs (e.g., four BWPs according to some specifications), where there is one BWP activity per carrier at a given time (according to some specifications). For the uplink, the UE can be similarly configured using up to several (e.g., four) carrier BWPs, where there is one BWP activity per carrier at a given time (according to some specifications). If the UE is configured using a supplementary uplink, the UE can be additionally configured using up to a specified number (e.g., four) carrier BWPs in the supplementary uplink, where there is one carrier BWP activity at a given time (according to some specifications).

[0045] Multi-community deployment—A primary node is defined as a node (radio access node) that provides control plane connectivity to the core network in the case of Multiple Radio Dual Connectivity (MR-DC). A primary node can be, for example, a primary eNB (3GPP LTE) or a primary gNB (3GPP NR). A secondary node is defined as a radio access node that does not have control plane connectivity to the core network and provides additional resources to the UE in the case of MR-DC. A primary cell group (MCG) is defined as a group of serving cells associated with a primary node, including a primary cell (PCell) and optionally one or more secondary cells (SCells). A secondary cell group (SCG) is defined as a group of serving cells associated with a secondary node, including a special cell, i.e., the primary cell (PSCell) of the SCG, and optionally one or more SCells. The UE can typically apply radio link monitoring to the PCell. If the UE is configured using an SCG, the UE can also apply radio link monitoring to the PSCell. Radio link monitoring is typically applied to active BWPs, and the UE does not need to monitor inactive BWPs. The PCell is used to initiate initial access, and the UE can communicate with the PCell and SCell via carrier aggregation (CA). The current modified capability means that the UE can transmit to and / or receive from multiple cells. The UE initially connects to the PCell, and once the UE is in a connected state, one or more SCells can be configured for the UE.

[0046] Core Network (CN) —The core network is defined as part of a 3GPP system that is independent of the UE's connectivity technology (e.g., radio access technology, RAT). The UE can connect to the core network via the radio access network (RAN), which can be RAT-specific.

[0047] Downlink Control Information (DCI) —In 3GPP communications, the DCI (Distributed Communication Interface) is sent to the mobile device or UE (e.g., by the serving base station in the network) and contains multiple distinct fields. Each field is used to configure a portion or aspect of the device's scheduled communications. In other words, each field in the DCI may correspond to one or more specific communication parameters that configure the corresponding aspect of the device's scheduled communications. By decoding the DCI, the UE obtains all configuration parameters or parameter values ​​based on the fields in the DCI, thereby obtaining all information about the scheduled communications, and subsequently executes the scheduled communications based on those parameters / parameter values.

[0048] Extended Reality (XR)— A broad term encompassing Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR). It is considered a next-generation computing platform designed to create virtual experiences indistinguishable from reality. Numerous XR experiences exist across a wide range of scenarios. Additional VR applications can include online gaming, virtual event participation, and educational experiences, while mobile AR use cases can include video games, mission-critical services, online shopping, spatial audio multi-party calling and conferencing, and digital collaborative design.

[0049] Transport Block Size (TBS) —In 5G NR, a Transport Block (TB) refers to the payload transmitted between the MAC (Media Access Control) layer and the PHY (Physical) layer, for example, to share data channels such as the PDSCH (Physical Downlink Shared Channel) and PUSCH (Physical Uplink Shared Channel). The Transport Block undergoes PHY layer processing at the transmitter before being mapped onto the PDSCH for transmission via the air interface. The TBS typically depends on the MCS (Modulation Decoding Scheme), the number of physical resource blocks used, etc. The modulation order and code rate can be determined by a table based on the DCI (Downlink Control Information), C-RNTI (Cell Radio Temporary Network Identifier), and MCS indexes (as configured in the 3GPP specification).

[0050] Uplink Control Information (UCI) —Includes Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), channel state information for the shared channel, and scheduling requests (SR) for uplink data transmission.

[0051] Configuration Granted (CG) —This can be considered an uplink version of semi-persistent scheduling (SPS). 5G NR defines the use of CG scheduling for uplink (UL) transmissions to eliminate the need for requesting and assigning resources for each uplink packet transmission by pre-allocating uplink resources to the UE. It is described in Release 15 of the 3GPP specification.

[0052] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". Statements describing a component as configured to perform one or more tasks are expressly intended not to invoke the interpretation of 35 U.S.C., 112(6).

[0053] Figure 1 and Figure 2 —Example Communication System Figure 1 Examples of simplified wireless communication systems according to some implementation schemes are illustrated. It should be noted that... Figure 1 The system described is merely one example of a possible system, and this implementation can be carried out in any system of various types as needed.

[0054] As shown in the figure, the example wireless communication system includes base stations 102A to 102N, collectively referred to as base station 102. Figure 1 As shown, base station 102A communicates with one or more user equipments 106A to 106N via a transmission medium. Each user equipment may be referred to herein as a “user equipment” (UE) or UE device. Therefore, user equipments 106A to 106N are referred to as UEs or UE devices, and are also collectively referred to as UE 106.

[0055] Base station 102A may be a transceiver base station (BTS) or a cell site, and may include hardware enabling wireless communication with UEs 106A to 106N. Base station 102A may also be configured to communicate with network 100 (e.g., the core network of a cellular service provider, telecommunications networks such as the Public Switched Telephone Network (PSTN) and / or the Internet, neutral hosts or various CBRS (Citizen Broadband Radio Service) deployments, and various other possibilities). Therefore, base station 102A facilitates communication between user equipment 106 and / or between user equipment 106 and network 100. Specifically, cellular base station 102A can provide UE 106 with various telecommunications capabilities such as voice, short message service (SMS), and / or data services. The communication area (or coverage area) of base station 106 may be referred to as a “cell.” It should be noted that “cell” may also refer to a logical identifier for a given wireless communication coverage area at a given frequency. Generally, any independent cellular wireless coverage area may be referred to as a “cell.” In such a case, the base station may be located at the intersection of three cells. In this uniform topology, a base station can serve three 120-degree beamwidth areas called cells. Furthermore, for carrier aggregation, small cells, relays, etc., can all represent cells. In carrier aggregation, the primary and secondary cells can serve at least partially overlapping coverage areas but serve on different corresponding frequencies. For example, a base station can serve any number of cells, and the cells served by the base station can be arranged side-by-side or not (e.g., at a remote radio head). Similarly, as used herein, with respect to a UE, sometimes, considering both the UE's uplink and downlink communications, the base station can be considered to represent the network. Therefore, a UE communicating with one or more base stations in the network can also be interpreted as a UE communicating with that network, and can further be considered as at least a part of the UE's communication on or through the network.

[0056] Base station 102 and user equipment 106 can be configured to communicate via a transmission medium using any of a variety of radio access technologies (RATs), also known as wireless communication technologies or telecommunications standards, such as LTE, LTE-A Advanced (LTE-A), LAA / LTE-U, 5G-NR (NR for short), Wi-Fi, Ultra Wideband, etc. It should be noted that if base station 102A is implemented in the context of LTE, it may alternatively be referred to as 'eNodeB' or 'eNB'. Similarly, if base station 102A is implemented in the context of 5G NR, it may alternatively be referred to as 'gNodeB' or 'gNB'. In some implementations, base station 102 (e.g., an eNB in ​​an LTE network or a gNB in ​​an NR network) may communicate with at least one UE having the capability to transmit reference signals according to the various implementations disclosed herein. Depending on the given application or specific considerations, for convenience, some of the various RATs may be functionally grouped according to the overall defined characteristics. For example, all cellular RATs can be uniformly considered as representing a first (form / type) RAT, while Wi-Fi communication can be considered as representing a second RAT. In other cases, individual cellular RATs can be considered separately as distinct RATs. For example, when distinguishing between cellular and Wi-Fi communication, "first RAT" can uniformly refer to all cellular RATs under consideration, while "second RAT" can refer to Wi-Fi. Similarly, where applicable, different forms of Wi-Fi communication (e.g., above 2.4 GHz and above 5 GHz) can be considered as corresponding to different RATs. Furthermore, cellular communication performed under a given RAT (e.g., LTE or NR) can be distinguished from each other based on the spectrum in which those communications are performed. For example, LTE or NR communication can be performed on the primary licensed spectrum as well as on secondary spectrum such as unlicensed spectrum and / or spectrum assigned to private networks. Overall, the use of various terms and expressions will always be clearly indicated in relation to the context of the various applications / implementations considered.

[0057] As shown in the figure, base station 102A can also be configured to communicate with network 100 (e.g., the core network of a cellular service provider, telecommunications networks such as the Public Switched Telephone Network (PSTN) and / or the Internet, and various other possibilities). Therefore, base station 102A can facilitate communication between user equipment 106 and / or between user equipment 106 and network 100. Specifically, cellular base station 102A can provide UE 106 with various communication capabilities, such as voice, SMS, and / or data services. UE 106 may be able to communicate using multiple wireless communication standards. For example, UE 106 can be configured to communicate according to any or all aspects of 3GPP cellular communication standards (such as LTE or NR). Base station 102A and other similar base stations (such as base stations 102B…102N) operating according to the same or different cellular communication standards can therefore be provided as one or more cell networks that can provide continuous or near-continuous overlapping services to UE 106 and similar devices over a wide geographical area via one or more cellular communication standards.

[0058] Therefore, although base station 102A can act as such Figure 1 The example illustrates the "serving cell" of UEs 106A-106N, but each UE in UE 106 may also be able to receive signals (and possibly within its communication range) from one or more other cells (possibly provided by base stations 102B-102N and / or any other base stations), which may be referred to as "neighboring cells." Such cells may also facilitate communication between user equipment 106 and / or between user equipment 106 and network 100. These cells may include "macro" cells, "micro" cells, "pecimen" cells, and / or cells providing service area sizes of any other granularity. For example, in... Figure 1 Base stations 102A-102B illustrated can be macro cells, while base station 102N can be a micro cell. Other configurations are also possible.

[0059] In some implementations, base station 102A may be a next-generation base station, such as a 5G New Radio (5G NR) base station or a “gNB”. In some implementations, the gNB may be connected to a legacy evolved packet core (EPC) network and / or to an NR core (NRC) network. Furthermore, a gNB cell may include one or more transmit and receive points (TRPs). Additionally, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

[0060] UE 106 can also be configured, or alternatively, to use WLAN, Bluetooth ™ ,Bluetooth ™Communication can be made using low power consumption, one or more Global Navigation Satellite Systems (GNSS, such as GPS or GLONASS), one and / or more mobile television broadcasting standards (e.g., ATSC-M / H or DVB-H), etc. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible. Furthermore, UE 106 may also communicate with network 100 via one or more base stations or via other devices, sites, or any electrical appliance not explicitly shown but considered part of network 100. Therefore, communication between UE 106 and the network can be interpreted as UE 106 communicating with one or more network nodes considered part of the network, and these network nodes may interact with UE 106 to communicate with UE 106, and in some cases affect at least some communication parameters and / or the use of communication resources by UE 106.

[0061] For example, as well as Figure 1 As illustrated, at least some of the UEs (e.g., UEs 106D and 106E) can represent vehicles communicating with each other and with base station 102, for example, via cellular communications such as 3GPP LTE and / or 5G-NR communications. Furthermore, UE 106F can represent a pedestrian communicating and / or interacting with the vehicles represented by UEs 106D and 106E in a similar manner. For example, in the context of vehicle-to-everything (V2X) communications (such as communications specified by certain versions of 3GPP standards), the disclosure... Figure 1 The examples illustrate various implementation schemes for vehicles communicating in a network.

[0062] Figure 2 Example user equipment 106 (e.g., one of UEs 106A to 106N) communicating with base station 122 and access point 112 according to some implementation schemes is illustrated. UE 106 may have cellular communication capabilities and non-cellular communication capabilities (e.g., Bluetooth). ™Devices such as mobile phones, handheld devices, computers, tablets, or virtually any type of wireless device (e.g., Wi-Fi, etc.) may be included. UE 106 may include a processor configured to execute program instructions stored in memory. UE 106 may perform any of the method embodiments described herein by executing such stored instructions. Alternatively or additionally, UE 106 may include programmable hardware elements, such as an FPGA (Field-Programmable Gate Array) configured to perform any of the method embodiments described herein or any portion thereof. UE 106 may be configured to communicate using any of a plurality of wireless communication protocols. For example, UE 106 may be configured to communicate using two or more of LTE, LTE-A, NR, WLAN, or GNSS. Other combinations of wireless communication standards are also possible.

[0063] UE 106 may include one or more antennas for communicating using one or more wireless communication protocols (e.g., those previously mentioned above) according to one or more RAT standards. In some embodiments, UE 106 may share one or more portions of the receive chain and / or transmit chain among multiple wireless communication standards. The shared radio components may include a single antenna, or may include multiple antennas for performing wireless communication (e.g., for MIMO). Alternatively, UE 106 may include separate transmit chains and / or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol configured to communicate using it. As another alternative, UE 106 may include one or more radio components or radio circuits shared among multiple wireless communication protocols, as well as one or more radio components uniquely used by a single wireless communication protocol. For example, UE 106 may include radio circuits for communicating using LTE and / or NR and / or other cellular wireless communication protocols, and for using Wi-Fi and Bluetooth. ™ Each component communicates via a separate radio unit. Other configurations are also possible.

[0064] Figure 3 —Block diagram of example UE Figure 3A block diagram of an example UE 106 according to some implementation schemes is illustrated. As shown, UE 106 may include a System-on-Chip (SOC) 300, which may include various elements / components for various purposes. For example, as shown, SOC 300 may include a processor 302 and display circuitry 304, the processor executing program instructions for UE 106, and the display circuitry performing graphics processing and providing display signals to a display 360. The processor 302 may also be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from the processor 302 and translate those addresses into locations in memory (e.g., memory 306, read-only memory (ROM) 350, NAND flash memory 310) and / or into other circuitry or devices, such as display circuitry 304, radio circuitry 330, connector I / F 320, and / or display 360. MMU 340 may be configured to perform memory protection and page table translation or setup. In some implementations, the MMU 340 may be included as part of the processor 302.

[0065] As shown in the figure, the SOC 300 can be coupled to various other circuits of the UE 106. For example, the UE 106 may include various types of memory (e.g., including NAND flash memory 310), connector interface 320 (e.g., for coupling to a computer system), display 360, and wireless communication circuitry (e.g., for LTE, LTE-A, NR, Bluetooth). ™ (e.g., Wi-Fi, GPS, etc.). UE device 106 may include at least one antenna (e.g., 335a) and may include multiple antennas (e.g., illustrated by antennas 335a and 335b) for performing wireless communication with a base station and / or other devices. Antennas 335a and 335b are shown by way of example, and UE device 106 may include fewer or more antennas. Generally, one or more antennas are collectively referred to as antenna 335. For example, UE device 106 may use antenna 335 to perform wireless communication via radio circuitry 330. As mentioned above, in some embodiments, the UE may be configured to use multiple wireless communication standards for wireless communication.

[0066] As further described herein, UE 106 (and / or base station 102) may include hardware and software components for implementing methods for transmitting reference signals by at least UE 106 according to the various embodiments disclosed herein. The processor 302 of UE device 106 may be configured to implement some or all of the methods described herein, for example by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, processor 302 may be configured as a programmable hardware element, such as an FPGA (Field-Programmable Gate Array) or as an ASIC (Application-Specific Integrated Circuit). Furthermore, processor 302 may be coupled to, for example, Figure 3 Other components shown and / or interoperable with these other components enable communication via a UE 106 for transmitting reference signals according to various embodiments disclosed herein. Specifically, processor 302 may be coupled to, for example, Figure 3 The processor 302 may also implement various other applications and / or interoperate with such other components to facilitate communication by the UE 106 in an attempt to optimize RAT selection.

[0067] In some implementations, the radio circuit 330 may include a separate controller dedicated to controlling communications for various corresponding RAT and / or RAT standards. For example, such as Figure 3 As shown, the radio circuit 330 may include a Wi-Fi controller 356, a cellular controller (e.g., an LTE and / or NR controller) 352, and Bluetooth. ™ Controller 354, and according to at least some embodiments, one or more of these controllers may be implemented as corresponding integrated circuits (referred to as ICs or chips), which communicate with each other and with the SOC 300 (e.g., with the processor 302). For example, Wi-Fi controller 356 may communicate with cellular controller 352 via a cell-ISM link or WCI interface, and / or Bluetooth. ™ Controller 354 can communicate with cellular controller 352 via a cell-ISM link, etc. While three separate controllers are illustrated within radio circuitry 330, other implementations may have fewer or more similar controllers for various different RAT and / or RAT standards, which can be implemented in UE device 106. For example, in Figure 5 At least one example block diagram illustrating some implementations of the cellular controller 352 is shown, and will be further described below.

[0068] Figure 4 —Block diagram of an example base station Figure 4A block diagram of an example base station 102 according to some implementation schemes is shown. Note that... Figure 4 The base station shown is merely one example of a possible base station. As illustrated, base station 102 may include a processor 404 capable of executing program instructions specific to base station 102. Processor 404 may also be coupled to a memory management unit (MMU) 440, which may be configured to receive addresses from processor 404 and translate these addresses into locations in memory (e.g., memory 460 and read-only memory (ROM) 450), or into other circuitry or devices.

[0069] Base station 102 may include at least one network port 470. (As mentioned above...) Figure 1 and Figure 2 As described herein, network port 470 may be configured to be coupled to a telephone network and provide access to multiple devices, such as UE device 106, that have access to the telephone network. Network port 470 (or an additional network port) may also be configured, or alternatively, to be coupled to a cellular network, such as the core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices, such as UE device 106. In some cases, network port 470 may be coupled to a telephone network via the core network, and / or the core network may provide the telephone network (e.g., in other UE devices served by a cellular service provider).

[0070] Base station 102 may include at least one antenna 434a, and may include multiple antennas (e.g., illustrated by antennas 434a and 434b) for performing wireless communication with mobile devices and / or other devices. Antennas 434a and 434b are shown as examples, and base station 102 may include fewer or more antennas. Generally, the one or more antennas that may include antenna 434a and / or antenna 434b are collectively referred to as antenna 434 or antenna 434. Antenna 434 may be configured to function as a wireless transceiver and may also be configured to communicate with UE device 106 via radio circuit 430. Antenna 434 communicates with radio component 430 via communication link 432. Communication link 432 may be a receive link, a transmit link, or both. Radio circuit 430 may be designed to communicate via various wireless telecommunication standards, including but not limited to LTE, LTE-A, 5G-NR (NR), etc. The processor 404 of base station 102 may be configured to implement some or all of the methods described herein, for example by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, processor 404 may be configured as a programmable hardware element such as a FPGA (Field-Programmable Gate Array) or as an ASIC (Application-Specific Integrated Circuit) or a combination thereof. In the case of certain RATs (e.g., Wi-Fi), base station 102 may be designed as an access point (AP), in which case network port 470 may be implemented to provide access to a wide area network and / or a local area network, for example, the network port may include at least one Ethernet port, and radio component 430 may be designed to communicate according to the Wi-Fi standard.

[0071] Figure 5 —Example Cellular Communication Circuit Figure 5 A simplified block diagram of an example cellular controller 352 according to some implementation schemes is shown. Note that... Figure 5 The block diagram of the cellular communication circuit is only one example of possible cellular communication circuits; other circuits (such as circuits that include or are coupled to enough antennas for different RATs to perform uplink activities using separate antennas, or circuits that include or are coupled to fewer antennas, such as circuits that can be shared among multiple RATs) are also possible. According to some embodiments, cellular communication circuit 352 may be included in a communication device such as the communication device 106 described above. As noted above, among other devices, communication device 106 may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop computer, notebook computer, or portable computing device), a tablet computer, and / or a combination of these devices.

[0072] Cellular communication circuitry 352 may be coupled (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 335a to 335b and 336 as shown in the figure. In some embodiments, cellular communication circuitry 352 may include dedicated receive chains for multiple RATs (including and / or coupled (e.g., communicatively; directly or indirectly) to dedicated processors and / or radio components) (e.g., a first receive chain for LTE and a second receive chain for 5G NR). For example, as Figure 5 As shown, the cellular communication circuit 352 may include a first modem 510 and a second modem 520. The first modem 510 may be configured for communication according to a first RAT (e.g., such as LTE or LTE-A), and the second modem 520 may be configured for communication according to a second RAT (e.g., such as 5G NR).

[0073] As shown, the first modem 510 may include one or more processors 512 and a memory 516 communicating with the processors 512. The modem 510 may communicate with a radio frequency (RF) front-end 530. The RF front-end 530 may include circuitry for transmitting and receiving radio signals. For example, the RF front-end 530 may include a receiver circuitry (RX) 532 and a transmitter circuitry (TX) 534. In some embodiments, the receiver circuitry 532 may communicate with a downlink (DL) front-end 550, which may include circuitry for receiving radio signals via an antenna 335a.

[0074] Similarly, the second modem 520 may include one or more processors 522 and a memory 526 communicating with the processors 522. The modem 520 may communicate with an RF front-end 540. The RF front-end 540 may include circuitry for transmitting and receiving radio signals. For example, the RF front-end 540 may include receiving circuitry 542 and transmitting circuitry 544. In some embodiments, the receiving circuitry 542 may communicate with a DL front-end 560, which may include circuitry for receiving radio signals via an antenna 335b.

[0075] In some implementations, switch 570 may couple transmitting circuitry 534 to uplink (UL) front-end 572. Additionally, switch 570 may couple transmitting circuitry 544 to UL front-end 572. UL front-end 572 may include circuitry for transmitting radio signals via antenna 336. Therefore, when cellular communication circuitry 352 receives an instruction to transmit according to a first RAT (e.g., supported by a first modem 510), switch 570 may be switched to a first state allowing the first modem 510 to transmit signals according to the first RAT (e.g., via a transmission chain including transmitting circuitry 534 and UL front-end 572). Similarly, when cellular communication circuitry 352 receives an instruction to transmit according to a second RAT (e.g., supported by a second modem 520), switch 570 may be switched to a second state allowing the second modem 520 to transmit signals according to the second RAT (e.g., via a transmission chain including transmitting circuitry 544 and UL front-end 572).

[0076] As described herein, the first modem 510 and / or the second modem 520 may include hardware and software components for implementing any of the various features and techniques described herein. For example, processors 512, 522 may be configured to implement some or all of the features described herein by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable storage medium). Alternatively (or in addition), processors 512, 522 may be configured as programmable hardware elements (such as FPGAs (Field-Programmable Gate Arrays)) or as ASICs (Application-Specific Integrated Circuits). Alternatively (or in addition), processors 512, 522 may be configured to implement some or all of the features described herein by combining one or more of other components 530, 532, 534, 540, 542, 544, 550, 570, 572, 335, and 336.

[0077] Furthermore, as described herein, processors 512, 522 may include one or more components. Therefore, processors 512, 522 may include one or more integrated circuits (ICs) configured to perform the functions of processors 512, 522. Additionally, each integrated circuit may include circuitry (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of processors 512, 522.

[0078] In some embodiments, cellular communication circuitry 352 may include only one transmit / receive chain. For example, cellular communication circuitry 352 may not include modem 520, RF front-end 540, DL front-end 560, and / or antenna 335b. As another example, cellular communication circuitry 352 may not include modem 510, RF front-end 530, DL front-end 550, and / or antenna 335a. In some embodiments, cellular communication circuitry 352 may also not include switch 570, and RF front-end 530 or RF front-end 540 may communicate with UL front-end 572 (e.g., direct communication).

[0079] XR services with a periodic business model As previously mentioned, wireless communication (e.g., NR cellular wireless communication) includes both uplink (UL) and downlink (DL) communication performed by wireless communication devices / user equipment (UE). In some cases, UL and DL communication may be part of data transmission (TX) and reception (RX) for extended reality (XR) services. For both downlink and uplink XR services, the (data) payload is typically periodic. For example, in the case of video transmission, the video stream may have various frame rates, such as 60 frames per second (fps), 90 fps, or 120 fps. Figure 6 The diagram illustrates an example of a periodic service with a packet arrival rate of 1 / T.

[0080] The Radio Access Network (RAN) obtains auxiliary information related to various characteristics of XR services and uses this information to perform (e.g., to the UEs it serves) appropriate resource allocation / assignment for XR services. Due to the periodic nature of XR (related) transmissions, Expected Configuration Grant (CG) provides a critical resource allocation method for UL XR services. CG essentially allocates / assigns pre-configured periodic UL radio resources, such as time and frequency resources, allowing the UE to anticipate in advance (within the time-frequency resource grid) where Physical Uplink Shared Channel (PUSCH) resources are available for UL without requiring dynamic signaling to identify those resource allocations. Figure 7 The example shown is a pre-configured resource allocation that can be created via CG with periodicity = T.

[0081] Jitter and varying payload of XR services According to certain sections of the 3GPP technical report, periodic XR services can be associated with random jitter, where the actual packet arrival time may deviate from the nominal timing (based on service periodicity). Packet size may also vary over time. This is in... Figure 8The diagram illustrates an example depicting the corresponding IP packets belonging to the corresponding video frame of a video stream. For example, scheduling can be configured via CG enhancements to accommodate these service characteristics occurring during UL transmission. In the case of a CG with a fixed Transport Block Size (TBS), the following issues can be considered given the varying packet sizes: • When the packet size is larger than the TBS of the CG timing, it cannot be accommodated within a single CG cycle. This increases latency; and • This is not resource efficient when the packet size is smaller than the TBS at the time of CG. The base station may have already allocated resources to other UEs.

[0082] CG with multiple PUSCH (multiple PUSCH) timing To accommodate periodic business with varying group sizes, the following objectives have been identified: • Multiple CG PUSCH sending opportunities within a single CG PUSCH configuration period; and • The UE provides dynamic indication of unused CG PUSCH timings via uplink control information (UCI).

[0083] CG with multiple push timings is typically used for businesses with varying packet sizes, such as audio / video. Figure 9 The example shown is a CG with multiple PUSCH opportunities per cycle.

[0084] Indication of unused transmission opportunities Due to the varying packet sizes of periodic XR services, UEs do not necessarily need to use every individual PUSCH opportunity within a CG period. As currently established, UEs can transmit an indication to their serving base station (e.g., to their serving gNB) to notify the base station which PUSCH opportunities (or which PUSCHs within a CG period) are unused, and the base station can then allocate resources associated with those unused PUSCHs (or PUSCH opportunities) to other UEs. This indication is referred to as the "Unused Transmission Opportunity UCI" or UTO-UCI, and it is a new type of UCI (similar to CG-UCI) that can be reused in PUSCHs. Under current protocols, it is anticipated that the UTO-UCI will be included in every transmitted CG PUSCH. In some implementations, the UTO-UCI may be provided as a bitmap, where bits correspond to PUSCH transmission opportunities of a certain duration or range, and the bit indicates whether a PUSCH transmission opportunity is used or unused. Generally speaking, since the size of the data buffer is visible to the Media Access Control (MAC) layer / control, the information to be transmitted by UTO-UCI can be generated by the MAC layer / provided to the Physical Layer (PHY) for signal transmission. Figure 10An example timing diagram is provided for the CG cycle in which the UE provides UTO-UCI to the base station.

[0085] HARQ process ID determined The determination of the HARQ process ID (PID) for each transmission timing in a multi-PUSCH CG is not yet fully standardized. However, several working assumptions exist regarding this process.

[0086] When the CG retransmission timer is not configured, the HARQ PID of the first configured / valid PUSCH within a given period is determined based on the legacy CG procedure. That is, the HARQ PID of the first PUSCH is determined by the following formula: HARQ process ID=[floor(X [(CURRENT_symbol – offset1) / periodicity) + offset2] modulo nrofHARQ-Processes .

[0087] Details of the parameters used in this formula are provided in the 3GPP specification TS.38.321. The HARQ process ID of the remaining configured / active CG PUSCH in the CG cycle is determined by incrementing the HARQ process ID of the previous PUSCH in the CG cycle by a specific value Y. In some implementations, the value of Y may be set to 1.

[0088] Configure grant timer As noted above, currently, each CG PUSCH is associated with a HARQ PID, which can be derived from a specified formula. In the case of a CG with multiple PUSCH timings (as described above), the CG configuration may include multiple CG PUSCHs (or PUSCH timings) with different HARQ PIDs per cycle. When a PUSCH is transmitted, a CG timer is started (e.g., the CG timing is started on the first OFDM symbol of the PUSCH). The CG timer is associated with the HARQ process for a given PUSCH. A PUSCH may be associated with a CG or a Dynamic Grant (DG). It should be noted that in this context, the terms PUSCH, PUSCH timing, PUSCH transmission timing, and the opportunity for UL communication or UL communication performed via a given PUSCH (e.g., using radio resources associated with a given PUSCH) are used interchangeably. Furthermore, more broadly, radio resources may also be associated with a given grant (e.g., with a given CG). In other words, the collective radio resources used by all PUSCH timings of a CG are referred to as associated with or used by the CG. When a CG timer associated with a HARQ PID (or a HARQ process with a given PID) is running, the UE can avoid overwriting the MAC PDU stored in the HARQ buffer (by retransmission) by not using the CG resources associated with the same HARQ process (or HARQ PID), since the stored MAC PDU may still be needed for HARQ retransmission. Figure 11 Example timing diagrams are provided illustrating the PUSCH timings associated with two different HARQ IDs. For example... Figure 11 As shown, when the CG timer associated with HARQ PID=0 is running, the PUSCH resource associated with HARQ PID=0 may not be used by the UE.

[0089] UE Intra-UE Priority Ranking In 5G NR, the UE can perform "intra-UE priority ordering" functionality. That is, if a UE has multiple UL grants whose PUSCH resources overlap at least partially in time—for example, UL communications configured by the corresponding UL grants overlap in time—the UE can select the UL grant with the highest priority. Grant priority can be determined based on the priority of the logical channel (LCH) to which the grant is mapped or will be mapped. Similarly, intra-UE priority ordering can be performed for UL (data) grants and physical uplink control channels (PUCCHs). For example, if a PUCCH is used to transmit a scheduling request (SR) triggered by an LCH with a higher priority than the data to be carried by the uplink grant, the UE can prioritize that PUCCH and may not perform de-prioritized PUSCH transmissions. Figure 12As illustrated, a transmission timing associated with a high-priority grant may take precedence over a transmission timing associated with a low-priority grant, which may result in a transmission timing associated with a low-priority or even lower-priority grant not being performed (e.g., because it is not processed).

[0090] Issues related to CG scheduling and associated communication Various issues regarding CG scheduling and related communications discussed above can be considered. These issues include: 1. When should the UE determine the HARQ process ID for each transmission opportunity in a multi-PUSCH CG cycle? 2. When some transmission opportunities are not used due to the running CG timer, how should the UE (e.g., via the MAC entity) determine the UTO by taking into account the CG timer state? 3. If intra-UE priority ordering is configured (e.g., logical channel-based priority ordering or LCH-based priority ordering), then some transmission opportunities will not be used when their resources overlap with other permissions that can carry data with higher priority. In these cases, how should the UE determine the UTO (Usage Timeout) by considering intra-UE priority ordering (e.g., via the MAC entity)? 4. How can resource efficiency be improved when multiple PUSCH CG memory sends data at a time when its default HARQ process is blocked by the running CG timer? 5. When configuring a UE (e.g., a MAC entity within the UE) using LCH-based priority ordering, a given PUSCH can still be associated with (higher) priority grants even after it has been declared "unused," for example, if some high-priority data that could be mapped to a given PUSCH arrives after the UE has sent a UTO-UCI. Therefore, any uplink grants whose resources overlap temporally with the duration of that "unused" PUSCH may become unnecessarily de-prioritized. This raises the question of how to avoid unnecessarily de-prioritizing uplink grants whose PUSCHs overlap with uplink grants whose transmission timing has already been indicated as "unused."

[0091] Figure 13 Problem 5 is illustrated in the example. According to the current 3GPP specification, grant priority ordering does not consider grants that have been identified (or indicated) as "unused". Therefore, some grants may be unnecessarily de-prioritized.

[0092] First suggestion: Timing for HARQ process ID determination For timing of HARQ PID determination for multi-PUSCH CG, two options can be considered: • First option: The UE can determine the HARQ PID for each transmission timing immediately before processing the corresponding PUSCH; and • Second option: Before processing the first PUSCH of a multi-PUSCH CG cycle, the UE can (e.g., all at once) determine the HARQ PID for all transmission opportunities in the multi-PUSCH CG cycle.

[0093] The first option is more in line with the current MAC specification (i.e., the 3GPP specification) modeling. However, this can pose a problem for the UE when deriving / determining the UTO for a multi-PUSCH CG. Under the current protocol, the UE is expected to transmit the UTO-UCI in each PUSCH, meaning the UE is also expected to determine the UTO for a given multi-PUSCH cycle before the first PUSCH (timing). Therefore, the UE is expected to first identify which PUSCH might be blocked by a running CG timer (e.g., prevented from use). However, to achieve this, the UE is expected to know (or identify) the HARQ PID for each PUSCH in advance. If the UE has not identified the corresponding HARQ PID associated with each PUSCH or PUSCH timing when attempting to identify the UTO, the UE may overlook transmission timings blocked by running CG timers and thus may incorrectly identify the UTO. For example, a scenario could arise where the UE has indicated it will use a specific PUSCH, but it cannot use that specific PUSCH because the CG timer associated with the HARQ process (or HARQ PID) corresponding to (or associated with) that specific PUSCH is running.

[0094] At least for the reasons stated above, the second option is preferred in at least some implementations. Therefore, in some implementations, for a multi-PUSCH CG (cycle), the UE can determine the corresponding HARQ PID for all transmission opportunities before processing the first PUSCH of the multi-PUSCH CG cycle. For example, all HARQ PIDs can be determined at once.

[0095] Second proposal: UTO determination method based on CG timer A procedure for determining or identifying a UTO can be executed. In some implementations, this procedure can be performed by the MAC in the UE. The information identifying the UTO can then be delivered to the physical layer (PHY) for UTO-UCI signaling by the UE. In some implementations, the procedure may include: • Step 1: Before processing the first PUSCH of a given multi-PUSCH CG cycle, determine the corresponding HARQ PID for all transmission opportunities of a given multi-PUSCH CG cycle; • Step 2: Based on the HARQ PID determined in Step 1, identify the transmission opportunities that can be blocked by the running CG timer (if any). The UE may treat these identified transmission opportunities as UTO or invalid CG PUSCH opportunities (or invalid PUSCH transmission opportunities), and treat the remaining transmission opportunities as available transmission opportunities; • Step 3: Determine how many remaining available transmission times are needed to accommodate all the data buffered in the LCH / LCG that is allowed to use the given multi-PUSCH CG (or the resource corresponding to the given multi-PUSCH CG); ○ If all remaining transmission opportunities are needed to accommodate all data buffered in the allowed LCH / LCG, then only the transmission opportunities identified in step 2 are considered UTO or invalid PUSCH transmission opportunities. ○ If only a subset of the remaining transmission opportunities is needed to accommodate all data buffered in the allowed (or corresponding) LCH / LCG, any transmission opportunity not included in the subset may also be considered a UTO or invalid PUSCH transmission opportunity; • Step 4: Deliver information identifying the timing of UTO or invalid PUSCH transmission (as identified in Steps 2 and 3) to the PHY for the UE to perform UTO-UCI signal transmission.

[0096] Based at least on the foregoing, in some implementations, a method for identifying or determining unused transmission opportunities (or associated with) multiple PUSCH CG (cycles) may be performed, for example, by a MAC entity. This method may include: determining a corresponding HARQ PID for one or more transmission opportunities of the multiple PUSCH CG, and determining which of the one or more transmission opportunities (or PUSCH transmission opportunities) have a corresponding HARQ PID associated with a CG timer that may be running when the transmission opportunity is to occur or be processed. In other words, the state of the CG timer may be evaluated for multiple transmission opportunities based on the corresponding HARQ PIDs of the multiple transmission opportunities. The method may also include: identifying a set of UTOs (if any) in the transmission opportunities of the multiple PUSCH CG based on the state of the CG timer, and in some implementations, further based on the state of the buffer. If the CG timer associated with the HARQ PID of a given transmission opportunity for multiple PUSCH CG (cycles) is likely running when the transmission opportunity is about to occur or be processed, the given transmission opportunity can be identified / indicated as a UTO, regardless of whether the UE intends to use the transmission opportunity to send data from the UE's transmission buffer. In some implementations, in this scenario, the given transmission opportunity is always identified / indicated as a UTO. The method may also include delivering information identifying the set of UTOs to the PHY for the UE to transmit in the UTO-UCI.

[0097] Third proposal: UTO determination method based on priority ordering When determining UTO based on priority ordering, two different scenarios can be considered. In the first scenario, the UE may have determined or been instructed that some transmission opportunities will not occur due to intra-UE priority ordering. For example, some high-priority data may have already arrived in the buffer and may be waiting for high-priority permission. In the second scenario, the UE may have determined or been instructed that some transmission opportunities may potentially be de-prioritized, but the de-prioritization is uncertain (e.g., high-priority data may not have yet arrived in the buffer).

[0098] In the first scenario, the UE can also determine the UTO for a given multi-PUSCH CG by considering whether the transmission timing is de-prioritized relative to another transmission (e.g., a higher-priority PUSCH or scheduling request PUCCH, SR-PUCCH). This is in Figure 14 The diagram illustrates an example timing sequence with four transmission times (1402, 1404, 1406, 1408) for multiple PUSCH CGs, during which the target is carrying lower-priority data. Figure 14As illustrated, the high-priority UL-granted resource 1410 overlaps with the transmission timings 1406 and 1408 of the multi-PUSCH CG. Therefore, transmission timings 1406 and 1408 are identified / marked as unused UTOs or invalid CG PUSCH timings because they conflict with UL-granted 1410.

[0099] Based at least on the foregoing, in some implementations, a method for identifying or determining unused transmission opportunities (or associated with) multiple PUSCH CGs (cycles) may be performed, for example, by a MAC entity, and the method may include: determining that one or more radio resources to be used by a PUSCH transmission opportunity of a multiple PUSCH CG overlap temporally with one or more radio resources to be used for a higher priority transmission relative to the PUSCH transmission opportunity; assessing whether to perform a higher priority transmission; identifying a set of UTOs or invalid CG PUSCH opportunities (if any) within the multiple PUSCH CG transmission opportunity based on the assessment and further based on buffer states; and delivering information identifying the set of UTOs and invalid CG PUSCH opportunities to the PHY. This information may be transmitted by the UE to the base station, for example, in the UTO-UCI.

[0100] In the second scenario, the UE can still indicate (e.g., via UTO-UCI) the transmission timing of a given PUSCH that uses multiple PUSCH CGs (e.g., they are not identified as UTOs), and when high-priority data (if any) associated with the given PUSCH transmission timing arrives, two different actions can be taken: • The UE can de-prioritize a given PUSCH transmission timing; or • The UE may not prioritize the timing of a given PUSCH transmission because the UE has already indicated that they should be used.

[0101] In some implementations, if a given PUSCH transmission timing is to be de-prioritized, the UE can update the UTO by changing the given PUSCH transmission timing from an "used" to an "unused" transmission timing and transmitting a UTO-UCI to indicate the update. This is in Figure 15 The diagram illustrates an example timing sequence for four transmission times (1502, 1504, 1506, 1508) with multiple PUSCH CGs, during which the target is carrying lower-priority data. Figure 15As illustrated, the high-priority UL grants resources to 1510 that overlap with the transmission timings 1506 and 1508 of the multi-PUSCH CG. Transmission timings 1506 and 1508 may or may not be de-prioritized, and therefore may or may not be considered as UTOs (or invalid CG PUSCH timings). For example, the UE may determine whether to de-prioritize transmission timings 1506 and 1508, and may de-prioritize or not de-prioritize transmission timings 1506 and 1508 based on that determination.

[0102] Fourth proposal: Remapping of HARQ PIDs By default, the HARQ PID for multi-PUSCH CGs can be exported based on the following rules: • When the CG (retransmission) timer is not configured, the HARQ PID of the first configured / active PUSCH within a given period can be determined based on the legacy CG procedure. For example, the HARQ PID of the first PUSCH can be determined by the following formula: HARQ process ID = [floor(X) (CURRENT_symbol – offset1) / periodic) + offset2]modulo nrofHARQ-Processes • The HARQ PID of any remaining configured / valid CG PUSCH in a CG cycle that does not yet correspond to a HARQ PID can be determined by incrementing the HARQ PID of the previous PUSCH in the CG cycle by a specified value Y. In some implementations, the value of Y can be 1. For example, for a multi-PUSCH CG cycle with four (4) PUSCH transmission opportunities, if the HARQ PID of the first PUSCH transmission opportunity is determined to be 3, the HARQ PIDs of the remaining PUSCHs can be defined as 4, 5, and 6 respectively (incrementing by 1 from the HARQ PID of the previous PUSCH transmission opportunity).

[0103] Based on the first proposal discussed above, the UE can identify some transmission opportunities within a multi-PUSCH CG that are unavailable due to running CG timers. According to the fourth proposal, if one or more transmission opportunities within a multi-PUSCH CG are unavailable due to running CG timers, the UE can operate to change the rules / methods used to derive the HARQ PID for at least one PUSCH (or associated with at least one PUSCH), allowing the UE to still utilize these resources for improved efficiency. Therefore, the UE can perform the following methods: • Step 1: The UE determines the HARQ PID for the timing of one or more PUSCH transmissions in a multi-PUSCH CG cycle based on a default method or rule (e.g., according to the first proposal disclosed above); • Step 2: For a PUSCH transmission timing that the UE intends to use in a multi-PUSCH CG cycle, the UE determines whether one or more of the determined HARQ PIDs are unusable due to a running CG timer (e.g., a running CG timer associated with the one or more determined HARQ PIDs). If it is determined that one or more of the determined HARQ PIDs are unusable, the UE may switch, change, or remap the HARQ PID of at least one PUSCH transmission timing in the multi-PUSCH CG cycle based on an alternative method or rule (which may differ from the default method / rule used to initially determine the HARQ PID). For example, if a HARQ PID determined based on the default method (e.g., Y=1) is unusable, the UE may change the previously determined HARQ PID by using an alternative method (e.g., changing the value of Y, such as setting Y=2). The UE may continue to change the value of Y until a HARQ PID is determined to be available. If it is determined that there is no unavailable HARQ PID, the UE proceeds to step 3; • Step 3: The UE determines the information identifying the UTO based on the data buffer state and further based on the HARQPID determined in Step 1 or Step 2 (e.g., the UE may thus determine the information identifying the UTO based on the second proposal disclosed above). It should be noted that the UE may not switch, change, or remap the HARQ PID associated with a PUSCH transmission timing that the UE does not intend to use / process during a multi-PUSCH CG cycle (as described above in Step 2). For example, the UE may have already indicated (or decided to indicate) the PUSCH as a UTO.

[0104] In some implementations, the UE may repeat step 2 up to N>=1 times, and when N is reached, proceed to step 3 regardless of the derived HARQ PID result. In some implementations, the UE may repeat step 2 until none of the determined HARQ PIDs is blocked by the running CG timer, or until the determined HARQ PID associated with the timing of the PUSCH transmission to be used is not blocked by the running CG timer. In some implementations, the difference between the default method / rule and the alternative method / rule may be, for example, the value of Y (as disclosed above). In some implementations, when an alternative method / rule is applied to change, remap, or switch a HARQ PID previously determined via the default method / rule, the UE may directly select an alternative HARQ PID that is closest to (higher or lower than) the previously determined HARQ PID and is not blocked by the running CG timer. In some implementations, the UE may indicate to its serving base station (e.g., to the serving gNB) which method / rule the UE has used; for example, the UE may indicate the value of Y. The UE can also indicate the final HARQ PID result of one or more multi-PUSCH CGs to the serving base station. In some implementations, the UE can apply such behavior to a specific CG configuration.

[0105] Fifth proposal: Consider prioritizing UTO approvals. Currently, when configuring LCH-based priority sorting, the UL-granted priority is determined by the highest priority among the logical channel (LCH) priorities, based on mapping constraints. This logical channel (LCH) is either multiplexed into a MAC PDU (e.g., the MAC PDU to be transmitted is already stored in a HARQ buffer) or has available data that can be multiplexed into a MAC PDU (e.g., the MAC PDU to be transmitted is not yet stored in a HARQ buffer). UL-granted priorities where no logical channel data is multiplexed into a MAC PDU or can be multiplexed into a MAC PDU are lower than the UL-granted priorities of any logical channel data being multiplexed into a MAC PDU or can be multiplexed into a MAC PDU, or the priority of the logical channel that triggered the SR.

[0106] Therefore, if data reusable to the buffer arrives after the UTO-UCI has been transmitted, a transmission opportunity that has been marked as "unused" can still be considered high priority. That is, due to the availability of such data, the priority of the grant can still take into account LCH priority, even if the UE does not plan to use the transmission opportunity as part of a multi-PUSCHCG (because it has been identified as a UTO). It is worth noting that a UE may not be allowed to use a PUSCH that has been marked as a UTO, even if the UE has available data in the buffer that can be transmitted on such a PUSCH. Under the current specification, UL grants whose resources overlap with that UTO may not be considered "prioritized UL grants" because the priority ordering rules do not consider the state as a UTO. It should also be noted that, due to considerations such as those described above, transmission opportunities that may have once been identified as UTOs (or radio resources associated with these UTOs) may still be available for transmission or be re-evaluated as not effectively becoming UTOs.

[0107] The above considerations are expressed by the following example fragment from the current 3GPP specification (TS 38.321), where the most relevant parts are indicated in bold: 1> If the uplink grant is received in a random access response (i.e., in a MAC RAR or fallback RAR), or addressed to a temporary C-RNTI, or determined as specified in Clause 5.1.2a for transmission of the MSGA payload: 2> Then the uplink grant is considered a prioritized uplink grant; 1> Otherwise, if the uplink is allowed to address to a CS-RNTI or C-RNTI with NDI = 1: 2> If in its Priority is higher than the priority granted by the uplink. There are no uplink-permitted overlapping PUSCH durations in the same BWP that have not yet been de-prioritized, and through simultaneousPUCCH-PUSCH The configuration does not allow simultaneous transmission of SR and uplink; and 2> If there are no PUCCH resources overlapping with SR transmissions that have not yet been de-prioritized, and the logical channel that triggered the SR has a higher priority than the uplink-granted priority: 3> Then the uplink grant is considered a prioritized uplink grant; 3> Treat other overlapping uplink grants (if any) as de-prioritized uplink grants; 3> Treat other overlapping SR transmissions (if any) as de-prioritized SR transmissions.

[0108] To address the issues described above, the MAC specification can be updated to allow the UE to consider whether an overlapping PUSCH is a transmission timing that has been declared "unused" (e.g., it has been identified or determined to be a UTO) when determining whether a UL grant should be considered a prioritized UL grant. For example, Part 4 (Second 2>) of the specification provided above is modified as follows, where the modifications are indicated in bold: 2> If there is no uplink-granted overlapping PUSCH duration in the same BWP whose priority is higher than the uplink-granted priority and which has not yet been de-prioritized and has not yet been indicated as an unused transmission opportunity, and through simultaneousPUCCH-PUSCH The configuration does not allow simultaneous transmission of SR and uplink; and Alternatively, rules can be defined in the MAC specification such that transmissions identified as UTOs are directly or automatically treated as de-prioritized UL grants. Therefore, when determining the priority of UL grants, radio resources overlapping with UTOs can be disregarded.

[0109] Based at least on the foregoing, in some implementations, the method for identifying or determining priority grants may be performed, for example, by a MAC entity, and the method may include: assessing whether the PUSCH duration of a first grant overlaps with the PUSCH duration of a second grant, determining whether the PUSCH duration of the second grant corresponds to a transmission timing that has been identified as a UTO, and determining whether the first grant is considered a priority grant based at least in part on the determination that the PUSCH duration of the second grant corresponds to a transmission timing that was previously identified as a UTO.

[0110] Sixth Proposal: Event-Triggered UTO Update Under the current protocol, the UE can utilize the following restrictions to update UTO information (more generally, specify the timing of transmission as used or not used): • CG PUSCH moments that were previously indicated as “unused” may later not be indicated as “not unused” (or “used”). • CG PUSCH moments that were previously indicated as “not unused” (or “used”) may later be indicated as “unused”.

[0111] In other words, if the CG PUSCH timing or transmission timing was previously specified as "used", the specification of the CG PUSCH timing or transmission timing can be changed to "unused", but the reverse is not true.

[0112] One issue is when the transmission timing designation can be reassessed. In some implementations, the determination of the use / unuse status of the transmission timing can be performed by the MAC entity. In some implementations, the UE can reassess and / or update (if necessary) the UTO designation when certain conditions are met and / or certain events occur. For example, in some implementations, a reassessment of the UTO designation can be triggered when at least one of the following conditions is met: • A portion of the buffered data in at least one logical channel (LCH) is discarded; • All data buffered in at least one LCH is discarded; • The amount (or size) of discarded data in at least one LCH meets the threshold; • After discarding data from the LCH, the amount (or size) of remaining data in at least one LCH meets the threshold; • At least a portion of the data buffered in at least one LCH is multiplexed to another transmission resource; • All data buffered in at least one LCH is multiplexed to another transmit resource; • The amount (or size) of data in at least one LCH that is multiplexed to another transmission resource meets the threshold; • The amount (or size) of remaining data in at least one LCH meets a threshold after a portion of the data in that LCH has been multiplexed to another transmission resource; • The remaining time until the discard timer for data in at least one LCH expires (or until the delivery deadline expires) meets the threshold; • Some resources have been identified as unavailable for the following reasons: ○ The CG timer associated with the HARQ process that is associated with the CG PUSCH (or ... ○ A CG PUSCH (timing) may be de-prioritized by another transmission (e.g., PUSCH or PUCCH) that partially overlaps with the CG PUSCH (timing) in time.

[0113] For the conditions described above, "at least one logical channel (LCH)" can be an LCH associated with the target multi-PUSCH CG (timing). That is, according to the previously configured LCH mapping constraints, an LCH can be mapped (or is considered mappable) to the resources configured for that CG.

[0114] In some implementations, when re-evaluating / updating the UTO designation for one or more CG PUSCH timings or transmission timings, the UE may re-evaluate / update the UTO designation based on the state of the CG timer associated with the HARQ PID of the corresponding transmission timing. For example, if the CG timer associated with the HARQ PID of the transmission timing may be running when the transmission timing is about to occur or be processed, the transmission timing may be updated to a UTO. In some implementations, the UE may re-evaluate / update the UTO designation based on whether the transmission timing can be de-prioritized by a higher priority transmission (e.g., another PUSCH or PUCCH).

[0115] After the UTO designation has been updated / evaluated, information identifying the set of UTOs to be re-evaluated / updated can be delivered to the PHY for the UE to send in the UTO-UCI.

[0116] Seventh Proposal: CG Timer-Aware Base Station Operation In some scenarios, the base station (e.g., gNB) can track the state of the CG timer associated with each HARQ process, and the UE (e.g., the UE communicating with the base station) can determine the UTO-UCI without considering the state of the corresponding CG timer (e.g., the second proposal described above has not yet been implemented). However, for transmission opportunities indicated as "used" (or "not used"), if the base station has determined or been indicated that the transmission opportunity is not used by the UE due to the corresponding running CG timer, the base station can completely omit decoding the transmission opportunity. That is, the base station can operate to not decode such transmission opportunities.

[0117] Based at least on the above, in some implementations, the base station may determine whether to decode a given transmission timing as follows: • Step 1: The base station receives the UTO-UCI, which indicates that a given transmission timing will be used by the UE; • Step 2: The base station determines whether the CG timer associated with the HARQ process (or HARQ PID) for a given transmission timing is expected to be running when the timing is to be used or is anticipated to occur: ○ If the CG timer is not expected to be running when a given transmission timing is to be used or is expected to occur, the base station may decode the transmission timing and may not reallocate the radio resources corresponding to the given transmission timing to other UEs; If the CG timer is expected to be running when a given transmission timing is to be used or is expected to occur, the base station may not decode the transmission timing (even if it is indicated by the UE as "used" or "not unused"), and may reallocate the radio resources corresponding to the given transmission timing to other UEs (if applicable, for example, if other UEs may need these resources).

[0118] The above process enables the base station to minimize the complexity of uplink decoding and / or maximize the efficiency of uplink decoding, while also improving the overall system capacity by allowing the base station to reallocate corresponding resources when needed.

[0119] Methods for granting permission for multi-PUSCH configuration Various proposals for characterizing and identifying transmission timings of multi-PUSCH CG (cycles) have been described in detail. It should be noted that two overall approaches can be considered to identify the UTO (Underlying Time Out) among all transmission timings of a multi-PUSCH CG cycle. According to the first overall approach, the UE may first determine the HARQ PID of one or more transmission timings of the multi-PUSCH CG, and then identify the UTO where applicable. According to the second overall approach, the UE may first identify the UTO of the multi-PUSCH CG, and then determine the HARQ PID of one or more transmission timings within the multi-PUSCH CG (cycle).

[0120] The first proposal described above can be considered for use in the first overall approach. The fourth proposal described above can be considered for use in both the first and second overall approaches. When the fourth proposal is applied in the second overall approach, the UE can determine whether it should change, switch, or remap the previously determined HARQ PID based on whether the PUSCH is indicated as used or not in the UTO-UCI.

[0121] Example wireless communication methods Figure 16 Figure 16 An example flowchart for wireless communication, according to some implementations, is shown, during which the transmission status of PUSCH transmission timing for multiple PUSCH CG cycles is determined based at least on a CG timer. Figure 16As shown, the UE can determine the corresponding HARQ PID for one or more PUSCH transmission opportunities in a multi-PUSCH CG cycle before processing the first PUSCH transmission of the multi-PUSCH CG cycle (1602). In some embodiments, the UE can determine the corresponding HARQ PID for all PUSCH transmission opportunities in a multi-PUSCH CG cycle before processing the first PUSCH transmission of the multi-PUSCH CG cycle. The UE can evaluate the state of the CG timer associated with one or more of the determined corresponding HARQ PIDs, and can also evaluate the state of the buffer associated with the multi-PUSCH CG (1604). The UE can identify a particular PUSCH transmission opportunity among the one or more PUSCH transmission opportunities as an unused transmission opportunity (UTO) or an invalid PUSCH transmission opportunity (ITO) based at least on the evaluation performed in 1604 (1606). The UE can send UTO uplink control information (UTO-UCI) to the base station, which includes information identifying the UTO and / or ITO to the base station (1608). In addition, the UE can subsequently perform UL communication without using UTO and ITO.

[0122] In some implementations, evaluating the state of the CG timer may include: determining that a particular PUSCH transmission timing may be blocked by a CG timer running for a determined HARQ PID corresponding to that particular PUSCH transmission timing. In some implementations, evaluating the state of the buffer may include: determining that a subset of remaining PUSCH transmission timings not identified as UTO or ITO is required to accommodate data buffered in one or more logical channels (LCHs) of resources that are allowed to use the subset of PUSCH transmission timings, and identifying the remaining PUSCH transmission timings not included in the subset as UTO or ITO.

[0123] In some implementations, the process described above can be performed by a Media Access Control (MAC) entity in the UE. The MAC entity can provide the physical layer (PHY) in the UE with information identifying the UTO and / or ITO, enabling the UE to send UTO-UCI to the base station.

[0124] Figure 17 Figure 17 An example flowchart for wireless communication, according to some implementations, is shown, during which the transmission status of PUSCH transmission timing for multiple PUSCH CG cycles is determined at least based on granted priority ordering. Figure 17As shown, the UE can determine that the PUSCH transmission timing of a multi-PUSCH CG cycle overlaps temporally with a second transmission timing, wherein the second transmission timing has a higher priority than the PUSCH transmission timing (1702). The UE can then identify the PUSCH transmission timing as UTO and / or ITO, at least in response to determining that the second transmission timing should be used / executed ("Yes" from 1704). The UE can then transmit the UTO-UCI identifying the UTO and / or ITO to the base station (1710). The UE can use a MAC entity to perform these procedures, and the MAC entity can deliver the information identifying the UTO and / or ITO to the UE's PHY. The UTO-UCI can then be determined at least based on the information provided to the PHY.

[0125] Determining when to perform a second transmission may include determining that the data to be transmitted via the second transmission opportunity exists in the transmission buffer. The second transmission opportunity may be a second PUSCH transmission opportunity that is not part of a multi-PUSCH CG cycle, or it may be a Physical Uplink Control Channel (PUCCH) transmission opportunity.

[0126] Figure 18 Figure 18 An example flowchart for wireless communication according to some embodiments is shown, during which the transmission status of PUSCH transmission timing for multiple PUSCH CG cycles is determined at least based on granted priority ordering, and the PUSCH transmission timing for multiple PUSCH CG cycles is de-prioritized. Figure 18 As shown, the UE can send a UTO-UCI to the base station, which indicates the PUSCH transmission timing of the multi-PUSCH CG cycle as a used transmission timing or non-UTO (1802). The UE can determine that the data to be transmitted via a second transmission timing exists in the transmission buffer ("Yes" from 1804), wherein the second transmission timing overlaps with the PUSCH transmission timing in time and has a higher priority than the PUSCH transmission timing. In response to determining that the data exists in the transmission buffer, the UE can de-prioritize the PUSCH transmission timing accordingly (1806) and can perform UL communication accordingly (1810).

[0127] Figure 19 Figure 19 An example flowchart for wireless communication is shown, during which at least one HARQ PID associated with the timing of PUSCH transmission in a multi-PUSCH CG cycle is modified. Depending on some implementations, the modification may include switching, remapping, and / or changing, etc. Figure 19As shown, the UE can determine whether one or more PUSCH transmission opportunities in a multi-PUSCH CG cycle can be blocked by one or more CG timers running for a HARQ PID corresponding to the one or more PUSCH transmission opportunities, wherein the HARQ PID is determined based on a default method (1902). In response to determining that the one or more PUSCH transmission opportunities can be blocked by the one or more CG timers ("Yes" from 1904), the UE can switch, remap, or change the corresponding HARQ PID corresponding to at least one of the one or more PUSCH transmission opportunities to a corresponding alternative HARQ PID (1906). The UE can perform UL communication at least based on the changed corresponding HARQ PID (1910).

[0128] In some implementations, the UE may determine whether the HARQ PID corresponding to a given PUSCH transmission opportunity should be changed to a corresponding alternative HARQ PID, at least based on whether the given PUSCH transmission opportunity has been indicated as an unused transmission opportunity (UTO) and / or an invalid PUSCH transmission opportunity (ITO). In some implementations, the UE may repeat step 1902 a specified number of times N>=1. Alternatively, the UE may continue to execute steps 1902 and 1906 until none of the determined corresponding HARQ PIDs associated with the PUSCH transmission opportunities identified as UTO and / or ITO among the one or more PUSCH transmission opportunities are blocked by the running CG timer.

[0129] In some implementations, performing 1906 may include using a second method different from the default method. In some implementations, the default method may include: assigning a value to a first HARQ PID, and obtaining each subsequent HARQ PID by incrementing the immediately preceding HARQ PID by a specified value Y, until all corresponding HARQ PIDs have been determined. The second method may include obtaining a corresponding alternative HARQ PID by incrementing the immediately preceding HARQ PID by a specified value Y' different from the specified value Y. The UE may indicate the specified value Y' to the base station.

[0130] Figure 20 Figure 20 An example flowchart for wireless communication, according to some implementations, is shown, in which uplink granting is prioritized by considering the transmission status of PUSCH transmission timings during multiple PUSCH CG cycles. Figure 20As shown, the UE can determine that the timing of a first PUSCH transmission corresponding to a first grant overlaps in time with the timing of a second PUSCH transmission corresponding to a second grant (2002), and can further determine whether the second PUSCH transmission timing has been identified or indicated as UTO (2004). The UE can refuse to de-prioritize the first grant in response to determining that the second PUSCH transmission timing has been identified or indicated as UTO ("yes" from 2004) (2006). The second grant can be a multi-PUSCH CG. The UE can then perform UL communication accordingly (2008).

[0131] Figure 21 Figure 21 An example flowchart for wireless communication according to some embodiments is shown, during which the base station may decode or not decode the PUSCH transmission timing based at least on the state of one or more CG timers associated with the PUSCH transmission timing of multiple PUSCH CG cycles. Figure 21 As shown, the base station can receive a UTO-UCI (2102) carrying information indicating that the transmission timing is to be used by the UE. For example, the UTO-UCI may indicate that the transmission timing is non-UTO. The base station may determine whether the CG timer associated with the HARQ (or HARQ PID) of the transmission timing is likely to be running when the transmission timing is to be used or processed (2104), and may decode the transmission timing and not reallocate the radio resources associated with the transmission timing to another UE at least in response to determining that the CG timer may not be running ("No" from 2104) (2108), or at least not decode the transmission timing and reallocate the radio resources associated with the transmission timing to another UE at least in response to determining that the CG timer may be running ("Yes" from 2104) (2106).

[0132] Various implementation plans Wireless communication performed according to some embodiments disclosed herein may include: determining that a first physical uplink shared channel (PUSCH) transmission timing corresponding to a first grant overlaps in time with a second PUSCH transmission timing corresponding to a second grant; determining whether the second PUSCH transmission timing has been identified or indicated as an unused transmission timing (UTO); and avoiding de-prioritizing the first grant in response to determining that the second PUSCH transmission timing has been identified or indicated as UTO. The second grant may be a multi-PUSCH configuration grant (CG).

[0133] Wireless communication performed according to some other embodiments disclosed herein may include re-evaluating the usage status of the Physical Uplink Shared Channel (PUSCH) transmission timing in response to one or more of the following: • A portion of the buffered data in at least one logical channel (e.g., a designated LCH) is discarded. • All data buffered in the specified LCH is discarded. • Specify the threshold amount of data to be discarded in the LCH. • Specify that the amount of remaining data in the LCH meets a threshold after discarding data from at least one LCH. • Specifies that a portion of the data buffered in the LCH is multiplexed to another transmission resource. • Specifies that all data buffered in the LCH is multiplexed to another transmission resource. • The amount of data in the specified LCH that is multiplexed to another transmission resource meets the threshold. • The amount of remaining data in a specified LCH meets a threshold after a portion of the data in the specified LCH has been multiplexed to another transmission resource. • The remaining time until the discard timer for the data in the specified LCH expires or the delivery deadline expires meets the threshold, and • Some radio resources are unavailable due to the following reasons: ○ The CG timer associated with the Hybrid Automatic Repeat Request (HARQ) process for CG PUSCH timing may be running when the CGPUSCH timing is about to occur or be processed, and ○ CG PUSCH is de-prioritized because another transmission partially overlaps with it in time.

[0134] Then, uplink (UL) communication can be performed based on the reassessed usage status of the PUSCH transmission timing. Furthermore, reassessing the usage status of the PUSCH transmission timing may include changing the usage status from "used" to "unused". In some implementations, the designated LCH may be restricted to radio resources of a CG configuration mapped to a multi-PUSCH CG.

[0135] Wireless communication performed according to at least some of the embodiments disclosed herein may include: receiving unused Transmission Timing Uplink Control Information (UTO-UCI) carrying information indicating that a transmission timing is to be used by a User Equipment (UE); determining whether a Configuration Grant (CG) timer associated with a Hybrid Automatic Repeat Request (HARQ) for the transmission timing is likely to be running when the transmission timing is used; then, in response to determining that the CG timer will not be running, the transmission timing may be decoded. If it is determined that the CG timer is likely to be running, the radio resources associated with the transmission timing may be reallocated to another UE instead of decoding the transmission timing.

[0136] Wireless communication performed according to at least some of the embodiments disclosed herein may include sending UTO uplink control information (UTO-UCI) to a base station, the UTO uplink control information (UTO-UCI) identifying a PUSCH transmission opportunity in a Multiple Physical Uplink Shared Channel (PUSCH) configuration grant (CG) period as a used transmission opportunity. Wireless communication may also include: determining that data to be transmitted via a second transmission opportunity exists in a transmission buffer, wherein the second transmission opportunity overlaps with the PUSCH transmission opportunity in time and has a higher priority than the PUSCH transmission opportunity; and de-prioritizing the PUSCH transmission opportunity in response to determining that the data exists in the transmission buffer.

[0137] A device (or specifically a baseband processor) may be used to perform wireless communication according to at least some of the embodiments described above, and / or may be operable to enable wireless communication according to at least some of the embodiments described above, whether located in a UE or a base station. In some embodiments, the UE may include a radio circuit that implements wireless communication for the UE. The UE may also include a device (or specifically a baseband processor) coupled to and interoperating with the radio circuit to perform wireless communication according to at least some of the various embodiments described above. Similarly, a base station may include a radio circuit that implements wireless communication for the base station, and the base station may also include a device (or specifically a baseband processor) coupled to and interoperating with the radio circuit to perform wireless communication according to at least some of the various embodiments described above.

[0138] It is widely acknowledged that the use of personally identifiable information should comply with privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for protecting user privacy. Personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0139] Embodiments of this disclosure may be implemented in any of a variety of forms. For example, in some embodiments, the embodiments may be implemented as a computer-implemented method, a computer-readable storage medium, or a computer system. In other embodiments, the embodiments may be implemented using one or more custom-designed hardware devices such as ASICs. Other embodiments may be implemented using one or more programmable hardware elements such as FPGAs.

[0140] In some implementations, a non-transitory computer-readable storage medium (e.g., a non-transitory memory element) may be configured to store program instructions and / or data, wherein if these program instructions are executed by a computer system, the computer system performs a method, such as any method implementation of the method implementations described herein, or any combination of the method implementations described herein, or any subset of any method implementations described herein, or any combination of such subsets.

[0141] In some embodiments, a device (e.g., a UE) may be configured to include a processor (or a set of processors) and a memory medium (or memory element), wherein the memory medium stores program instructions, and the processor is configured to read from and execute these program instructions, wherein these program instructions are executable to implement any method implementation of the various method implementations described herein (or any combination of method implementations described herein, or any subset of any method implementations described herein, or any combination of such subsets). The device may be implemented in any of a variety of forms.

[0142] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A method for wireless communication, the method comprising: Before processing the first PUSCH transmission in the Multi-Physical Uplink Shared Channel (PUSCH) Configuration Grant (CG) cycle, determine the corresponding Hybrid Automatic Repeat Request Process Identifier (HARQPID) for the timing of multiple PUSCH transmissions in the multi-PUSCH CG cycle; and Uplink (UL) communication is performed based on at least one or more determined HARQ PIDs.

2. The method according to claim 1, further comprising: Evaluate the state of the CG timer associated with one or more of the identified corresponding HARQ PIDs; At least based on the state of the CG timer, one or more of the plurality of PUSCH transmission opportunities are identified as unused transmission opportunities (UTO) or invalid PUSCH transmission opportunities (ITO); and The UL communication is performed without using the UTO and the ITO.

3. The method of claim 2, wherein identifying one or more PUSCH transmission opportunities among the plurality of PUSCH transmission opportunities as UTO or ITO based on the state of the CG timer comprises: It is determined that the one or more PUSCH transmission timings can be blocked by the CG timer running for a determined HARQ PID corresponding to the one or more PUSCH transmission timings.

4. The method according to claim 2, further comprising: The UTO and ITO are further identified based on the buffer state.

5. The method of claim 4, wherein further identifying the UTO and the ITO based on the buffer state comprises: Determine a subset of the remaining PUSCH transmission opportunities that are not identified as UTO or ITO among the plurality of PUSCH transmission opportunities to accommodate data buffered in one or more logical channels of resources that are allowed to use the PUSCH transmission opportunities; The remaining PUSCH transmission opportunities that are not included in the subset are identified as UTO or ITO.

6. The method according to claim 2, further comprising: Send UTO uplink control information (UTO-UCI) to the base station. The UTO-UCI includes information identifying the UTO or the ITO or both.

7. The method of claim 2, wherein the evaluation and the identification are performed by a Media Access Control (MAC) entity in the User Equipment (UE).

8. The method according to claim 7, further comprising: The MAC entity sends information identifying the UTO, the ITO, or both to the physical layer (PHY) in the UE.

9. A baseband processor, the baseband processor comprising: A memory, the memory being used to store information; and Processing circuitry, coupled to the memory and configured to: The timing of PUSCH transmission during the Multi-Physical Uplink Shared Channel (PUSCH) Configuration Grant (CG) period overlaps with a second transmission timing, wherein the second transmission timing has a higher priority than the PUSCH transmission timing. At least in response to determining that the second transmission timing needs to be performed, the PUSCH transmission timing is marked as an unused transmission timing (UTO) or an invalid PUSCH transmission timing (ITO), and Prepare UTO uplink control information (UTO-UCI) for transmission to the base station, wherein the UTO-UCI indicates the identified UTO or the identified ITO.

10. The baseband processor of claim 9, wherein the processing circuitry is configured to perform the determination and the identification via a Media Access Control (MAC) entity in a User Equipment (UE).

11. The baseband processor of claim 10, wherein the processing circuitry is further configured to: The MAC entity delivers information identifying the UTO or ITO to the UE's physical layer (PHY); and The UTO-UCI is determined at least based on the information provided.

12. The baseband processor of claim 9, wherein the processing circuitry is configured to determine to execute the second transmission timing by determining that data to be transmitted via the second transmission timing exists in the transmission buffer.

13. The baseband processor of claim 9, wherein the second transmission timing is one of the following: The timing of the second PUSCH transmission is not part of the aforementioned multi-PUSCH CG cycle; or Timing of Physical Uplink Control Channel (PUCCH) transmission.

14. A non-transitory memory element storing instructions executable by processing circuitry to perform operations including: Determine whether one or more PUSCH transmission opportunities during a Multiple Physical Uplink Shared Channel (PUSCH) Configuration Grant (CG) period can be blocked by one or more CG timers running for a HARQ PID corresponding to the one or more PUSCH transmission opportunities, wherein the HARQ PID is determined based on a default method; In response to determining that the one or more PUSCH transmission timings can be blocked by the one or more CG timers, the corresponding HARQ PID corresponding to at least one of the one or more PUSCH transmission timings is changed to the corresponding alternative HARQ PID; and Uplink (UL) communication is performed at least based on the corresponding HARQ PID that has been changed.

15. The non-transitory memory element according to claim 14, further comprising: The determination of whether the HARQ PID corresponding to the at least one of the one or more PUSCH sending times should be changed to the corresponding alternative HARQ PID is based at least on whether at least one of the one or more PUSCH sending times has been indicated as an unused sending time (UTO) or an invalid PUSCH sending time (ITO).

16. The non-transitory memory element according to claim 14, further comprising: Determine whether the HARQPID corresponding to at least one of the one or more PUSCH transmission times should be changed to the corresponding alternative HARQPID for a specified number of times N>=1.

17. The non-transitory memory element according to claim 14, wherein the instructions further include: The determination and the change are performed until none of the determined corresponding HARQ PIDs associated with the PUSCH transmission timing that is not identified as an unused transmission timing (UTO) or an invalid PUSCH transmission timing (ITO) among the one or more PUSCH transmission timings are blocked by the running CG timer.

18. The non-transitory memory element of claim 14, wherein changing the corresponding HARQ PID comprises using a second method different from the default method.

19. The non-transitory memory element of claim 18, wherein the default method comprises: Assign the value to the first HARQ PID; as well as Each subsequent HARQ PID is obtained by incrementing the preceding HARQ PID by a specified value Y, until all the corresponding HARQ PIDs have been determined.

20. The non-transitory memory element of claim 19, wherein the second method comprises obtaining the corresponding alternative HARQ PID by incrementing the immediately preceding HARQ PID by a specified value Y' different from the specified value Y; and The operation also includes instructing the base station to specify the value Y'.

Images