Terminal device, base station device, and communication method

Abstract

A method performed by a user equipment (UE) is described. The method includes receiving, from a base station, information configuring a scheduling cell and a scheduled cell for cross-carrier scheduling and a carrier indicator field (CIF) value of the respective cell; monitoring, for a first DCI format associated with a first serving cell, a first set of PDCCH candidates with a CCE aggregation level (AL) in a first set of CCEs in a CORESET, wherein the first set of CCEs is given based on at least the CIF value of the first serving cell and the first DCI format with a first size is for an uplink grant type 2 PUSCH release; monitoring, for a second DCI format associated with a second serving cell, a second set of PDCCH candidates with the CCE AL in a second set of CCEs in the CORESET, wherein the second set of CCEs is given based on at least the CIF value of the second serving cell and the second DCI format has a second size; and receiving, in the first set of CCEs, a PDCCH by a PDCCH candidate for the second DCI format, in a case that the first size and the second size are the same.

Description

Technical Field

[0001] This disclosure relates to terminal devices, base station devices, communication methods, and integrated circuits. Background Technology

[0002] Currently, as a radio access system and radio network technology for fifth-generation cellular systems, and as an extension standard for Long Term Evolution (LTE), technical investigations and standard development are underway for Advanced LTE Pro (LTE-A Pro) and New Radio Technology (NR) in the 3GPP project.

[0003] In fifth-generation cellular systems, three services have been proposed as hypothetical scenarios: enhanced mobile broadband (eMBB) for high-speed and high-capacity transmission, ultra-reliable and low-latency communication (URLLC) for low-latency and high-reliability communication, and massive machine-type communication (mMTC) for connecting a large number of machine-type devices such as the Internet of Things (IoT).

[0004] For example, a wireless communication device can communicate with one or more devices for multiple service types. However, current existing systems and methods, for example, that allow a DCI format with one purpose for UL search space sharing, offer limited flexibility and efficiency. As shown in this discussion, the systems and methods according to the invention support a DCI format with multiple purposes for search space sharing, which can improve PDCCH blocking probability and save power consumption of the UE searching for PDCCH candidates, and provide communication flexibility and efficiency. Attached Figure Description

[0005] Figure 1 It is a block diagram illustrating a configuration of one or more base stations and one or more user equipment (UEs) in which systems and methods for searching space sharing for cross-carrier scheduling can be implemented;

[0006] Figure 2 This is an illustration of an example 200 showing how to determine the PDCCH monitoring timing for PDCCH candidates based on the corresponding search space set configuration and CORESET configuration;

[0007] Figure 3 This is an illustration of an example 3 showing a special field of one or more UL Authorization Type 2 fields used for scheduling activation / deactivation of PDCCH verification;

[0008] Figure 4 This is an illustration of an example 400 of the REG resource number used for CORESET;

[0009] Figure 5This is a flowchart illustrating a specific implementation of a method 500 for UE 102 to perform search space sharing for cross-carrier scheduling;

[0010] Figure 6 This is a diagram illustrating an example 600 of the link search space set used for cross-carrier scheduling;

[0011] Figure 7 This is a flowchart illustrating a specific implementation of a method 700 for base station 160 to perform search space sharing for cross-carrier scheduling;

[0012] Figure 8 This shows the various components that can be utilized in the UE;

[0013] Figure 9 This shows the various components that can be used in a base station; Detailed Implementation

[0014] This invention describes a method performed by a User Equipment (UE). The method includes: receiving from a base station information for configuring multiple carriers for cross-carrier scheduling and configuring Carrier Indicator Field (CIF) values ​​for the respective carriers; monitoring a first set of PDCCH candidates with a CCE aggregation level (AL) in a first set of CCEs in a CORESET for a first DCI format associated with a first serving cell, wherein the first set of CCEs is given based at least on the CIE value of the first serving cell and the first DCI format of a first size is used to release PUSCH transmissions; monitoring a second set of PDCCH candidates with the CCE AL in a second set of CCEs in the CORESET for a second DCI format associated with a second serving cell, wherein the second set of CCEs is given based at least on the CIF value of the second serving cell and the second DCI format of a second size; transmitting to the base station an indication of the ability to support search space sharing for carrier aggregation operations, such that the UE can receive PDCCHs in the first set of CCEs using PDCCH candidates for the second DCI format, provided that the first and second sizes are the same.

[0015] This invention describes a method performed by a base station. The method includes: transmitting to a user equipment (UE) information for configuring multiple carriers for cross-carrier scheduling and configuring Carrier Indicator Field (CIF) values ​​for the respective carriers; transmitting, for a first DCI format associated with a first serving cell, a first PDCCH candidate having a CCE aggregation level (AL) in a first set of CCEs in a CORESET, wherein the first set of CCEs is given based at least on the CIF value of the first serving cell and the first DCI format having a first size is used to release PUSCH transmission; transmitting, for a second DCI format associated with a second serving cell, a second PDCCH candidate having the CCE AL in a second set of CCEs in the CORESET, wherein the second set of CCEs is given based at least on the CIF value of the second serving cell and the second DCI format having a second size; receiving from the UE an indication of the ability to support search space sharing for carrier aggregation operation; and transmitting the second PDCCH candidate in the first set of CCEs if the first size and the second size are the same.

[0016] This invention describes a user equipment (UE). The UE includes: a receiving circuit configured to receive from a base station information for configuring multiple carriers for cross-carrier scheduling and configuring carrier indicator field (CIF) values ​​for the respective carriers; monitoring a first set of PDCCH candidates with a CCE aggregation level (AL) in a first set of CCEs in a CORESET for a first DCI format associated with a first serving cell, wherein the first set of CCEs is given based at least on the CIF value of the first serving cell and the first DCI format of a first size is used to release PUSCH transmission; monitoring a second set of PDCCH candidates with the CCE AL in a second set of CCEs in a second set of CCEs in a second serving cell for a second DCI format associated with a second serving cell, wherein the second set of CCEs is given based at least on the CIF value of the second serving cell and the second DCI format of a second size; and a transmission circuit configured to transmit to the base station an indication of the ability to support search space sharing for carrier aggregation operation, such that the UE can receive PDCCH in the first set of CCEs with PDCCH candidates for the second DCI format if the first size and the second size are the same.

[0017] This invention describes a base station. The base station includes: a transmission circuit configured to transmit to a user equipment (UE) information for configuring multiple carriers for cross-carrier scheduling and configuring carrier indicator field (CIF) values ​​for the respective carriers; for a first DCI format associated with a first serving cell, transmitting a first PDCCH candidate with a CCE aggregation level (AL) in a first set of CCEs in a CORESET, wherein the first set of CCEs is given based at least on the CIF value of the first serving cell and the first DCI format of a first size is used to release PUSCH transmission; for a second DCI format associated with a second serving cell, transmitting a second PDCCH candidate with the CCE AL in a second set of CCEs in the CORESET, wherein the second set of CCEs is given based at least on the CIF value of the second serving cell and the second DCI format of a second size; a receiving circuit configured to receive from the UE an indication of the ability to support search space sharing for carrier aggregation operation; and a transmission circuit configured to transmit the second PDCCH candidate in the first set of CCEs if the first size and the second size are the same.

[0018] 3GPP Long Term Evolution (LTE) is the name of a project awarded to improve the Universal Mobile Telecommunications System (UMTS) mobile phone or device standard to meet future needs. In one aspect, UMTS has been modified to provide support and specifications for Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 3GPP NR (New Radio) is the name of a project awarded to improve the LTE mobile phone or device standard to meet future needs. In one aspect, LTE has been modified to provide support and specifications for New Radio Access (NR) and Next Generation Radio Access Network (NG-RAN) (TS 38.331, 38.321, 38.300, 37.300, 38.211, 38.212, 38.213, 38.214, etc.).

[0019] At least some aspects of the systems and methods disclosed herein can be described in conjunction with 3GPP LTE, LTE-A Advanced, LTE-Pro Advanced, New Radio (NR), and other 3G / 4G / 5G standards (e.g., 3GPP Releases 8, 9, 10, 11, 12, 13, 14, and / or 15 and / or Narrowband Internet of Things (NB-IoT)). However, the scope of this disclosure should not be limited in this respect. At least some aspects of the systems and methods disclosed herein can be used in other types of wireless communication systems.

[0020] Wireless communication equipment can be electronic devices used to transmit voice and / or data to a base station, which in turn can communicate with the network of the equipment (e.g., the Public Switched Telephone Network (PSTN), the Internet, etc.). In describing the systems and methods herein, wireless communication equipment may alternatively be referred to as a mobile station, UE (User Equipment), access terminal, subscriber station, mobile terminal, remote station, user terminal, terminal, subscriber unit, mobile device, relay node, etc. Examples of wireless communication equipment include cellular phones, smartphones, personal digital assistants (PDAs), laptop computers, netbooks, e-readers, wireless modems, etc. In 3GPP specifications, wireless communication equipment is generally referred to as UE. However, since the scope of this disclosure should not be limited to 3GPP standards, the terms "UE" and "wireless communication equipment" are used interchangeably herein to refer to the more general term "wireless communication equipment."

[0021] In 3GPP specifications, base stations are typically referred to as gNB, Node B, eNB, Home Enhanced or Evolved Node B (HeNB), or other similar terms. Since the scope of this disclosure should not be limited to the 3GPP standard, the terms "base station," "gNB," "Node B," "eNB," and "HeNB" are used interchangeably herein to refer to the more general term "base station." Furthermore, an example of "base station" is an access point. An access point can be an electronic device that provides access to a network (e.g., a local area network (LAN), the Internet, etc.) for wireless communication devices. The term "communication equipment" can be used to refer to wireless communication equipment and / or base stations.

[0022] It should be noted that, as used herein, a “cell” can be any communication channel that is designated by standardization or regulatory bodies for use with Advanced International Mobile Communications (IMT-Advanced), IMT-2020 (5G), and all or subsets thereof, making it a licensed frequency band (e.g., a frequency band) adopted by 3GPP for communication between the base station and the UE. It should also be noted that in the general descriptions of NR, NG-RAN, E-UTRA, and E-UTRAN, as used herein, a “cell” can be defined as “a combination of downlink resources and optional uplink resources.” The link between the carrier frequencies of the downlink resources and the carrier frequencies of the uplink resources can be indicated in the system information transmitted on the downlink resources.

[0023] "Configured cells" are those cells that the UE is aware of and has been permitted by the base station to transmit or receive information. A "configured cell" can be a serving cell. The UE can receive system information and perform necessary measurements on the configured cells. For radio connectivity, a "configured cell" can consist of a primary cell and / or zero, one, or more secondary cells. "Active cells" are those configured cells on which the UE is currently transmitting and receiving. That is, active cells are those on which the UE monitors its Physical Downlink Control Channel (PDCCH) and, in the case of downlink transmissions, on which the UE decodes its Physical Downlink Shared Channel (PDSCH). "Deactivated cells" are those configured cells on which the UE does not monitor the transmission of the PDCCH. It should be noted that "cells" can be described in different dimensions. For example, a "cell" can have temporal, spatial (e.g., geographical), and frequency characteristics.

[0024] Base stations can connect to the 5G core network (5G-CN) via the NG interface. 5G-CN can be referred to as the Next Generation Core Network (NGC) or the 5G Core Network (5GC). Base stations can also connect to the Evolved Packet Core (EPC) via the S1 interface. For example, a base station can connect to the Next Generation (NG) Mobility Management Function (MME) via the NG-2 interface and to the NG Core User Plane (UP) Function (UP) via the NG-3 interface. The NG interface supports many-to-many relationships between the NG Mobility Management Function, the NG Core UP Function, and the base station. The NG-2 interface is the NG interface used for the control plane, and the NG-3 interface is the NG interface used for the user plane. For example, for EPC connections, a base station can connect to the MME via the S1-Mobility Management Entity (MME) interface and to the Serving Gateway (S-GW) via the S1-U interface. The S1 interface supports many-to-many relationships between the MME, the Serving Gateway, and the base station. The S1-MME interface is the S1 interface used for the control plane, and the S1-U interface is the S1 interface used for the user plane. The Uu interface is the radio interface used between the UE and the base station for radio protocols.

[0025] A radio protocol architecture may include a user plane and a control plane. The user plane protocol stack may include a Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and a Physical (PHY) layer. A Data Radio Bearer (DRB) is a radio bearer that carries user data (as opposed to control plane signaling). For example, a DRB may be mapped to the user plane protocol stack. The PDCP, RLC, MAC, and PHY sublayers (terminating at base station 460a on the network) perform user plane functions (e.g., header compression, encryption, scheduling, ARQ, and HARQ). PDCP entities reside in the PDCP sublayer. RLC entities may reside in the RLC sublayer. MAC entities may reside in the MAC sublayer. PHY entities may reside in the PHY sublayer.

