User equipment and wireless communication method performed by user equipment

Abstract

A user equipment (UE) and a wireless communication method performed by the user equipment are provided. The method includes receiving a radio resource control (RRC) configuration from a base station (BS) to configure a first semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) and generating a first uplink control information (UCI) to the first SPS PDSCH in response, wherein the RRC configuration comprises a first parameter indicating a priority of the first UCI.

Description

Technical Field

[0001] This application claims priority to U.S. Provisional Application No. 62 / 866,796, filed on June 26, 2019, entitled “Method and Apparatus for Monitoring the Downlink Control Channel of an Entity” (hereinafter referred to as “Provisional Application 796”), the entire disclosure of which is incorporated herein by reference.

[0002] This invention relates to wireless communication, and more specifically, to a user device and a wireless communication method performed by the user device. Background Technology

[0003] Various efforts have been made in the communications field to improve different aspects of wireless communication in cellular wireless communication systems (such as fifth-generation (5G) New Radio (NR)) by increasing data rates, latency, reliability, and mobility. In NR Technical Specification (TS) Release 15 (Rel-15), Modulation and Coding Scheme (MCS) tables (e.g., qam64lowSE) were introduced to schedule more reliable data transmission. For licensed Physical Downlink Shared Channel (PDSCH) transmissions, there are two methods to configure the qam64lowSE table. One is by extending the existing Radio Resource Control (RRC) parameter mcs-Table in the PDSCH configuration (e.g., PDSCH-Config), and the other is by configuring the MCS Cell Radio Network Temporary Identifier (C-RNTI) (MCS-C-RNTI). For downlink (DL) semi-persistent scheduling (SPS) transmissions, only the RRC parameter mcs-Table in the SPS configuration (e.g., SPS-Config) can indicate whether the qam64lowSE table is configured. Furthermore, in NR Rel-15, User Equipment (UE) does not expect to transmit more than one Physical Uplink Control Channel (PUCCH) with Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) information in a single time slot. Therefore, in Rel-15, multiplexing, prioritization, or conflicting behavior of HARQ-ACK transmissions does not need to be considered for different service types within a UE's time slot. Different service types supported by 5G NR include Enhanced Mobile Broadband (eMBB) and Ultra Reliable Low Latency Communications (URLLC). However, in Rel-16 and later versions, UCI messages may completely or partially overlap within a time slot. Multiple UCI messages may include UCIs for licensed PDSCH transmissions and / or UCIs for SPS PDSCH transmissions. Therefore, an improved and efficient mechanism is needed for the UE to handle UCI conflicts within a time slot. Summary of the Invention

[0004] This invention relates to a user equipment and a wireless communication method performed by the user equipment, the method being a method performed by the UE in a cellular wireless communication network for configuring the priority of UCI.

[0005] According to one embodiment of the present invention, a user equipment (UE) is provided, comprising: one or more non-transitory computer-readable media containing computer-executable instructions; and at least one processor coupled to the one or more non-transitory computer-readable media, the at least one processor being configured to execute the computer-executable instructions to: receive a radio resource control (RRC) configuration from a base station (BS) to configure a first semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH); and generate first uplink control information (UCI) in response to the first SPS PDSCH;

[0006] The RRC configuration includes a first parameter that indicates the priority of the first UCI.

[0007] According to another embodiment of the present invention, the present invention provides a wireless communication method performed by a user equipment, comprising: receiving a radio resource control (RRC) configuration from a base station (BS) to configure a first semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH); and generating a first uplink control information (UCI) in response to the first SPS PDSCH; wherein the RRC configuration includes a first parameter indicating the priority of the first UCI. Attached Figure Description

[0008] The exemplary viewpoint of this case can be better understood by referring to the accompanying drawings. Note that the various features in the drawings are not drawn to scale, and their dimensions can be arbitrarily increased or decreased for clarity of discussion.

[0009] Figure 1 This is a flowchart illustrating a method for configuring UCI priority for an SPS PDSCH in a UE, as provided in an embodiment of the present invention.

[0010] Figure 2 The flowchart illustrates a method for configuring UCI priority for a UE in dynamic PDSCH, as provided in an embodiment of the present invention.

[0011] Figure 3 This is a diagram illustrating a process for handling UCI conflicts implemented according to an example of the present invention.

[0012] Figure 4 This is a block diagram illustrating a node for wireless communication according to various aspects of the present invention. Detailed Implementation

[0013] The following description contains specific information relating to exemplary embodiments of the present invention. The accompanying drawings and detailed description are for exemplary embodiments. However, the invention is not limited to these exemplary embodiments. Other variations and embodiments of the invention will arise in those skilled in the art upon reference to this description.

[0014] Unless otherwise stated, the same or corresponding components in the figures may be indicated by the same or corresponding reference numerals. Furthermore, the figures and illustrations are generally not drawn to scale and are not intended to correspond to actual relative dimensions.

[0015] For the purposes of consistency and ease of understanding, similar features are identified by numbers in the exemplary figures (although in some examples they are not shown). However, features in different implementations may differ in other respects and should not be narrowly limited to what is shown in the figures.

[0016] The terms “in one embodiment” or “in some embodiments” may each refer to one or more of the same or different embodiments. The term “coupled” is defined as a direct or indirect connection via an intermediate component, not necessarily a physical connection. The term “comprising” means “including but not limited to” and specifically indicates an open inclusion or membership in the above combinations, groups, series, or equivalents. The expression “at least one of A, B, and C” or “at least one of the following: A, B, and C” means “only A, or only B, or only C, or any combination of A, B, and C.”

[0017] The terms "system" and "network" are used interchangeably. The term "and / or" only describes the relationship between related objects, indicating that there are three possible relationships: A and / or B. This could mean that A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0018] For purposes of explanation and non-limitation, specific details such as functional entities, technologies, protocols, and standards are described to provide an understanding of the disclosed technologies. In other examples, detailed descriptions of well-known methods, technologies, systems, and architectures are omitted to avoid obscuring the description with unnecessary detail.

