IMPROVED PHYSICAL CHANNELS IN MULTIPLE TRP

Abstract

The systems, methods, and devices described herein relate to physical channel enhancements in Multiple TRPs. Reliability enhancements are provided for the physical downlink control channel (PDCCH), including, for example, enhanced support for control resource set combinations (CORESET). Reliability enhancements are provided for the physical uplink control channel (PUCCH), including, for example, activation / deactivation of repeat combinations, resource selection, etc. Reliability enhancements are provided for the physical uplink shared channel (PUSCH), including, for example, spatial relationship determination and signaling, configurable and dynamic permission enhancements, etc.

Description

Description IMPROVED PHYSICAL CHANNELS IN MULTIPLE TRP Cross Reference to Related Applications This application claims the benefit of Provisional U.S. Patent Application No. 63 / 006,977, filed on April 8, 2020, Provisional U.S. Patent Application No. 63 / 061,281, filed on August 5, 2020, Provisional U.S. Patent Application No. 63 / 091,545, filed on October 14, 2020, and Provisional U.S. Patent Application No. 63 / 136,306, filed on January 12, 2021, the disclosure of which is incorporated herein by reference in its entirety. Background of the Invention Mobile communications using wireless communication continue to evolve. The fifth generation can be referred to as 5G. Previous (legacy) generations of mobile communications could include, for example, fourth-generation (4G) long-term evolution (LTE). Brief Description of the Invention Systems, methods, and instrumentation are disclosed herein related to physical channel enhancements in multitransmit / receive point (MTRP) operations. Reliability enhancements may be provided for the physical downlink control channel (PDCCH), including, for example, enhanced support for control resource set (CORESET) combinations. Reliability enhancements for the PDCCH may comprise enhancements to determining downlink control information (DCI) repetition times, determining transmission configuration indicator (TCI) selection for data scheduled with DCI repetitions, determining PDCCH candidates from multiple beams, and detecting PDCCH decoding failures and related behavior including channel state information (CSI) feedback.Reliability enhancements may be provided for the physical uplink control channel (PUCCH), including, for example, activation / deactivation of repeat combinations, resource selection, spatial filter configuration tables for repeats, and multiplexing if overlapping with the physical uplink shared channel (PUSCH). Reliability enhancements may be provided for the PUSCH, including, for example, spatial link determination and signaling, configurable and dynamic permission enhancements, and spatial filter configuration and repeat transmission based on DCI field values ​​and / or spatial filter configuration tables. A wireless transmitter / receiver unit (WTRU) may be used in enhanced transmissions in MTRP operations. The WTRU may receive SRI information, for example, which may include a set of SRI patterns. The WTRU may receive a DCI associated with uplink scheduling information. The DCI may indicate a number of transmission repetitions, a redundancy value, and / or a spatial domain resource allocation (SDRA) indicator. The WTRU may determine an audible reference signal source indicator (SRI) pattern, for example, from a set of SRI patterns. The WTRU may determine an SRI pattern based on the SDRA indicator, the number of repetitions, and / or the redundancy value. The SRI pattern may be associated with a sequence of SRIs. The WTRU may determine (e.g., based on the SRI pattern) a spatial relationship for the repetition transmission (e.g., a PUSCH repetition transmission).The WTRU may determine a spatial relationship for a repeat transmission based on the SRI sequence (e.g., the first repeat transmission uses the first SRI in the sequence, the second repeat transmission uses the second SRI in the sequence, and so on). The WTRU may transmit a repeat transmission (e.g., a PUSCH repeat transmission) using the specified spatial relationship. The WTRU may determine the transmission time associated with a repeat transmission (e.g., a PUSCH repeat transmission), for example, based on an offset value (e.g., a K2 value). The wireless / transmit unit (WTRU) may determine, with respect to PUSCH / PUCCH transmissions, whether to use single or multiple TRP operating modes. The WTRU may determine the spatial filter configuration based on dynamic switching between single and multiple TRP modes. Short Description of Image FIG. 1A is a system diagram illustrating an example of a communication system in which one or more of the described embodiments may be implemented. FIG. 1B is a system diagram illustrating an example of a wireless transmit / receive unit (WTRU) that may be used in the communications system illustrated in FIG. 1A in accordance with the embodiment. FIG. 1C is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communications system illustrated in FIG. 1A according to the embodiment. FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communications system illustrated in FIG. 1A according to the embodiment. FIG. 2 is a diagram depicting an example configuration MTRP DCI singular and plural. GBR. 3 is a diagram illustrating an example of an improvement TRP is common on physical channels. GBR. 4 is a diagram illustrating an example of a DCI recurrence offset. FIG. 5 is a diagram depicting an example of a PUCCH iteration for an enhanced PUCCH. FIGURE 6 is a diagram depicting an example of a PUCCH transmission enhanced with spatial link cycles. FIGURE 7 is a diagram depicting an example of a resource configuration for PUCCH repetition based on the value of K1. FIGURE 8 is a diagram illustrating an example of a table that relates repetition and spatial filter patterns. FIG. 9 is a diagram depicting an example of a resource configuration for PUSCH repetition based on SDRA and TDRA. FIG. 10 is a diagram depicting an example of a DCI with fields connected to a table with repeating and spatial filter patterns. Fig. 11 illustrates resource selection based on dynamic switching between single and multiple TRPs. Complete Description of the Invention FIG. 1A is a diagram illustrating an example of a communication system 100 in which one or more of the described embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the shared use of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), Fourier transform spreading (DFT) unique word tailless secret OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, multiple carrier bank filter (FBMC), and the like. As shown in FIG. 1A, the communication system 100 may include wireless transmitter / receiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the described embodiment includes any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment.For example, WTRU 102a, 102b, 102c, 102d, any of which may be referred to as a “station and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., telesurgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated process chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like.Any of UE 102a, 102b, 102c, and 102d may interchangeably be referred to as a WTRU. The communication system 100 may also include a base station 114a and / or a base station 114b. Each base station 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be a base station (BTS), a Node B (eNB), an eNode B, a Home Node B, or a Home eNode. B, gNode B (gNB), NR NodeB, site controller, access point (AP), wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include a plurality of interconnected base stations and / or network elements. The base station 114a may be part of a RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cells may provide coverage for wireless services to a specific geographic area that may be relatively fixed or that may change over time. The cells may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors.Thus, in one embodiment, the base station 114a may include three transmitters-receivers, namely, one for each cell sector. In the embodiment, the base station 114a may implement multiple input multiple output (MIMO) technology and may use multiple transmitters-receivers for each cell sector. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction. The base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via the air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT). More specifically, as mentioned above, the communication system 100 may be a multiple access system and may implement one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may form an air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or HSPA Evolution (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA). In the embodiment, base station 114a and WTRU 102a, 102b, The 102c may implement radio technologies such as UMTS Evolved Terrestrial Radio Access (E-UTRA), which may form an air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro). In the embodiment, base station 114a and WTRU 102a, 102b, 102c can implement radio technologies such as Access NR Radio, which can form a 116 air interface using New Radio (NR). In the embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access simultaneously, for example using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by different types of radio access technologies and / or transmissions sent to / from different types of base stations (e.g., eNBs and gNBs). In other embodiments, the base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Standard Interim 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like. The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a highway, and the like. In one embodiment, the base station 114b and the WTRU 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRU 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115. The RAN 104 / 113 can communicate with the CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in the FIG.1A, it will be understood that the RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that utilize the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to connecting to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with other RANs (not shown) that utilize GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. CN 106 / 115 may also serve as a gateway for WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communications protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) within the TCP / IP Internet Protocol suite. The network 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the network 112 may include other CNs connected to one or more RANs, which may use The same RAT as RAN 104 / 113 or a different RAT. Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transmitters and receivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may implement cellular-based radio technology, and with a base station 114b, which may implement IEEE 802 radio technology. FIG. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transmitter-receiver 120, a transmitter / receiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be understood that the WTRU 102 may include any subcombination of the above elements while remaining consistent with the embodiment. The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate within a wireless environment. The processor 118 may be coupled to a transmitter-receiver 120, which may be coupled to a transmitter / receiver element 122. While FIG. 1B depicts the processor 118 and the transmitter-receiver 120 as separate components, it will be understood that the processor 118 and the transmitter-receiver 120 may be integrated together in an electronic package or chip. Transmitter / receiver element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, the transmitter / receiver element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmitter / receiver element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In still another embodiment, the transmitter / receiver element 122 may be configured to transmit and / or receive both RF signals and light signals. It will be understood that the transmitter / receiver element 122 may be configured to transmit and / or receive any combination of wireless signals. Although the transmitter / receiver element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmitter / receiver elements 122. More specifically, the WTRU 102 may implement MIMO technology. Thus, in a single embodiment, the WTRU 102 may include two or more transmitter / receiver elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116. Transmitter-receiver 120 may be configured to modulate signals to be transmitted by transmitter / receiver elements 122 and to demodulate signals received by transmitter / receiver elements 122. As mentioned above, WTRU 102 may have multimode capabilities. Thus, transmitter-receiver 120 may include multiple transmitter-receiver elements to enable WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11, for example. The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light emitting diode (OLED) unit). Processor 118 may also output user data to speaker / microphone 124, keypad 126, and / or display / touchpad 128. In addition, processor 118 may also access information from, and store data in, any appropriate type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 132 may include subscriber identity module (SIM) cards, memory sticks, secure digital memory (SD) cards, and the like. In other embodiments, processor 118 may access information from, and store data in, memory not physically located on the WTRU 102, such as on a server or home computer (not shown). The processor 118 may receive power from a power source 134, and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any device suitable for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Liion), etc.), solar cells, fuel cells, and the like. Processor 118 may also be coupled with a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, information from the GPS chipset 136, the WTRU 102 may also receive location information via air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information through any suitable location determination method while remaining consistent with the embodiment. The processor 118 may further be coupled with other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transmitter-receiver, a digital camera (for still photos and / or video), a universal serial bus (USB) port, a vibration device, a television transmitter-receiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like.Peripheral 138 may include one or more sensors, such sensors being one or more of a gyroscope, accelerometer, hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, motion sensor, biometric sensor, and / or humidity sensor. The WTRU 102 may include a full duplex radio for which the transmission and reception of some or all of its signals (e.g., pertaining to a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference either through hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiment, the WRTU 102 may include a half duplex radio for which the transmission and reception of some or all of its signals (e.g., pertaining to a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be concurrent and / or simultaneous. FIG. 1C is a system diagram illustrating RAN 104 and CN 106 according to the embodiment. As mentioned above, RAN 104 may implement E-UTRA radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106. The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transmitter-receivers for communicating with the WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, eNode-B 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. Each eNode-B 160a, 160b, 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, and the like. As shown in FIG. 1C, eNode-B 160a, 160b, 160c can communicate with each other via the X2 interface. The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of those elements may be owned and / or operated by an entity other than the CN operator. The MME 162 may connect to any eNode-B 162a, 162b, 162c in the RAN 104 via the S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of WTRUs 102a, 102b, 102c, carrier enablement / disablement, selecting a specific service gateway during initial attachment of WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide control plane functions for switching between the RAN 104 and another RAN (not shown) implementing another radio technology, such as GSM and / or WCDMA. The SGW 164 can connect to each eNode B 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handovers between eNode Bs, triggering calls (paging) when DL data is available to the WTRUs. 102a, 102b, 102c, managing and storing WTRU contexts 102a, 102b, 102c, and the like. SGW 164 may be connected to PGW 166, which may provide WTRUs 102a, 102b, 102c access to packet switched networks, such as Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP enabled devices. The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, and 102c and traditional landline communication devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. In addition, CN 106 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. Although the WTRU is described in FIG. 1A-1D as a wireless terminal, it is intended that in certain representative embodiments that such terminal may use (e.g., temporarily or permanently) a wired communications interface with the communications network. In a representative embodiment, another network 112 may be a WLAN. A WLAN in Infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interface to a Distribution System (DS) or other type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to the STA originating from outside the BSS can be reached through the AP and can be delivered to the STA. Traffic originating from an STA to a destination outside the BSS can be sent to an AP for delivery to its respective destination. Traffic between STAs within a BSS can be sent through an AP, for example, where the source STA can send traffic to the AP and the AP can send traffic to the destination STA. Traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer or end-to-end (peer-to-peer) traffic. Peer-to-peer traffic can be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). WLANs using Independent BSS (IBSS) mode may not have APs, and STAs (e.g., all STAs) within or using the IBSS can communicate directly with each other. The IBSS communication mode can sometimes be referred to here as the “ad-hoc” communication mode. When using 802.11ac infrastructure operating mode or similar operating modes, APs can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set through signaling. The primary channel can be the operating channel of a BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in 802.11 systems. For CSMA / CA, STAs (e.g., any STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, then that particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a particular BSS. High Throughput (HT) STAs can use 40 MHz wide channels for communication, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to define a 40 MHz wide channel. Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. 160 MHz channels can be formed by combining 8 adjacent 20 MHz channels or by combining two non-adjacent 80 MHz channels, which can be referred to as an 80+80 configuration. For an 80+80 configuration, the data, after channel encoding, can be passed through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, can be performed on each stream separately. The streams can be mapped to both 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC). Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel and carrier operating bandwidths are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to representative embodiments, 802.11ah can support Type Control Meter / Machine Type Communications, such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, for example, limited capabilities that include support for (e.g., only support for) specific and / or limited bandwidths. MTC devices may include batteries with a battery life above a threshold (e.g., to maintain an extremely long battery life). WLAN systems, which can support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA, from among all STAs operating in the BSS, that supports the smallest bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1 MHz mode, even though the APs and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. The setting of Carrier Sensing and / or Network Allocation Vectors (NAVs) can depend on the status of the primary channel.If the primary channel is busy, for example, because the STA (which only supports 1 MHz operating mode), is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and may be available. In the United States, the available frequency band, which can be used by 802.11ah, is from 902 MHz to 928 MHz. In Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code. FIG. 1D is a system diagram illustrating RAN 113 and CN 115 according to the embodiment. As mentioned above, RAN 113 can use NR radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 113 can also communicate with CN 115. The RAN 113 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with the embodiment. The gNBs 180a, 180b, 180c may each include one or more transmitters / receivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. Within a single embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beam forming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may utilize multiple antennas to transmit wireless signals to, and / or receive wireless signals from, WTRU 102a. In embodiment, gNB 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown).A subset of these component carriers may reside in unlicensed spectrum, while the remaining component carriers may reside in licensed spectrum. In the embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and gNBs 180b (and / or gNBs 180c). WTRU 102a, 102b, 102c can communicate with gNB 180a, 180b, 180c use scalable numerology-related transmissions. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c uses subframes or transmission time intervals (TTIs) of varying or scalable length (e.g., containing varying numbers of OFDM symbols and / or lasting varying absolute lengths of time). gNB 180a, 180b, 180c can be configured to communicate with WTRU 102a, 102b, 102c in stand-alone and / or non-stand-alone configurations. In stand-alone configurations, WTRU 102a, 102b, 102c can communicate with gNB 180a, 180b, 180c without also accessing another RAN (e.g., such as eNode-B 160a, 160b, 160c). In a stand-alone configuration, WTRU 102a,102b, The 102c can utilize one or more gNBs 180a, 180b, 180c as mobility anchor points. In a stand-alone configuration, the WTRUs 102a, 102b, and 102c can communicate with the gNBs. 180a, 180b, 180c use signals in unlicensed bands. In a non-standalone configuration, WTRU 102a, 102b, 102c can communicate with / connect to a gNB. 180a, 180b, 180c while also communicating with / connecting to Other RANs such as eNode-B 160a, 160b, 160c. For example, WTRU 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for WTRU 102a, 102b, 102c, and gNB 180a, 180b, 180c can provide additional reach and / or throughput to serve WTRU 102a, 102b, 102c. Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a, 182b, and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via the Xn interface. The CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of such elements may be owned and / or operated by an entity other than the CN operator. The AMF 182a, 182b may connect to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of a specific SMF 183a, 183b, registration area management, NAS signaling termination, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c.For example, different network slices can be formed for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine-type communication (MTC) access, and / or the like. The AMF 162 can provide control plane functions for switching between the RAN 113 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi. SMF 183a, 183b can connect to AMF 182a, 182b in CN 115 via the N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b in CN 115 via the N4 interface. SMF 183a, 183b can select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. PDU session types may be IP-based, non-IP-based, Ethernet-based, and the like. UPF 184a, 184b can be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like. The CN 115 may facilitate communication with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN. 108. In addition, CN 115 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, 102c may connect to Data Network (DN) 185a, 185b local via UPF 184a, 184b via N3 interface to UPF 184a, 184b and N6 interface between UPF 184a, 184b and DN 185a, 185b. In view of FIG. 1A-1D and the corresponding description of FIG. 1A1D, one or more, or all, of the functions described herein with respect to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein, may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions. Emulation devices may be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulation devices may perform one or more, or all, of the functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more, or all, of the functions when temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation devices may be directly coupled to other devices for testing purposes and / or may perform testing using over-the-air wireless communications. One or more emulation devices may perform one or more, including all, functions when not implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in a test scenario in a test laboratory and / or an unimplemented wired and / or wireless communications network (e.g., a testbed) to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data. Systems, methods, and instrumentation are disclosed herein related to physical channel enhancements in multitransmit / receive point (MTRP) operations. Reliability enhancements may be provided for the physical downlink control channel (PDCCH), including, for example, enhanced support for control resource set (CORESET) combinations. Reliability enhancements for the PDCCH may comprise enhancements to determining downlink control information (DCI) repetition times, determining transmission configuration indicator (TCI) selection for data scheduled with DCI repetitions, determining PDCCH candidates from multiple beams, and detecting PDCCH decoding failures and related behavior including channel state information (CSI) feedback.Reliability enhancements may be provided for the physical uplink control channel (PUCCH), including, for example, activation / deactivation of repeat combinations, resource selection, spatial filter configuration tables for repeats, and multiplexing if overlapping with the physical uplink shared channel (PUSCH). Reliability enhancements may be provided for the PUSCH, including, for example, spatial link determination and signaling, configurable and dynamic permission enhancements, and spatial filter configuration and repeat transmission based on DCI field values ​​and / or spatial filter configuration tables. A wireless transmitter / receiver unit (WTRU) may be used in enhanced transmissions in MTRP operations. The WTRU may receive SRI information, for example, which may include a set of SRI patterns. The WTRU may receive a DCI associated with uplink scheduling information. The DCI may indicate a number of transmission repetitions, a redundancy value, and / or a spatial domain resource allocation (SDRA) indicator. The WTRU may determine an audible reference signal source indicator (SRI) pattern, for example, from a set of SRI patterns. The WTRU may determine an SRI pattern based on the SDRA indicator, the number of repetitions, and / or the redundancy value. The SRI pattern may be associated with a sequence of SRIs. The WTRU may determine (e.g., based on the SRI pattern) a spatial relationship for the repetition transmission (e.g., a PUSCH repetition transmission). The WTRU may determine a spatial relationship for a repeat transmission based on the SRI sequence (e.g., the first repeat transmission uses the first SRI in the sequence, the second repeat transmission uses the second SRI in the sequence, and so on). The WTRU may transmit a repeat transmission (e.g., a PUSCH repeat transmission) using the specified spatial relationship. The WTRU may determine the transmission time associated with a repeat transmission (e.g., a PUSCH repeat transmission), for example, based on an offset value (e.g., a K2 value). The wireless / transmit unit (WTRU) may determine, with respect to PUSCH / PUCCH transmissions, whether to use single or multiple TRP operating modes. The WTRU may determine the spatial filter configuration based on dynamic switching between single and multiple TRP modes. Multi-transmit / receive point (MTRP) operation may be supported (e.g., in new radios (NR)). The WTRU may receive and process physical downlink control channel (PDCCH) and physical downlink shared channel (PDSCH) transmissions. In the example, the channel transmissions described herein, such as PDCCH and PDSCH transmissions, may be NR transmissions, e.g., NR physical downlink control channel and NR physical downlink shared channel transmissions. References herein to channels, e.g., PDCCH, PDSCH, PUCCH, PUSCH, etc., may refer to channel transmissions (e.g., received or transmitted channel transmissions). FIG. 2 is a diagram illustrating example single and multiple downlink control information (DCI) MTRP configurations. FIG. 2 shows two example downlink MTRP operation scenarios with a primary TRP (P-TRP) and a secondary TRP (S-TRP). In the first example scenario (e.g., scenario 1), a single PDCCH can schedule a single PDSCH, where separate layers can be transmitted from separate TRPs. In the second example scenario (e.g., scenario 2), multiple PDCCHs can schedule (e.g., each can schedule) each PDSCH, where a PDSCH (e.g., each PDSCH) can be transmitted from a separate TRP. NR can support a limited number of PDSCHs and / or PDCCHs. In the example, the maximum number of PDSCHs may be two and the maximum number of PDCCHs may be two. Multiple TRP transmissions can be implemented, for example, for downlink shared data channels (DL), for example, for enhanced mobile broadband (eMBB) and ultra-reliable low latency (URLLC) scenarios. Multiple transmission schemes (e.g., four transmission schemes) for PDSCH can improve the reliability and robustness of downlink data transmission (e.g., for URLLC). Additional resources can be used in the spatial, frequency, and time domains, for example, to support the transmission schemes. Additional resources can be used, for example, to enable lower code rates for transmissions and / or to support repeats of the original transmission (e.g., depending on the transmission scheme). Frequency band 1 (FR1) and band 2 (FR2) operation can be improved. Reliability and robustness improvements for PDSCH can be extended to other physical channels (e.g., PDCCH, physical uplink shared channel (PUSCH) and / or physical uplink control channel (PUCCH). Enhancements can utilize multiple TRP and / or multiple panels capabilities. Enhancements related to quasi-collocation (QCL) and / or transmission configuration indicator (TCI) can enable inter-cell MTRP with multiple PDSCH based on multiple DCI. Beam management can be improved. Multiple input multiple output (MIMO) can be applied to MTRP to support, for example, high-speed train (HST) scenarios in single-frequency networks (SFN). Reliability improvements are expressed for physical channels (e.g., PDCCH, PUCCH, and PUSCH), for example, as shown in FIG. 3. FIG. 3 is a diagram illustrating an example of multiple TRP enhancements to a physical channel (e.g., PDCCH, PUCCH, and / or PUSCH). In the example (e.g., a single TRP system), the physical channel may be transmitted over a channel with poor channel conditions, for example, which may degrade reception performance. The connection between the WTRU and the TRP may fail, for example, due to rotation and / or blockage of the WTRU. The robustness of the physical channel can be improved. For example, multiple TRPs can be used for PDCCH transmission and / or for PUCCH and / or PUSCH reception, for example, to provide diversity. Multiple copies can be transmitted. More than one TRP may be involved in downlink (DL) transmission or uplink (UL) reception. Repeaters can be combined, for example, to provide a combinational benefit.Repetition can allow reception of one of several copies, for example, if one or more other copies fail to reach their destination, which can improve reception performance. The permit properties may include, for example, one or more of the following: frequency allocation; time allocation aspects (e.g., duration); priority; modulation and coding scheme (MCS); transport block size (TB); number of spatial layers; number of transport blocks (TB); TCI status, channel state information reference signal (CSI-RS) resource indicator (CRI) or sounding reference signal (SRS) resource index (SRI); number of repetitions; and / or an indication of whether the permit is a type 1, type 2, or dynamic permit. The PDCCH enhancements disclosed herein are applicable. CORESET can be used interchangeably with search space, PDCCH search space, PDCCH, PDCCH candidate, PDCCH decoding candidate, and / or PDCCH monitoring device. Identity, ID, and index can be used interchangeably. CORESET co-coding can be referred to as bit-level and / or symbol-level coding that combines one or more of the following: one or more bits (e.g., soft or hard bits) from different CORESETs or PDCCHs; one or more modulation symbols from different CORESETs or PDCCHs; and / or one or more DCIs from different CORESETs or PDCCHs. A PDCCH can be associated with a TRP. A WTRU can be configured with one or more CORESETs and a PDCCH search space for a bandwidth section (BWP). A CORESET (e.g., each CORESET) and / or a PDCCH search space (e.g., each PDCCH search space) can be associated with a TRP. A TRP can be referred to as a TRP identity. A TRP identity (TRP-id) can be used interchangeably with a CORESET group, CORESET group identity, or a set of CORESET, CORESET pool identity (CORESETPoolId), PDCCH search space group, PDCCH search space group identity, PDCCH search space pool, PDCCH search space pool identity (searchSpacePoolId), QCL group identity, and / or TRP group identity. PDCCH search space can be used interchangeably with search space (SS). The TRP or TRP identity for a CORESET and / or PDCCH search space may be determined based on one or more of the following examples. In the examples, the TRP identity may be indicated, for example, in the configuration for the CORESET and / or search space. The TRP identity may be present in the configuration, for example, if the WTRU is configured to operate in an operating mode for multiple PDCCH TRP monitoring. In the examples, one or more QCL parameters may be indicated or configured, for example, for the CORESET and / or search space. The CORESET and / or search space may have the same QCL association and may be considered to have the same TRP association. The same QCL association may, for example, be the same source reference signal, which may be used for one or more QCL parameters. The WTRU may define a mode of operation, for example, for PDCCH reception. One or more modes of operation may be used for PDCCH reception. The first mode of operation may be based on reception of a single PDCCH. The second mode of operation may be based on reception of multiple PDCCHs. The WTRU may monitor, receive, and / or attempt to decode a single PDCCH, which may carry scheduling information for one or more PDSCHs and / or one or more PUSCHs. The WTRU may (for example, for reception of multiple PDCCHs), monitor, receive, and / or attempt to decode one or more PDCCHs, which may carry scheduling information for one or more PDSCHs and / or one or more PUSCHs. PUSCH. There may be multiple modes, such as one or more of the following. Mode-1 can be a single PDCCH decoding mode (e.g., decoding a single PDCCH to receive a single DCI). In Mode-1a, one PDCCH can schedule one PDSCH and / or one PUSCH. In Mode-1b, one PDCCH can schedule one or more PDSCHs. For example, mode-2 can be a multiple PDCCH decoding mode (e.g., decoding multiple PDCCH to receive one DCI). In Mode-2a, one or more PDCCHs can schedule one PDSCH and / or one PUSCH. In Mode-2b, one or more PDCCHs can schedule one or more PDSCHs. A PDCCH can be any candidate PDCCH in the search space. A single PDCCH can be referred to as a candidate PDCCH carrying a DCI or as a DCI, for example, a single PDCCH can refer to the time / frequency resources of a single candidate PDDCH or can refer to the DCI bits. A PDSCH or PUSCH can be referred to as a transport block (e.g., a shared channel). PDCCH decoding mode, PDCCH decoding type, PDCCH decoding scheme, PDCCH receive mode, PDCCH receive type, PDCCH receive scheme, PDCCH monitoring mode, PDCCH monitoring type, and PDCCH monitoring scheme can be used interchangeably. The number of CORESETs for decoding multiple PDCCHs can be determined, for example, based on the operating mode. One or more of the following may apply. The mode of operation can be determined, for example, by the number of CORESETs in a CORESET group. For example, the WTRU may consider a CORESET group as the first mode of operation (e.g., multi-PDCCH decoding), for example, if the CORESET group consists of two or more CORESETs. The WTRU may consider a CORESET group as the second mode of operation (e.g., single-PDCCH decoding), for example, if the CORESET group consists of zero or one CORESET. The mode of operation can be determined, for example, based on the number of associated CORESETs (e.g., for DCI reception). In an example, the WTRU can consider associated CORESETs as the first mode of operation (e.g., multiple PDCCH decoding), for example, if two or more CORESETs are associated. The WTRU can consider the lack of associated CORESETs (e.g., zero or one CORESET or multiple unassociated CORESETs) as the second mode of operation (e.g., single PDCCH decoding). The number of associated CORESETs for a DCI can be indicated, for example, implicitly, for example, based on the number of search spaces associated with different CORESET-ids configured to monitor the DCI. The mode of operation may be determined, for example, based on the WTRU capability and the gNB configuration based on the WTRU capability reporting. For example, the WTRU may receive a PDCCH decoding mode type or indication (e.g., single PDCCH decoding mode or multiple PDCCH decoding mode). The WTRU may decode DCI based on multiple PDCCHs, for example, if the PDCCH decoding mode type or indication indicates multi-PDCCH decoding. The WTRU may decode DCI based on a single PDCCH, for example, if the PDCCH decoding type indication indicates single PDCCH decoding or no PDCCH decoding type is indicated. A WTRU may request a preferred mode of operation, for example, for PDCCH decoding. A WTRU may indicate (for example, to the gNB) the preferred mode of operation, for example, if the WTRU does not support some (for example, both) modes of operation and / or DCI decoding based on CORESET fails. In an example, a WTRU may be configured with one or more uplink resources (for example, a physical random access channel (PRACH), PUCCH and / or PUSCH) that the WTRU may use to indicate the preferred mode of operation. A WTRU may transmit one or more uplink signals (for example, based on the first uplink resource of one or more uplink resources), for example, if DCI decoding based on CORESET fails. A WTRU may transmit one or more uplink signals (for example, based on the second uplink resource), for example, if DCI decoding based on CORESET succeeds. The first uplink resource and the second uplink resource may be identical.The indication may be switch-based, for example, if the first uplink resource and the second uplink resource are identical). In the example, an uplink signal transmission on the first uplink resource may indicate a request for the second mode of operation (e.g., single-PDCCH decoding), for example, if the WTRU is configured with the first mode of operation (e.g., multi-PDCCH decoding). An uplink signal transmission on the first uplink resource may indicate a request for the first mode of operation, for example, if the WTRU is configured with the second mode of operation. The operating mode can be determined, for example, based on the CORESET configuration and / or the search space. In the example, the operating mode can be determined, for example, based on the number of TRP-ids configured for the CORESET configured in the BWP. The first operating mode can be used, for example, if the number of TRPids is 1. Otherwise, the second operating mode can be used. In the example, the first operating mode can be used if no TRP-id is configured and / or does not exist for the CORESET configuration. The second operating mode can be used if a TRP-id is configured for the CORESET configuration. In the example, QCL association information can determine the operating mode. The first operating mode can be used, for example, if the QCL association is the same for some (e.g., all) configured CORESETs. The second operating mode can be used, for example, if the QCL association is different across some (e.g., all) CORESETs. One or more of the following may apply.TRP-id may be present in the CORESET / SS configuration, for example, based on the operating mode used for PDCCH reception. QCL associations may be configured generically for multiple (e.g., all) CORESET / SS for the first operating mode. QCL associations may be configured individually or separately for each of the multiple (e.g., all) CORESET / SS for the second operating mode. QCL associations may be referred to as QCL type configurations. The operating mode can be determined based on dynamic indications. For example, a DCI in a common search space can indicate the PDCCH receive operating mode (e.g., PDCCH receive mode) in one or more WTRU-specific search spaces. The DCI in the common search space can be a common DCIA group, the common DCI group can be shared by a group of WTRUs. The common DCI group can be a cyclic redundancy check (CRC) that is randomized, for example, with a group radio network temporary identifier (RNTI). The start time of the PDCCH receive mode indicated in the common DCI group can be an X symbol or slot after the last symbol or slot of the PDCCH carrying the group common DCI. X can be determined, for example, based on the subcarrier distance of the associated BWP and / or WTRU capabilities (e.g., WTRU processing capability). A DCI in the same search space (e.g., the same one) can indicate the activation / deactivation of the PDCCH receive mode (e.g., mode-2).In the example, the default PDCCH receive mode (e.g., mode-1) may be used, for example, if the PDCCH receive mode is disabled or not enabled and the indicated PDCCH receive mode (e.g., mode-2) may be used, for example, if the PDCCH receive mode is enabled. The DCI may be used interchangeably with the medium access control control element (CE) (e.g., the DCI and MAC CE may perform the same function). Multiple PDCCH reception / decoding schemes may be implemented. One or more multiple PDCCH decoding schemes may be used. One or more PDCCHs (e.g., which may be PDCCH transmissions as used herein), e.g., candidate PDCCHs, received (e.g., by a WTRU) in a multi-PDCCH reception scheme may overlap in the time and / or frequency domain. One or more PDCCHs in multiPDCCH mode, e.g., for receiving one or more PDSCHs or PUSCHs, may be referred to as a multi-PDCCH set (MpffCCH). One or more The PDCCH or PDCCH candidates in Mp^Cra can be combined (e.g., at the bit level or symbol level) and can be used to decode the associated DCI. PDCCHs can overlap (e.g., completely overlap) in both the time and frequency domains (e.g., spatial domain multiplexing (SDM)). One or more PDCCHs in an Mp^CH may originate from different CORESETs or non-overlapping CORESETs. For example, the first PDCCH in an Mp^CcH may originate from the first CORESET and the second PDCCH in an Mp^cH may originate from the second CORESET. For example, CORESETs associated with one or more PDCCHs in Mp^CcH may be configured with a number of symbols (e.g., the same number of symbols) and frequency locations (e.g., the same frequency locations), e.g., the same physical resource block (PRB) configured in the BWP. In the first PDCCH in Mpp.cH may be from the first search space, which may be associated with the first CORESET. The second PDCCH in Mp^-^ may be from the second search space, which may be associated with the second CORESET. The first CORESET and the second CORESET may have different CORESET-ids. In an example, search spaces associated with one or more PDCCHs in an MppCcH may be associated with the same CORESET and / or CORESET-id. A search space (e.g., each search space) may be configured with one or more QCL parameters. QCL parameters configured in the associated CORESET may be ignored or overridden by QCL parameters configured in the search space (e.g., each search space), for example, if a WTRU monitors one or more PDCCHs in the search space. In the example, a PDCCH candidate may be received from one or more spatial Rx parameters (e.g., Ds-type QCL). The PDCCH candidate with the first spatial Rx parameter may be referred to as the first PDCCH in the MCdHch. The PDCCH candidate with the second spatial Rx parameter may be referred to as the second PDCCH in the MpffCCH. PDCCHs may overlap (e.g., partially overlap) in the time and / or frequency domains (e.g., time division multiplexing (TDM)) and / or frequency division multiplexing (FDM). One or more search spaces associated with one or more PDCCHs in an MCdHch may overlap in time and / or frequency. In an example, one or more search spaces for PDCCHs in an MpppCCH may be associated with the same CORESET (for example, the same CORESET-id). One or more search spaces may be monitored at different time locations (for example, different symbols in different slots or slots). A search space (for example, each search space) may be configured with one or more QCL parameters. QCL parameters configured in the associated CORESET may be overridden or overridden by QCL parameters configured in a search space (for example, each search space), for example, if a WTRU monitors one or more PDCCHs in a search space. In the example, one or more search spaces for the PDCCH in Mp^-c# can be associated with different CORESETs. The search spaces can lie within time windows (for example, slots, subframes, etc.). The PDCCHs may be non-overlapping in terms of time and frequency domains (e.g., TDM and / or FDM). One or more search spaces associated with one or more PDCCHs in Μ-ρΗη may correspond to different CORESETs and may be located in non-overlapping time locations (e.g., symbols and / or slots). The WTRU may define associated CORESETs. The WTRU may support increased reliability of PDCCH reception, for example, based on the use of one or more CORESETs. In an example, the WTRU may jointly decode DCI, for example, by combining signals from multiple PDCCHs received from multiple CORESETs. Multiple CORESETs for receiving multiple PDCCHs for decoding DCI may be associated with each other, for example, by using one or more of the following: explicit indications or implicit indications. In the example of connecting a CORESET with explicit indication, the WTRU may receive one or more CORESET IDs, for example, using a downlink channel (for example, PDCCH and / or PDSCH). The downlink channel may carry bit information for one or more CORESET IDs. In an example, a WTRU may receive one or more associated CORESET IDs in a CORESET configuration (e.g., each CORESET configuration), which may for example be contained in and / or received in one or more radio resource control (RRC) messages. For example, a WTRU may receive one or more associated CORESET IDs in one or more MAC-CE messages. One or more MAC-CE messages may consist of, for example, one or more of the following: target Cell ID; target BWP ID; target CORESET ID; and / or associated CORESET IDs. For example, a gNB may indicate one or more associated CORESET IDs in one or more DCI groups. One or more DCI fields in one or more DCI groups may comprise (e.g., explicitly comprise) one or more CORESET IDs. The indication of one or more CORESET IDs may be based on the RRC configuration. For example, a WTRU may be given a list. A code point (e.g., each code point) of the list may comprise one or more CORESET groups. One or more groups A CORESET (e.g., each of one or more CORESET groups) may consist of one or more associated CORESET IDs. A WTRU may receive a DCI field indicating a code point from a list. A WTRU may receive multiple PDCCHs and decode the DCI, for example, based on the code point. In the example, the group DCI may indicate the CORESET ID, and the CORESET ID may indicate to the WTRU which CORESET ID is associated with the WTRU's specific DCI reception. A WTRU may receive one or more CORESET group IDs, for example, using downlink channel transmissions (e.g., PDCCH and / or PDSCH). Downlink channel transmissions may carry bit information for one or more CORESET group IDs. For example, a WTRU may receive one or more group IDs in a CORESET configuration (e.g., each CORESET configuration), for example, if the CORESET configuration is received via one or more messages, such as one or more RRC messages. One or more CORESETs may be defined as related CORESETs based on one or more CORESETs that comprise one or more identical CORESET group IDs. In the example, an indication that a CORESET is associated may be given by an implicit indication, which may be based on the CORESET set ID and / or the CORESET decoding type. In the example, a WTRU can receive multiple PDCCHs for DCI based on CORESET with identical CORESET set IDs. In an example, a WTRU may receive a decoding type, for example, in a CORESET configuration (e.g., each CORESET configuration) of one or more RRC messages. The WTRU may jointly decode the PDCCH of one or more CORESETs that may be indicated as multi-PDCCH decoding, for example, if the decoding type is indicated as multiPDCCH decoding. The WTRU may decode the PDCCH of a CORESET, for example, if the decoding type is not indicated or indicates single-PDCCH decoding. The associated CORESET can be used interchangeably with CORESET in a CORESET group, and / or CORESET with identical PDCCH decoding type. WTRU can specify multi-PDCCH decoding. The WTRU may implement multi-PDCCH decoding, for example, based on one or more of the following: RNTI, CORESET ID, precoder granularity, resource element group (REG) mapping type for control channel element (CCE). The WTRU may implement multi-PDCCH decoding, for example, based on RNTI. For example, the WTRU may implement multi-PDCCH decoding for one or more PDCCHs that may be CRC-scrambled by a first RNTI (e.g., cell (C)-RNTI, MCS-C-RNTI, and / or configured scheduling (CS)-RNTI) with multi-PDCCH decoding. The WTRU may implement single PDCCH decoding for one or more PDCCHs that may be CRC-scrambled by a second RNTI (e.g., system information (SI)-RNTI, paging (P)-RNTI, random access (RA)-RNTI, slot format indication (SFI)-RNTI, interruption (INT)-RNTI, transmit power control (TPC)-PUSCH-RNTI, TPC-PUCCHRNTI, and / or TPC-SRS-RNTI). The WTRU may implement multi-PDCCH decoding, for example, based on CORESET IDs. For example, the WTRU may implement single-PDCCH decoding for one or more CORESETs with a first CORESET ID (e.g., CORESET 0), and may implement multi-PDCCH decoding for one or more CORESETs with a second CORESET ID (e.g., CORESET other than 0). WTRU can implement multi-PDCCH decoding, for example, based on precoder granularity (e.g., REG bundle size). The WTRU can implement multi-PDCCH decoding, for example, based on the type of CCE REG mapping (e.g., insertion or non-insertion). The WTRU can determine whether it will decode (i.e., attempt to decode) using single PDCCH decoding or multi-PDCCH decoding. PDCCH, for example, based on the downlink measurement quality. Single PDCCH decoding may be a separate configuration from multi-PDCCH decoding or part of multi-PDCCH decoding. The WTRU may attempt to decode / decode using either single PDCCH decoding or the specified multi-PDCCH decoding. Single PDCCH decoding may refer to the WTRU monitoring one of multiple PDCCHs for multiPDCCH decoding. For example, a WTRU may be configured with multiple PDCCH decoding. Multiple (e.g., two) PDCCHs may be used for DCI reception. The WTRU may decode or attempt to decode the first PDCCH (e.g., only the first PDCCH) or the second PDCCH (e.g., only the second PDCCH) for DCI reception, which may be referred to as single PDCCH decoding. The WTRU may be configured with a separate configuration (e.g., single PDCCH decoding), which may differ from multiPDCCH decoding (e.g., in terms of a number of CORESETs, CORESETPoolId, etc.). The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on one or more of the following: DL measurements of one or more reference signals associated with the PDCCH; system parameters; a number of non-overlapping PDCCH blind decodes and / or CCEs for channel estimation in the slot; the type of traffic expected in the slot; the type of PDSCH / PUSCH scheduling; the demodulation reference signal (DM-RS) configuration; or the minimum scheduling time. The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on DL measurements of one or more reference signals that may be associated with a PDCCH (e.g., a measurement reference for CORESET associated with multiple PDCCHs (e.g., a PDCCH group)). In an example, the WTRU may decode a PDCCH associated with a CORESET with a measurement higher than a threshold, for example, if the CORESET measurement in the CORESET group is higher than a threshold. The measurement may include, for example, at least one of reference signal received power (RSRP), L1-RSRP, signal-to-interference-plus-noise ratio (SINR), L1-SINR, or radio link quality (e.g., hypothetical block error rate (BLER)). For example, the WTRU may decode or attempt to decode a PDCCH from a CORESET with a higher measurement result, for example, if the CORESET measurement result has a gap greater than X[dB]. For example, a WTRU can perform single PDCCH decoding, for example, if the sum of the CORESET measurements associated with multi-PDCCH decoding is within a certain gap Y[dB] of the highest measured CORESET measurement. The WTRU can determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on system parameters (e.g., slot number, subframe number, radio frame number). The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on a number of PDCCH blind decodes and / or non-overlapping CCEs for channel estimation in a slot. In an example, the WTRU may perform single PDCCH decoding, for example, if the number of PDCCH blind decodes and / or if the number of non-overlapping CCEs for channel estimation is higher than a threshold. Conversely, for example, the WTRU may perform multiple PDCCH decoding. The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on the type of traffic (e.g., eMBB or URLLC) that may be anticipated in the slot. The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on the PDSCH / PUSCH scheduling type (e.g., slot level or sub-slot level). The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on the DM-RS configuration (for example, front-load DM-RS or front-load DM-RS with additional DM-RS). The WTRU may determine whether to perform, decode, or operate single-PDCCH decoding or multi-PDCCH decoding, for example, based on the minimum scheduling time (e.g., the minimum K0 value in the time domain resource allocation (TDRA) table). WTRU can determine whether to avoid buffers. The WTRU can skip blind decoding of the PDCCH from CORESET, for example, based on one or more conditions. The WTRU may skip blind decoding of the PDCCH of a CORESET, for example, if the DCI was successfully decoded, for example, based on the PDCCH of the previous CORESET associated with the CORESET. In an example, the WTRU may not decode the DCI of the second CORESET, for example, if the DCI was successfully decoded from the first CORESET. A successfully decoded DCI may consist of skipping the CRC check. The WTRU can skip blind decoding of the PDCCH from a CORESET, for example, if one or more CORESETs associated with the CORESET are disabled. WTRU can skip blind decoding of PDCCH from CORESET, for example, if the CORESET group associated with CORESET is disabled. Bypassing blind decoding can be done, for example, based on one or more of the following conditions: CORESET is in the time window and / or CORESET is in the frequency window. In an example, the WTRU may skip decoding the DCI of the second CORESET within a time window, for example, if the DCI is decoded (e.g., successfully decoded) from the first CORESET. The time window may be configured in or may be based on, for example, one or more milliseconds, symbols, slots, or frames. The time window may be based on a specific CORESET (e.g., the first CORESET). For example, the time window may be defined as n + T, where n may denote the slot of the first CORESET. A time window may be based on a periodicity and an offset. For example, the WTRU may be configured with a periodicity and an offset in one or more RRC configurations. The WTRU may determine the CORESET within a time window, for example, based on a periodicity (e.g., the configured periodicity) and an offset (e.g., the configured offset). In an example, the WTRU may skip decoding the DCI of the second CORESET within a frequency window, for example, if the DCI is decoded (i.e., successfully decoded) from the first CORESET. The frequency window may be based on one or more resource blocks (RBs), resource block groups (RBGs), precoded resource block groups (PRGs), and / or subbands. The WTRU may determine CORESET priorities. Priorities may be implemented, for example, among CORESETs and / or CORESET groups. For example, the WTRU may determine the first one or more CORESETs to be decoded or monitored. The WTRU may monitor the first one or more CORESETs, for example, based on a determination. The WTRU may skip monitoring the second one or more CORESETs. The WTRU may determine the first one or more CORESETs, for example, based on one or more of the following: the lowest CORESET ID; the lowest CORESET group ID; the lowest physical cell ID; and / or the lowest serving cell ID. WTRU may prioritize CORESETs, for example, based on the lowest CORESET ID. For example, WTRU may determine or select the CORESET with the lowest CORESET ID. WTRU may (e.g., for one or more related CORESETs) determine (e.g., select) the CORESET ID among one or more CORESET IDs of related CORESETs for priority. For example, WTRU may determine or select the CORESET with the lowest CORESET ID among one or more CORESET IDs. WTRU can prioritize CORESETs, for example, based on the lowest CORESET group ID. For example, WTRU can determine or select the CORESET group with the lowest CORESET group ID. WTRU can prioritize CORESETs, for example, based on the lowest physical cell ID. For example, WTRU can determine or select the CORESET associated with the lowest physical cell ID. WTRU can prioritize CORESETs, for example, based on the lowest serving cell ID. For example, WTRU can determine or select the CORESET associated with the lowest serving cell ID. Priority can be used, for example, if one or more of the following conditions are met: the number of CORESETs per slot is greater than the maximum number of CORESETs supported by the WTRU; the number in the serving cell is greater than a number (e.g., the first number); and / or the number in the active BWP in the serving cell is greater than a number (e.g., the first number). The WTRU can specify a time reference for a repetition. Different time references can be specified for a DCI repetition. A DCI repetition (e.g., each DCI repetition) can be sent with a time offset, and the time offset can vary. The WTRU can specify a time instant if the DCI can be sent according to the reference time point and an offset with respect to the reference time point. The WTRU can use any of the random access channel (RACH) instances; synchronization signal blocks (SSB); search space slots; or slot index patterns as the reference time point. The WTRU can use a RACH opportunity as a reference time point. The WTRU can determine that multiple DCI repetitions can be sent in the search space in the time interval following the RACH opportunity slot. The WTRU can determine where the repetitions can be offset with respect to the RACH opportunity slot. As illustrated in FIG. 4, the WTRU can identify that a RACH event can be followed by repetition 0 and repetition 1. If the WTRU uses the preamble of the RACH opportunity to send msg1, the WTRU can determine that msg2 can be sent with two repetition offsets from the RACH opportunity. The WTRU can use SSB as a reference time point. The WTRU can use the SSB location and determine the repetition offset from the SSB time. The WTRU can measure RSRP or reference signal received quality (RSRQ) and can determine the presence and number of repetitions based on at least one channel measurement. The WTRU can determine channel measurement by specifying that more than one repetition may be sent if RSRP or RSRQ falls below a threshold of n1. The WTRU can determine channel measurement by determining the number of repetitions based on a mapping from the RSRP or RSRQ value to the number of repetitions. For example, if the WTRU determines RSRP may be less than n1 (RSRP < n1), the WTRU can choose to use K = 2 repetitions. If the WTRU determines that RSRP may be greater than n1 (RSRP > n1), the WTRU may choose to use K = 1 iterations. The WTRU can use a search space slot as a reference time point. The WTRU can specify a search space ID (SS) and can specify that a repeat is sent with respect to the SS slot with an offset as a function of the repeat number. As illustrated in Fig. 4, the WTRU can use SS0 at T1. The WTRU can determine that k repetitions can be sent at time T1+k*T_offset where T_offset can be a configurable parameter. The search space can be configured with a value for the kth repetition. The WTRU can first monitor (e.g., be restricted to first monitor) SSs with k equal to zero (k=0), and if it fails to receive with k equal to zero (k=0), the WTRU can search the search area (SS) configured with k greater than zero (k>0). The WTRU can use a slot index pattern as a reference point in time where the slot index (e.g., each slot index) can be used to determine the number of repetitions. The WTRU can use a slot format indicator (SFI) to determine the DL slot time. The WTRU can use a pattern that identifies slot 1 where repetition 1 can be sent, and slot 2 where repetition 2 can be sent. The slot pattern with repetitions can be configured with the SFI or configured in a separate system information block (SIB). The WTRU can determine the TCI for data if multiple DCI repetitions are detected. If a single DCI is transmitted, the WTRU can determine the spatial filter to be used for the scheduled data (e.g., PDSCH transmission or PUSCH transmission) based on the DCI. The DCI may contain an explicit QCL indication and the WTRU may have time (e.g., sufficient time) to change the spatial filter. If the WTRU does not have time to change its spatial filter, it may use (e.g., use as a default) the same spatial filter used to receive the DCI. If multiple DCI repetitions are used and each DCI repetition can be transmitted with its own TCI, the WTRU may not have the information to determine which TCI to use for the scheduled data. The WTRU may receive an indication of K equal to 2 (K=2). The WTRU can identify that repetition 1 can be configured with TCI1, and repetition 2 can be configured with TCI2.It may be unclear whether WTRU expects scheduled data to be sent with TCI1 or TCI2. WTRU behavior is undetermined if CORESET can be configured with multiple TCI values ​​or if data transmission can be scheduled using DCI with multiple TCI values. The WTRU may determine spatial relationships for scheduled data based on rules that define spatial relationships (e.g., default spatial relationships) that may be applied if multiple DCI repetitions are received with multiple TCIs scheduling data. The reference time used by the WTRU to switch its spatial filter may depend on whether the rule is applicable. The WTRU may switch its spatial filter if it identifies a repetition that satisfies the rule. The WTRU may ignore other repetitions. The WTRU may determine how many repetitions to expect and may switch its spatial filter upon receiving a repetition. If the WTRU receives multiple DCIs with different TCIs, the WTRU may apply one or more rules or logic (e.g., related to the TCI, to determine the DCI, etc.) such as, for example, one or more of the following. The WTRU can use the TCI corresponding to the repetition index k. The WTRU can determine the repetition index DCI and can use the TCI of the repetition of the kth DCI. The WTRU may use the TCI from the last successfully received DCI. The DCI may correspond to a DCI sent without repetitions that may have been used in a previous transmission, or, the DCI may correspond to one of the repetitions in the current repetition sequence. The WTRU may choose to use the TCI associated with the first correctly encoded DCI repeat in the K repeat sequence. WTRU can use repeats with TCI that corresponds to the RS with the highest RSRP. The WTRU may determine that the TCI associated with a single panel may be used. The WTRU may receive repetition 1 on panel 1 and repetition 2 on panel 2. The WTRU may use the TCI associated with panel 1 (for example, because panel 1 may be the only panel the WTRU is configured to use). The WTRU may determine that the TCI associated with a TRP index may be used. If the WTRU receives repetition 1 from TRP1 and repetition 2 from TRP2, the WTRU may use the TCI from TRP1 (for example, because TRP1 may be the TRP associated with the TRP index). The WTRU may choose to use a TCI from a known state, for example, if some loops are configured with an unknown TCI state. An unknown TCI state may be a TCI state for which the WTRU may not have specified a spatial filter (e.g., the WTRU has not yet performed a measurement on the QCL source RS). WTRU can choose to use the TCI index as a reference. WTRU can use the lowest TCI index of the repeats (e.g., all repeats), or a specific TCI index (e.g., TCI = 2). The WTRU can determine the TCI using the code point table configured for the PDSCH and can specify the code point index. The WTRU can accept multiple DCI repetitions. The WTRU can choose to use the TCI corresponding to the TCI 1 code point configured for the PDSCH. WTRU can use TCI patterns. WTRU can determine TCI based on the mapping from the pattern. In the example, the pattern might include TCI1 and TCI2. WTRU can determine which TCI from the pattern to use based on the number of repetitions. If one (1) repetition is specified, WTRU can choose to use TCI1. If two (2) repetitions are specified, WTRU can choose to use TCI2. The WTRU can determine the TCI based on the RNTI of the DCI. If the WTRU decodes a DCI scrambled with C-RNTI, it can use TCI1. If the WTRU decodes a DCI scrambled with RA-RNTI, it can use TCI2. The WTRU can select a TCI based on the traffic type. If the WTRU receives URLLC DCI scheduling data, it can use TCI1 as a reference. If the WTRU receives eMBB DCI scheduling data, it can use TCI2. The WTRU may determine PDCCH candidates from multiple TRPs and / or beams. The WTRU may determine at least one PDCCH candidate mapped over resources that may have more than one QCL association or TCI state (e.g., resources transmitted from more than one TRP or beam). The WTRU may determine PDCCH candidates (e.g., a set of PDCCH candidates), for example for an operation mode (e.g., where an operation mode may refer to a PDCCH transmission where the PDCCH candidate is sent with two TCI states, e.g., one PDDCH candidate may be transmitted over multiple RBs, where some RBs may be sent with TCI1 and other RBs may be sent with TCI2). The WTRU can determine PDCCH candidates by specifying a search space configuration including more than one CORESET identity. The WTRU can determine control channel elements and / or resource element groups, for example, by combining resources from more than one CORESET according to one or more rules (e.g., predefined rules). The WTRU can determine REGs and / or CCEs from time-domain alignments across more than one CORESET. The WTRU can determine PDCCH candidates (e.g., blind-level PDCCH candidates) based on combined control channel elements that may share the same index of the corresponding CORESET, which can increase (e.g., double) the aggregation level. The WTRU can interleave bits or symbols from combined control channel elements, or interleave control channel elements themselves. Doing so can improve resilience in the event of unequal quality among TRPs. The WTRU can determine PDCCH candidates by specifying a single CORESET with more than one symbol in the time domain, for example, if the QCL association or TCI state depends on the time symbol. The WTRU can perform other operations (for example, all other operations) (for example, REG / CCE mapping, determining PDCCH candidates) from existing rules. The WTRU can determine that REG or CCE includes resource elements from both symbols according to a mapping rule (for example, a new mapping rule). The WTRU may determine a PDCCH candidate by defining a search space for that candidate, for example, based on a combination of at least two preconfigured search spaces. The combination of at least two search spaces may be characterized by a higher layer. The PDCCH candidate for the combination may be restricted to monitoring slots / symbols common to at least two search spaces. Separate periodicities and offsets may be specifically configured for the combination. The PDCCH candidate may be derived as a combination (e.g., an alignment) of control channel elements from both search spaces. The WTRU may interleave bits or symbols from the combined control channel elements, or interleave the control channel elements themselves. If the number of PDCCH candidates, or the number of control channel elements, exceeds their respective maximums in a PDCCH slot or range (e.g., overbooking), the WTRU may apply a lower or higher priority level to PDCCH candidates mapped to resources with more than one QCL property compared to other resources. The WTRU may select the priority level and / or whether to enable or disable PDCCH monitoring of those resources based on the CE MAC received from the network. The WTRU can determine (e.g., detect) PDCCH decoding failures and / or behavior. Since the TRP sends its own PDCCH transmissions, which can be mapped to different CORESETs or different search spaces within the same CORESET or two different search spaces associated with two different CORESETs, the WTRU may have a proper signal (RS) and can use the RS to distinguish one radio link quality from another. WTRUs can be configured with TCI states. TCI states can generate CSI-RS and DM-RS PDCCHs for a particular TRP radio link they are placed on (e.g., QCL). Two sets of CSI-RS #1 and DM-RS #1 and separate CSI-RS #2 and DM-RS #2 can be used for WTRUs configured with MTRP reception. These TCI states can be configured per CORESET and per TRP. If multiple CORESETs are defined per TRP, the spatial relationship for CSI-RS and DM-RS placement can be maintained per TRP. Other subdivisions (e.g., any other subdivision) of the search space and CORESETs can follow the TCI state division per TRP. As a WTRU monitors (e.g., initiates monitoring) the PDCCH for a link (e.g., both links), the WTRU may measure (e.g., simultaneously measure) the CSI-RS for TRP-configured radio links (e.g., each TRP radio link). The WTRU may maintain, for each link, one or more of the following measurements and numbers (e.g., counters) respectively: Qin, Qout (e.g., for radio link monitoring (RLM)) and RLM number (e.g., counters and timers); RSRP; RSRQ; L1-SINR; and channel quality indicator (CQI). A CORESET or search space (SS) may have two associated TCI states (e.g., different TCI states). The WTRU can use two different spatial filters and can decode the PDCCH candidates accordingly. The WTRU can apply a different spatial filter to each decoding candidate per TRP / TCI. The WTRU may choose to decode (e.g., attempt to decode) a PDCCH candidate (e.g., both PDCCH candidates) or a single candidate (e.g., only one candidate) based on one or more measurements based on the associated RLM or CSI-RS results per TRP. Qin / Qout may be replaced by an RSRP threshold or L1-SINR level linked to the TRP's CSI-RS set. If the status The previously calculated (e.g., the last calculated) Qin / Qout of a TRP link is Qin, the WTRU may attempt to decode the associated PDCCH transmission. If the link (e.g., both links) show the previously evaluated (e.g., the last evaluated) RLM status is Qin, and the PDCCH transmission associated with the first TRP fails, the WTRU may search for and decode the PDCCH transmission associated with the second TRP. If the previously calculated (e.g., the last calculated) RLM status Qin / Qout for a TRP (e.g., both TRPs) shows Qout, and the WTRU does not declare a radio link failure (RLF), the WTRU may start decoding the spatially related PDCCH transmissions (e.g., both spatially related PDCCH transmissions) in CORESET. If the WTRU successfully decodes the first PDCCH candidate of one TRP, it may ignore searching and decoding for the second PDCCH candidate. MTRP-related PDCCH decoding feedback can be provided. The following feedback and measurement reporting techniques can be used alone or in combination with others. If the PDCCH candidate of a particular TRP fails to decode (e.g., all decoding options), and other PDCCH transmissions from other TRPs are successfully decoded, the WTRU may include an indication of the PDCCH decoding failure in the feedback message for that TRP. The WTRU may include feedback for the PDCCH decoding status that may help the gNB adjust the aggregation level or change the repeat scheme for PDCCH reliability, including reconfiguring the WTRU with a single TRP transmission or other measure (e.g., BWP reconfiguration). Feedback can be added to the Ack / Nack on the PUCCH transmission for scheduled PDSCH transmissions or in the UCI for subsequent PUSCH transmissions in the form of a two-bit codebook. The two-bit codebook can be the following set: {(0,1), (1,0), (1,1)}. The WTRU can use two different RNTIs, for example, one per PDCCH or TRP. The WTRU can use the RNTI associated with a successful PDCCH for feedback so that the gNB can determine which PDCCH transmission was successful. The WTRU can use (for example, implicitly or explicitly) the RNTI of the decoded PDCCH transmission to indicate whether the decoding of the first or second received PDCCH transmission was successful. The WTRU may indicate an ID corresponding to the CORESET or SS associated with the PDCCH (e.g., CORSETpoolindex) to indicate the decoded PDCCH transmission. If a WTRU receives multiple PDCCH transmissions, it may attempt to decode the first transmission. If decoding the first transmission fails, it may attempt to decode the second transmission, and so on. If attempts to decode individual PDCCH transmissions fail, it may attempt to decode a soft combination of the received PDCCH transmissions. For two PDDCH iterations, the WTRU can use an ID corresponding to each attempt and can provide ID feedback to the gNB. The ID can be associated with each attempt and may be a simple index (e.g., 1, 2, 3, etc.). The ID can be an RNTI (e.g., RNTI_attempt1, RNTI_attempt2, etc.). The ID may correspond to a CORESET or SS associated with the PDCCH (e.g., CORSETpoolindex). A WTRU may use (e.g., use only) two IDs in connection with two PDCCH retries. The WTRU may indicate ID1 if the first attempt was successful, and ID2 if the second attempt was successful. The WTRU may indicate no ID in its feedback to indicate that its last attempt with soft merge was successful. On two PDDCH iterations, to reduce the number of decoding attempts and power consumption, the WTRU may attempt decoding of the received PDCCH transmission twice (e.g., only twice). The two attempts may be decoding PDCCH1 and PDCCH2, or decoding PDCCH1 and soft-merging PDCCH1 and PDCCH2. The WTRU may demonstrate its PDCCH decoding capability (e.g., number of decoding attempts) and soft-merging capability to the gNB. Based on the demonstrated capability, the WTRU may receive relevant configuration parameters (e.g., power saving mode, processing time parameters, etc.). The WTRU may provide feedback (e.g., implicit or explicit feedback) on the RNTI of the decoded PDCCH transmission to indicate whether the decoding of the first or second attempt was successful. Determination of successful decoding of PDCCH transmissions can be performed on PUCCH resource selection. A specific PUCCH resource (for example, a resource for a set of configured PUCCH resources) can be linked to the successful decoding of a TRP PDCCH transmission. If the gNB chooses to send DCIs across more than one aggregation level (AL), the WTRU can report which ALs were successfully decoded. The WTRU can report the minimum successful AL (e.g., search space index, CORESET ID, REG bundle size). Reports can be mapped to a codebook that minimizes the size of the feedback report. Reports can be periodic or triggered by a threshold (e.g., a threshold related to the AL size) or associated with failed attempts if PDCCH transmissions are sent across ALs. WTRU can use an ID corresponding to each AL to indicate the minimum successful AL. The ID can be associated with each attempt and can be a simple index (e.g., 1, 2, 3, etc.) corresponding to AL = 1, 2, 4, etc. The ID can be an RNTI (e.g., RNTI_AL1, RNTI_AL2, etc.). The ID may correspond to CORESET or SS associated with PDCCH (e.g., CORSETpoolindex). The WTRU, based on the success or failure of PDCCH decoding per TRP, may maintain a number (e.g., via a counter) per TRP that may increase for each successive failure and may be reset if a successful decoding of a PDCCH transmission is performed. Each number may have a network-configured threshold. If the WTRU reaches the threshold for a particular TRP, it may signal a decoding failure using a feedback technique. The threshold may be set, for example, to one (1), so that each failure is reported. A higher number may imply failure feedback after the count and threshold increase rules are met. The WTRU, upon signaling a PDCCH transmission decoding failure for a particular TRP, may terminate the decoding attempts associated with the TRP and may operate in single TRP receive mode. If the TRP has determined the Qin / Qout status to be Qin, and the PDCCH decoding failure threshold is reached, the WTRU may signal the threshold. The WTRU may continue to monitor and attempt to decode the PDCCH on the TRP. If the measurement for a TRP based on the QCLed RS signal (e.g., CSI-RS) associated with the TRP falls below the threshold, the WTRU may generate a report using RRC reports (e.g., L3) or using a physical layer feedback implementation, and may stop attempting to decode the associated TRP PDCCH transmission. If the TRP is not in the RLF state, based on the Qin / Qout state and numbers (e.g., counters), and the RS measurement is below the configured threshold, the WTRU may report the situation and continue decoding attempts on the associated PDCCH transmission of the TRP. If the PDCCH transmission is sent in time pattern repeat mode, the WTRU can report the number of failed attempts in the repeat cycle. If the PDCCH is sent in two different slots and the WTRU fails on the first attempt, the WTRU can signal the number of failures assuming a PDCCH combination of one (1) attempt, otherwise zero (0) failures. The gNB can optimize the number of repetitions in the time domain or change the reliability scheme. WTRU may reset the numbers (e.g., counters) used in reporting implementation after the related feedback or report is submitted. The PUCCH enhancements disclosed herein may be implemented in systems, devices, and / or methods. The WTRU can improve the reliability of PUCCH transmissions, for example, by transmitting multiple copies (e.g., two copies). The copies (e.g., each copy) can be transmitted, for example, with different spatial relationships, time relationships, or frequency resource allocations (e.g., to improve reception diversity). The WTRU may not be able to transmit repetitions with different parameters against multiple TRPs, for example, if the PUCCH configuration is configured for only one spatial relationship. Enhancements are disclosed to allow the WTRU to switch between different transmission configurations (e.g., transmission configurations with different spatial relationships) and to allow repetitions to be combined. PUCCH formats 0 and 1 (e.g., in NR) can carry uplink control information (UCI) (e.g., small UCI), for example, containing hybrid automatic repeat request (HARQ) feedback and / or scheduling request (SR) bits. PUCCH formats 1 and 0 can be based on, for example, sequence transmissions to carry the UCI information bits. PUCCH format transmissions can be completed, for example, over the duration of one or two symbols. PUCCH format 1 may be based on long sequence transmissions spread over several symbols, for example, to offer more reliable operation and performance for cell-edge WTRUs. The maximum RB size in PUCCH format 1 may be limited to one RB, which may not offer sufficient range and reliability improvements.Repeating the PUCCH format across multiple slots can improve reliability and coverage, but can increase decoding latency (e.g., at the same time). PUCCH format 2 may have a short duration (e.g., similar to PUCCH format 0). PUCCH format 2 can carry a larger payload (e.g., PUCCH format 2 can be configured with more than one RB). Enhanced PUCCH transmissions can be used to improve reliability and extend coverage, for example, in systems with one or more transmission points. One form of enhanced PUCCH transmission may be based on repetition (e.g., a form of repetition). In an example, short PUCCH transmissions (e.g., PUSCH 0 and 2 formats) can be repeated within a slot, for example, to improve coverage and transmission reliability. PUCCH repetition can be realized, for example, by using resources that can be used for PUSCH transmissions (e.g., as shown by the example in FIG. 5). FIG. 5 is a diagram illustrating an example of PUCCH recurrence for enhanced PUCCH transmission. The activation and deactivation of enhanced PUCCH transmissions and resource allocation may be performed, for example, by a WTRU. The WTRU may determine (e.g., implicitly and / or explicitly determine) the use of enhanced PUCCH transmissions, for example, by dynamic or semi-static signaling. The WTRU may receive a set of resources (e.g., an indication of a set of resources) for enhanced PUCCH transmissions. The resource indication may be received (e.g., implicitly or explicitly received), for example, by semi-static or dynamic indication. The WTRU may, for example, implicitly determine the use of enhanced PUCCH transmission. The WTRU may determine (e.g., implicitly determine) the activation (e.g., and deactivation) of enhanced PUCCH transmission. The WTRU may be configured to react to one or more implicit indications. The WTRU may consider the implicit indications in addition to other triggers for activating enhanced PUCCH transmission. Implicit indications for enhanced PUCCH transmission may be implemented. One or more of the following may apply. In the example, the WTRU can detect the activation of enhanced PUCCH transmission, for example, if the WTRU determines that the WTRU is configured in MTRP transmission. In an example, the WTRU can detect activation of an enhanced PUCCH transmission, for example, if the WTRU receives an indication by the DCI including multiple (e.g., two) TCI states and one code division multiplexing (CDM) group, and if the higher layer parameter RepSchemeEnabler is set to one of 'FDMSchemeA', 'FDMSchemeB', and 'TDMSchemeA'. Two antenna ports can be multiplexed on the same set of subcarriers by assigning different orthogonal codes. The WTRU can detect activation of an enhanced PUCCH transmission, for example, if the WTRU receives an indication by the DCI including two TCI states and two CDM groups, without a TDRA field. In the example, the WTRU can be triggered to use some PUCCH configuration, for example, based on the detected RNTI. The WTRU can, for example, detect a DCI scrambled with the RNTI. The WTRU may determine from the RNTI value that the transmission is intended for multiple TRPs (e.g., MTRP-RNTI, or C-RNTI with values ​​defined in different ranges for single and MTRP). The WTRU may be triggered (e.g., based on the determination) to use any number of PUCCH configurations. In the example, a PUCCH configuration (e.g., each PUCCH configuration) may be associated with a separate K1, PUCCH resource indicator (PRI), and spatial relationship, so that the WTRU can transmit multiple copies. The MTRP-RNTI may be defined, for example, to indicate or allow the WTRU to determine the number of iterations of the MTRP-RNTI value. For example, the MTRP-RNTI value may be defined from [0;k*n1-1] for n1 iterations and from [k*n1:k*n2-1] for n2 iterations, where k may be a scaling factor. The WTRU may choose to use n1 iterations with n1 associated K1, PRI, spatial relationship, and / or PUCCH configurations, for example, if the MTRP-RNTI value is less than k*n1.Some configurations of PUCCH, K1, PRI, spatial relationships, and the like can be indicated (e.g., explicitly shown) in the DCI (e.g., randomized with mTRP-RNTI) and / or can be preconfigured in the WTRU. The WTRU can perform enhanced PUCCH transmissions, for example, based on quality measurement thresholds. The WTRU can perform enhanced PUCCH transmissions, for example, based on comparing downlink measurements (e.g., L1-RSRP, L1-SINR, CQI, mobility status, doppler frequency, etc.) to configured thresholds. The WTRU may determine the activation of enhanced PUCCH transmissions, for example, based on PUCCH format and / or priority. For example, the WTRU may use enhanced PUCCH transmissions for PUCCH format 0 or 1 (e.g., only PUCCH format 0 or 1). The WTRU can be configured (e.g., explicitly configured) to enable or disable enhanced PUCCH transmission. The WTRU can be configured (e.g., with higher-layer signaling) to enable or disable enhanced PUCCH transmission. The WTRU can be configured with additional information related to a set of dedicated resources that can be used for enhanced transmission (e.g., PUCCH replay on dedicated resources). The dedicated resources can be specified (e.g., by configuration) to be available statically (e.g., indefinitely or always) and / or for a configured duration. The duration (e.g., trackable, e.g., using a timer) can be based on, for example, an indication (e.g., explicit) (e.g., DCI or MAC CE). The WTRU may receive indications (e.g., dynamic) (e.g., via DCI or MAC CE) to enable or disable enhanced PUCCH transmission. In the example, the DCI field may be considered an indication of the activation or disabling of enhanced PUCCH transmission. The DCI field may be a new field or a reuse of an existing field. The DCI may indicate a set of resources to be used by the enhanced PUCCH transmission. In the example, the DCI may (e.g., directly) point to a set of resources. The resources may be specified, for example, based on a fixed or configurable offset from the PUSCH resource. The resources indicated for the enhanced PUCCH may be inside or outside the PUSCH resource zone. For example, the WTRU may use the indicated PUSCH resource for enhanced PUCCH transmission, for example, if the WTRU receives an uplink clearance (e.g., without sending an SR). The WTRU may interpret the received clearance as activating enhanced PUCCH transmission. PUCCH looping and resource selection may be provided. The WTRU may perform intra-slot hopping for looping (e.g., per loop), for example, to improve (e.g., further enhance) PUCCH looping performance. The WTRU may use different looping and hopping patterns (e.g., per PUCCH type). The WTRU may assume fixed or predetermined looping and hopping patterns. The WTRU may receive related information (e.g., semi-static or dynamic). Related information may include hopping patterns. The WTRU may assume that the pattern may be fixed, predetermined, or may be indicated dynamically / semi-statically. In an example, the loop may be repeated at a location other than the resource location indicated by the PUCCH resource indicator (e.g., as shown by the example in FIG. 5, in the bandwidth section). Beamforming for PUCCH transmissions can be indicated (e.g., in NR) via spatial information. There can be one or more spatial relationship configurations (e.g., parameter values) for a PUCCH resource (e.g., each PUCCH resource). The spatial settings for PUCCH transmissions can be provided (e.g., for a single configuration), for example, by the pucch-SpatialRelationInfoId configured in PUCCHSpatialRelationInfoId. The WTRU can determine the spatial settings (e.g., a single spatial setting) for PUCCH transmissions by the MAC control element, for example, if the WTRU is provided with multiple values ​​for PUCCHSpatialRelationInfo. PUCCH transmissions can be performed according to the spatial filter used for receiving SSB, configured CSI-RS, or for SRS transmissions, for example, depending on the index configured in the spatial relationship information. FIGURE 6 is a diagram illustrating an example of a PUCCH transmission enhanced with spatial link cycling. The WTRU can be configured with any number of PUCCH repetitions. The WTRU can cycle through the configured spatial link cycles for PUCCH repetition transmissions (e.g., every PUCCH repetition transmission). In an example, a PUCCH resource ID (e.g., each PUCCH resource ID) may be configured with multiple (e.g., eight) PUCCH spatial relationship information, e.g., represented by code points in the MAC CE. The spatial information configured in the code points (e.g., each code point) may be applied to PUCCH transmissions (e.g., each PUCCH transmission). The WTRU may select from the MAC CE (e.g., one of the reserved bits in the MAC CE) whether to apply spatial cycles to PUCCH repeats or active spatial relationships (e.g., only active spatial relationships). In an example, a WTRU may be configured with multiple PUCCHSpatialRelationInfos. A configuration code point (e.g., each configuration code point) may represent one or more states of a spatial domain filter. A code point may be indicated to the WTRU. The WTRU may apply the spatial domain filter represented by a different state at the code point on each PUCCH iteration. The application of the spatial domain filter indicated by a state (e.g., each state) may, for example, be sequential (e.g., based on a sequence of states or other predefined pattern known to the WTRU and the gNB). The WTRU may (e.g., as shown by the example in FIG. 6) transmit PUCCH repeats, for example, considering one or more symbols as guard time (TG) between transmissions, for example, to allow sufficient time for spatial filter reset. In an example, a WTRU may be configured with multiple beams (e.g., multiple PUCCH-spatialRelationInfo, spatial domain filters, etc.) for PUCCH transmissions with N repetitions. A PUCCH transmission (e.g., each PUCCH transmission) of N repetitions may be associated with (e.g., one) configured beam. A beam may be defined, for example, as a function of: the symbol index (e.g., the index of the starting symbol in a slot); and / or the PUCCH transmission number (e.g., the i-th transmission of N repetitions, where i may be referred to as the PUCCH transmission number). The WTRU may be configured with a plurality of PUCCH repetitions. A PUCCH repetition (e.g., each PUCCH repetition) may be associated with PUCCH spatial relationship information (e.g., beams). The WTRU may determine a subset of PUCCH repetitions for transmission, for example, based on one or more of the following: measurements of the associated downlink reference signal in each PUCCH spatial relationship information and / or the power backoff level of the PUCCH transmission associated with the PUCCH spatial relationship information. The WTRU may determine a subset of PUCCH iterations for transmission, for example, based on measurements of associated downlink reference signals in the PUCCH spatial relationship information (e.g., each PUCCH spatial relationship information). For example, one or more downlink reference signals may be associated with one or more PUCCH spatial relationship information. The WTRU may determine the subset based on measurements. For example, the WTRU may select a subset of iterations associated with PUCCH spatial relationship information with measurements higher than a threshold. The DL reference signals associated with the SRI may be used for DL ​​measurements, for example, if the SRI is used as the PUCCH spatial relationship information. The WTRU may determine a subset of PUCCH repeats for transmission, for example, based on the power back-off level of the PUCCH transmission associated with the PUCCH spatial relationship information, for example, due to maximum permissible exposure (MPE). For example, the WTRU may make a determination (e.g., decide) to pass a PUCCH transmission in a PUCCH repeat, for example, if the power of the associated PUCCH transmission is less than a threshold or if the power back-off level is higher than a threshold (e.g., due to MPE), based on the associated PUCCH spatial relationship information. The WTRU can define different PUCCH resource indicators (PRIs) and spatial relationships for PUCCH iterations. For example, the WTRU can use the PRI value to determine which PUCCH resource configuration to use. The PRI may be a one-to-one index for the PUCCH resource. The WTRU can receive the PRI, for example, in a DCI, and / or the WTRU can receive the PRI in a RACH procedure (for example, msgB or msg4). For example, WTRU can determine the spatial relationship of PUCCH and PRI. The WTRU can determine the spatial relationship of PUCCH and PRI, for example, through the association between PRI values ​​and spatial filters. For example, the WTRU can receive a PRI. A PRI can be associated with any number of spatial filters. The WTRU can be triggered to transmit multiple copies of the PUCCH using the PRI. The WTRU can use multiple different spatial filters associated with PRIs for multiple copies. The relationship between PRIs and spatial filters may, for example, be preconfigured. The PUCCH configuration can be activated by frequency hopping. The WTRU can define a different spatial relationship for each hopping. The WTRU can define the spatial relationship of PUCCHs and PRIs, for example, through a number of PRI values. PRIs (e.g., each PRI) can be associated with a spatial relationship. For example, the WTRU can accept a pair (e.g., PRI_i1, PRI_i2). The WTRU can choose, for example, whether to use PRI_i1 for iteration i1 (e.g., with an associated SRI_i1) and PRI_i2 for iteration i2 (e.g., with an associated SRI_i2). SRIs can be associated with PRIs, for example, as part of a configuration. The WTRU can determine the spatial relationship of PUCCH and PRI, for example, based on an offset. The WTRU can accept an offset (e.g., delta_K). The spatial relationship and PRI for a loop can be determined, for example, based on a single pair (PRI, SRI). For example, the WTRU can make a decision to use PRI_i1 = PRI with associated SRI_i1 = SRI for loop i1. The WTRU can decide to use PRI_i2 = PRI+delta_K with associated SRI_i2 = SRI for loop i2, or the WTRU can decide to use PRI_i2 = PRI with SRI_i2 = SRI +delta_K for loop i2. For example, the WTRU can use Eq. 1 with delta_K to determine the PUCCH resource: rpu cch = t ~ + ApRi + delta_K Eq. 1 ™ CC E ,p where NCCE-p may be the number of CCEs in CORESET pn^ on PDCCH reception for DCI format,CCE,pmay be the index of the first CCE for PDCCH reception, andΔ PRImay be the value of the PUCCH resource indicator field in DCI format. The WTRU can select K1 and a spatial relationship for PUCCH repetition. The WTRU can use the K1 value, for example, to determine when to transmit the PUCCH in time. K1 may be the time offset between PDSCH transmissions to the PUCCH. The WTRU can receive a K1 value (e.g., a single K1 value), for example, in DCI, or the WTRU can receive K1, for example, in RACH procedures (e.g., msgB or msg4). The WTRU can determine the spatial relationship of PUCCHs, for example, by using the K1 value. The WTRU may determine the spatial relationship of PUCCHs, for example, through the association between K1 values ​​and spatial relationships. For example, the WTRU may receive multiple K1 values ​​(e.g., two K1 values) and may transmit PUCCHs in multiple different time instances (e.g., two different time instances) identified by multiple K1 values ​​(e.g., two K1 values). A K1 (e.g., each K1) may be associated with a spatial filter. The WTRU may determine which spatial transmission filter to use for a transmission (e.g., each transmission), for example, based on the K1 value. For example, a K1 (e.g., each K1) may be associated with an SSB, CSI-RS, or SRS, from which the WTRU may determine the QCL information. The WTRU can determine the spatial relationship of PUCCHs, for example, through the relationship between a TCI code point and one or more K1 values. For example, the WTRU can receive a TCI code point associated with multiple TCI states (e.g., two TCI states). The WTRU can, for example, determine which code point to configure with multiple K1 values ​​(e.g., two K1 values), or each TCI state can be configured with a K1 value. The WTRU can be triggered to send multiple repetitions according to the number of K1 values ​​associated with the TCI code point or the number of TCI states. In the example, a K1 value (e.g., a single K1 value) and an offset K1_offset may be linked to multiple PUCCH resources. The PUCCH resources (e.g., each PUCCH resource) may be configured with a spatial relationship. In the example, the WTRU may decide to send the first PUCCH repetition with time offset K1 on PUCCH resource 1. The WTRU may send the second PUCCH repetition with time offset K1+K1_offset on PUCCH resource 2. The time offset K1_offset may be indicated (e.g., indicated dynamically) or may be a configurable value. FIG. 7 is a diagram illustrating an example of resource configuration for PUCCH repeaters based on the K1 value. FIG. 7 shows an example where the WTRU determines the PUCCH resource based on the K1 indication and uses an offset to trigger the WTRU to send multiple repeaters, i.e., each with a separate configuration. The WTRU can determine the spatial relationship of the PUCCH, for example, by using the K1 value. The WTRU can use the offset index to determine the spatial relationship per TRP. In the example, i1 may be the SRI indicated in the DCI. The WTRU can choose to use i1 in the first iteration, i2 = i1 + (i3-1)*SRI_offset for the second iteration (for example, where the SRI_offset may be indicated in the DCI or preconfigured) and i3 is the index of the transmission (for example, the iteration index, TRP index, CORESETpoolindex). The WTRU can determine the spatial relationship of the PUCCH, for example, by using the K1 value. The SRI time or offset can be indicated, for example, dynamically in the DCI, in msg3 or msgB, or as part of the MAC-CE sent to update the spatial relationship of the PUCCH resource. The WTRU can be configured to define a number of iterations and spatial filter patterns. The WTRU can define (e.g., can dynamically define) the number of iterations and spatial filter patterns such as, for example, SRI, for PUCCH based on a lookup table. The table can be preconfigured (e.g., via RRC) as part of the PUCCH configuration. The SRI configuration can consist of SRI values ​​or patterns (e.g., SRI1-SRI2). SRI values / patterns can be defined for the PUCCH case. The WTRU can also define SRI values / patterns for PUSCH iterations. The table can be configured for either PUCCH or PUSCH configuration and can be used for either configuration. One table can be used for both PUCCH and PUSCH, or one table can be configured per PUCCH and PUSCH. The table can consist of links between iteration numbers and SRI values ​​or SRI value patterns. The table can link one iteration number to more than one SRI value pattern. The table can consist of links to SRI patterns.For PUCCH iterations, tables may apply to specify PRI values / patterns or combinations of SRI / PRI pairs. An SRI value / pattern may be linked to multiple PRI values / patterns, and the SRI / PRI value / pattern pair to be used may be determined using, for example, techniques such as those described herein. A PRI value / pattern (e.g., a single PRI value / pattern) may be linked to multiple SRI values / patterns. Predefined rules can be used to select the PUCCH retracement number and / or pattern based on parameters and / or parameter combinations (e.g., as described herein). The TRP can be informed of the WTRU's selection through the predefined rules. The TRP can monitor the retracement number and pattern based on tables and rules configured with the tables. The WTRU can dynamically switch between single and multiple TRP operation. The WTRU can choose to switch based on the RSRP difference between TRP1 and TRP2. If the difference is determined to be below a threshold, the WTRU can determine that the difference is likely equidistant from the TRP and can choose to use transmission to multiple TRPs. FIG. 8 illustrates an example technique for a preconfigured WTRU with a table linking repetitions and spatial filter patterns where each spatial filter can be specified by an SRI. Referring to FIG. 8, SRI1 and SRI2 can target TRP1. SRI3 and SRI4 can target TRP2. The WTRU can use a combination of parameters to select the appropriate repetition number, multiple TRP operation mode, and spatial filter pattern. The WTRU can perform an RSRP measurement and generate a report to the TRP. The WTRU can determine that the RSRP is above a threshold, which can be judged sufficient for a single repetition. The WTRU can determine that the RSRP difference between TRP1 and TRP2 is above the threshold. The WTRU can determine that TRP1 can be used (e.g., should be used). Based on the table and the CSI report, TRP1 can determine that the next PUCCH transmission can be a single repetition sent from the WTRU with SRI1.For subsequent PUCCH transmissions, the WTRU may select single TRP mode with one repetition and may use the SRI1 spatial filter. The WTRU may make (for example, may subsequently make) another RSRP measurement and may report that measurement to the TRP. The WTRU may determine that the RSRP difference between TRP1 and TRP2 is below a threshold. If the WTRU subsequently sends a PUCCH transmission, it may select multiple TRP mode with two repetitions and may use the SRI1 and SRI3 patterns. The WTRU can determine which entry to use in the table, which can consist of a combination of repetition numbers and / or patterns, based on one or more parameters. Parameters can be related to one or more of the following: signal quality; panel configuration; TRP operating mode; previous transmission; subframe number; RS group; PRI (associated with the PUCCH case); and / or repetition type. The WTRU can determine which table entry to use based on parameters related to signal quality. The WTRU can choose to use SRI if the RSRP is above a threshold. The WTRU can determine which entries in the table to use based on parameters related to the panel configuration. The WTRU can choose to use SRIs sent from the same or different panels. The WTRU can choose to change the number of iterations, for example, based on the number of panels enabled. If the WTRU uses two panels, it can use two iterations per panel. If one panel is disabled, the WTRU can switch to four iterations per panel. The WTRU can determine which entry in the table to use based on parameters related to the TRP's operating mode. The WTRU can choose to use an SRI based on whether it is sending to a single TRP or multiple TRPs. The WTRU can use a pattern with an SRI targeting a single TRP, or it can use a pattern with one SRI per TRP. The WTRU can determine which entry in the table to use based on parameters associated with the previous transmission (e.g., the last transmission). The WTRU can choose to use a pattern containing an SRI used in a previous scheduled transmission (e.g., in a DCI, or configured permit) or used in a previous UL transmission (e.g., the last UL transmission) which may have been, for example, a RACH. The WTRU can determine which entries in the table to use based on parameters related to time, time duration, etc. (e.g., using a timer). The WTRU can choose to use a number or pattern of repetitions based on time, time duration, etc. (e.g., using a timer). For example, the WTRU can choose to use a pattern that includes the SRI used in the last T or TTI subframe. The WTRU can determine which entry in the table to use based on parameters associated with the subframe number. The WTRU can determine the SRI based on the SFI pattern or the even / odd parity slot. The WTRU can choose to use one SRI pattern if it is scheduled to start in an even slot. WTRU can determine which entries in the table to use based on parameters associated with the RSS group. WTRU can choose to use any SRI that belongs to the same RS group. The WTRU can determine which entry in the table to use based on parameters associated with the PRI (e.g., in the case of PUCCH). The WTRU can determine the SRI based on the associated PRI value. A PRI value / pattern (e.g., each PRI value / pattern) can be linked to multiple SRI values. The WTRU can choose to use one of the SRI values / patterns linked to a PRI (e.g., SRI1, SRI2) when transmitting with PRI1. The WTRU can determine which PRI value / pattern and number of PRIs to use based on the SRI value / pattern. The WTRU can determine which entry in the table to use based on the associated A / B repetition type (for example, in the case of PUSCH). The WTRU can determine which SRI configuration to use based on the configured repetition type. For example, if the repetition type is type A, the WTRU can choose to use SRI pattern 1. If the repetition type is type B, the WTRU can use SRI pattern 2. If the repetition type is type B, the WTRU can determine the pattern depending on whether the nominal repetition count is equal to the actual repetition count. The WTRU may be configured to address PUCCH repetitions overlapping with PUSCH. A set of PUCCH repetitions may overlap with one or more PUSCH transmissions or PUSCH repetitions. The WTRU may multiplex the uplink control information (UCI) of the PUCCH repetitions with the overlapping PUSCH transmissions, for example, if at least one of the following conditions is met: the PUCCH payload size is below a threshold, where the threshold may be predefined (e.g., 12 bits or 2 bits) and may correspond to the maximum payload size for a particular coding type such as, for example, polar coding or block coding; the coding scheme for the UCI coding is one of a set of coding schemes permitted for multiplexing with PUCCH repetitions (e.g., block coding);the number of code bits for the UCI after matching is the same across PUCCH iterations and PUSCH iterations or transmissions (e.g., all PUCCH iterations and PUSCH iterations or transmissions); or each PUCCH iteration will overlap with a PUSCH transmission or iteration and a multiplexing condition, which may be related to the timeline, is satisfied for each PUCCH iteration. If at least one of the above conditions is satisfied, the PUSCH transmission cannot be dropped and the receiver on the network side may be able to combine the reception of multiple UCI transmissions via PUCCH or PUSCH.; Additional conditions related to the priority indices of PUCCH and PUSCH transmissions must be met for multiplexing to occur. A PUCCH or PUSCH transmission may be downgraded if its priority index is lower than that of the overlapping transmission and if the latency and / or reliability requirements of the transmission with the higher priority index might not be met if multiplexing were performed. If the priority index of the PUCCH repeat and the PUSCH transmission or repeat is the same, the WTRU can drop the overlapping PUSCH transmission or repeat, for example, if at least one condition is not met. PUCCH / PUSCH multiplexing and repetition can be provided. Among the PUCCH formats, PUCCH format 2 may be based on OFDM transmission, PUCCH formats 0 and 1 may be sequence-based, and formats 3 and 4 may be based on DFT-OFDM transmission. PUCCH format 2 may have a short time duration (e.g., similar to PUCCH format 0). For example, an enhanced PUCCH transmission may be based on a PUCCH 2 format repeat. One or more PUCCH repeat opportunities may occur simultaneously as a PUSCH transmission. PUCCH repeats may occur (e.g., if enhanced PUCCH transmission is enabled), for example, based on a fixed or predetermined pattern relative to the PUCCH resource indicated by the PUCCH resource indicator. For example, a PUCCH transmission may be repeated at the same frequency location as the PUCCH resource indicated by the PUCCH resource indicator. PUCCH repeats may occur based on a hopping pattern, for example, with a configurable offset relative to the actual PUCCH transmission (e.g., original, non-repeated). In an example (e.g., if a PUCCH repeat transmission is concurrent with a PUSCH transmission), the spatial domain filter for the PUCCH repeat can be replaced by a spatial domain filter for the ongoing PUSCH transmission. The UCI can be multiplexed with the PUSCH data (e.g., in NR). The PUSCH payload can be moved or matched, for example, depending on the size of the UCI. In the example, the UCI transmission can be improved, for example, by using a repeat mechanism for the actual UCI. The WTRU can improve the UCI transmission, for example, by using a repeat (e.g., a simple repeat) of the HARQ and / or SR bits or by using a codeword. The WTRU can improve the reliability of the UCI transmission, for example, by using more than one bit to transmit the HARQ and / or SR feedback. The WTRU can use a codeword consisting of several bits corresponding to the UCI content (e.g., each UCI content).UCI multiplexing with PUSCH can be used for UCI repeat (for example, only used for UCI repeat), for example, as an addition to the actual PUCCH transmission. The PUSCH enhancements disclosed herein may be implemented in systems, devices, and / or methods. The WTRU can transmit multiple copies, for example, to improve the reliability of PUSCH transmission. Copies (e.g., each copy) can be transmitted, for example, with different spatial, temporal, or frequency resource allocation relationships, for example, to improve reception diversity. The WTRU can define spatial transmission filters. The WTRU can use spatial domain resource allocation tables. The WTRU can define spatial relationships for uplink transmission and downlink reception. The example described for defining spatial relationships for uplink transmission on PUSCH can be used to define multiple spatial relationships for downlink reception on PDSCH. The word PUSCH can be replaced with PDSCH and a similar implementation can be implemented for the downlink. The WTRU can determine the spatial relationship between PUSCH loops and spatial transmission filters, for example, based on a spatial domain resource allocation (SDRA) table. The SDRA table can be configured, for example, with a number of loops (e.g., row 1 for a single loop, row 2 for two loops, and so on). Table 1 is an example of an SDRA table. Each row can have N_set subentries, where N_set can be the number of spatial relationship sets configured per loop (e.g., see FIGS. 8, 10, and 11). Table 1 - Example of SDRA table Number of repetitions SDRA bit field Spatial relationship set 1 0 {RS_1} 1 {RS_2} 2 0 {(RS_1, RS_2)} 1 {(RS_3, RS_4)} WTRU can be triggered to use a spatial relationship set (e.g., a set of spatial relationships), for example, based on the K_SDRA bit field of length log2(N_set) in The DCI that schedules PUSCH transmissions (e.g., as shown in Fig. 9) and / or RS indexes provided in the DCI. FIG. 9 is a diagram depicting an example of a resource configuration for PUCCH repetition based on one or more SDRA and TDRA. TDRA can be used by the WTRU to determine the number of repetitions. In the example, the resource configuration can refer to spatial filter associations for repetitions. The WTRU can be triggered to use a spatial relationship set based on, for example, the K_SDRA bit field of length log2(N_set) in the DCI that schedules the PUSCH (e.g., as shown in the example in FIG. 9). The WTRU can determine that the WTRU's PUSCH transmission is configured with two repetitions, for example, from the TDRA. In the example, the WTRU can be configured with an SDRA table (e.g., the example SDRA table in Table 1) and look for a row (e.g., row 2) that corresponds to two repetitions. The row can be configured with N_set of spatial relationship sets: {(RS_1, RS_2), (RS_3, RS_4)}. The received SDRA bit field may have a value of 0. The WTRU can be triggered to use the first spatial relationship set (RS_1, RS_2), for example, based on the SDRA bit field having a value of 0.The WTRU may determine that the spatial transmission filters for iterations 1 and 2 are based on RS_1 and RS_2, respectively. The WTRU can be triggered to use a spatial relationship set based on, for example, the RS index provided in the DCI. The spatial relationship set can be defined, for example, so that each set has a one-to-one relationship with an RS. The WTRU can determine the rows of the SDRA table, for example, based on the number of repetitions. The WTRU can decide to use a spatial relationship set that contains the RS index. For example, the RS in the spatial relationship set can consist of SRIs. The WTRU can receive an SRI in the DCI. The WTRU can decide to send two repetitions. The WTRU can determine (for example, based on the SDRA table as shown in Table 1) that the spatial relationship set associated with the two repetitions can be configured as {(SRI_1, SRI_2), (SRI_3, SRI_4)}. The WTRU can receive SRI_1 in DCI. The WTRU can decide to use the spatial relationship set that contains SRI_1, namely (SRI_1, SRI_2), for example, if the WTRU receives SRI_1 in DCI. The spatial relationship set in the SDRA table can be reconfigured, for example, if the WTRU or TRP determines that updated spatial relationships can provide better performance. The TRP can update the spatial relationship set, for example, via a MAC-CE containing the K_SDRA value. The WTRU can provide the spatial relationship set with the uplink MAC-CE. For example, the WTRU may choose to deactivate a panel. The WTRU may suggest a spatial relationship set to update the SDRA table, for example, so that the spatial relationship set (e.g., all spatial relationship sets) are configured for the activated panel. WTRU can determine spatial relationships, for example, based on an enhanced TDRA configuration. WTRU can be configured with a push-AllocationList table. A row (e.g., each row) of the table can be configured with a set of spatial relationships. WTRU can be triggered to use multiple spatial relationships from a set, for example, if an allocation PUSCH is configured with repetitions. The WTRU can decide to enforce the spatial relationships of the list, for example, by associating a repetition index (e.g., one repetition index) with a value (e.g., one value) in the spatial relationship set. The switching time offset can be configured, for example, to allow the WTRU to switch the WTRU's spatial relationships for each transmission. For example, the WTRU can receive a TDRA pointing to row n of the push-AllocationList and the row can be configured with the value K2, the Type B mapping, the start and length indicator (SLIV) value, the switching time offset, and the spatial relationship set spatialRelationSet = [RS_1, RS_2, .„]. The WTRU can decide to use the spatial relationships for repetitions in the appropriate order in the list. For example, repetition 1 uses RS1, repetition 2 uses RS2, and so on.The WTRU may decide to apply a switching time offset between each repetition when switching the WTRU's spatial relationship. The TRP may wait to receive repetitions with the specified spatial relationship and at the time with the offset applied between them. PUSCH repetitions can be scheduled with different spatial relationships. The WTRU can use the K2 value, for example, to determine when to send a PUSCH. K2 can be the time offset between PDCCH and PUSCH transmissions. The WTRU can receive a K2 value (e.g., a single K2 value), for example, in a DCI that schedules PUSCH transmissions. The WTRU can decide to send multiple PUSCH repetitions with different spatial filters. For example, the WTRU can alternate WTRU transmissions to multiple receiving TRPs. The spatial filters used for each TRP can be selected differently, for example, to maximize the received signal. The WTRU can use the time lag between repetitions, for example, to determine when to send repetitions and to allow the WTRU to change the characteristics of the WTRU's spatial filter. In the example, WTRU can determine the K2 value and the PUSCH spatial relationship for multiple PUSCH iterations. A WTRU may determine the K2 value and the spatial relationship of a PUSCH for multiple PUSCH iterations, for example, through the relationship between the K2 value and the spatial relationship. For example, a WTRU may receive multiple K2 values. A K2 value (e.g., each K2 value) may be associated with a spatial filter. For example, a WTRU may receive multiple (e.g., two) K2 values ​​in a DCI that schedules PUSCH transmissions. The WTRU may send PUSCH transmissions in multiple (e.g., two) different time instances identified by multiple (e.g., two) K2 values. The K2 value (e.g., each K2 value) may be associated with a spatial filter, for example, so that the WTRU can determine which spatial transmission filter to use for a iteration (e.g., each iteration) based on the K2 value. The WTRU can determine the K2 value and the PUSCH spatial relationship for multiple PUSCH repetitions, for example, through the relationship between the UL TCI code point and the K2 value. For example, the WTRU can receive a UL TCI code point linked to multiple (e.g., two) TCI states. The code point can be linked to multiple K2 values. The WTRU can use multiple K2 values ​​to send PUSCH repetitions at different time instances. The WTRU can determine the WTRU spatial filter, for example, based on the UL TCI state linked to the TCI code point. The K2 value can be linked to the TCI state. The WTRU can receive a K2 value (e.g., a single K2 value) and an offset, K2_offset, which the WTRU can use to determine when to send a PUSCH repetition. The WTRU can decide to send the first PUSCH repetition with a time offset of K2, and send the second PUSCH repetition with a time offset of K2+K2_offset. The time offset K2_offset can be indicated (e.g., indicated dynamically) in the DCI or may be a configurable value. The WTRU can decide to use the offset, for example, if the WTRU is scheduled with multiple repetitions to multiple TRPs. The WTRU can decide to use a spatial relationship (e.g., provided in the DCI) for the repetitions, or the offset can be linked to the spatial relationship.For example, the WTRU may apply the offset as: K2 = K2_DCI + (i3-1)*K2_offset, where K2 may be the offset used for the repeat, K2_DCI may be the value indicated in the DCI, i3 may be the index of the i3rd transmission (e.g., repeat index, TRP index, coresetpool index), and K2_offset may be the offset. The WTRU may specify the time slot to be used for the i3rd transmission, for example by i3. The WTRU can define spatial filters for repeat transmissions, for example. The WTRU may use the offset index to determine the spatial relationships included in the DCI. For example, i1 may be the SRI indicated in the DCI. The WTRU may decide to use i1 for the first repetition, i2 = i1 + (i31)*SRI_offset for the second repetition (e.g., where SRI_offset may be indicated in the DCI or may have been preconfigured) and i3 may be the index of the i3rd transmission (e.g., repetition index, TRP index, coresetpoolindex). The WTRU can be pre-configured with spatial relationship patterns, for example, for use on multiple links. The WTRU can be triggered to use the pattern, for example, if the WTRU receives a TCI code point with multiple linked TCI states. The WTRU can specify a spatial filter implicitly based on the DCI field. The spatial filter index, number of repetitions, single / multiple TRP modes, and / or spatial filter pattern can be referred to as the spatial filter configuration. The WTRU can be scheduled to send PUSCH repetitions with a DCI that may not signal (i.e., explicitly signal) the spatial filter, number of repetitions, or spatial filter pattern. The WTRU may determine (e.g., implicitly determine) a spatial filter configuration, for example, through one or a combination of fields in the DCI and links from the fields to a spatial filter configuration table as illustrated in FIG. 10. One or more DCI fields may be linked to a spatial filter configuration. The WTRU may determine the spatial filter configuration based on one or a combination of DCI field states. DCI fields may include new data indicators (NDI), frequency hopping flags, MCS, redundancy values ​​(RV), BWP indicators, UL or additional UL indicators (SUL), and the like. If the WTRU receives an NDI=0 field state, it may use pattern1 (e.g., SRI1-SRI2). If the WTRU receives an NDI=1 field state, The WTRU can use SRI1-SRI2-SRI3-SRI4. The WTRU can use any combination of field states to determine the spatial filter configuration. If the WTRU receives data indicating NDI = 0 and RV = 0, the WTRU can choose to use SRI1-SRI2. If the WTRU receives data indicating NDI = 0 and RV = 1, the WTRU can choose to use SRI3SRI4. The DCI field states can be encoded into the bit stream. The value '00' in the bitstream can be used to correspond to the NDI DCI field being equal to zero (NDI = 0) and the DCI field being equal to zero (NDI = 0). RV is equal to zero (RV = 0). The value '01' in the bitstream can be used to correspond to the DCI field NDI equal to zero (NDI = 0) and the DCI field RV equal to one (RV = 1). Each bitstream can be mapped to a spatial filter configuration table. The mapping can be reconfigured, for example, via MAC-CE. The WTRU can specify how to map the spatial filter configuration to one-to-one repeats, or the WRTU can specify different patterns based on the DCI plane. The WTRU can specify that the spatial configuration pattern is SRI1-SRI2 with four repeats. If RV is specified equal to zero (RV=0), the WTRU can apply SRI1-SRI1-SRI2-SRI2. If RV is specified equal to one (RV=1), the WTRU can apply SRI1-SRI2-SRI1-SRI2. The patterns can be linked to the number of repeats so that the WTRU can specify to use one pattern with two repeats and a different pattern if sending four repeats. Fields can be linked to entries in tables such as the SDRA table described in connection with Table 1. The WTRU can receive an explicit SDRA indication in the DCI, for example, which may indicate a subset of SRI values / patterns. The WTRU can determine one value / pattern from the subset, for example, using field values ​​from the DCI. Preconfigured tables can be used (e.g., as depicted in FIG. 10) if there is no indication (e.g., explicit indication) in the DCI of the spatial filter configuration. TRPs can be used to configure links between DCI values ​​and spatial filter configuration table entries. The WTRU can derive (e.g., implicitly derive) spatial filter configurations based on one or many DCI fields. The WTRU can receive a DCI with a frequency hopping flag equal to one (frequency hopping flag = 1), an NDI equal to zero (NDI = 0), and an RV equal to three (RV = 3).The WTRU can map the DCI field to a table with a preconfigured spatial filter configuration. The table can be part of a PUSCH configuration or linked to a PUSCH configuration that can, for example, be used for PUCCH. The WTRU can choose to use four loops, across multiple TRPs, with SRI1 and SRI3 in the pattern SRI1-SRI1-SRI3-SRI3. If the TRP schedules a WTRU with a DCI, the TRP can monitor the WTRU loops according to the links established in the table. The WTRU can provide feedback via CSI reports or beam failure recovery (BFR) (e.g., BFR MAC-CE). The TRP can change the spatial filter configuration in the table based on the WTRU feedback. MAC-CE or RRC reconfiguration can be used to update the table. The DCI field can be mapped to more than one pattern. The WTRU can choose to use one pattern over another, for example, based on parameters. The WTRU can choose to use one or more patterns based on one or more of the following: channel quality (RSRP, SINR, and the like); the last used spatial filter configuration; the default configuration (e.g., using a single TRP by default); the time, time duration, timer, etc. (e.g., between a DCI and a scheduled PUSCH); and / or the subframe index in which the DCI was received. The WTRU may use configured permits with multiple spatial relationships. The WTRU may be (pre-configured) to perform PUSCH transmissions within a configured permit (e.g., one configured permit), for example, using a set of spatial relationships. The WTRU may define a spatial relationship transmission pattern for a TB (e.g., each TB) and / or a configured permit (e.g., each configured permit), which may include, for example, one or more of the following: a set of spatial relationships that may be used for transmission TB (e.g., each TB transmission); a set of spatial relationships that can be used for transmissions within a configured permit (e.g., each configured permit); a sequence of spatial relationships that can be used for resources within a bundle (e.g., each resource within a bundle) and / or a sequence of spatial relationships that can be used for resource bundles (e.g., each resource bundle), which allows the WTRU to determine which spatial relationship to use in each transmitting resource; and / or a sequence of spatial relationships that can be used for TB transmissions (e.g., one TB), which allows the WTRU to determine which beam to use for transmission (e.g., each transmission) of the TB (e.g., which spatial relationship to use for the initial transmission, and which beam to use for each retransmission). The spatial relationship transmission pattern may be determined, for example, based on one or more of the following: (previous) configuration by the network; a number of TB repetitions in the configured permit; a time delay between successive transmissions (e.g., two successive transmissions) of the TB; a set of configured spatial relationships in the configured permit; and / or the QoS of the data configured in the permit. Spatial relationships may be (pre-)configured by the network. The WTRU may determine spatial relationship transmission patterns, for example, based on a configured permit configuration. The WTRU may be configured with spatial relationship transmission patterns in the configured permit, which may be associated with a TB (e.g., each TB), a resource pool, and / or a configured permit period. For example, the WTRU may be (pre-)configured with a table of multiple spatial relationship transmission patterns. The WTRU may be configured with an index in the table indicating which spatial relationship transmission pattern to use. A number of TB repetitions can be specified (e.g., in a configured permit). The WTRU can determine the transmission pattern of spatial links, for example, based on the number of TB repetitions in the configured permit. For example, the WTRU can be scheduled with a permit that has a repK resource transmission bundle (e.g., repK can provide the number of repetitions to be used when the WTRU uses the configured permit). The WTRU can decide to use the first beam for the first N transmissions and the second spatial link for the transmission of the remaining bundles. There may be a time lag between successive transmissions (e.g., two consecutive transmissions) of a TB. The WTRU can be configured with multiple beam sets for PUSCH transmissions. The WTRU can determine which beam set to use for transmission in a bundle (e.g., a single bundle) of configured permits, for example, based on the time lag between resources in the bundle. The WTRU can use the first set of spatial relationships (e.g., the first set of beams can be associated with a single panel), for example, if the time lag is less than a threshold. The WTRU can use the second set of beams (e.g., the second set of beams can be associated with multiple antenna panels), for example, if the time lag is greater than a threshold. A set of beams may be configured within a permit. The WTRU may determine a spatially related transmission pattern, for example, based on the set of beams configured within the permit. The WTRU may determine which subset of beams may be used for transmission in a bundle and / or for transmission in a bundle based on the set of beams configured for the configured permit. For example, the WTRU may be configured with (e.g., one) set of beams (e.g., two beams) for transmission in a configured permit. The WTRU may decide to use (e.g., all) of the beams for transmission in a bundle or for transmission in a bundle, for example, if the set of beams is associated with a panel (e.g., one panel). The WTRU may decide to use a subset of beams (e.g., one subset of beams) associated with a panel (e.g., one panel) for transmission in a bundle or for transmission in a bundle, for example, if the set of beams is associated with multiple panels.This approach may limit the WTRU to performing panel switching for transmission in a single bundle (e.g., a single bundle) and / or for TB transmission. The beam transmission pattern may be determined based on the QoS of the TB. The WTRU may determine the beam transmission pattern, for example, based on the QoS of the associated TB, which may be determined, for example, based on one or more of the following: the priority of the logical channels (LCHs) included in the TB and / or the reliability of the data included in the TB. For example, the priority of the TB may be determined as the highest priority of the LCHs included in the TB. The reliability of data included in a TB may be based on the packet error rate (PER). In an example, an LCH (e.g., each LCH) may be configured to one or more reliability values, which may be used to indicate the desired PER of the data in the LCH. The WTRU may determine the reliability of the TB, for example, based on the highest reliability of the LCH that has data included in the TB. The WTRU may be configured with one or more reliability levels for a QoS flow (e.g., each QoS flow). The WTRU may determine the reliability of the TB, for example, based on the highest reliability of the flow included in the TB. For example, a WTRU may use the first beam pattern for TBs that have the first priority range. The WTRU may use the second beam pattern for TBs that have the second priority range. In the example, the WTRU may be configured with multiple (e.g., two) sets of LCHs. The first set of LCHs may be associated with high-reliability data and the second set of LCHs may be associated with low-reliability data. The WTRU may use the first beam set (e.g., one beam) for transmissions of TBs that have data from the second set of LCHs and may use the second beam set (e.g., with two associated panels) for transmissions of TBs that have data from at least one LCH in the first set of LCHs. The WTRU may be configured to perform resource selection based on dynamic switching between single and multiple TRP transmission modes. In an example, FIG. 11 may illustrate the features described herein related to resource selection based on dynamic switching between single and multiple TRPs. For example, the WTRU may determine a loop category based on the indicated loops. The WTRU may determine (e.g., after the loop category is determined) an SRI pattern from multiple SRI patterns within the loop category, for example, based on signaled RV information (e.g., RV bits) and SDRA information (e.g., SDRA bits). The WTRU can dynamically determine the transmission mode (e.g., single or multiple TRPs, e.g., as shown in FIGS. 10 and 11) for PUSCH transmissions, e.g., PUSCH transmissions scheduled using a DCI, or for PUCCHs associated with a DCI. The WTRU can determine the transmission mode based on, e.g., dynamic indications in the DCI, explicit indications using, e.g., SDRA, and / or implicit indications (e.g., combinations of DCI fields), e.g., as described in the examples of FIGS. 10 and 11. The WTRU can choose to use single or multiple uplink TRP mode transmission based on the scrambling used for DCI. The scrambling can be partitioned into subsets of values ​​where each subset can be associated with a transmission mode (e.g., single or multiple TRP modes). The WTRU may use the scheduling type to determine whether to use single or multiple TRP transmission. The WTRU may determine that a subset of type 1 configured permits may be used for single TRP transmission and another subset may be used for multiple TRP transmission. The WTRU may determine that type 1 configured permits may be associated with single TRP transmission mode and that type 2 configured permits may be associated with multiple TRP transmission mode. If the WTRU determines the transmission mode, it may not have values ​​for other spatial relationship parameters such as, for example, SRI, pattern, etc. The WTRU may determine values ​​for unknown parameters based on the transmission mode. The WTRU can determine transmission parameters for repeated PUCCH transmissions or PUSCH transmissions, for example, based on the transmission mode (e.g., single or multiple TRPs) or based on a threshold given by the number of TRPs (e.g., N_TRP > 1). The WTRU may specify that the default transmission mode is related to the number of repetitions. The WTRU may specify that N_rep > 2 can be configured for multiple TRP modes. For N_rep>2 iterations, if the WTRU determines that it is in Multiple TRP mode, it may choose to use the N_rep spatial relationship (e.g., the best N_rep spatial relationship) across all TRPs. The WTRU may be configured with a set (e.g., a minimum set) of spatial relationships to use per TRP. Between N_rep iterations, the WTRU may choose to use at least one spatial relationship from each TRP to ensure multiple TRPs are used. The WTRU can choose to add a switching gap between repeats, for example, depending on the transmission mode. If scheduled in Multiple TRP mode, the WTRU can choose to add an additional switching gap when switching between SRIs (for example, to account for panel switching time if each SRI is associated with a different panel and each panel with a TRP). The switching gap can be associated with the repeat pattern, and the switching gap can be enabled depending on the number of TRPs. With a single TRP, there may be no switching gap. For MTRP, the WTRU can use a gap of T_gap seconds when switching SRIs. The WTRU can specify a default repetition pattern (e.g., cyclic or sequential) or a default spatial relationship (e.g., SRI) for each transmission mode. If the WTRU determines that a single TRP mode is used, it can choose to use a cyclic repetition pattern (e.g., SRI1-SRI2-SRI1-SRI2). If the WTRU determines that multiple TRPs are used, it can choose to use a sequential repetition pattern (e.g., SRI1SRI1-SRI2-SRI2). These patterns can be configured, for example, to reduce (e.g., minimize) the switching time between SRI changes assuming the SRIs are in different panels. The WTRU may determine the set of spatial relationships for the repeater based on whether the transmission is a single or multiple TRP. If the WTRU determines that the transmission is a single TRP, it may choose to use two spatial relationships, which may be, for example, the two best spatial relationships, to the single TRP. If the WTRU determines that the transmission is multiple TRPs, it may choose to use a spatial relationship (e.g., the best spatial relationship) from TRP1 and a spatial relationship (e.g., the best specific relationship) from TRP2. The WTRU may choose a spatial relationship, e.g., the best spatial relationship, based at least on signal quality as indicated by, for example, reference signal received power (RSRP). If the PUSCH transmission corresponds to a type 2 configured grant enabled by the DCI, the WTRU can dynamically switch between multiple configured GrantConfigs. The WTRU can be configured with multiple configured grantConfigs. The WTRU can receive a DCI with an indication of dynamic switching from single to multiple TRP mode. The WTRU can choose to use a configured grant with spatial relationship parameters for Multiple TRP mode. A WTRU may be configured with a single configured permit and a configured permit may be associated with multiple sets of spatial relationships. The WTRU may specify that the spatial relationships may be partitioned into single and multiple TRP spatial relationships, and the WTRU may specify which spatial relationship to use depending on which transmission mode is used. The WTRU may have one type 1 configured permit that may be configured with one spatial relationship pattern for single TRP mode, and one spatial relationship pattern for multiple TRP mode. The WTRU may specify that PUSCH transmissions on the configured permit are for multiple TRP mode. The WTRU may choose to use the spatial relationship on the multiple TRPs associated with the configured permit. The WTRU can determine transmission parameters based on the scrambling used. For type 2 configured permits, the permit can be partitioned according to scrambling subsets (e.g., the CS-RNTI subset). The WTRU can determine spatial filters for single or multiple TRP transmissions based on the configured link between the subset and the index. The WTRU can, for PUCCH transmissions, determine PUCCH repetition parameters based on whether single or multiple TRP mode is used. For PUCCH transmissions carrying CSI reports, the WTRU may specify a PUCCH or PRI configuration depending on whether the CSI report is for single or multiple TRP mode. If the CSI report contains reports for reference signals associated with more than one TRP, the WTRU may choose to use the PUCCH spatial link repeat configuration for multiple TRPs with the specified switching delay and SRI for multiple TRPs. The WTRU can specify which CSI reporting configuration to use based on the number of TRPs or the number of repetitions. The WTRU can select a resource (e.g., group-based or non-group-based reporting, number of beams in the report, RSRP or SINR reporting) depending on whether the CSI report is repeated to a single TRP or to multiple TRPs. The WTRU can specify that it report PUCCH repetitions to multiple TRPs. The WTRU can choose to report SINR if N_TRP is greater than one (N_TRP>1). The WTRU can specify RSRP reporting if it reports CSI to a single TRP. If the WTRU receives a dynamic indication between single and multiple TRPs, it can determine the set of spatial relationships to be used for transmission and the transmission parameters. The WTRU can adjust its spatial transmission filter to apply it to either a PUCCH transmission or a PUSCH transmission. The WTRU can transmit multiple repetitions where each repetition can use one of the spatial relationships from the specified set. Although the features and elements described above are described in specific combinations, each feature or element may be used alone without other features and elements of the embossed embodiment, or in various combinations with or without other features and elements. While the implementation described herein may consider specific 3GPP protocols, it is understood that the implementation described herein is not limited to these scenarios and may be applicable to other wireless systems. For example, while the solution described herein considers LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it is understood that the solution described herein is not limited to these scenarios and may also be applicable to other wireless systems. The processes described above may be implemented in computer programs, software, and / or firmware incorporated into computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs).The software-associated processor can be used to implement a radio frequency transmitter-receiver for use in a WTRU, terminal, base station, RNC, or any 5 host computer.