[0026] The control plane may include a control plane protocol stack. The PDCP sublayer (terminating at the base station on the network side) performs control plane functions (e.g., encryption and integrity protection). The RLC and MAC sublayers (terminating at the base station on the network side) perform the same functions as the user plane. Radio Resource Control (RRC) (terminating at the base station on the network side) performs the following functions: RRC performs broadcast functions, paging, RRC connection management, radio bearer (RB) control, mobility functions, UE measurement reporting and control. The Non-Access Stratum (NAS) control protocol (terminating at the MME on the network side) performs Evolved Packet System (EPS) bearer management, authentication, Evolved Packet System Connection Management (ECM)-IDLE mobility processing, paging initiation and security control in ECM-IDLE, etc.

[0027] The Signalling Radio Bearer (SRB) is a radio bearer (RB) that can only be used to transmit RRC and NAS messages. Three SRBs can be defined. SRB0 can be used for RRC messages using the Common Control Channel (CCCH) logical channel. SRB1 can be used for RRC messages (which may include piggybacked NAS messages) and NAS messages prior to SRB2 establishment, all of which use the Dedicated Control Channel (DCCH) logical channel. SRB2 can be used for RRC messages including recorded measurement information and NAS messages, all of which use the DCCH logical channel. SRB2 has a lower priority than SRB1 and can be configured by the network (e.g., the base station) after security activation. The Broadcast Control Channel (BCCH) logical channel can be used to broadcast system information. Some BCCH logical channels can transmit system information that can be sent from the network to the UE via the BCH (Broadcast Channel) transmission channel. The BCH can be transmitted on the Physical Broadcast Channel (PBCH). Some BCCH logical channels can transmit system information that can be sent from the network to the UE via the DL-SCH (Downlink Shared Channel) transmission channel. Paging can be provided using the Paging Control Channel (PCCH) logical channel.

[0028] For example, the DL-DCCH logical channel can be used (but is not limited to) RRC reconfiguration messages, RRC re-establishment messages, RRC release, UE capability query messages, DL information delivery messages, or security mode command messages. The UL-DCCH logical channel can be used (but is not limited to) measurement report messages, RRC reconfiguration complete messages, RRC re-establishment complete messages, RRC setup complete messages, security mode complete messages, security mode failure messages, UE capability information messages, UL handover preparation delivery messages, UL information delivery messages, counter check response messages, UE information response messages, proximity indication messages, RN (relay node) reconfiguration complete messages, MBMS count response messages, inter-frequency RSTD measurement indication messages, UE auxiliary information messages, intra-device coexistence indication messages, MBMS interest indication messages, and SCG failure information messages. The DL-CCCH logical channel can be used (but is not limited to) RRC re-establishment messages, RRC re-establishment rejection messages, RRC rejection messages, or RRC setup messages. The UL-CCCH logical channel can be used (but is not limited to) RRC re-establishment request messages or RRC setup request messages.

[0029] System information can be divided into main information blocks (MIB) and multiple system information blocks (SIB).

[0030] The UE can receive one or more RRC messages from the base station to obtain RRC configuration or parameters. The UE's RRC layer can be configured with its RRC layer and / or lower layers (e.g., PHY layer, MAC layer, RLC layer, and PDCP layer) according to the RRC configuration or parameters that can be configured by RRC messages, broadcast system information, etc. The base station can transmit one or more RRC messages to the UE to enable the UE to configure its RRC layer and / or lower layers according to the RRC configuration or parameters that can be configured by RRC messages, broadcast system information, etc.

[0031] When carrier aggregation is configured, the UE can have an RRC connection with the network. A single radio interface provides carrier aggregation. During RRC establishment, re-establishment, and handover, a serving cell can provide Non-Access Stratum (NAS) mobility information (e.g., Tracking Area Identifier (TAI)). During RRC re-establishment and handover, a serving cell can provide security input. This cell can be referred to as the primary cell (PCell). In the downlink, the component carrier corresponding to the PCell can be the Downlink Primary Component Carrier (DL PCC), while in the uplink, this component carrier can be the Uplink Primary Component Carrier (UL PCC).

[0032] Depending on the UE capabilities, one or more SCells can be configured to form a group of serving cells together with PCells. In the downlink, the component carrier corresponding to the SCell can be a downlink secondary component carrier (DL SCC), while in the uplink, the component carrier can be an uplink secondary component carrier (UL SCC).

[0033] Therefore, the group of serving cells used for UE configuration can consist of one PCell and one or more SCells. For each SCell, the use of uplink resources (other than downlink resources) performed by the UE can be configurable. The number of configured DL SCCs can be greater than or equal to the number of UL SCCs, and it is possible to configure SCells solely for uplink resource use without configuring them.

[0034] From the UE's perspective, each uplink resource can belong to a serving cell. The number of configurable serving cells depends on the UE's aggregation capabilities. A PCell can only be changed using handover procedures (e.g., using security key changes and random access procedures). A PCell can be used for PUCCH transmission. A primary / secondary cell (PSCell) can also be used for PUCCH transmission. A PSCell can be referred to as the primary SCG cell or SpCell of a secondary cell group. PCells or PSCells cannot be deactivated. Re-establishment can be triggered when a PCell experiences a radio link failure (RLF), not when an SCell experiences an RLF. Furthermore, NAS information can be obtained from the PCell.

[0035] SCell reconfiguration, addition, and removal can be performed by RRC. During synchronization handover or reconfiguration, the Radio Resource Control (RRC) layer can also add, remove, or reconfigure SCells for use with a target PCell. When a new SCell is added, dedicated RRC signaling can be used to send all the necessary system information for the SCell (e.g., when in connected mode, the UE does not need to directly obtain broadcast system information from the SCell).

[0036] The systems and methods described herein enhance the efficient use of radio resources in carrier aggregation (CA) operations. Carrier aggregation refers to the simultaneous use of more than one component carrier (CC). In carrier aggregation, more than one cell can be aggregated into a UE. In one example, carrier aggregation can be used to increase the effective bandwidth available to the UE. In conventional carrier aggregation, it is assumed that a single base station provides multiple serving cells for the UE. Even in scenarios where two or more cells can be aggregated (e.g., macro cells aggregated with remote radio headend (RRH) cells), the cells can be controlled (e.g., scheduled) by a single base station.

[0037] The systems and methods described herein enhance the efficient use of radio resources in carrier aggregation operations. Carrier aggregation refers to the simultaneous utilization of more than one component carrier (CC). In carrier aggregation, more than one cell can be aggregated into a UE. In one example, carrier aggregation can be used to increase the effective bandwidth available to the UE. In conventional carrier aggregation, it is assumed that a single base station provides multiple serving cells for the UE. Even in scenarios where two or more cells can be aggregated (e.g., macro cells aggregated with remote radio headend (RRH) cells), the cells can be controlled (e.g., scheduled) by a single base station. However, in smaller cell deployment scenarios, each node (e.g., base station, RRH, etc.) can have its own independent scheduler. To maximize the radio resource utilization efficiency of two nodes, the UE can connect to two or more nodes with different schedulers. The systems and methods described herein enhance the efficient use of radio resources in dual connectivity operations. The UE can be configured with multiple groups of serving cells, each group can have carrier aggregation operations (e.g., if the group includes more than one serving cell).

[0038] In Dual Connectivity (DC), the UE may be required to have UL-CA for simultaneous PUCCH / PUCCH and PUCCH / PUSCH transmissions across cell groups (CGs). In smaller cell deployment scenarios, each node (e.g., eNB, RRH, etc.) may have its own independent scheduler. To maximize radio resource utilization efficiency between two nodes, the UE may connect to two or more nodes with different schedulers. The UE may be configured with multiple groups of serving cells, each of which may have carrier aggregation operation (e.g., if the group includes more than one serving cell). When a primary cell group and a secondary cell group are configured, a UE in RRC_CONNECTED state may be configured with Dual Connectivity or MR-DC. A cell group (CG) may be a subset of the UE's serving cells configured with Dual Connectivity (DC) or MR-DC, i.e., a primary cell group (MCG) or a secondary cell group (SCG). A primary cell group may be the UE's serving cell group including PCells and zero or more secondary cells. A secondary cell group (SCG) can be a secondary cell group of the UE configured with DC or MR-DC, which includes a PSCell and zero or more other secondary cells. A primary / secondary cell (PSCell) can be an SCG cell in which the UE is instructed to perform random access during an SCG change procedure. A "PSCell" can also be referred to as a primary SCG cell. In dual connectivity or MR-DC, two MAC entities can be configured in the UE: one for the MCG and one for the SCG. Each MAC entity can be configured by an RRC of a serving cell that supports PUCCH transmission and contention-based random access. In the MAC layer, the term "Special Cell" (SpCell) can refer to such a cell, while the term SCell can refer to other serving cells. The term SpCell can refer to the PCell of the MCG or the PSCell of the SCG, depending on whether the MAC entity is associated with the MCG or SCG, respectively. The timing lead group (TAG) of the SpCell containing the MAC entity can be called the primary TAG (pTAG), while the term secondary TAG (sTAG) refers to other TAGs.

[0039] The DC can be further enhanced to support multiple RAT dual connectivity (MR-DC). MR-DC can be a generalization of E-UTRA intra-DC as described in 36.300, where multiple Rx / Tx UEs can be configured to utilize resources provided by two different nodes via a non-ideal backhaul connection, one providing E-UTRA access and the other providing NR access. One node acts as the primary node (MN), and the other acts as the secondary node (SN). MN and SN are connected via a network interface, and at least Mn is connected to the core network. In the DC, the PSCell can be a primary or secondary cell. In EN-DC, the PSCell can be the primary SCG cell or SpCell of the secondary cell group.

[0040] E-UTRAN can support MR-DC via E-UTRA-NR Dual Connectivity (EN-DC), where the UE connects to an eNB acting as the MN and an en-gNB acting as the SN. The en-gNB is the node that provides NR user plane and control plane protocol termination to the UE and acts as a secondary node in the EN-DC. The eNB connects to the EPC via the S1 interface and to the en-gNB via the X2 interface. The en-gNB can also connect to the EPC via the S1-U interface and to other en-gNBs via the X2-U interface.

[0041] A timer will run once started and will continue until it stops or expires; otherwise, it will not run. If a timer is not running, it can be started; if a timer is running, it can be restarted. A timer can always be started or restarted from its initial value.

[0042] For NR, techniques for aggregating NR carriers can be studied. Lower-layer aggregation such as carrier aggregation (CA) for LTE and upper-layer aggregation such as DC are investigated. From a layer 2 / 3 perspective, aggregation of carriers with different digits can be supported in NR.

[0043] The main services and functions of the RRC sublayer may include the following:

[0044] - Broadcasting of system information related to the access stratum (AS) and non-access stratum (NAS);

[0045] - Paging initiated by CN or RAN;

[0046] The establishment, maintenance, and release of the RRC connection between the UE and the NR RAN include:

[0047] - Adding, modifying, and releasing carrier aggregation;

[0048] - Adding, modifying, and releasing dual connectivity in NR or between LTE and NR;

[0049] - Includes security features for key management;

[0050] - Establishment, configuration, maintenance, and release of signaling radio bearers and data radio bearers;

[0051] - Mobility features, including:

[0052] - Switch;

[0053] - UE cell selection and reselection, and control over cell selection and reselection;

[0054] -Context transfer during switching;

[0055] -QoS management functions;

[0056] - UE measurement reports and control of reports;

[0057] - Message passing from NAS / UE to UE / NAS.

[0058] Each MAC entity of the UE can be configured by an RRC with Discontinuous Receive (DRX) functionality, which controls the UE's PDCCH monitoring activities for the MAC entity's C-RNTI (Radio Network Temporary Identifier), CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. For cell-level scheduling, the following identifiers are used:

[0059] -C (cell)-RNTI: A unique UE identifier used as an identifier for RRC connections and for scheduling (dynamic scheduling, dynamic scheduling unicast transmission);

[0060] -CS (Configured Scheduling)-RNTI: A unique UE identifier used for semi-persistent scheduling (configured scheduling unicast transmission) in the downlink;

[0061] -INT-RNTI: Identifier of preemption in the downlink;

[0062] -P-RNTI: Identifier for paging and system information change notifications in the downlink;

[0063] -SI-RNTI: Identifier for broadcast and system information in the downlink;

[0064] -SP-CSI-RNTI: A unique UE identifier used for semi-persistent CSI reporting on PUSCH;

[0065] For power and time slot format control, use the following identifiers:

[0066] -SFI-RNTI: Identifier of slot format;

[0067] -TPC-PUCCH-RNTI: A unique UE identifier used to control PUCCH power;

[0068] -TPC-PUSCH-RNTI: A unique UE identifier used to control PUSCH power;

[0069] -TPC-SRS-RNTI: A unique UE identifier used to control SRS power;

[0070] The following identifiers were also used during the random access process:

[0071] -RA-RNTI: Identifier of random access response in the downlink;

[0072] - Temporary C-RNTI: A UE identifier temporarily used for scheduling during the random access procedure;

[0073] -Random value for contention resolution: A UE identifier temporarily used for contention resolution purposes during the random access procedure.