[0019] Those skilled in the art will immediately recognize that any network function or algorithm disclosed may be implemented by hardware, software, or a combination of both. The disclosed functions may correspond to modules that are software, hardware, firmware, or any combination thereof.

[0020] Software implementation may include calculator executable instructions stored on a calculator-readable medium such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose calculators with communication processing capabilities may be programmed with the corresponding executable instructions to execute the described network functions or algorithms.

[0021] Microprocessors or general-purpose calculators may be formed using application-specific integrated circuits (ASICs), programmable logic arrays, and / or one or more digital signal processors (DSPs). Although some disclosed embodiments relate to software installed and executed on calculator hardware, alternative embodiments, such as firmware or hardware or a combination of hardware and software, are also within the scope of this invention. Calculator-readable media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc (CD) read-only memory (CD ROM), magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing calculator-readable instructions.

[0022] A radio communication network architecture (e.g., Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-APro, or New Radio Systems) typically includes at least one base station (BS), at least one user equipment (UE), and one or more optional network elements providing connectivity to the network. The UE communicates with the network (e.g., the Core Network (CN), Evolved Packet Core (EPC), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Next Generation Core (NGC), 5G CN (5GC), or a RAN established via the BS).

[0023] It should be noted that, in this invention, the UE may include, but is not limited to, a mobile station, mobile terminal or device, or a user communication radio terminal. For example, the UE may be a portable wireless device, including but not limited to a mobile phone, tablet computer, wearable device, sensor, or personal digital assistant (PDA) with wireless communication capabilities. The UE is configured to receive and transmit signals to one or more cells in the RAN via an air interface.

[0024] The BS can be configured to provide communication services based at least on a Radio Access Technology (RAT), such as WiMAX, GSM (commonly referred to as 2G), GERAN (GSM Evolution for GSM RAN), GPRS, GSM Enhanced Data Rate (GSM) based on UMTS (commonly referred to as 3G based on W-CDMA), HSPA, LTE, LTE-A, eLTE (eLTE), i.e., LTE connected to 5GC, NR (commonly referred to as 5G), and / or LTE-APro. However, the scope of this disclosure is not limited to these protocols.

[0025] A BS can be, but is not limited to, a Node B (NB) in UMTS, an Evolved Node B (eNB) in LTE or LTE-A, a Radio Network Controller (RNC) in UMTS, a BS controller (BSC in GSM / GERAN), an ng-eNB in ​​an E-UTRA BS associated with 5GC, a Next Generation Node B (gNB) in 5G-RAN, or any other device capable of controlling radio communications and managing radio resources within a single cell. The BS can serve one or more UEs via a radio interface.

[0026] The BS is operable to provide radio coverage to a specific geographic area using multiple cells forming the RAN. The BS supports cell operation. Each cell is operable to provide service to at least one UE within its radio coverage area.

[0027] Each cell (usually referred to as the serving cell) provides service to one or more UEs within its radio coverage area, such that each cell schedules downlink (DL) and optional uplink (UL) resources to at least one UE within its radio coverage for DL ​​and optional UL packet transmissions. A BS can communicate with one or more UEs in a radio communication system via multiple cells.

[0028] Cells can allocate sidelink (SL) resources to support Proximity Service (ProSe) or Vehicle to Everything (V2X) services. Each cell may have coverage areas that overlap with other cells.

[0029] As previously mentioned, NR's frame structure supports flexible configuration to accommodate various next-generation (e.g., 5G) communication requirements, such as enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable and low-latency communications (URLLC), while meeting high reliability, high data rates, and low latency requirements. Orthogonal frequency division multiplexing (OFDM) technology from the 3rd Generation Partnership Project (3GPP) can serve as the baseline for NR waveforms. Scalable OFDM parameter sets, such as adaptive subcarrier spacing, channel bandwidth, and cyclic prefix (CP), can also be used.

[0030] NR considers two coding schemes, specifically Low-Density Parity-Check (LDPC) codes and Polar codes. Coding scheme adaptation can be configured based on channel conditions and / or service applications.

[0031] A single NR frame's Transmission Time Interval (TTI) should include at least DL (Deep Link) transmission data, a guard period, and uplink (UL) transmission data. The individual components of the DL, guard period, and UL transmission data should also be dynamically configurable based on the network, such as NR. Sidelink resources can also be provided in NR frames to support ProSe or V2X services.

[0032] Since at least two HARQ-ACK codebooks can be built simultaneously for the UE to support different service types, a physical identifier may be needed to identify the HARQ-ACK codebooks. For licensed PDSCH, the new RNTI may be a physical identifier to help distinguish HARQ-ACK codebooks for different service types. In other words, PDSCH transmissions scheduled by DL control information (DCI) scrambled with the new RNTI can be considered high-priority transmissions that can be linked to a specific HARQ-ACK codebook with low-latency feedback. For licensed Physical Uplink Shared Channel (PUSCH), the new RNTI may be an identifier identifying UCI multiplexing behavior. It should be noted that this invention does not exclude other possible physical identifiers. However, the introduction of the new RNTI may have some impact on the configuration of the qam64lowSE table.

[0033] Potential impacts include: Prioritized PDSCH or PUSCH transmissions may be configured using the qam64lowSE low spectral efficiency table with only RRC signaling, as configurations using MCS-C-RNTI may be unavailable; prioritizing PDSCH transmissions may be overly restrictive if configurations using the qam64lowSE table are implied, since low-latency service is not necessarily associated with high reliability; and the physical identifier used to identify HARQ-ACK feedback between licensed (CG) authorizations for licensed PDSCH / PUSCH and DL SPS PDSCH / UL configurations may remain unclear.