Claims

Claim 1. A wireless transmitter / receiver unit (WTRU) comprising: a processor configured to: receive downlink control information (DCI) associated with uplink scheduling information, wherein the DCI indicates a spatial domain indicator; receive an indication indicating a number of repetitions; determine a sounding reference signal resource indicator (SRI) pattern from a set of SRI patterns, wherein the determination of the SRI pattern is based on the spatial domain indicator and the number of repetitions; determine, based on the SRI pattern, a first spatial relationship for a first physical uplink shared channel (PUSCH) repetition transmission and a second spatial relationship for a second PUSCH repetition transmission; and transmit the first PUSCH repetition transmission using the first spatial relationship and the second PUSCH repetition transmission using the second spatial relationship.

2. The WTRU according to claim 1, wherein the processor is further configured to receive SRI information, wherein the SRI information comprises a set of SRI patterns, and wherein the set of SRI patterns comprises a set of SRI patterns.

3. The WTRU according to claim 2, wherein the processor is further configured to determine a set of SRI patterns from the set of SRI patterns, and wherein the determination of the set of SRI patterns is based on the indicated number of repetitions.

4. The WTRU according to claim 1, wherein each SRI pattern in the SRI pattern set is associated with an SRI sequence.

5. The WTRU according to claim 1, wherein the first spatial relationship is determined based on the first SRI in the determined SRI pattern and the second spatial relationship is determined based on the second SRI in the determined SRI pattern.