[0074] For NRs connected to 5GC, the following UE identifier is used in the NG-RAN class:

[0075] -I-RNTI: Used to identify the UE context of RRC INACTIVE.

[0076] The sizes of various fields in the time domain are expressed in time units T. c =1 / (Δf) max ·N f ) represents, where Δf max =480·10 3 Hz and N f =4096. Constant. K =T s / T c =64, where T s =1 / (Δf) ref ·N f,ref ), Δf ref =15·10 3 Hz and N f,ref =2048.

[0077] As shown in Table 4.2-1 of [TS 38.211], multiple OFDM parameters are supported, where the cyclic prefix of μ and the bandwidth portion are obtained from the higher-level parameters subcarrierSpacing and cyclicPrefix, respectively.

[0078] The size of each field in the time domain can be represented as multiple time units T. s = 1 / (15000×2048) seconds. Downlink and uplink transmissions are organized into T... f =(Δf max N f / 100)·T c = Frames with a duration of 10ms, each including T sf =(Δf max N f / 1000)·T c = Ten subframes with a duration of 1 ms. The number of consecutive OFDM symbols in each subframe is Each frame is divided into two equal-sized half-frames of five subframes, with each frame having half-frame 0 which includes subframes 0-4 and half-frame 1 which includes subframes 5-9.

[0079] For the subcarrier spacing (SCS) configuration μ, the time slots are numbered in ascending order within the subframe. And numbered in ascending order within the frame. This refers to the number of time slots per subframe, specifically the subcarrier spacing μ. Within a time slot, there exists... 10 consecutive OFDM symbols, of which The cyclic prefix depends on the information given in Tables 4.3.2-1 and 4.3.2-2 of [TS38.211]. Time slots in subframes. The start time and OFDM symbols in the same subframe The start time alignment is crucial. Subcarrier spacing refers to the interval (or frequency bandwidth) between two consecutive subcarriers in the frequency domain. For example, subcarrier spacing can be set to 15kHz, 30kHz, 60kHz, 120kHz, or 240kHz. Multiple consecutive subcarriers (e.g., 12) in the frequency domain define a resource block. For carriers with different frequencies, the applicable subcarriers can be different. For example, for carriers in frequency range 1, only the subcarrier spacing in the set {15kHz, 30kHz, 60kHz} applies. For carriers in frequency range 2, only the subcarrier spacing in the set {60kHz, 120kHz, 240kHz} applies. Base stations cannot configure inapplicable subcarrier spacing for carriers.

[0080] OFDM symbols in a time slot can be categorized as “downlink,” “flexible,” or “uplink.” Signaling in the time slot format is described in subclause 11.1 of [TS 38.213].

[0081] Within a downlink frame time slot, the UE may assume that downlink transmissions occur only in the "downlink" or "flexible" symbols. Within an uplink frame time slot, the UE may transmit only in the "uplink" or "flexible" symbols.

[0082] Various examples of the systems and methods disclosed herein will now be described with reference to the accompanying drawings, wherein the same reference numerals indicate elements with similar functions. The systems and methods generally described and illustrated in the accompanying drawings can be arranged and designed in a variety of different specific embodiments. Therefore, the more detailed description of several specific embodiments presented in the figures below is not intended to limit the scope of the claims, but merely to represent the systems and methods described.

[0083] Figure 1This is a block diagram illustrating one or more base stations 160 (e.g., eNB, gNB) and one or more user equipment (UE) 102 in which systems and methods for searching space sharing for cross-carrier scheduling can be implemented. One or more UEs 102 may use one or more antennas 122a-n to communicate with one or more base stations 160. For example, UE 102 uses one or more antennas 122a-n to transmit electromagnetic signals to and receive electromagnetic signals from base station 160. Base station 160 uses one or more antennas 180a-n to communicate with UE 102.

[0084] It should be noted that in some configurations, one or more of the UEs 102 described herein can be implemented in a single device. For example, in some implementations, multiple UEs 102 can be combined into a single device. Additionally or alternatively, in some configurations, one or more of the base stations 160 described herein can be implemented in a single device. For example, in some implementations, multiple base stations 160 can be combined into a single device. Figure 1 In scenarios such as those described herein, a single device may include one or more UEs 102. Alternatively or additionally, according to the systems and methods described herein, one or more base stations 160 may be implemented as a single device or multiple devices.

[0085] UE 102 and base station 160 can communicate with each other using one or more channels 119 and 121. For example, UE 102 can use one or more uplink (UL) channels 121 and signals to send information or data to base station 160. Examples of uplink channels 121 include the Physical Uplink Control Channel (PUCCH) and the Physical Uplink Shared Channel (PUSCH). Examples of uplink signals include the Demodulation Reference Signal (DMRS) and the Sounding Reference Signal (SRS). One or more base stations 160 can also use, for example, one or more downlink (DL) channels 119 and signals to transmit information or data to one or more UEs 102. Examples of downlink channels 119 include PDCCH, PDSCH, etc. PDCCH can be used to schedule DL transmissions on PDSCH and UL transmissions on PUSCH, wherein the downlink control information (DCI, DCI format) on PDCCH includes downlink allocation (DL allocation) and uplink scheduling authorization (UL authorization). The PDCCH is used to transmit downlink control information (DCI) in the context of downlink radio communication (radio communication from the base station to the UE). Here, one or more DCIs (which may be referred to as DCI formats) are defined for the transmission of downlink control information. Information bits are mapped to one or more fields defined in the DCI format. Examples of downlink signals include the primary synchronization signal (PSS), secondary synchronization signal (SSS), cell-specific reference signal (CRS), non-zero power channel state information reference signal (NZP CSI-RS), and zero power channel state information reference signal (ZP CSI-RS), etc. Other types of channels or signals may also be used.

[0086] Each of one or more UEs 102 may include one or more transceivers 118, one or more demodulators 114, one or more decoders 108, one or more encoders 150, one or more modulators 154, one or more data buffers 104, and one or more UE operation modules 124. For example, one or more receive paths and / or transmit paths may be implemented in UE 102. For simplicity, only a single transceiver 118, decoder 108, demodulator 114, encoder 150, and modulator 154 are shown in UE 102, but multiple parallel elements (e.g., multiple transceivers 118, decoders 108, demodulators 114, encoders 150, and modulators 154) may be implemented.

[0087] Transceiver 118 may include one or more receivers 120 and one or more transmitters 158. One or more receivers 120 may use one or more antennas 122a-n to receive signals (e.g., downlink channels, downlink signals) from base station 160. For example, receiver 120 may receive and downconvert signals to generate one or more received signals 116. One or more received signals 116 may be provided to demodulator 114. One or more transmitters 158 may use one or more antennas 122a-n to transmit signals (e.g., uplink channels, uplink signals) to base station 160. For example, one or more transmitters 158 may upconvert and transmit one or more modulated signals 156.

[0088] Demodulator 114 can demodulate one or more received signals 116 to generate one or more demodulated signals 112. One or more demodulated signals 112 can be provided to decoder 108. UE 102 can use decoder 108 to decode the signals. Decoder 108 can generate one or more decoded signals 106, 110. For example, signal 106 decoded by the first UE may include received payload data, which may be stored in data buffer 104. Signal 110 decoded by the second UE may include overhead data and / or control data. For example, signal 110 decoded by the second UE can provide data that UE operation module 124 can use to perform one or more operations.

[0089] As used herein, the term "module" may mean a particular element or component that can be implemented in hardware, software, or a combination of both. However, it should be noted that any element referred to herein as a "module" may alternatively be implemented in hardware. For example, the UE operation module 124 may be implemented in hardware, software, or a combination of both.

[0090] Generally, the UE operation module 124 enables the UE 102 to communicate with one or more base stations 160. The UE operation module 124 may include a UE RRC information configuration module 126. The UE operation module 124 may include a UE DCI control module 128. In some embodiments, the UE operation module 124 may include a physical (PHY) entity, a media access control (MAC) entity, a radio link control (RLC) entity, a packet data convergence protocol (PDCP) entity, and a radio resource control (RRC) entity. The UE RRC information configuration module 126 may process information received from the base stations (e.g., RRC parameters for multiple carrier configurations, CIF values ​​for each carrier, search space configuration, and CORESET configuration). For example, the UE RRC information configuration module 126 may process RRC parameters for search space configuration. The UE DCI control module (processing module) 128 may determine, based on the processing output from the UE RRC information configuration module 126, when and where to monitor or search for PDCCH candidates for each search space set in the CORESET. For a UE capable of supporting search space sharing, if the first DCI format associated with the first serving cell and the second DCI format associated with the second serving cell have the same DCI size, the UE DCI control module 126 can determine that PDCCH is received in the first group of CCEs through PDCCH candidates for the second DCI format, and the first group of CCEs is assigned to PDCCH candidates for the first DCI format.

[0091] The UE operation module 124 may provide information 148 to one or more receivers 120. For example, the UE operation module 124 may notify the receivers 120 when to receive or not receive transmissions based on Radio Resource Control (RRC) messages (e.g., broadcast system information, RRC reconfiguration messages), MAC control elements, and / or DCI (Downlink Control Information). The UE operation module 124 may provide information 148 to one or more receivers 120, including PDCCH monitoring timing and DCI format size. The UE operation module 124 may notify the receivers 120 when or where to receive / monitor PDCCH candidates with which DCI format and DCI size.

[0092] The UE operation module 124 can provide information 138 to the demodulator 114. For example, the UE operation module 124 can inform the demodulator 114 of the expected modulation pattern for the transmission from the base station 160.

[0093] The UE operation module 124 may provide information 136 to the decoder 108. For example, the UE operation module 124 may inform the decoder 108 of the expected encoding for the transmission from the base station 160. For example, the UE operation module 124 may inform the decoder 108 of the expected PDCCH candidate encoding with which DCI size for the transmission from the base station 160.

[0094] The UE operation module 124 may provide information 142 to the encoder 150. Information 142 may include data to be encoded and / or instructions for encoding. For example, the UE operation module 124 may instruct the encoder 150 to encode transmission data 146 and / or other information 142.

[0095] Encoder 150 can encode transmission data 146 and / or other information 142 provided by UE operation module 124. For example, encoding data 146 and / or other information 142 may involve error detection and / or correction coding, mapping data to spatial, temporal and / or frequency resources for transmission, multiplexing, etc. Encoder 150 can provide the encoded data 152 to modulator 154.

[0096] The UE operation module 124 may provide information 144 to the modulator 154. For example, the UE operation module 124 may inform the modulator 154 of the modulation type (e.g., constellation mapping) to be used for transmission to the base station 160. The modulator 154 may modulate encoded data 152 to provide one or more modulated signals 156 to one or more transmitters 158.

[0097] The UE operation module 124 may provide information 140 to one or more transmitters 158. This information 140 may include instructions for the one or more transmitters 158. For example, the UE operation module 124 may instruct one or more transmitters 158 when to transmit a signal to a base station 160. The one or more transmitters 158 may upconvert one or more modulated signals 156 and transmit the one or more modulated signals to one or more base stations 160.

[0098] Base station 160 may include one or more transceivers 176, one or more demodulators 172, one or more decoders 166, one or more encoders 109, one or more modulators 113, one or more data buffers 162, and one or more base station operation modules 182. For example, one or more receive paths and / or transmit paths may be implemented in base station 160. For simplicity, only a single transceiver 176, decoder 166, demodulator 172, encoder 109, and modulator 113 are shown in base station 160, but multiple parallel elements (e.g., multiple transceivers 176, decoders 166, demodulators 172, encoders 109, and modulators 113) may be implemented.

[0099] Transceiver 176 may include one or more receivers 178 and one or more transmitters 117. One or more receivers 178 may use one or more antennas 180a-n to receive signals (e.g., uplink channels, uplink signals) from UE 102. For example, receiver 178 may receive and downconvert signals to generate one or more received signals 174. One or more received signals 174 may be provided to demodulator 172. One or more transmitters 117 may use one or more antennas 180a-n to transmit signals (e.g., downlink channels, downlink signals) to UE 102. For example, one or more transmitters 117 may upconvert and transmit one or more modulated signals 115.

[0100] Demodulator 172 can demodulate one or more received signals 174 to generate one or more demodulated signals 170. The one or more demodulated signals 170 can be provided to decoder 166. Base station 160 can use decoder 166 to decode the signals. Decoder 166 can generate one or more decoded signals 164, 168. For example, signal 164 decoded by the first base station may include received payload data, which may be stored in data buffer 162. Signal 168 decoded by the second base station may include overhead data and / or control data. For example, signal 168 decoded by the second base station may provide data that base station operation module 182 can use to perform one or more operations (e.g., PUSCH transmission data).

[0101] Generally, base station operation module 182 enables base station 160 to communicate with one or more UEs 102. Base station operation module 182 may include base station RRC information configuration module 194. Base station operation module 182 may include base station DCI control module 196. Base station operation module 182 may include PHY entity, MAC entity, RLC entity, PDCP entity, and RRC entity. For example, base station operation module 196 may determine for the UE when and where to monitor or search configured PDCCH candidates for each search space set of each serving cell.