[0034] Based on the new RNTI method described above, it may be necessary to specify the scheduling qam64lowSE table without MCS-C-RNTI. Furthermore, how to maintain flexibility in scheduling different MCS tables when receiving allocation / authorization indications from the Physical Downlink Control Channel (PDCCH) may also need clarification. Additionally, if the Cyclic Redundancy Check (CRC) of the corresponding DCI is set to zero in the configured Scheduling (CS) RNTI (CS-RNTI) and the new Enabled Transport Block (TB) Data Indicator (NDI) field, the priority of UL authorization received or configured by SPSPDSCH may not be recognizable based on the new RNTI. Therefore, it may be necessary to specify general behavior for physical identifiers used to identify different service types' HARQ-ACK codebooks, authorization-based PDSCHs, SPS PDSCHs, and their UL counterparts. The physical identifier can be a new DCI format, a new RNTI, or a new field within the DCI format. It should be noted that this invention does not exclude other possible physical identifiers for dynamically scheduling MCS tables (e.g., new DCI fields, dedicated search space sets, new DCI formats).

[0035] Scenario 1: New RNTI used for priority indication during dynamic MCS table adaptation

[0036] In one implementation, a new RNTI can be introduced as a physical identifier for identifying HARQ-ACK codebooks of different service types. In another implementation, a PUSCH transmission scheduled by a DCI with CRC bits scrambled by the new RNTI can indicate whether UCI multiplexing is allowed on the PUSCH. For example, if a PUSCH transmission is scheduled by a DCI scrambled with the new RNTI, in one implementation, UCI multiplexing on the PUSCH is not allowed, while only the UCI corresponding to a PDSCH scheduled by a DCI scrambled with the new RNTI is allowed to be multiplexed on the PUSCH in another implementation. It should be noted that the new RNTI can be a UE-specific RNTI applicable to the cell group or Transport Receive Point (TRP) group configured for the UE. Several mechanisms for configuring the qam64lowSE table or tables that may be introduced in the future on the new RNTI are disclosed below.

[0037] Case 1-1: Combine the RRC parameter mcs-Table in PDSCH-Config, PUSCH-Config, SPS-Config, or ConfiguredGrantConfig with some conditions such as Transport Block Size (TBS) / Duration / Number of Physical Resource Blocks (PRB) for data transmission.

[0038] For PDSCH or PUSCH scheduled with DCI format CRC scrambled by new-RNTI, or for PDSCH or PUSCH scheduled without corresponding PDCCH transmission, use the higher-layer PDSCH configuration SPS-Config or PUSCH configuration ConfiguredGrantConfig:

[0039] Case 1-1-1: If the higher-layer parameter mcs-Table given by PDSCH-Config, PUSCH-Config, SPS-Config, or ConfiguredGrantConfig is set to 'qam64LowSE' or other table error rate (BLER) requirements used to configure data transmission, the UE can check whether the duration of TBS or PDSCH / PUSCH or the number of PRBs allocated for PDSCH / PUSCH is greater than a predefined or configured threshold (e.g., configured via RRC) signal.

[0040] In one implementation, the threshold configured for the PDSCH / PUSCH duration can be the number of symbols or the number of sub-slots. A sub-slot can include multiple symbols within a single slot. Considering that data transmissions indicated as high priority do not necessarily have high reliability requirements, data with a large TBS, or a long duration, or a large PRB number, or a combination of these factors, can be considered to require a high data rate.

[0041] In one implementation, if the number of TBS / duration / PRB data transmissions exceeds a threshold, the UE can use the MCS index (e.g., I_MCS) and the 64QAM table (e.g., Table 5.1.3.1-138.214 in TS) to determine the modulation order and target code rate used in the PDSCH or PUSCH; otherwise, the UE can follow a table configured using higher-layer parameters (e.g., Table 5.1.3.1-3 in TS 38.214).

[0042] In another implementation, more MCS tables can be considered (e.g., the 256QAM table in Table 5.1.3.1-2 of TS 38.214) and multiple thresholds can be introduced. The thresholds can define the applicable scope of each MCS table.

[0043] Case 1-1-2: If the higher-layer parameter mcs-Table given by PDSCH-Config, PUSCH-Config, SPS-Config, or ConfiguredGrantConfig does not exist, or if the higher-layer parameter mcs-Table given by PDSCH-Config, PUSCH-Config, SPS-Config, or ConfiguredGrantConfig is set to 'qam256', the UE can check whether the duration of the TBS or PDSCH / PUSCH for data transmission or the number of allocated PRBs is less than a predefined threshold or a configured threshold (e.g., configured via RRC signaling).

[0044] In one implementation, the threshold configured for the PDSCH / PUSCH duration can be the number of symbols or the number of sub-slots. Considering that data transmissions indicated as high priority may also have high reliability requirements, data with a small TBS, short duration, or small PRB number, or a combination of the above factors, can be considered to require high reliability.

[0045] In one implementation, if the number of TBS / duration / PRB data transmissions is less than a threshold, the UE can use the I_MCS and qam64lowSE tables (e.g., Table 5.1.3.1-3 in TS 38.214) or other tables to configure data transmissions with low BLER requirements to determine the modulation order and target code rate used in the PDSCH or PUSCH; otherwise, the UE can use the 64QAM table (e.g., Table 5.1.3.1-1 in TS 38.214).

[0046] Case 1-2: Handling of Media Access Control (MAC) Control Element (CE)

[0047] Scenario 1-2-1: The network can indicate the MCS table for the serving cell's PDSCH and / or PUSCH by sending an MCS table indication via a UE-specific PDSCH / PUSCH MAC CE. The UE-specific PDSCH / PUSCH MAC CE for MCS table indication can be a specific indication notifying the UE which MCS table should be used. When the UE receives the MAC CE, it can apply the corresponding indication to the PDSCH / PUSCH transmission. In one implementation, a corresponding MAC CE command is provided for the corresponding DLPDSCH and UL PUSCH transmissions. In another implementation, a single MAC-CE command applies to both PDSCH and PUSCH.