6. The WTRU according to claim 2, wherein the processor is further configured to receive the updated SRI information.

7. The WTRU according to claim 2, wherein the processor is further configured to send update information to the network device, and wherein the update information comprises a proposed update to the SRI information.

8. The WTRU according to claim 1, wherein the processor is further configured to determine a first transmission time associated with the first PUSCH repeat transmission and a second transmission time associated with the second PUSCH repeat transmission.

9. A method implemented in a wireless transmitter / receiver unit (WTRU), the method comprising: receiving downlink control information (DCI) associated with uplink scheduling information, wherein the DCI indicates a spatial domain indicator; receiving an indication indicating a number of repetitions; determining a sounding reference signal resource indicator (SRI) pattern from a set of SRI patterns, wherein the determination of the SRI pattern is based on the spatial domain indicator and the number of repetitions; determining, based on the SRI pattern, a first spatial relationship for a first physical uplink shared channel (PUSCH) repetition transmission and a second spatial relationship for a second PUSCH repetition transmission; and transmitting the first PUSCH repetition transmission using the first spatial relationship and the second PUSCH repetition transmission using the second spatial relationship.

10. The method of claim 9, wherein the method further comprises: receiving SRI information, wherein the SRI information comprises a set of SRI patterns, and wherein the set of SRI patterns comprises a set of SRI patterns.

11. The method of claim 10, wherein the method further comprises: determining a set of SRI patterns from a set of SRI patterns, and wherein the determination of the set of SRI patterns is based on an indicated number of repetitions.

12. The method according to claim 9, wherein each SRI pattern in the SRI pattern set is associated with an SRI sequence.

13. The method according to claim 9, wherein the first spatial relationship is determined based on the first SRI in the determined SRI pattern and the second spatial relationship is determined based on the second SRI in the determined SRI pattern.

14. The method of claim 10, wherein the method further comprises: sending update information to a network device, and wherein the update information comprises a proposed update to the SRI information.

15. The method of claim 9, wherein the method further comprises: determining a first transmission time associated with the first PUSCH repeat transmission and a second transmission time associated with the second PUSCH repeat transmission.

Images