[0102] The base station DCI control module 196 can determine, for the corresponding UE, when and how to monitor or search for PDCCH candidates configured in the search space set in the CORSET. The base station RRC information configuration module 194 can generate information (e.g., RRC parameters for multiple carrier configurations, CIF values ​​for each carrier, search space configuration, and CORESET configuration) based on the output from the base station DCI control module 196. For UEs capable of supporting search space sharing, if the first DCI format associated with the first serving cell and the second DCI format associated with the second serving cell have the same DCI size, the base station DCI control module 196 can determine that PDCCHs are transmitted in the first set of CCEs via PDCCH candidates for the second DCI format, and the first set of CCEs is assigned to PDCCH candidates for the first DCI format.

[0103] The base station operation module 182 can provide the benefit of effectively performing PDCCH candidate search and monitoring.

[0104] The base station operation module 182 shall provide information 190 to one or more receivers 178. For example, the base station operation module 182 may notify the receiver 178 when to receive or not receive transmissions based on RRC messages (e.g., broadcast system information, RRC reconfiguration messages), MAC control elements, and / or DCI (downlink control information).

[0105] The base station operation module 182 may provide information 188 to the demodulator 172. For example, the base station operation module 182 may inform the demodulator 172 of the expected modulation pattern for transmissions from one or more UEs 102.

[0106] The base station operation module 182 may provide information 186 to the decoder 166. For example, the base station operation module 182 may inform the decoder 166 of the expected encoding for transmissions from one or more UEs 102.

[0107] The base station operation module 182 can provide information 101 to the encoder 109. Information 101 may include data to be encoded and / or instructions for encoding. For example, the base station operation module 182 may instruct the encoder 109 to encode transmission data 105 and / or other information 101.

[0108] Generally, the base station operation module 182 enables the base station 160 to communicate with one or more network nodes (e.g., NG Mobility Management Function, NG Core UP Function, Mobility Management Entity (MME), Serving Gateway (S-GW), gNB). The base station operation module 182 can also generate an RRC reconfiguration message to be sent to the UE 102.

[0109] Encoder 109 can encode transmission data 105 and / or other information 101 provided by base station operation module 182. For example, encoding data 105 and / or other information 101 may involve error detection and / or correction coding, mapping data to spatial, temporal and / or frequency resources for transmission, multiplexing, etc. Encoder 109 can provide encoded data 111 to modulator 113. Transmission data 105 may include network data to be relayed to UE 102.

[0110] The base station operation module 182 may provide information 103 to the modulator 113. This information 103 may include instructions for the modulator 113. For example, the base station operation module 182 may inform the modulator 113 of the modulation type (e.g., constellation mapping) to be used for transmission to the UE 102. The modulator 113 may modulate encoded data 111 to provide one or more modulated signals 115 to one or more transmitters 117.

[0111] The base station operation module 182 may provide information 192 to one or more transmitters 117. This information 192 may include instructions for the one or more transmitters 117. For example, the base station operation module 182 may instruct one or more transmitters 117 when (and when not) to send signals to one or more UEs 102. The base station operation module 182 may provide information 192 to one or more transmitters 117, including PDCCH monitoring timing and DCI format size. The base station operation module 182 may inform the transmitters 117 when or where to transmit PDCCH candidates with which DCI format and DCI size. One or more transmitters 117 may upsample and modulate a signal 115 and transmit the modulated signal to one or more UEs 102.

[0112] It should be noted that one or more of the elements or components included in base station 160 and UE 102 may be implemented in hardware. For example, one or more of these elements or components may be implemented as chips, circuits, or hardware components, etc. It should also be noted that one or more of the functions or methods described herein may be implemented in hardware and / or executed using hardware. For example, one or more of the methods described herein may be implemented in chipsets, application-specific integrated circuits (ASICs), large-scale integrated circuits (LSIs), or integrated circuits, and / or implemented using chipsets, application-specific integrated circuits (ASICs), large-scale integrated circuits (LSIs), or integrated circuits, etc.

[0113] The base station can generate an RRC message including one or more RRC parameters and transmit the RRC message to the UE. The UE can receive the RRC message including one or more RRC parameters from the base station. The term "RRC parameter" in this disclosure may alternatively be referred to as "RRC information element". The RRC parameter may also include one or more RRC parameters. In this disclosure, the RRC message may include system information, and the RRC message may include one or more RRC parameters. The RRC message may be transmitted on a Broadcast Control Channel (BCCH) logical channel, a Common Control Channel (CCCH) logical channel, or a Dedicated Control Channel (DCCH) logical channel.

[0114] In this disclosure, the description "base station can configure UE" may also imply / mean "base station can transmit RRC messages including one or more RRC parameters to UE". Alternatively or alternatively, "RRC parameters configure UE" may also mean "base station can transmit RRC messages including one or more RRC parameters to UE". Alternatively or alternatively, "UE is configured to" may also mean "UE can receive RRC messages including one or more RRC parameters from base station".

[0115] The base station can transmit an RRC message to the UE, including one or more RRC parameters related to the BWP configuration. The UE can receive an RRC message from the base station, including one or more RRC parameters related to the BWP configuration. For each cell, the base station can configure at least an initial DLBWP and an initial uplink bandwidth portion (initial ULBWP) to the UE. In addition, for each cell, the base station can configure additional UL and DL BWPs to the UE.

[0116] The RRC parameter `initialDownlinkBWP` indicates the initial downlink BWP (initial DL BWP) configuration for the serving cell (e.g., SpCell and Scell). The base station can configure the RRC parameter `locationAndBandwidth` included in `initialDownlinkBWP` such that the initial DL BWP encompasses the entire CORESET 0 of the serving cell in the frequency domain. `locationAndBandwidth` can be used to indicate the frequency domain location and bandwidth of the BWP. The RRC parameter `initialUplinkBWP` indicates the initial uplink BWP (initial UL BWP) configuration for the serving cell (e.g., SpCell and Scell). The base station can transmit to the UE `initialDownlinkBWP` and / or `initialUplinkBWP`, which may be included in `SIB1`, the RRC parameter `ServingCellConfigCommon`, or the RRC parameter `ServingCellConfig`.

[0117] SIB1 is the Cell-Specific System Information Block (SIB), which can contain information related to scheduling when assessing whether a UE is allowed to access the cell and defining other system information. SIB1 can also contain radio resource configuration information common to all UEs and prohibition information applied to unified access control. The RRC parameter ServingCellConfigCommon is used to configure cell-specific parameters of the UE's serving cell. The RRC parameter ServingCellConfig is used to configure (add or modify) the UE using the serving cell, which can be the SpCell or SCell of an MCS or SCG. The RRC parameter ServingCellConfig in this paper is primarily UE-specific, but also partially cell-specific.

[0118] The base station can configure the UE using the RRC parameters BWP-Downlink and BWP-Uplink. The RRC parameter BWP-Downlink can be used to configure an additional DL BWP. The RRC parameter BWP-Uplink can be used to configure an additional UL BWP. The base station can transmit BWP-Downlink and BWP-Uplink, which may be included in the RRC parameter ServingCellConfig, to the UE.

[0119] If the UE does not configure (provide) the initial Downlink BWP from the base station, the initial DL BWP is defined by the location and number of consecutive physical resource blocks (PRBs), starting with the lowest-indexed PRB among the PRBs of the subcarrier spacing (SCS) and cyclic prefix of the PDCCH received in the CORESET for the Type 0-PDCCH CSS set (i.e., CORESET 0) and the CORESET for the Type 0-PDCCH CSS set, and ending at the PRB with the highest index. If the UE configures (provides) the initial Downlink BWP from the base station, the initial DL BWP is provided by the initial Downlink BWP. If the UE configures (provides) the initial Uplink BWP from the base station, the initial UL BWP is provided by the initial Uplink BWP.

[0120] The UE can be configured by a base station, at least one initial BWP, and up to four additional BWPs. One of the initial BWP and the configured additional BWPs can be activated as the active BWP. The UE can monitor the DCI format and / or receive PDSCH in the active DL BWP. The UE can not monitor the DCI format and / or receive PDSCH in a DL BWP other than the active DL BWP. The UE can transmit PUSCH and / or PUCCH in the active UL BWP. The UE can not transmit PUSCH and / or PUCCH in BWPs other than the active UL BWP.

[0121] As described above, the UE can monitor the DCI format in the active DL BWP. More specifically, the UE can monitor a set of PDCCH candidates from one or more CORESETs on the active DL BWP of each active serving cell configured with PDCCH monitoring, based on the corresponding search space set, where monitoring means decoding each PDCCH candidate according to the monitored DCI format.

[0122] The PDCCH candidate set to be monitored by the UE is defined based on the PDCCH search space set. The search space set can be either a CSS set or a USS set. The UE can monitor the PDCCH candidate set from one or more of the following search space sets.

[0123] -Type0-PDCCH CSS set, configured for DCI format with CRC scrambled by SI-RNTI on the primary cell of MCG, via pdcch-ConfigSIB1 in MIB, searchSpaceSIB1 in PDCCH-ConfigCommon, or searchSpaceZero in PDCCH-ConfigCommon.

[0124] -Type0A-PDCCH CSS set, configured via searchSpaceOtherSystemInformation in PDCCH-ConfigCommon for DCI format configuration with CRC scrambled by SI-RNTI on the primary cell of MCG.

[0125] -Type1-PDCCH CSS set, if the ra-SearchSpace in PDCCH-ConfigCommon is configured for a DCI format with a CRC scrambled by RA-RNTI or TC-RNTI on the primary cell.

[0126] -Type2-PDCCH CSS set, configured via pagingSearchSpace in PDCCH-ConfigCommon for DCI format configuration with CRC scrambled by P-RNTI on the primary cell of MCG.

[0127] The -Type3-PDCCH CSS set is configured via SearchSpace in PDCCH-Config for DCI format configurations with CRCs scrambled by INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, or TPC-SRS-RNTI (and only for primary cells, with CRCs scrambled by C-RNTI, MCS-C-RNTI, or CS-RNTI), where searchSpaceType = common.

[0128] - The USS set is configured in DCI format by SearchSpace in PDCCH-Config. This DCI format has a CRC scrambled by C-RNTI, MCS-C-RNTI, SP-CSI-RNTI or CS-RNTI, where searchSpaceType = ue-Specific.

[0129] For DL ​​BWP, if the UE is configured (provided) with the aforementioned search space set, the UE can determine the PDCCH monitoring timing for a set of PDCCH candidates within the configured search space set. The PDCCH monitoring timing for monitoring the PDCCH candidates of search space set s is determined based on the configuration of search space set s and the CORESET configuration associated with search space set s. In other words, the UE can monitor a set of PDCCH candidates for a search space set within the determined (configured) PDCCH monitoring timing in one or more configured control resource sets (CORESETs) based on the corresponding search space set configuration and CORESET configuration. The base station can transmit information to the UE specifying one or more CORESET configurations and / or search space configurations. This information can be included in MIBs and / or SIBs broadcast by the base station. This information can be included in RRC configurations or RRC parameters. The base station can broadcast system information such as MIBs and SIBs to indicate the CORESET configuration or search space configuration to the UE. Alternatively, the base station can transmit an RRC message to the UE including one or more RRC parameters related to the CORESET configuration and / or search space configuration.

[0130] The following describes an example of search space set configuration.

[0131] The base station can transmit an RRC message including one or more RRC parameters related to the search space configuration. The base station can determine one or more RRC parameters related to the UE's search space configuration. The UE can receive an RRC message from the base station including one or more RRC parameters related to the search space configuration. The RRC parameters related to the search space configuration (e.g., SearchSpace, searchSpaceZero) define how and where to search for PDCCH candidates. "Searching / monitoring PDCCH candidates for DCI format" can also be simply referred to as "monitoring / searching DCI format".

[0132] For example, the RRC parameter `searchSpaceZero` is used to configure the initial common search space of the DL BWP to 0. `searchSpaceZero` corresponds to 4 bits. The base station can transmit `searchSpaceZero` via PBCH (MIB) or ServingCellConfigCommon.

[0133] Additionally, the RRC parameter SearchSpace defines how and where to retrieve PDCCH candidates. The RRC parameter SearchSpace can include multiple RRC parameters, such as searchSpaceId, controlResourceSetId, monitoringSlotPeriodicityAndOffset, duration, monitoringSymbolsWithinSlot, nrofCandidates, and searchSpaceType. Some of the above RRC parameters may or may not be present in the RRC parameter SearchSpace. That is, the RRC parameter SearchSpace can include all of the above RRC parameters. If some of the parameters are absent from the RRC parameter SearchSpace, UE 102 may apply a default value for each of those parameters.