[0048] In one implementation, when the UE receives an MCS table indication from the network via a UE-specific PDSCH / PUSCH MAC CE, the UE's MAC entity can implicitly indicate information about the UE's MCS table indication—the specific PDSCH / PUSCH MAC CE—to the lower layers. In other words, the MCS table indication may include the range of applicable MCS (e.g., maximum and minimum applicable MCS; up to 64QAM or 256QAM) or allowed MCS configurations, rather than providing specific instructions for the applicable MCS table.

[0049] In one implementation, the MCS table indication received via a UE-specific PDSCH / PUSCH MAC CE can be identified by a MAC Protocol Data Unit (PDU) subheader with a Logical Channel Identifier (LCID). The MAC CE can have a variable size and the following fields, and can include one or any combination of the following provided information:

[0050] -TRP ID: This field contains the TRP-Id of the TRP applicable to MAC CE.

[0051] -CORESET ID: This field contains the CORESET-Id of the Control Resource Set (CORESET), which includes scheduling information for the data channels to which MAC CE applies.

[0052] -Serving Cell ID: This field indicates the identifier of the serving cell to which MAC CE applies.

[0053] -BWP ID: This field contains the BWP-Id of the DL / UL Bandwidth Part (BWP) applicable to MAC CE.

[0054] -MCS Table ID: This field indicates the MCS table identified by mcs-Table or mcs-Table-Id.

[0055] -PDSCH / SPS: This field indicates whether the MCS table is used for dynamic PDSCH scheduling or SPS scheduling.

[0056] -PUSCH / Configured grant: This field indicates whether the MCS table indicates whether it is used for dynamic PUSCH scheduling or configuration-granted scheduling.

[0057] -PDSCH / PUSCH: This field indicates whether the MCS table is used for PDSCH or PUSCH.

[0058] -SPS Configuration ID: This field indicates which SPS configuration is applied to, as indicated by the MCS table.

[0059] -Configured license configuration ID: This field indicates which configured license configuration is applied to in the MCS table.

[0060] The `mcs-Table` parameter in `PDSCH-Config`, `PUSCH-Config`, `SPS-Config`, or `ConfiguredGrantConfig` can be an integer to identify which table is applied, or it can be a configuration information element (IE) `mcs-Table-Id`. It's important to note that from the UE's perspective, the IE `mcs-Table-Id` can be cell-specific, cell group-specific, or TRP-specific. Furthermore, MCS table indexes can be associated with specific MCS tables. For example, index 0 can reference the 64QAM table, index 1 can reference the 256QAM table, and index 2 can reference the qam64lowSE table.

[0061] Scenario 1-2-2: The network can use higher-layer parameters to indicate the MCS table used for PDSCH (BWP and / or serving cell and / or TRP), and this parameter can be enabled / de-enabled via the MCS table to enable / de-enabled MAC CE. For example, if the enabling status is verified and the MCS table is configured by a higher layer, the UE can apply the MCS table configured by the higher layer; otherwise, the UE can use a preset MCS table (e.g., a 64QAM table). It is important to note that if there is no higher-layer parameter (e.g., mcs-table), the UE can use the preset MCS table regardless of the enabling / de-enabled MAC CE status. In one implementation, if the mcs-table parameter is not present, the preset MCS table can be a 64QAM table. In another implementation, the preset MCS table can be a qam64LowSE table based on the new RNTI.

[0062] In one implementation, the MCS table startup / de-startup MAC CE can be identified by a MAC PDU subheader with LCID. In one implementation, the MAC CE can have a fixed size of zero bits. In another implementation, the MAC CE can have a variable size and the following fields to indicate the startup / de-startup status of different BWPs and / or different cells and / or different TRPs. The MAC CE can include one or any combination of the following information:

[0063] -Start / Deactivate: This field indicates the start / deactivation status of the MCS table.

[0064] -TRP ID: This field contains the TRP-Id of the TRP applicable to MAC CE.

[0065] -CORESET ID: This field contains the CORESET-Id of the CORESET, which contains scheduling information for the data channels to which MAC CE applies.

[0066] -Serving Cell ID: This field indicates the identifier of the Serving Cell to which the MAC CE is applied.

[0067] -BWP ID: This field contains the BWP-Id of the DL BWP applicable to MAC CE.

[0068] -MCS Table ID: This field indicates the MCS table identified by mcs-Table or mcs-Table-Id.

[0069] -PDSCH / SPS: This field indicates whether the MCS table is used for dynamic PDSCH scheduling or SPS scheduling.

[0070] -PUSCH / Configured grant: This field indicates whether the MCS table indicates whether it is used for dynamic PUSCH scheduling or configuration-granted scheduling.

[0071] -PDSCH / PUSCH: This field indicates whether the MCS table is used for PDSCH or PUSCH.

[0072] -SPS Configuration ID: This field indicates which SPS configuration is applied to, as indicated by the MCS table.

[0073] -Configured license configuration ID: This field indicates which configured license configuration is applied to in the MCS table.

[0074] Scenario 1-2-3: The network can use higher-layer parameters to indicate the MCS table used for PDSCH (BWP and / or serving cell and / or TRP). However, if the UE receives a MAC CE indication indicating which MCS table should be applied, the UE can use the MCS table indicated by the MAC CE. For example, if the qam64lowSE table is configured by mcs-Table in PDSCH-Config, PUSCH-Config, SPS-Config, or ConfiguredGrantConfig, and the UE receives a MAC CE indicating a 64QAM table, the UE can apply the 64QAM table for, for example, depending on which channel the MAC CE indicates, PDSCH, PUSCH, SPS PDSCH, or CG PUSCH. Furthermore, a MAC CE for the MCS table indication can be applied when reconfiguration occurs. In other words, the priority of the MAC CE indication for the MCS table can be higher than signaling from the RRC configuration for the MCS table.

[0075] Scenario 2: Priority distinction of corresponding UCIs between licensed PDSCH (e.g., PDSCH) and unlicensed PDSCH (e.g., SPS PDSCH).

[0076] Several mechanisms are provided below for handling conflicts between UCIs with different priorities for authorized PDSCH-based UCIs (e.g., HARQ-ACK information for PDSCH) and unauthorized PDSCHs (e.g., HARQ-ACK information for SPS PDSCH). It should be noted that UCIs can be transmitted on PUCCH or PUSCH transmissions. In one implementation, a UCI sent by the UE in response to a PDSCH or SPS PDSCH may include HARQ-ACK information. It should be noted that "high-priority transmission" or "one transmission takes precedence over other transmissions" in this invention can refer to the transmission sent by the UE when multiple transmissions overlap in the time domain (e.g., partially or entirely). The time-domain resource allocation between different transmissions can be configured within the same symbol. Other transmissions may not be transmitted besides those identified as high-priority transmissions. In the following cases, the UCI priority of PDSCH can be identified by the new-RNTI (e.g., the UCI corresponding to the PDSCH scrambled by the new-RNTI can be regarded as high priority) or other physical identifiers (e.g., a DCI field, a new DCI format).

[0077] Case 2-1: A conflict occurs between the UCI of the DCI-scheduled PDSCH and the UCI of the newly RNTI-scrambled CRC and SPS PDSCH, which are identified as transmissions with higher priority.

[0078] In one implementation, both the UCI for PDSCH and the UCI for SPS PDSCH can be identified as high-priority transmissions using different physical identifiers. In another implementation, the UCI for PDSCH can be identified as high-priority using a new RNTI, and the UCI for SPS PDSCH can be identified as a high-priority transmission among multiple overlapping active SPS PDSCH UCIs. In other words, when a UCI for PDSCH with a new RNTI and a UCI for PDSCH with a C-RNTI or MCS conflict, the UCI for PDSCH scheduled by the DCI with a CRC scrambled by the new RNTI can be considered a high-priority transmission – C-RNTI in case 2-1.

[0079] Case 2-1-1: In one implementation, the UCI priority of a dynamically scheduled PDSCH (e.g., PDSCH) can always be considered higher than the UCI priority of an SPS PDSCH because the priorities between PDSCH and SPS PDSCH are not yet determined. For example, when the UCI of PDSCH and SPS PDSCH conflict, the UCI of PDSCH can take precedence. In another implementation, although the UCIs of both PDSCH and SPS PDSCH are marked as high-priority transmissions (e.g., PDSCH and SPS PDSCH can use different physical identifiers to indicate priorities), the UCI corresponding to PDSCH can always take precedence over the UCI corresponding to SPS PDSCH when a conflict occurs.

[0080] Scenario 2-1-2: In one implementation, multiple active SPS configurations can be supported, and each SPS configuration can have a corresponding index. The SPS PDSCH corresponding to a specific index can be considered the preferred PDSCH. In one implementation, when a conflict occurs, the SPS PDSCH with a specific index (e.g., index 0) among multiple active SPS PDSCHs can take precedence over other SPS PDSCHs with other indices. In one implementation, the SPS PDSCH corresponding to the configuration with index 0 can be the preferred SPS PDSCH; when the UCI of the PDSCH and the UCI of the SPS PDSCH conflict, the UCI of the SPS PDSCH with index 0 can be processed first. In one implementation, if multiple active SPS PDSCHs overlap, the SPS PDSCH corresponding to the configuration with index 0 can be the preferred SPS PDSCH among the multiple active SPS PDSCHs, and the UCI of the SPS PDSCH configured with index 0 can be the same; when a conflict occurs, the priority is used as the UCI of the PDSCH. In one implementation, the UCI of both the SPS PDSCH and PDSCH with index 0 can be considered as high-priority transmissions, and the priority between UCIs may not be required.

[0081] Case 2-1-3: In one implementation, the priority of the UCI of the SPS PDSCH can be configured by parameters in the SPS configuration (e.g., SPS-Config). In one implementation, if a specific parameter for identifying priority is configured in SPS-Config, then when the UCI of the dynamic PDSCH conflicts with the UCI used for the dynamic PDSCH, the UCI of the SPS PDSCH corresponding to the SPS-Config with the specific parameter can be prioritized. In one implementation, the configured parameters can identify the priority of the corresponding SPS PDSCH UCI, and the UCI of the SPS PDSCH identified as having higher priority can take precedence over the UCI of the PDSCH. In one implementation, if a specific parameter for identifying priority is configured in SPS-Config, then in the event of a conflict, the UCI of the SPS PDSCH corresponding to the SPS-Config with the specific parameter can have the same priority as the UCI of the PDSCH. In one implementation, the configured parameters can identify the priority of the corresponding SPS PDSCH UCI, and the UCI of the SPS PDSCH identified as having high priority can have the same priority as the UCI of the PDSCH. In another implementation, the UCI of the SPS PDSCH and the UCI of the PDSCH can be identified as high-priority transmissions using different physical identifiers, and it may not be necessary to further compare the priorities of the UCI of the PDSCH and the UCI of the SPS PDSCH.

[0082] Case 2-1-4: In one implementation, a field in the DCI format indicating the initiation of an SPS PDSCH can be used to indicate the priority order between the PDSCH and SPS PDSCH. This field can be a new field or a reused field in the DCI format. In one implementation, the new field may include a bit to indicate whether the initiated SPS PDSCH is prioritized. For example, a bit with a value of "1" may be considered "priority SPS PDSCH" (e.g., high priority), while a bit with a value of "0" may be considered "de-priority SPS PDSCH" (e.g., low priority transmission). Alternatively, a bit with a value of "0" may be considered "priority SPS PDSCH," while a bit with a value of "1" may be considered "de-priority SPS PDSCH." In one implementation, existing fields in the DCI format can be reused. The UE can verify the priority SPS PDSCH based on existing fields in the DCI format. In one implementation, when a conflict occurs between the UCI used for PDSCH and the UCI used for SPS PDSCH, the UCI of SPS PDSCH corresponding to the DCI with the specific field indicating priority may be given priority. In another implementation, when a conflict occurs, the UCI of SPS PDSCH corresponding to the DCI with the specific field may have the same priority as the UCI of PDSCH.