[0134] In this paper, the RRC parameter `searchSpaceId` is the identifier or index of the search space. The `searchSpaceId` parameter is used to identify the search space. More specifically, the `searchSpaceId` parameter provides the search space set index `s`, 0 ≤ `s` < 40. The search space `s` mentioned below can then refer to the search space identified by the index `s` indicated by the `searchSpaceId` parameter. The RRC parameter `controlResourceSetId` relates to the identifier of the CORESET and is used to identify the CORESET. The `controlResourceSetId` parameter indicates the association between the search space `s` and the CORESET identified by `controlResourceSetId`. The `controlResourceSetId` parameter indicates the CORESET applicable to the search space. The CORESET `p` mentioned below can refer to the CORESET identified by the index `p` indicated by the `controlResourceSetId` parameter. Each search space is associated with one CORESET. The RRC parameter `monitoringSlotPeriodicityAndOffset` indicates the time slot configured for periodic and offset PDCCH monitoring. Specifically, the `monitoringSlotPeriodicityAndOffset` parameter indicates `k`. s The PDCCH monitoring cycle of each time slot and o s The PDCCH monitoring offset for each time slot. The UE can determine which time slot is configured for PDCCH monitoring based on the RRC parameter `monitoringSlotPeriodicityAndOffset`. The RRC parameter `monitoringSymbolsWithinSlot` indicates the first symbol used for PDCCH monitoring within the time slot configured for PDCCH monitoring. That is, the parameter `monitoringSymbolsWithinSlot` provides the PDCCH monitoring pattern within the time slot, thereby indicating the first symbol of the CORESET within the time slot used for PDCCH monitoring (the configured time slot). The RRC parameter `duration` indicates the number of consecutive time slots T that the search space persists (or exists) in each timing (PDCCH timing, PDCCH monitoring timing). s .

[0135] The RRC parameter can include aggregationLevel1, aggregationLevel2, aggregationLevel4, aggregationLevel8, and aggregationLevel16. For CCE aggregation levels 1, 2, 4, 8, and 16 respectively, the RRC parameter nrofCandidates can provide multiple PDCCH candidates for each CCE aggregation level L through aggregationLevel1, aggregationLevel2, aggregationLevel4, aggregationLevel8, and aggregationLevel16. In other words, the value L can be set to any of the set {1, 2, 4, 8, 16}. The number of PDCCH candidates for each CCE aggregation level L can be configured to 0, 1, 2, 3, 4, 5, 6, or 8. For example, when the number of PDCCH candidates for each CCE aggregation level L is configured to 0, the UE cannot search for PDCCH candidates for CCE aggregation L. That is, in this case, the UE cannot monitor and search for PDCCH candidates for CCE aggregation L in the search space set s. For example, the number of PDCCH candidates for each CCE aggregation level L is configured to be 4, and the UE can monitor 4 PDCCH candidates for CCE aggregation level L in the search space set s.

[0136] The RRC parameter `searchSpaceType` indicates whether the search space set `s` is a CSS set or a USS set. `searchSpaceType` can be either `common` or `ue-Specific`. The `common` parameter configures the search space set `s` as a CSS set and specifies the DCI format to be monitored. The `ue-Specific` parameter configures the search space set `s` as a USS set. `ue-Specific` can also include `dci-Format`. The `dci-Formats` parameter indicates whether to monitor PDCCH candidates in the search space set `s` for DCI formats 0_0 and 1_0, or for DCI formats 0_1 and 1_1, or for DCI formats 0_2 and 1_2. In other words, the RRC parameter `searchSpaceType` indicates whether the search space set `s` is a CSS set or a USS set, and the DCI format to be monitored.

[0137] A set of USS (User Sets) for CCE aggregation level L is defined by a set of PDCCH candidates for CCE aggregation level L. The USS set can be constructed from multiple USS corresponding to the corresponding CCE aggregation level L. The USS set may include one or more USS corresponding to the corresponding CCE aggregation level L. A set of CSS (CSS) for CCE aggregation level L is defined by a set of PDCCH candidates for CCE aggregation level L. The CSS set can be constructed from multiple USS corresponding to the corresponding CCE aggregation level L. The CSS set may include one or more CSS corresponding to the corresponding CCE aggregation level L.

[0138] In this document, "UE monitors the PDCCH used for the search space set s" is also referred to as "UE can monitor a set of PDCCH candidates for the search space set s". Alternatively, "UE monitors the PDCCH used for the search space set s" is also referred to as "UE can attempt to decode each PDCCH candidate of the search space set s according to the monitored DCI format".

[0139] In this disclosure, the term "PDCCH search space set" may also be referred to as "PDCCH search space". The UE monitors PDCCH candidates in one or more of the search space sets. The search space set can be a common search space (CSS) set or a UE-specific search space (USS) set. In some implementations, the CSS set may be shared / configured among multiple UEs. These multiple UEs can search for PDCCH candidates within the CSS set. In some implementations, the USS set is configured for a specific UE. The UE can search for one or more PDCCH candidates within the USS set. In some implementations, the USS set may be derived at least from the value of the C-RNTI addressed to the UE.

[0140] The following describes an example of CORESET configuration.

[0141] The base station can configure one or more CORESETs for each DL BWP in the serving cell for the UE. For example, the RRC parameter ControlResourceSetZero is used to configure CORESET 0 of the initial DL BWP. The RRC parameter ControlResourceSetZero corresponds to 4 bits. The base station can transmit ControlResourceSetZero to the UE, which can be included in the MIB or the RRC parameter ServingCellConfigCommon. The MIB can include system information transmitted on the BCH (PBCH). The RRC parameters related to the initial DL BWP configuration can also include the RRC parameter ControlResourceSetZero. The RRC parameter ServingCellConfigCommon is used to configure the cell-specific parameters of the serving cell of the UE and contains the parameters that the UE will typically obtain from the SSB, MIB, or SIB when accessing the cell from the idle state.

[0142] In addition, the RRC parameter ControlResourceSet is used to configure the time and frequency CORESETs other than CORESET 0. The RRC parameter ControlResourceSet can include multiple RRC parameters, such as ControlResourceSetId, frequencyDomainResource, duration, cce-REG-MappingType, precoderGranularity, tci-PresentlnDCI, pdcch-DMRS-ScramblingID, etc.

[0143] Here, the RRC parameter ControlResourceSetId is the CORESET index p used to identify the CORESET within the serving cell, where 0 < p < 12. The RRC parameter duration indicates the number of consecutive symbols N of the CORESET symb CORESET , which can be configured as 1, 2, or 3 symbols. The CORESET consists of a set of N RB CORESET resource blocks (RBs) in the frequency domain and N symb CORESET symbols in the time domain. The RRC parameter frequencyDomainResource indicates a set of N RB CORESETThere are six RBs. Each bit in the frequencyDomainResource corresponds to a group of six RBs, starting with the first RB group in the BWR. The first (leftmost / most significant) bit corresponds to the first RB group in the BWP, and so on. Bits set to 1 indicate that the RB group belongs to the frequency domain resource of this CORESET.

[0144] According to the CORESET configuration, a CORESET (CORESET 0 or CORESET p) consists of a set of PRBs with a duration of 1 to 3 OFDM symbols. Resource elements (REGs) and control channel elements (CCEs) are defined within a CORESET. A CCE consists of 6 REGs, where a REG equals one resource block during one OFDM symbol period. The control channel is formed by aggregating CCEs. That is, a PDCCH consists of one or more CCEs. Different code rates for the control channel are achieved by aggregating different numbers of CCEs. Interleaved and non-interleaved CCE-to-REG mappings are supported in a CORESET. Each resource element group carrying the PDCCH carries its own DMRS.

[0145] To monitor a set of PDCCH candidates in the search space set, the UE can determine the timing of PDCCH monitoring based on the search space set configuration and the associated CORESET configuration. Figure 2 This is an example 200 illustrating how to determine the PDCCH monitoring timing for PDCCH candidates based on the corresponding search space set configuration and CORESET configuration.

[0146] exist Figure 2 In the PDCCH monitoring period k s Configured for 6 time slots. PDCCH monitors offset o s It is configured for 2 time slots. Duration T s It is configured with 2 time slots. The subcarrier spacing configuration u is configured to 0, which means that the subcarrier spacing of the active DL BWP is 15kHz. In this case, u = 0, N frame,u slot It equals 10. That is, when u = 0, the number of time slots per frame is 10. u s,f It is the number of time slots within a radio frame. That is, n u s,f The value is in {0,…,N frame,u slot Within the range of -1}.

[0147] UE 102 can determine the PDCCH monitoring timing on the active DL BWP based on the PDCCH monitoring periodicity, PDCCH monitoring offset, and PDCCH monitoring mode within the time slots of each configured search space set s. For search space set s, if the number is n u s,f The time slots satisfy formula (1)(n) f *N frame,u slot +n u s,f -o s )mod k s =0, then UE 102 can determine that the PDCCH monitoring opportunity exists at number n. f The frame numbered n u s,f In the time slot. According to equation (1), UE 102 can number n f The frame with value = 0 is numbered n u s,f =2 and n u s,f =8 time slots and numbered n f The frame numbered n = 1 u s,f The time slot with time slot 4 is determined to be the time slot where PDCCH monitoring occurs. Assume T... s Configured with 2 time slots, UE 102 can target T s = PDCCH candidates from two consecutive time-slot surveillance search space sets s, starting from the determined number n u s,f The time slot begins. In other words, UE 102 may not be targeted at the next (k) slot. s -T s PDCCH candidates for a continuous time-slot monitoring search space set s. Figure 2 As shown, UE 102 can display the number n f The frame with value = 0 is numbered n u s,f =Time slots 2, 3, 8 and 9 and slot numbered n f The frame numbered n = 1 u s,f Slots 4 and 5 are designated as slots with PDCCH monitoring opportunities. UE 102 can monitor the PDCCH candidates in the search space set s within the designated slots configured for PDCCH monitoring. A slot with PDCCH monitoring opportunities can also refer to a slot configured for PDCCH monitoring.

[0148] Furthermore, the time slot designated (or configured) for PDCCH monitoring can have one or more PDCCH monitoring opportunities. The PDCCH monitoring mode within a time slot configured for PDCCH monitoring is indicated by a 14-bit string (monitoringSymbolsWithinSlot). Each bit within the 14-bit string can correspond to a symbol within the time slot. The most significant (left) bit (MSB) can represent the first OFDM in the time slot, and the second most significant (left) bit can represent the second OFDM symbol in the time slot, and so on. A bit set to one identifies the first OFDM symbol of the control resource set within the time slot. Figure 2 As shown, the time slot 202 configured for PDCCH monitoring can have two PDCCH monitoring opportunities. The first PDCCH monitoring opportunity 204 is located on the first, second, and third consecutive symbols. The second PDCCH monitoring opportunity 206 is located on the 8th, 9th, and 10th consecutive OFDM symbols. The duration of a PDCCH monitoring opportunity is equal to the duration of the CORESET associated with the search space set s. Generally, the duration of a PDCCH monitoring opportunity (the number of consecutive OFDM symbols in a PDCCH monitoring opportunity) can be one, two, or three symbols. Figure 2 In this context, CORESET includes a PDCCH monitoring opportunity with three consecutive ODM symbols in the time domain.

[0149] according to Figure 2 The UE can monitor a set of PDCCH candidates for the search space set s in a first PDCCH monitoring time 204 within the associated CORESET, and can also monitor a set of PDCCH candidates for the search space set s in a second PDCCH monitoring time 206 within the CORESET in each time slot where PDCCH monitoring is configured for the search space set s. Here, in each PDCCH monitoring time, each PDCCH candidate of the search space set s is mapped to a resource in the associated CORESET. In other words, in one PDCCH monitoring time, one PDCCH candidate of the search space set s is mapped to one associated CORESET. In different PDCCH monitoring times, one PDCCH candidate of the search space set s will not be mapped to more than one associated CORESET. For example, one PDCCH candidate of the search space set s may be mapped to both the first PDCCH monitoring time 204 and the second PDCCH monitoring time 206.

[0150] For ease of explanation, unless a DCI format is specified, the DCI format referred to below may be called "DCI format for uplink (or UL license)". DCI format 0_0, DCI format 0_1, or DCI format 0_2 can be used to schedule or release PUSCH transmissions. UE 102 can monitor PDCCH candidates for DCI format 0_0 in the CSS or USS. UE 102 can monitor PDCCH candidates for DCI format 0_1 ​​and / or DCI format 0_2 in the USS, but may not monitor PDCCH candidates for DCI format 0_1 ​​and / or DCI format 0_2 in the CSS. DCI format 0_1 ​​can schedule two transport blocks for one PUSCH, while DCI format 0_2 can only schedule one transport block for one PUSCH. DCI format 0_2 may not include some fields (e.g., the "CBG transport information" field), which may be present in DCI format 0_1.