[0083] Case 2-1-5: Priority can depend on the periodicity scheduled in the SPS configuration (e.g., SPS-Config). In one implementation, if the periodicity in the SPS-Config is less than a threshold (e.g., 2 symbols), the UCI of the SPS PDSCH can take precedence when a conflict occurs between the UCI of the PDSCH and the UCI of the SPSPDSCH. In another implementation, when a conflict occurs, the UCI of the SPS PDSCH with a periodicity less than the threshold can have the same priority as the UCI of the PDSCH.

[0084] Case 2-1-6: Priority can depend on the K1 value of the SPS PDSCH. In one implementation, when a conflict occurs between the UCI used for the PDSCH and the UCI used for the SPS PDSCH, the UCI used for the PDSCH transmission with a K1 value less than a threshold (e.g., 2 symbols) can be given priority. The K1 value can indicate the time offset between a given PDSCH and the corresponding HARQ-ACK information. In one implementation, K1 can be the number of time slots / sub-time slots from the time slot / sub-time slot containing the end of the PDSCH to the time slot / sub-time slot containing the beginning of the PUCCH with HARQ-ACK information. In one implementation, when a conflict occurs, the UCI of the SPS PDSCH with a K1 value less than the threshold can have the same priority as the UCI of the PDSCH.

[0085] The implementations described in cases 2-1-1 to 2-1-6 can be standalone methods or can be combined to form a specific method.

[0086] Case 2-2: Conflict between the UCI of a PDSCH scheduled by a DCI scrambled with C-RNTI and the UCI of an SPS PDSCH identified as having high priority transmission.

[0087] In one implementation, both the UCI for PDSCH and the UCI for SPS PDSCH can be identified as high-priority transmissions using different physical identifiers. In another implementation, the UCI for PDSCH can be identified as a low-priority transmission, and the UCI for SPS PDSCH can be identified as a high-priority transmission. In yet another implementation, other physical identifiers (e.g., DCI field, new DCI format) can be used to identify the UCI for PDSCH as high-priority, and the UCI for SPS PDSCH can be identified as a high-priority transmission among multiple overlapping UCIs. Active SPS PDSCH.

[0088] Scenario 2-2-1: In one implementation, multiple active SPS configurations can be supported, and each SPS configuration can have a corresponding index. The SPS PDSCH corresponding to a specific index can be considered the preferred PDSCH. For example, among three SPS PDSCHs with indices 0, 1, and 2 respectively, the SPS PDSCH with index 0 can have the highest priority. In one implementation, the SPS PDSCH corresponding to the configuration with index 0 can be considered the preferred SPS PDSCH compared to the SPS PDSCH corresponding to the configuration with index 0. The UCI of the SPS PDSCH of the configuration with index 0 can be prioritized when the UCI of the PDSCH and the UCI of the SPS PDSCH conflict. The UCI of the PDSCH can be indicated as low-priority or high-priority transmission without using a new RNTI (e.g., using a DCI field or a priority indication in a new DCI format). In one implementation, both the UCI of the SPS PDSCH with index 0 and the UCI of the PDSCH can be considered high-priority transmissions, and the priority between UCIs may not be required.

[0089] Case 2-2-2: In one implementation, the priority of the UCI of the SPS PDSCH can be configured by parameters in the SPS configuration (e.g., SPS-Config). In one implementation, if a specific parameter for identifying priority is configured in SPS-Config (e.g., the parameter indicates whether the priority of the SPS PDSCH UCI is high or low), then the UCI of the corresponding SPS PDSCH—when there is a conflict between the UCI used for the PDSCH and the UCI used for the SPS PDSCH—can take precedence over the configuration with the specific parameter. In one implementation, the configured parameter can identify the priority of the corresponding SPS PDSCH UCI, and the UCI of the SPS PDSCH identified as having higher priority can take precedence over the UCI of the PDSCH. The UCI of the PDSCH can be indicated as low-priority transmission or high-priority transmission (e.g., using priority indication fields in DCI or a new DCI format). In one implementation, the priority of the UCI used for the PDSCH can be indicated by fields in the DCI format used to schedule the PDSCH reception. The UE can determine whether to prioritize the UCI used for PDSCH or the UCI used for SPSPDSCH based on the priority of each UCI.

[0090] Case 2-2-3: In one implementation, the field in the DCI format indicating the initiation of the SPS PDSCH can be used to indicate the priority order between the PDSCH and the SPS PDSCH. This field can be a new field or a reused field in the DCI format. In one implementation, the new field may include a bit to indicate whether the initiated SPS PDSCH is prioritized. For example, a bit with a value of "1" can be considered "prioritized SPS PDSCH," while a bit with a value of "0" can be considered "de-prioritized SPS PDSCH." Alternatively, a bit with a value of "0" can be considered "prioritized SPS PDSCH," while a bit with a value of "1" can be considered "de-prioritized SPS PDSCH." In one implementation, existing fields in the DCI format can be reused. The UE can verify the prioritized SPS PDSCH based on existing fields in the DCI format. In one implementation, when a conflict occurs between the UCI used for the PDSCH and the UCI used for the SPS PDSCH, the UCI of the SPS PDSCH corresponding to the DCI with the specific field indicating priority can be given priority.

[0091] Case 2-2-4: Priority can depend on the periodicity scheduled in the SPS configuration (e.g., SPS-Config). In one implementation, if the periodicity in the SPS-Config is less than a threshold (e.g., 2 symbols), the UCI of the SPS PDSCH can be prioritized when a conflict occurs between the UCI of the PDSCH and the UCI of the SPSPDSCH.

[0092] Case 2-2-5: Priority can depend on the K1 value of the SPS PDSCH. In one implementation, when a conflict occurs between the UCI used for PDSCH and the UCI used for SPS PDSCH, the UCI used for PDSCH transmission with a K1 value less than a threshold (e.g., 2 symbols) can be given priority.