[0151] In this disclosure, UE 102 can transmit PUSCH based on UL authorization and / or higher-level configuration. In other words, PUSCH transmission can be dynamically scheduled by UL authorization in DCI (or DCI format or PDCCH or DCI format in PDCCH), or it can correspond to configured authorization type 1 or type 2. More specifically, PUSCH transmission dynamically scheduled by UL authorization can be referred to as "dynamic PUSCH". PUSCH corresponding to configured authorization type 1 can be referred to as "configured authorization type 1 PUSCH (or, for example, UL authorization type 1 PUSCH, UL authorization based on type 1 configuration, type 1 PUSCH with configured authorization, PUSCH configured by configured authorization type 1)". PUSCH corresponding to configured authorization type 2 can be referred to as "configured authorization type 2 PUSCH (or, for example, UL authorization type 2 PUSCH, UL authorization based on type 2 configuration, type 2 PUSCH with configured authorization, PUSCH scheduled by active DCI format)".

[0152] The configured license type 1 PUSCH transport is semi-statically configured to operate upon receipt of higher-layer parameters without detecting UL licenses in the DCI. After receiving the higher-layer parameters, the configured license type 2 PUSCH transport is semi-persistently scheduled by UL licenses in a valid active DCI (or a valid active DCI format).

[0153] If the CRC of the corresponding DCI format is scrambled with CS-RNTI and the New Data Indicator (NDI) field in the DCI format used to enable transport blocks is set to "0", then UE 102 can verify the DCI format (configured UL grant type 2PDCCH) for schedule activation or schedule release. If according to Figure 3 If all fields (special fields) of the DCI format are set according to the corresponding conditions, DCI format verification is achieved. If verification is achieved, UE 102 can treat the information in the DCI format as a valid activation or release of the configured UL license type 2. If verification is not achieved, the UE will discard all information in the DCI format.

[0154] More specifically, if a single configuration for UL-licensed type 2PUSCH is provided to UE 102, if according to Figure 3 (a) By setting a special field in the DCI format, a DCI format with a CRC scrambled by CS-RNTI with NDI=0 can activate the corresponding configured license type 2PUSCH for scheduling activation. This DCI format may be referred to as the "Activated DCI Format" in this document.

[0155] If a single configuration for UL-licensed type 2PUSCH is provided to UE 102, if according to Figure 3 (b) By setting a special field in the DCI format, a DCI format with a CRC scrambled by CS-RNTI with NDI=0 can release the configured license type 2PUSCH for scheduled release. This DCI format may be referred to herein as the "Release DCI Format".

[0156] If more than one configuration is provided to UE 102 for UL authorization type 2PUSCH, if according to Figure 3 (c) By setting a special field in the DCI format, a DCI format with a CRC scrambled by CS-RNTI with NDI=0 can activate a corresponding configuration for UL authorization type 2PUSCH. The value of the HARQ process number field in this DCI format indicates that the configuration for UL authorization type 2PUSCH is activated. This DCI format may be referred to herein as the "activated DCI format".

[0157] If more than one configuration is provided to UE 102 for UL authorization type 2PUSCH, if according to Figure 3 (d) By setting a special field in the DCI format, a DCI format with a CRC scrambled by CS-RNTI with NDI=0 can release one or more corresponding configurations of UL authorization type 2PUSCH. The value of the HARQ process number field in this DCI format indicates that one or more configurations for UL authorization type 2PUSCH are released. This DCI format may be referred to herein as the "Release DCI Format".

[0158] according to Figure 3DCI format 0_0, DCI format 0_1, or DCI format 0_2 can be used to activate or deactivate the DCI format. UE 102 can determine whether a DCI format scrambled by CS-RNTI with NDI=0 is an activated or deactivated DCI format based on the value of one or more special fields of the received DCI format. The deactivated DCI format mentioned below can also be referred to as "Uplink License Type 2 Schedule Release (or Uplink License Type 2 Schedule Release PDCCH)" or "Uplink License Type 2 PUSCH Release".

[0159] Additionally, DCI formats 0_1 and 0_2 can also be used as the activation or deactivation DCI formats for semi-persistent CSI reporting on the PUSCH. UE 102 can determine the received DCI format scrambled by SP-CSI-RNTI as either the activation or deactivation DCI format based on the value of one or more special fields of the received DCI format, for use in activating or deactivating semi-persistent CSI.

[0160] Therefore, the DCI release format described below can include "Uplink License Type 2 Schedule Release (or Uplink License Type 2 Schedule Release PDCCH or Uplink License Type 2 PUSCH Release)" and / or "Semi-persistent CSI Release (Semi-persistent CSI Deactivation of PDCCH)". The DCI release format can also be referred to as "DCI Release of PUSCH Transmission". The DCI activation format can include "Uplink License Type 2 Schedule Activation" and / or "Semi-persistent CSI Activation".

[0161] As described above, the DCI format associated with PUSCH (or, for example, the DCI format associated with PUSCH transmission or the DCI format used for scheduling PUSCH) can be a DCI format for scheduling PUSCH transmission or a DCI format for releasing PUSCH transmission. The DCI format for scheduling PUSCH transmission can include (i) a dynamic DCI format that dynamically schedules PUSCH transmission; and (ii) an active DCI format that semi-persistently schedules (or activates) PUSCH transmission.

[0162] Therefore, in terms of the intended use of the DCI format, based on the RNTI type and value of one or more fields in the DCI format, UE 102 can determine that the DCI format can be used at least for scheduling or releasing PUSCH transmissions.

[0163] Figure 4 This is an illustration of an example 400 REG resource number used for CORESET.

[0164] UE 102 can be configured by a set of N RB CORESETA PRB and a set of N symb CORESET A set of PDCCH candidates for monitoring the search space set in CORESET p, consisting of a contiguous set of OFDM symbols. Resource blocks N configured for CORESET. RB CORESET Each PRB can be continuous or discontinuous in the frequency domain. For a CORESET, REGs within the CORESET are numbered in ascending order, starting with the first OFDM symbol and the smallest resource block (0) in a time-priority manner. Figure 4 In (a), REGs within CORESET are numbered in ascending order, starting from the first OFDM symbol and the resource block with the smallest number (0) in time priority. REGs within CORESET 402 are numbered from 0 to 35 in time priority.

[0165] exist Figure 4 In (b), N CCE,p This refers to the number of CCEs in the CORESET, numbered from 0 to (N). CCE,p -1). The CORESET in this paper includes 6 CCEs. According to the CCE-to-REG mapping, UE 102 can determine which corresponding REGs constitute a CCE. For non-interleaved CCE-to-REG mapping, all CCEs used for DCIs with ALL are mapped to consecutive REG bundles in the CORESET. For example, for non-interleaved CCE-to-REG mapping, CCE (CCE#0)406 with index 0 consists of 6 consecutive REGs with indices 0, 1, 2, 3, 4, and 5. For interleaved CCE-to-REG mapping, the REG bundles of the CCEs constituting the PDCCH are distributed in the frequency domain in units of REG bundles. REG bundle i is defined as {i*B, i*B+1, ..., i*B+B-1}, where B is the REG bundle size indicated by the base station.

[0166] UE 102 can determine the CCE index of the aggregation level L corresponding to the PDCCH candidate of the USS in the USS set based on the C-RNTI value addressed to the UE. The UE can determine the CCE index of the aggregation level L corresponding to the PDCCH candidate of the CSS in the CSS set even without having the C-RNTI value addressed to the UE.

[0167] More specifically, for the search space set s associated with CORESET p, in the slot n for the active DL BWP of the serving cell corresponding to the Carrier Indicator Field (CIF) value, the PDCCH candidate m corresponding to the search space set s,n _ CIThe CCE index of the aggregation level L, n_CI, is given by equation (2): L*((Y p,n +floor(m s,n_CI *N CCE,p ) / (L*M s,max (L) ))+n_CI)mod(floor(N CCE,p / L)))+i. The parameters in equation (2) are as follows: For any CSS, Y p,n It equals 0, while for USS, Y p,n =(A p *Y p,n-1 ) mod D, where Y p,-1 =n RNTI ≠0, for p mod 3 = 0, A p =39827, for p mod 3 = 1, A p =39829, for p mod 3 = 2, A p =39839, and D=65537; slotn can be represented as n u s,f , representing the time slot number within a radio frame relative to the SCS configuration u; i = 0,…,L-1; N CCE,p This refers to the number of CCEs in CORESET p, numbered from 0 to (N). CCE,p -1); n RNTI This is the C-RNTI value provided to the UE by the base station; if the UE 102 is configured with a carrier indicator field for monitoring the serving cell on the PDCCH, then n_CI is the value of that carrier indicator field; otherwise, including for any CSS, n_CI equals 0; m s,n_CI＝ 0,…,M s,n_CI (L) -1, where M s,n_CI (L) For the serving cell corresponding to n_CI, the UE is configured to monitor the number of PDCCHs in the aggregation level L of the search space set s; for any CSS, M s,max (L) =M s,0 (L) For USS, M s,max (L) M is the value of n_CI for all configurations of the CCE aggregation level L for the search space set s. s,n_CI (L) The maximum value.

[0168] Here, in the CORESET associated with the search space set s, a set of CCEs of the ALL are the CCE indices that determine the location of the PDCCH candidates that the UE 102 is configured to monitor for the ALL of the search space set. Here, a set of CCEs of the ALL can also refer to the USS. That is, the search space set s can consist of one or more corresponding sets of CCEs of the corresponding ALL. A set of CCEs can also be called a "USS". A set of CCEs of the ALL can also refer to "the USS of the ALL".

[0169] According to equation (2) above, at least based on the corresponding CIF value of the serving cell, UE 102 can identify the corresponding CCE group of ALL for different serving cells. That is, UE 102 can monitor PDCCH candidates associated with different serving cells on different corresponding CCE groups.

[0170] However, for a UE configured with cross-carrier scheduling, the UE can transmit to base station 160 an indication of its ability to support search space sharing for carrier aggregation operations. That is, if the DCI formats associated with the two serving cells are of the same size, the UE can receive one or more PDCCH candidates initially identified for monitoring the other serving cell on a set of CCEs.

[0171] For example, if the DCI format associated with the first serving cell has the same size as the DCI format associated with the second serving cell, the PDCCH candidate associated with the second serving cell can be transmitted by the base station in the CCE locations (a set of CCEs) initially allocated to the PDCCH candidate associated with the first serving cell. If the UE receives the DCI format associated with the second serving cell in the CCE location allocated to the first serving cell, the UE does not need to further search for the PDCCH candidate associated with the second serving cell in another CCE location allocated to the second serving cell. Thus, the UE can save power consumption. Therefore, search space sharing helps reduce power consumption and can sometimes avoid the probability of PDCCH blocking.

[0172] However, existing NR systems of version 16 for uplink only allow DCI format scheduling for PUSCH transmissions used for search space sharing. In other words, existing NR systems of version 16 do not allow the release of DCI formats as mentioned above regarding search space sharing. Assuming that even if the released DCI format has the same size as another DCI format associated with another serving cell, the UE may further search for the released DCI format in another CCE location, this limitation will result in increased power consumption for the UE. Furthermore, this limitation will restrict the flexibility of the base station in locating PDCCH candidates and will lead to a potential PDCCH blocking probability. Therefore, removing this limitation can provide the base station with flexibility in PDCCH configuration and help reduce the power consumption of the UE.

[0173] Figure 5 This is a flowchart illustrating a specific implementation of a method 500 for UE 102 to perform search space sharing for cross-carrier scheduling.

[0174] UE 102 can receive 502 information from base station 160. This information may be included in the MIB (or SIB) broadcast by base station 160. Alternatively, this information may be one or more RRC parameters included in an RRC message.

[0175] The information received on 502 can configure multiple serving cells for carrier aggregation operation for UE 102. For example, this information can configure a first serving cell and a second serving cell for carrier aggregation for the UE.

[0176] The information received on 502 can further configure UE 102 for cross-carrier scheduling, and configure the carrier indicator field (CIF) value of the corresponding carrier. That is, this information can include the RRC parameter CrossCarrierSchedulingConfig configured for the serving cell to indicate whether the serving cell is cross-carrier scheduled by another serving cell or whether the serving cell cross-carrier schedules another serving cell. The RRC parameter CrossCarrierSchedulingConfig specifies when to use cross-carrier scheduling in the serving cell. More specifically, the RRC parameter CrossCarrierSchedulingConfig provides the serving cell with either RRC parameter A (for self-scheduling) or RRC parameter B (for cross-carrier scheduling). If UE 102 is configured with RRC parameter A for the serving cell, the serving cell is scheduled by its own PDCCH. If UE 102 is configured with RRC parameter B for the serving cell, the serving cell is scheduled by the PDCCH on another serving cell.

[0177] In this disclosure, the term "serving cell" can also refer to "the scheduled cell" when it is cross-carrier scheduled by another serving cell. The term "serving cell" can also refer to "the scheduling cell". In other words, the scheduling cell is the serving cell for which UE 102 has configured RRC parameter A, and the scheduled cell is the serving cell for which UE 102 has configured RRC parameter B.