[0093] The implementation methods described in cases 2-2-1 to 2-1-5 can be individual methods or combined to form a specific method.

[0094] Figure 1This is a flowchart of a method 100 performed by a UE to configure UCI priority for an SPS PDSCH, according to an exemplary embodiment of the present invention. In action 102, the UE may receive RRC configuration from the BS to configure a first SPS PDSCH. For example, the RRC configuration may include an IE SPS-Config. The UE may also receive a DCI format with CRC bits scrambled by CS-RNTI to initiate the first SPS PDSCH. After the first SPS PDSCH is initiated, the UE may periodically receive PDSCHs without receiving the corresponding PDCCHs. The periodicity of the SPS PDSCHs may be indicated in the RRC configuration.

[0095] In action 104, the UE may generate a first UCI in response to the first SPS PDSCH. The first UCI may include HARQ-ACK information for the first SPS PDSCH, such as ACK / NACK feedback to the BS. The RRC configuration received in action 102 may include a first parameter indicating the priority of the first UCI. The UE may generate a HARQ-ACK codebook associated with the priority indicated by the explicit indication in the RRC configuration (e.g., the first parameter).

[0096] Figure 2 This is a flowchart of a method 200 performed by a UE to configure the priority of a UCI for a PDSCH, according to an exemplary embodiment of the present invention. In action 202, the UE can receive a DCI format for scheduling PDSCH reception from the BS. The DCI format in action 202 may have CRC bits scrambled by C-RNTI. In action 204, in response to PDSCH reception, the UE can generate a second UCI. The second UCI may include HARQ-ACK information for PDSCH reception. The DCI format received in action 202 may include a field indicating the priority of the second UCI. The UE can generate a HARQ-ACK codebook associated with the priority indicated by the DCI format.

[0097] Action 206 can optionally be performed by the UE. In one implementation, when in Figure 1 When the first UCI is generated in action 104, action 206 can be executed by the UE. Figure 1The first UCI and the second UCI generated in action 204 partially or completely overlap in the time domain (also known as a UCI conflict). In one implementation, a UCI conflict may occur when the first UCI and the second UCI are to be transmitted in the same time slot. In action 206, the UE may send one of the first UCI and the second UCI to the BS based on the priority of the first UCI and the second UCI. For example, if the first UCI has a higher priority than the second UCI, the UE may send the first UCI, and vice versa. In one implementation, if the first UCI and the second UCI have the same priority, the UE may send both the first UCI and the second UCI.

[0098] Figure 3 Figure 300 illustrates a process for handling UCI conflicts according to an example implementation of the present invention. In action 332, UE 310 receives RRC configuration from BS 320 to configure SPS PDSCH. In action 334, UE 310 generates a first UCI in response to the SPS PDSCH. In action 336, UE 310 receives the DCI format of the scheduled PDSCH. In action 338, UE 310 generates a second UCI in response to the PDSCH. In action 340, after determining that the first UCI and the second UCI partially or completely overlap in the time domain, UE 310 may send a priority UCI to BS 320 based on the priority of the first UCI and the priority of the second UCI. Figure 3 The actions shown should not be interpreted as necessarily dependent on a specific order. The order in which the processes are described should not be interpreted as a constraint. For example, in other implementations, action 338 may be performed before action 334. That is, the second UCI may be generated before the first UCI is generated.

[0099] It should be noted that when the UE supports multiple initiated SPS PDSCH configurations, UCI conflicts may also occur between the UCI used for the first SPS PDSCH and the UCI used for the second SPS PDSCH. In one implementation, in Figure 1 The RRC configuration received in action 102. Figure 2 The priority of the first UCI used for the first SPS PDSCH and the priority of the second UCI used for the second SPS PDSCH can be indicated. When the first UCI used for the first SPS PDSCH and the second UCI used for the second SPS PDSCH partially or completely overlap in the time domain, the UE can send a priority UCI based on the priority of the first UCI and the priority of the second UCI.

[0100] In one implementation, the UE can support multiple initiated SPS PDSCH configurations, and the UE may need to handle conflicts between multiple initiated SPS PDSCHs. The UE can receive RRC configuration from the BS to configure a second SPS PDSCH. In one implementation, the RRC configuration can be combined with... Figure 1 The same as received in action 102. 1 is used to configure the first SPS PDSCH. When the first SPS PDSCH and the second SPS PDSCH partially or completely overlap in the time domain, the RRC configuration may include a second parameter indicating the preferred SPS PDSCH.

[0101] In one implementation, the second parameter can be a specific priority index, which can be an integer greater than or equal to 0. The SPS PDSCH associated with the specific priority index can be considered a priority PDSCH. In one implementation, the second parameter for the priority SPS PDSCH can correspond to index 0. That is, the SPS PDSCH associated with index 0 can be considered a priority SPS PDSCH.

[0102] Figure 4 This is a block diagram illustrating a node for wireless communication according to the present invention. Figure 4 As shown, node 400 may include a transceiver 420, a processor 428, a memory 434, one or more presentation components 438, and at least one antenna 436. Node 400 may also include an RF spectrum band module, a BS communication module, a network communication module and a system communication management module, input / output (I / O) ports, I / O components, and a power supply. Figure 4 (Not shown in the image).

[0103] Each component can communicate with each other directly or indirectly through one or more buses 440. Node 400 can be an execution reference. Figure 1 and 2 The various functions of the UE or BS are publicly available. 1 to 3.

[0104] Transceiver 420 has a transmitter 422 (e.g., transmit / transmit circuitry) and a receiver 424 (e.g., receive / receive circuitry) and can be configured to transmit and / or receive time and / or frequency resource allocation information. Transceiver 420 can be configured to transmit in different types of subframes and time slots, including but not limited to available, unavailable, and flexibly available subframe and time slot formats. Transceiver 420 can be configured to receive data and control channels.

[0105] Node 400 may include a variety of calculator-readable media. Calculator-readable media may be any available media that can be accessed by node 400 and includes volatile and non-volatile media, removable and non-removable media.

[0106] Calculator-readable media can include calculator storage media and communication media. Calculator storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as calculator-readable instructions, data structures, program modules or data.

[0107] Calculator storage media include RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital multifunction disc (DVD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices. Calculator storage media do not include transmitted data signals. Communication media typically contain calculator-readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transmission mechanisms, and include any information transmission medium.

[0108] The term "modulated data signal" refers to a signal in which one or more characteristics are set or altered to encode information. Communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, radio frequency, and infrared wireless media. Any combination of the previously listed components should also be included within the scope of calculator-readable media.

[0109] Memory 434 may include calculator storage media in the form of volatile and / or non-volatile memory. Memory 434 may be removable, non-removable, or a combination thereof. Example memories include solid-state memory, hard disk drives, optical disk drives, etc. Figure 4 As shown, memory 434 can store various functions configured to cause processor 428 to perform the functions disclosed herein, for example, reference Figure 1 and 2 Alternatively, instruction 432 cannot be executed directly by processor 428, but is configured to cause node 400 (e.g., when compiled and executed) to perform the various functions disclosed herein.

[0110] Processor 428 (e.g., having processing circuitry) may include intelligent hardware devices such as a central processing unit (CPU), microcontroller, ASIC, etc. Processor 428 may include memory. Processor 428 can process data 430 and instructions 432 received from memory 434, as well as information transmitted and received via transceiver 420, baseband communication module, and / or network communication module. Processor 428 can also process information to be sent to transceiver 420 for transmission via antenna 436 to network communication module for transmission to the core network.

[0111] One or more presentation components 438 present data indications to a person or another device. Examples of presentation components 438 include display devices, speakers, printing components, and vibration components.

[0112] As will be apparent from the above description, various techniques can be used to implement the concepts without departing from the scope of the concepts described herein. Furthermore, although these concepts have been specifically described with reference to certain embodiments, those skilled in the art will recognize that changes in form and detail can be made without departing from the scope of those concepts. Therefore, the described embodiments are to be considered illustrative rather than restrictive in all respects. It should also be understood that this application is not limited to the specific embodiments described above, and many rearrangements, modifications, and substitutions are possible without departing from the scope of the invention.

Claims

1. A user equipment comprising: a transceiver; one or more non-transitory computer-readable media that collectively store computer-executable instructions; and at least one processor coupled to the transceiver and the one or more non-transitory computer-readable media, the at least one processor configured to execute the computer-executable instructions, and the computer-executable instructions cause the user equipment to: receive, from a base station via the transceiver, a radio resource control configuration to configure a first semi-persistent scheduling physical downlink shared channel, the radio resource control configuration comprising a first parameter indicating a priority of first uplink control information corresponding to the first semi-persistent scheduling physical downlink shared channel; receive, from the base station via the transceiver, a downlink control information format for a scheduled physical downlink shared channel reception, the downlink control information format comprising a field indicating a priority of second uplink control information corresponding to the scheduled physical downlink shared channel reception; generate the first uplink control information in response to the first semi-persistent scheduling physical downlink shared channel; and generate the second uplink control information in response to the scheduled physical downlink shared channel reception, when the first uplink control information and the second uplink control information overlap in time domain, transmit, to the base station via the transceiver, the first uplink control information or the second uplink control information based on the priority of the first uplink control information and the priority of the second uplink control information.

2. The user device of claim 1, wherein: wherein the first uplink control information and the second uplink control information comprise hybrid automatic repeat request acknowledgement information.

3. The user device of claim 1, wherein: wherein the at least one processor is further configured to execute the computer-executable instructions to: receive, from the base station via the transceiver, the radio resource control configuration to configure a second semi-persistent scheduling physical downlink shared channel; wherein the radio resource control configuration comprises a second parameter indicating a prioritized semi-persistent scheduling physical downlink shared channel when the first semi-persistent scheduling physical downlink shared channel and the second semi-persistent scheduling physical downlink shared channel partially or completely overlap in time domain.

4. The user device of claim 3, wherein: wherein the second parameter of the prioritized semi-persistent scheduling physical downlink shared channel corresponds to an index of 0. 5.A method of wireless communication performed by a user equipment comprising: receiving, from a base station, a radio resource control configuration to configure a first semi-persistent scheduling physical downlink shared channel, the radio resource control configuration comprising a first parameter indicating a priority of first uplink control information corresponding to the first semi-persistent scheduling physical downlink shared channel; receiving, from the base station, a downlink control information format for a scheduled physical downlink shared channel reception, the downlink control information format comprising a field indicating a priority of second uplink control information corresponding to the scheduled physical downlink shared channel reception; generating the first uplink control information in response to the first semi-persistent scheduling physical downlink shared channel; generating the second uplink control information in response to the scheduled physical downlink shared channel reception; and when the first uplink control information and the second uplink control information overlap in time domain, transmitting, to the base station, the first uplink control information or the second uplink control information based on the priority of the first uplink control information and the priority of the second uplink control information. When the first uplink control information and the second uplink control information overlap in time domain, transmitting the first uplink control information or the second uplink control information to the base station based on a priority of the first uplink control information and a priority of the second uplink control information.

6. The wireless communication method performed by a user equipment of claim 5, wherein, Wherein, The first uplink control information and the second uplink control information comprise hybrid automatic repeat request acknowledgement information.

7. The wireless communication method performed by a user equipment of claim 5, wherein, Also comprising: Receiving, from the base station, the radio resource control configuration to configure a second semi-persistent scheduling physical downlink shared channel; Wherein, the radio resource control configuration comprises a second parameter, when the first semi-persistent scheduling physical downlink shared channel and the second semi-persistent scheduling physical downlink shared channel partially or completely overlap in time domain, the second parameter indicates a priority semi-persistent scheduling physical downlink shared channel. 8.The wireless communication method performed by a user equipment of claim 7, wherein, Wherein the second parameter of the priority semi-persistent scheduling physical downlink shared channel corresponds to an index 0.

Images