[0178] RRC parameter A indicates whether a carrier indicator field exists in the DCI format. For cross-carrier scheduling, RRC parameter A indicates the presence of a carrier indicator in the DCI format. The value (CIF value) of the carrier indicator field in the DCI format (UL licensed or DL ​​allocated) of the scheduling cell is 0. Here, "UE 102 is configured with RRC parameter A (or RRC parameter CrossCarrierSchedulingConfig) for cross-carrier scheduling" can mean "UE is configured with a carrier indicator field for monitoring the serving cell's PDCCH on it."

[0179] If UE 102 is configured with a carrier indicator field for monitoring the PDCCH of the serving cell, different DCI formats may include carrier indicator fields with different bit widths. For example, if UE 102 is configured with a carrier indicator field for the serving cell, the UE can monitor PDCCH candidates on the serving cell for DCI format 0_1, which includes a 3-bit carrier indicator field, while UE 102 can monitor PDCCH candidates for DCI format 0_2, which includes a carrier field with configuration bits. In other words, if RRC parameter A indicates the presence of a carrier indicator field, the RRC parameter CrossCarrierSchedulingConfig can further provide RRC parameter C. RRC parameter C is used to configure the number of bits in the carrier indicator field in DCI format 0_2 to be 0, 1, 2, or 3 bits. When the number of bits in the carrier indicator field of DCI format 0_2 is configured (determined) to 0 bits by the RRC parameter C, UE 102 may not use DCI format 0_2 monitored in the scheduling cell to schedule resources across carriers, such as PUSCH or PUCCH on another scheduled cell. In this case, UE 102 may use DCI format 0_1 ​​monitored in the scheduling cell to schedule resources across carriers, such as PUSCH or PUCCH on another scheduled cell. According to various embodiments of this disclosure, if UE 102 is configured with a carrier indicator field for the serving cell, base station 106 may configure UE 102 to monitor PDCCH on the serving cell for cross-carrier scheduling via either DCI format 0_1 ​​or DCI format 0_2 including the carrier indicator field, or base station 106 may configure UE 102 to monitor PDCCH on the serving cell for cross-carrier scheduling via DCI format 0_1 ​​instead of DCI format 0_2.

[0180] For the scheduled cell, RRC parameter B provides the serving cell ID of the scheduled cell, allowing the transmission (monitoring) of PDCCH (e.g., UL authorization or DL ​​allocation) on the scheduled cell for use in scheduling resources, such as PUSCH, PUCCH and / or PDSCH on the scheduled cell.

[0181] RRC parameter B also provides a CIF value for scheduling the cell, indicating the DCI format (UL grant or downlink allocation) applicable to the scheduled cell. If a DCI format (e.g., UL grant or DL ​​allocation) is received in the scheduling cell, the UE can determine which serving cell the received DCI format applies to based on the CIF value of the received DCI format. In other words, if the CIF value in the DCI format corresponds to the value indicated by RRC parameter B configured for scheduled cell A, then the DCI format applies to scheduled cell A.

[0182] For example, if base station 160 plans to assign a DCI format for scheduled cell A to UE 102, base station 160 can transmit the DCI format to UE 102 on the scheduled cell by setting the CIF value in the DCI format to the value indicated by RRC parameter B configured for scheduled cell A. If UE 102 receives the DCI format on the scheduled cell and the CIF value in the received DCI format corresponds to the value indicated by RRC parameter B configured for scheduled cell A, then UE 102 can determine that the received DCI format is suitable for scheduled cell A. The CIF value indicated by RRC parameter B can be configured from 1 to 7.

[0183] Additionally, if base station 160 plans to allocate the DCI format used for scheduling cells to UE 102, base station 160 can transmit the DCI format to UE 102 on the scheduling cell by setting the CIF value in the DCI format to 0. If UE 102 receives the DCI format on the scheduling cell and the CIF value in the received DCI format corresponds to 0, then UE 102 can determine that the received DCI format is suitable for the scheduling cell.

[0184] The information received on 502 can also provide UE 102 with CORESET configuration and search space configuration for scheduling the cell. For example, this information may include one or more RRC parameters (e.g., ControlResourceSetZero, ControlResourceSet) related to the CORESET configuration to configure the time and frequency control resource set used to search for downlink control information on the scheduling cell. Additionally, this information may include one or more RRC parameters (SearchSpace, searchSpaceZero) related to the search space configuration to define how and when to search for PDCCH candidates in the DCI format of the search space on the scheduling cell. The ControlResourceSet configured for scheduling the cell may include several of the aforementioned RRC parameters, such as ControlResourceSetId, frequencyDomainResource, duration, cce-REG-MappingType, precoderGranularity, tci-PresentInDCI, pdcch-DMRS-ScramblingID, etc. The SearchSpace configured for scheduling cells can include several of the RRC parameters mentioned above, such as searchSpaceId, ControlResourceSetId, monitoringSlotPeriodicityAndOffset, duration, monitoringSymbolsWithinSlot, nrofCandidates, and searchSpaceType.

[0185] The information received on 502 may also provide UE 102 with one or more RRC parameters (e.g., SearchSpace) related to the search space configuration of the scheduled cell. The information received on 502 may not provide the UE with the CORESET configuration for the scheduled cell. That is, base station 160 may not transmit the CORESET configuration for the scheduled cell to UE 102. The SearchSpace configured for the scheduled cell may include searchSpaceId, nrofCandidates, and may not include the other aforementioned RRC parameters for the search space set.

[0186] For UE 102 configured with cross-carrier scheduling, UE 102 can monitor PDCCH candidates on the active DL BWP of the scheduling cell for the DCI format associated with multiple serving cells consisting of the scheduling cell and one or more scheduled cells. As above Figure 2The UE 102 can determine the PDCCH monitoring timing for monitoring PDCCH candidates based on the search space set configuration and associated CORESET configuration of the active DL BWP configured for scheduling the cell. More specifically, for each search space set s of the active DL BWP configured for scheduling the cell, the UE 102 can determine the corresponding PDCCH monitoring timing. The UE 102 can monitor the PDCCH candidates of each search space set s at the corresponding PDCCH timing determined in the associated CORESET on the active DL BWP of the scheduling cell.

[0187] Additionally, the search space set *s* configured for the scheduled cell is linked to the search space set *s* configured for the scheduled cell based on the search space set ID. In other words, for cross-carrier scheduling, the scheduled cell and the search space sets within the scheduled cell with the same search space ID are linked to each other. UE102 can monitor PDCCH candidates of the search space sets configured for the scheduled cell at PDCCH monitoring times determined for search space sets with the same search space set ID configured for the scheduled cell.

[0188] UE 102 can monitor the PDCCH candidates configured for the search space set of the scheduled cell only if both the DL BWP configured with the same search space ID in the scheduling cell and the scheduled cell are active. Figure 6 This is a diagram illustrating an example 600 of the link search space set used for cross-carrier scheduling.

[0189] according to Figure 6 UE 102 is configured with two BWPs by higher layers for scheduling cell 602 (DL BWP#1604 and DL BWP#2606). For DL ​​BWP#1604, two search space sets (SS set #1603 and SS set #2605) are configured. For DL ​​BWP#2606, two search space sets (SS set #3607 and SS set #4609) are configured. Additionally, UE 102 is configured with two BWPs by higher layers for scheduled cell 612 (DL BWP#1614 and DL BWP#2616). For DL ​​BWP#1614, two search space sets (SS set #1613 and SS set #3615) are configured. For DL ​​BWP#2616, two search space sets (SS set #2617 and SS set #4619) are configured. Figure 6 In the process, BWP#1 in the scheduling cell and BWP#1 in the scheduled cell are configured as active DLBWPs.

[0190] exist Figure 6In this scenario, the UE can monitor the PDCCH candidates of SS sets #1 603 and #2 605 on active DL BWP #1 604. Conversely, the UE can monitor the PDCCH candidates of SS set #1 613 on active DL BWP #1 604. However, for SS set #3 615, there is no linked SS set with the same search space set ID as SS set #3 615 in the scheduling cell. In this case, SS set #3 615 in active DL BWP #1 614 can be considered an invalid search space set for cross-carrier scheduling. Therefore, the UE can choose not to monitor the PDCCH candidates of SS set #3 615 on active DL BWP #1 604.

[0191] For the link search space set in the scheduling cell and the scheduled cell, the UE can monitor the corresponding PDCCH candidates in the same associated CORESET at the same PDCCH timing. As mentioned above, the USS of the CCE aggregation level is defined by a set of PDCCH candidates aggregated by the CCE. In other words, the USS of the CCE AL L of the search space set corresponds to a set of CCEs of the AL L, which corresponds to the PDCCH candidates of the search space set.

[0192] For CCE AL L, the USS configured for different serving cells can be separated based on the corresponding CIF values. In other words, for a search space set s associated with a CORESET (e.g., a linked search space set), a set of CCEs for PDCCH candidates for the first serving cell and a set of CCEs for PDCCH candidates for the second serving cell can be separated by the corresponding CIF values ​​of the first and second serving cells. A set of CCEs for PDCCH candidates for the first serving cell in the CORESET is given at least based on the CIF value of the first serving cell. A set of CCEs for PDCCH candidates for the second serving cell in the CORESET is given at least based on the CIF value of the second serving cell.

[0193] Based on the information received at 502, UE 102 can determine at 504 to monitor PDCCH candidates associated with one or more serving cells on the active DL BWP of the scheduling cell. For example, UE 102 can monitor a first set of PDCCH candidates with a CCE aggregation level (AL) in a first set of CCEs in CORESET for a first DCI format associated with a first serving cell, wherein the first set of CCEs is given based at least on the CIF value of the first serving cell and a first DCI format with a first size is used for scheduling PUSCH. In this document, the first DCI format used for scheduling PUSCH can consist of a first DCI format for scheduling PUSCH transmission and / or a first DCI format for releasing PUSCH transmission. The first DCI format for releasing PUSCH transmission can be an uplink grant type 2 scheduling release and / or a semi-persistent CSI release. In other words, the first DCI format with a first size can be a release DCI format. Furthermore, the first DCI format with a first size can be a DCI format for scheduling PUSCH transmission.

[0194] UE 102 can determine a second DCI format associated with the second serving cell based on information received on 502, monitor a second set of PDCCH candidates with CCE AL in the second set of CCEs in CORESET, wherein the second set of CCEs is given at least based on the CIF value of the second serving cell and the second DCI format has a second size. The second DCI format is a DCI format used for scheduling PUSCH. The second DCI format can be a DCI format used for scheduling PUSCH transmissions. The second DCI format for releasing PUSCH transmissions can be an uplink grant type 2 scheduling release and / or a semi-persistent CSI release. Alternatively or additionally, the second DCI format can be used to release PUSCH transmissions.

[0195] In this paper, the CORESET at 504 and the CORESET at 506 are the same CORESET associated with the search space set (or the linked search space set). More specifically, the CORESET in this paper may be referred to as "the PDCCH monitoring moment of the search space set in the CORESET". That is, the CORESET at 504 and the CORESET at 506 may also refer to "the same PDCCH monitoring moment in the CORESET".

[0196] At point 508, UE 102 may transmit to base station 160 an indication of support for search space sharing for carrier aggregation operation, enabling UE to receive PDCCH in the first group of CCEs via PDCCH candidates for the second DCI format, provided that the first and second sizes are the same. This is because UE 102 can receive PDCCH in the first group of CCEs via PDCCH candidates for the second DCI format if the first and second sizes are the same.

[0197] In Example A of the search space sharing implementation, the first DCI format and the second DCI format can be the same DCI format other than DCI format 0_0. Both the first and second DCI formats can be DCI format 0_1. Alternatively, both the first and second DCI formats can be DCI format 0_2. For example, the first DCI format is DCI format 0_1. In this case, the second DCI format is DCI format 0_1. If the first DCI format is DCI format 0_2, the second DCI format is DCI format 0_2. That is, at 508, UE 102 can receive PDCCH in the first set of CCEs using a PDCCH candidate with the same DCI format as the first DCI format, provided that the first and second sizes are the same. The DCI format in this document refers to the DCI format of the search space set in the second serving cell.

[0198] In Example A, for a UE configured to monitor PDCCH candidates for DCI format 0_1 ​​for a search space set in a serving cell and for DCI format 0_2 for a different search space set in another serving cell, even if DCI format 0_2 has the same size as DCI format 0_1, UE 102 may not receive PDCCH via PDCCH candidates of DCI format 0_2 (or DCI format 0_1) associated with the second serving cell in the first set of CCEs, but UE 102 may receive DCI format 0_1 ​​(or DCI format 0_2) associated with the first serving cell in the first set of CCEs. In other words, in this case, base station 160 may not transmit PDCCH to UE 102 via PDCCH candidates of DCI format 0_2 associated with the second serving cell in the first set of CCEs, but base station 160 may transmit DCI format 0_1 ​​associated with the first serving cell in the first set of CCEs.

[0199] Additionally, in Example A, UE 102 may transmit capability A to base station 160, which instructs UE 102 to monitor PDCCH candidates for DCI format 0_1 ​​and DCI format 0_2 within the same search space set s in the same serving cell. For UE 102, if the two DCI formats are in the same search space set in the same serving cell, DCI format 0_1 ​​may not have the same size as DCI format 0_2. However, there is a possibility that DCI format 0_1 ​​associated with a serving cell may have the same size as DCI format 0_2 associated with another serving cell. For example, in this case, even if DCI format 0_2 has the same size as DCI format 0_1, UE 102 may not receive PDCCH with the PDCCH candidate of DCI format 0_2 (or DCI format 0_1) associated with the second serving cell in the first set of CCEs, but UE 102 may receive DCI format 0_1 ​​(or DCI format 0_2) associated with the first serving cell in the first set of CCEs. The base station can also avoid the situation where the DCI format 0_1 ​​associated with the serving cell has the same size as the DCI format 0_2 associated with another serving cell by adding one or more zero padding or RRC configurations.

[0200] In Example B of the search space sharing implementation, the first DCI format and the second DCI format can correspond to different DCI formats other than DCI format 0_0. The first DCI format can be DCI format 0_1, and the second DCI format can be DCI format 0_2. On the other hand, the first DCI format can be DCI format 0_2, and the second DCI format can be DCI format 0_1. In this case, the carrier indicator field of DCI format 0_2 is configured to 3 bits. In other words, UE 102 can receive PDCCH in the first group of CCEs via PDCCH candidates for the second DCI format, provided that the first and second sizes are the same and the carrier indicator fields of the first and second DCI formats are configured to the same bit size (e.g., 3 bits), where the first DCI format and the second DCI format correspond to different DCI formats as described above.

[0201] On the other hand, in Example B, if the carrier indicator field of DCI format 0_2 is configured to a size other than 3 bits, then DCI format 0_2 cannot be used for search space sharing even if DCI format 0_2 and DCI format 0_1 ​​have the same size. That is, for a first DCI format and a second DCI format with carrier indicator fields of different sizes, even if the first DCI format and the second DCI format have the same DCI size, UE 102 may not receive a PDCCH in the first group of CCEs via a PDCCH candidate for the second DCI format, where the first DCI format and the second DCI format correspond to different DCI formats as described above. In this case, UE 102 may not distinguish whether the DCI format received in the first group of CCEs is the first DCI format associated with the first serving cell or the second DCI format associated with the second serving cell. Similarly, in the same search space set s within the same serving cell, DCI format 0_1 ​​and DCI format 0_2 may not have the same DCI size.

[0202] In practice, the first serving cell can be a dispatching cell, and the second serving cell can be a dispatched cell. Alternatively, the first serving cell can be a dispatched cell, and the second serving cell can be a dispatching cell. Alternatively, both the first and second serving cells can be dispatched.

[0203] Figure 7 This is a flowchart illustrating a specific implementation of a method 700 for base station 160 to perform search space sharing for cross-carrier scheduling.

[0204] Base station 160 can generate 702 information for UE 102. This information can be included in a MIB (or SIB) broadcast by base station 160. Alternatively, this information can be one or more RRC parameters included in an RRC message. Base station 160 can transmit the 702 generated information to UE 102.

[0205] The information generated at 702 can configure multiple serving cells for carrier aggregation operation for UE 102. The information generated at 702 can further configure UE 102 for cross-carrier scheduling and configure the carrier indicator field (CIF) values ​​for the corresponding configured carriers. The information generated at 702 can also provide UE 102 with CORESET configuration and search space configuration for the scheduled cells. The information generated at 702 can also provide UE 102 with search space configuration for the scheduled cells. The information generated at 702 may not provide UE 102 with CORESET configuration for the scheduled cells.

[0206] Base station 160 may, based on the information transmitted on 702, transmit PDCCH candidates associated with one or more serving cells on the active DL BWP of the scheduling cell. Base station 160 may, on 704, based on the information transmitted on 702, transmit PDCCH candidates with CCE aggregation level (AL) in a first set of CCEs in the CORESET for a first DCI format associated with the first serving cell, wherein the first set of CCEs is given at least based on the CIF value of the first serving cell, and a first DCI format of a first size is used for scheduling PUSCH. The first DCI format for scheduling PUSCH includes a first DCI format for scheduling PUSCH transmission and / or a first DCI format for releasing PUSCH transmission.

[0207] Base station 160 may, based on the information transmitted on 702, transmit PDCCH candidates with CCE aggregation level (AL) in the second set of CCEs in CORESET for a second DCI format associated with the second serving cell, wherein the second set of CCEs is given at least based on the CIF value of the second serving cell and the second DCI format has a second size. The second DCI format is used for scheduling PUSCH. The second DCI format used for scheduling PUSCH includes a second DCI format for scheduling PUSCH transmission and / or a second DCI format for releasing PUSCH transmission.

[0208] At 708, base station 160 can receive from UE 102 an indication of support for search space sharing for carrier aggregation operation, enabling UE 102 to receive PDCCH in the first group of CCEs using PDCCH candidates for the second DCI format, provided the first and second sizes are the same. If base station 160 receives this capability from UE 102, base station 160 can transmit PDCCH in the first group of CCEs using PDCCH candidates for the second DCI format, provided the first and second sizes are the same.

[0209] Figure 8 Various components that can be used with UE 802 are shown. (Combined) Figure 8 The described UE 802 can be combined with Figure 1The UE 102 described herein is implemented. UE 802 includes a processor 881 that controls the operation of UE 802. Processor 881 may also be referred to as a central processing unit (CPU). Memory 887 (which may include read-only memory (ROM), random access memory (RAM), a combination of both, or any type of device capable of storing information) provides instructions 883a and data 885a to processor 881. A portion of memory 887 may also include non-volatile random access memory (NVRAM). Instructions 883b and data 885b may also reside in processor 881. Instructions 883b and / or data 885b loaded into processor 881 may also include instructions 883a and / or data 885a from memory 887, which are loaded for execution or processing by processor 881. Instruction 883b may be executed by processor 881 to implement one or more of the methods 200 described above.

[0210] UE 802 may also include a housing that accommodates one or more transmitters 858 and one or more receivers 820 to allow data transmission and reception. Transmitters 858 and receivers 820 may be combined into one or more transceivers 818. One or more antennas 822a-n are attached to the housing and electrically coupled to the transceivers 818.

[0211] The various components of UE 802 are coupled together via a bus system 889 (which may include a power bus, control signal bus, and status signal bus in addition to the data bus). However, for clarity, the various buses are... Figure 8 The UE 802 is shown as a bus system 889. The UE 802 may also include a digital signal processor (DSP) 891 for processing signals. The UE 802 may also include a communication interface 893 that provides users with access to the functions of the UE 802. Figure 8 The UE 802 shown is a functional block diagram, not a list of specific components.

[0212] Figure 9 The various components that can be used in base station 960 are shown. (Combined) Figure 9 The described base station 960 can be combined with Figure 1The base station 160 described herein is used for implementation. Base station 960 includes a processor 981 that controls the operation of base station 960. Processor 981 may also be referred to as a central processing unit (CPU). Memory 987 (which may include read-only memory (ROM), random access memory (RAM), a combination of both, or any type of device capable of storing information) provides instructions 983a and data 985a to processor 981. A portion of memory 987 may also include non-volatile random access memory (NVRAM). Instructions 983b and data 985b may also reside in processor 981. Instructions 983b and / or data 985b loaded into processor 981 may also include instructions 983a and / or data 985a from memory 987, which are loaded for execution or processing by processor 981. Instruction 983b may be executed by processor 981 to implement one or more of the methods 300 described above.

[0213] Base station 960 may also include a housing that accommodates one or more transmitters 917 and one or more receivers 978 to allow data transmission and reception. Transmitters 917 and receivers 978 may be combined into one or more transceivers 976. One or more antennas 980a-n are attached to the housing and electrically coupled to the transceivers 976.

[0214] The various components of base station 960 are coupled together via bus system 989 (which may include power bus, control signal bus, and status signal bus in addition to data bus). However, for clarity, the various buses are... Figure 9 The system is shown as a bus system 989. Base station 960 may also include a digital signal processor (DSP) 991 for processing signals. Base station 960 may also include a communication interface 993 that provides user access to the functionality of base station 960. Figure 9 The base station 960 shown is a functional block diagram rather than a list of specific components.

[0215] The term "computer-readable medium" means any available medium that can be accessed by a computer or processor. As used herein, the term "computer-readable medium" can mean a non-transitory and tangible computer-readable medium and / or processor-readable medium. By way of example, and not limitation, a computer-readable medium or processor-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store required program code in the form of instructions or data structures and that can be accessed by a computer or processor. As used herein, magnetic disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and... Optical discs, unlike magnetic disks which typically copy data magnetically, use lasers to copy data optically.

[0216] It should be noted that one or more of the methods described herein may be implemented in hardware and / or executed using hardware. For example, one or more of the methods described herein may be implemented in circuits, chipsets, application-specific integrated circuits (ASICs), large-scale integrated circuits (LSIs), or integrated circuits, and / or implemented using circuits, chipsets, application-specific integrated circuits (ASICs), large-scale integrated circuits (LSIs), or integrated circuits.

[0217] Each method disclosed herein includes one or more steps or actions for implementing the method. These method steps and / or actions may be interchanged with each other and / or combined into a single step without departing from the scope of the claims. In other words, unless the proper operation of the method requires a specific order of steps or actions, the order and / or use of a particular step and / or action may be modified without departing from the scope of the claims.

[0218] It should be understood that the claims are not limited to the precise configuration and components shown above. Various modifications, alterations, and changes may be made to the arrangement, operation, and details of the systems, methods, and apparatus described herein without departing from the scope of the claims.

Claims

1. A user equipment (UE), the UE comprising: A receiving unit, configured to receive information from a base station to configure a first serving cell and a second serving cell for cross-carrier scheduling, wherein the information indicates a first carrier indicator field (CIF) value for the first serving cell and a second CIF value for the second serving cell; and Receive Physical Downlink Control Channel (PDCCH); and A control unit is configured to monitor a first set of Physical Downlink Control Channel (PDCCH) candidates with a CCE aggregation level AL in a first set of Control Channel Elements (CCEs) in a Control Resource Set (CORESET) for a first downlink control information (DCI) format associated with the first serving cell, wherein the first set of CCEs is given at least based on the first CIF value of the first serving cell and the first DCI format has a first size; and the control unit is configured to monitor a second set of PDCCH candidates with the CCE AL in a second set of CCEs in the CORESET for a second DCI format associated with the second serving cell, wherein the second set of CCEs is given at least based on the second CIF value of the second serving cell and the second DCI format has a second size and is used for uplink grant type 2 Physical Uplink Shared Channel (PUSCH) release, wherein... When the first size and the second size are the same, the control unit is also configured to monitor the PDCCH for the second DCI format in the first group of CCEs.

2. A base station, the base station comprising: The transmission unit is configured to transmit information to the user equipment (UE) to configure a first serving cell and a second serving cell for cross-carrier scheduling, and the information indicates a first carrier indicator field (CIF) value for the first serving cell and a second CIF value for the second serving cell. and Transmit the Physical Downlink Control Channel (PDCCH); For a first downlink control information (DCI) format associated with the first serving cell, a first physical downlink control channel (PDCCH) candidate with a CCE aggregation level (AL) is transmitted in a first set of control channel elements (CCEs) in the control resource set (CORESET), wherein the first set of CCEs is given at least based on the first CIF value of the first serving cell, and the first DCI format has a first size. For a second DCI format associated with the second serving cell, a second PDCCH candidate with the CCE AL is transmitted in a second set of CCEs in the CORESET, wherein the second set of CCEs is given at least based on the second CIF value of the second serving cell, and the second DCI format has a second size and is used for uplink grant type 2 physical uplink shared channel (PUSCH) release, wherein When the first size and the second size are the same, the transmission unit is also configured to transmit a PDCCH for the second DCI format in the first group of CCEs.

3. A method performed by a user equipment (UE), the method comprising: Information is received from the base station to configure a first serving cell and a second serving cell for cross-carrier scheduling, and the information indicates a first carrier indicator field CIF value for the first serving cell and a second CIF value for the second serving cell. Receive Physical Downlink Control Channel (PDCCH); For a first downlink control information (DCI) format associated with the first serving cell, a first set of PDCCH candidates with a CCE aggregation level AL are monitored in a first set of control channel elements (CCEs) in a control resource set (CORESET), wherein the first set of CCEs is given at least based on the first CIF value of the first serving cell and the first DCI format has a first size; For a second DCI format associated with the second serving cell, monitor a second set of PDCCH candidates with the CCE AL in a second set of CCEs in the CORESET, wherein the second set of CCEs is given at least based on the second CIF value of the second serving cell, and the second DCI format has a second size and is used for uplink grant type 2 physical uplink shared channel (PUSCH) release; When the first size and the second size are the same, monitor the PDCCH for the second DCI format in the first group of CCEs.

Images