UTCI deactivation mechanism in a multi-stage UTCI management framework

Abstract

Disclosed herein are one or more techniques providing methods / devices / systems for addressing unified TCI (UTCI) management techniques and related technologies. These one or more techniques may generally provide innovation and / or improvement to the field of wireless communications. Examples may include a process for determining a TCI to use for transmission / reception. There may be UTCI deactivation in a multi-stage UTCI management framework.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 445,601, filed February 14, 2023, the contents of which are incorporated herein by reference. [Background technology]

[0002] In wireless telecommunications, devices may have the ability to send transmissions using one or more beams, and therefore there is a need to efficiently manage which beams are used so that the transmitting and receiving devices can operate and communicate in an efficient manner. Summary of the Invention

[0003] One or more techniques are disclosed herein that provide a method / device / system for addressing unified TCI (UTCI) management and related techniques. These one or more techniques may generally provide innovation and / or improvement to the field of wireless communications. Examples may include a process for determining a TCI to use for transmission / reception. There may be UTCI deactivation in a multi-stage UTCI management framework. [Brief explanation of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which:

[0005] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1C]1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 2] A figure showing an example of a DCI field (e.g., a TCI field) of a DCI for unified TCI status indication. [Figure 3] FIG. 10 illustrates an example of a UTCI update timeline and UTCI selection for data reception. [Figure 4] FIG. 10 illustrates an example of a UTCI update timeline and UTCI selection for UL transmission. [Figure 5] FIG. 10 illustrates an example of UTCI deactivation based on UTCI selection. [Figure 6] FIG. 1 illustrates an example method in accordance with one or more techniques described herein. [Figure 7] FIG. 10 is a diagram illustrating an example of a UTCI update timeline and UTCI selection. [Figure 8] FIG. 1 illustrates an example method in accordance with one or more techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0006] Disclosed herein are one or more techniques that provide methods / devices / systems for addressing Unified TCI (UTCI) management and related technologies. These one or more techniques generally provide innovation and / or improvement to the field of wireless communications and may address specific problems such as (but not limited to): How to determine the PDSCH (default) beam when the UTCI selector indicates at least one of one or more UTCIs in the DL-DCI and the scheduling and / or time offset (k0) is less than a threshold (e.g., timeDurationForQCL) as part of the WTRU capability parameters? How to determine the UL beam, at least with respect to the applicable timeline, when the UTCI selector in the UL-DCI indicates at least one of one or more UTCIs indicated by the DL-DCI? How to map or associate between the WTRU panel and the UTCI selected by the UTCI selector out of the indicated one or more UTCIs applicable to multiple channels and / or signals? How to maintain QCL tracking behavior for which one or more UTCIs indicated by the DL-DCI when the UTCI selector indicates a subset of one or more UTCIs? How to determine the DL or UL beam when the DCI indicates cross-carrier scheduling?

[0007] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, and the like, to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ 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), zero-tailed unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0008] 1A, communications system 100 may include wireless transmit receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automation processing chain context), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0009] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 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 communications networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB (eNB), a Home Node B, a Home eNodeB, a gNodeB (gNB), a next generation Node B such as a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0010] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, sometimes referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide wireless service coverage to a particular geographic area, which may be relatively fixed or may change over time. A cell 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 transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0011] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over 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).

[0012] More particularly, as mentioned above, the communications system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0013] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0014] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

[0015] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE and NR radio access, e.g., using a dual connectivity (DC) principle. In this manner, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0016] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0017] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the 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. 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.

[0018] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be appreciated that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] The CN 106 may also serve as a gateway for the 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 communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0020] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers 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 that may employ cellular-based wireless technology and may be configured to communicate with a base station 114b that may employ IEEE 802.2 wireless technology.

[0021] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive 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 GPS chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0022] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be incorporated together in an electronic package or chip.

[0023] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0024] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More particularly, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0025] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0026] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0027] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device 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 (Li-ion), etc.), solar cells, fuel cells, etc.

[0028] The processor 118 may also be coupled to 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 instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

[0029] The processor 118 may further be coupled to 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 transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (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, etc. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0030] The WTRU 102 may include a full-duplex radio that may transmit and receive some or all of the signals (e.g., associated with a particular subframe in both the UL (e.g., for transmission) and DL (e.g., for reception) simultaneously and / or simultaneously). The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference through either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe in either the UL (e.g., for transmission) or DL ​​(e.g., for reception) simultaneously).

[0031] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to an embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0032] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNodeB 160a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

[0033] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1D, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0034] 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the above elements are shown as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0035] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0036] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0037] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0038] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the 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.

[0039] Although the WTRU is described in FIGS. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

[0040] In a representative embodiment, the other network 112 may be a WLAN.

[0041] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or from the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be sent through the AP; for example, a source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0042] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In some representative embodiments, for example, in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented. In CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0043] High-throughput (HT) STAs may use 40 MHz wide channels for communication, for example, by forming the 40 MHz wide channel through a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0044] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data may be passed through a segment parser, which may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC).

[0045] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including, for example, support for some and / or limited bandwidths (e.g., only that). MTC devices may include batteries with above-threshold battery life (e.g., to maintain extremely long battery life).

[0046] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel sometimes referred to as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (that only support 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though most of the available frequency bands remain idle.

[0047] In the United States, the available frequency bands that can be used by 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 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.

[0048] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to an embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0049] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0050] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or absolute time durations).

[0051] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0052] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0053] 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 the above elements are shown as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. 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 being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established 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 MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0055] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0056] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communications 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 DL packets, providing mobility anchoring, etc.

[0057] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the 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, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0058] 1A-1D and the corresponding description thereof, one or more, or all, of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0059] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network for testing other devices within that network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communication.

[0060] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test laboratory and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061] The unified transmission configuration indication (TCI) framework may support one unified TCI indicated or maintained at the WTRU to be applicable to two or more channels or signal types (e.g., separate DL / UL joint or pair) simultaneously, unlike individual beam control per channel or signal as may be used in legacy cases.

[0062] In some cases, there may be multi-TRP (MTRP) support, and multi-downlink control information (DCI)-based MTRP (MDCI-MTRP) may be based on CORESETPoolIndex=0 or 1 to support enhanced mobile broadband (eMBB). In some cases, single-DCI-based MTRP (SDCI-MTRP) may be based on associating up to two TCI states to codepoints in the TCI field in the DCI for repeated transmissions between TRPs for improved reliability.

[0063] In some cases (e.g., MIMO), there may be a unified TCI framework for indicating multiple DL and UL TCI states focusing on multi-TRP usage scenarios.

[0064] The WTRU may transmit or receive a physical channel or a reference signal according to at least one spatial domain filter. The term "beam" may be used herein to refer to a spatial domain filter.

[0065] The WTRU may transmit a physical channel or signal using the same spatial domain filter as that used to receive an RS (e.g., a CSI-RS) or synchronization signal block (SSB). The WTRU transmission may be referred to as the "target," and the received RS or SSB may be referred to as the "reference" or "source." In such a case, the WTRU may be said to transmit the target physical channel or signal according to a spatial relationship with the reference for such RS or SS block.

[0066] The WTRU may transmit a first physical channel or signal according to the same spatial domain filter as that used to transmit a second physical channel or signal. The first and second transmissions may be referred to as the "target" and "reference" (or "source"), respectively. In such a case, the WTRU may be said to transmit the first (target) physical channel or signal according to a spatial relationship of the reference to the second (reference) physical channel or signal. Note that because the reference is used for the target, the reference (second) may be earlier in time compared to the target (first).

[0067] The spatial relationship may be implicit, configured by RRC, or signaled by MAC CE or DCI. For example, the WTRU may implicitly transmit the PUSCH and DM-RS of the PUSCH according to the same spatial domain filter as the SRS indicated by an SRS resource indicator (SRI) indicated in the DCI or configured by RRC. In another example, the spatial relationship may be configured by RRC for the SRI or signaled by MAC CE for the PUCCH. Such a spatial relationship may also be referred to as a "beam indication."

[0068] The WTRU may receive a first (target) downlink channel or signal according to the same spatial domain filter or spatial reception parameters as a second (reference) downlink channel or signal. For example, such an association may exist between a physical channel, such as a PDCCH or PDSCH, and its respective DM-RS. At least when the first and second signals are reference signals, such an association may exist when the WTRU is configured with quasi-co-location (QCL) assumption type D between the corresponding antenna ports. Such an association may be configured as a transmission configuration indicator (TCI) state. The WTRU may indicate the association between the CSI-RS or SS block and the DM-RS by an index into a set of TCI states configured by RRC and / or signaled by MAC CE. Such an indication may also be referred to as a "beam indication." In other words, the transmission configuration indicator (TCI) state may provide an association between a reference signal and a source signal so that the device can transmit / receive the target signal. One or more TCI indications may be transmitted in a control channel, such as a PDCCH. An indication of one or more TCIs may be transmitted in a Downlink Control Channel Information (DCI) message, which may provide an indication (e.g., TCI) explicitly (e.g., fields, RNTI scrambling, etc.) or implicitly (e.g., format, size, etc.), as further disclosed herein.

[0069] A unified TCI (e.g., common TCI, common beam, common RS, etc.) may refer to a beam / RS to be used (e.g., simultaneously) for multiple physical channels / signals. The term "TCI" may include a TCI state that includes at least one source RS to provide a basis (e.g., WTRU assumptions) for determining a QCL and / or spatial filter, which may be used for reception / transmission of a target signal.

[0070] In an example, a WTRU may receive (e.g., from a base station) an indication of a first unified TCI to be used / applied for both a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH) (e.g., and downlink RS). The source reference signal in the first unified TCI may provide common QCL information for at least WTRU-dedicated reception on the PDSCH and all or a subset of CORESET in the CC. In an example, a WTRU may receive (e.g., from a base station) an indication of a second unified TCI to be used / applied for both a physical uplink control channel (PUCCH) and a physical uplink shared channel (PUSCH) (e.g., and uplink RS). The source reference signal in the second unified TCI may provide a reference for determining a common UL TX spatial filter for at least dynamic grant / configuration grant-based PUSCH and all or a subset of dedicated PUCCH resources in the CC.

[0071] The WTRU may be configured in a first mode (e.g., Separate DLULTCI mode) for the unified TCI, and the indicated unified TCI (e.g., the first unified TCI or the second unified TCI) may be applicable to either the downlink (e.g., based on the first unified TCI) or the uplink (e.g., based on the second unified TCI).

[0072] In an example, the WTRU may receive (e.g., from a base station) an indication of a second unified TCI to be commonly used / applied for the PDCCH, PDSCH, PUCCH, and PUSCH (e.g., and also DL RS and / or UL RS).

[0073] The WTRU may be configured in a second mode (e.g., JointTCI mode) for unified TCI, and the indicated unified TCI (e.g., a third unified TCI) may be applicable to both the downlink and the uplink (e.g., based on the third unified TCI).

[0074] The WTRU may determine the TCI state applicable to transmission or reception by first determining a unified TCI state instance applicable to the transmission or reception and then determining the TCI state corresponding to the unified TCI state instance. Transmission may consist of at least PUCCH, PUSCH, and SRS. Reception may consist of at least PDCCH, PDSCH, and CSI-RS. A unified TCI state instance may also be referred to as a TCI state group, TCI state process, unified TCI pool, group of TCI states, set of time domain instances / stamps / slots / symbols, and / or set of frequency domain instances / RBs / subbands, etc. A unified TCI state instance may be equivalent to or identified with a control resource set (CORESET) pool identification (e.g., CORESETPoolIndex, TRP indicator, etc.).

[0075] As disclosed herein, a unified TCI may be interchangeable with one or more of a unified TCI state, a unified TCI instance, a TCI, and / or a TCI state.

[0076] As disclosed herein, a transmitting and receiving point (TRP) may be used interchangeably with one or more of a TP (transmission point), RP (receiving point), RRH (radio remote head), DA (distributed antenna), BS (base station), sector (of a BS), network node, relay device (e.g., a WTRU), and cell (e.g., a geographic cell area served by a BS), and this interchangeability may also apply conversely (e.g., a reference to a base station may be interchangeable with a TRP, etc.). Hereinafter, a multi-TRP may be used interchangeably with one or more of a TRP, an M-TRP, and multiple TRPs. For example, when some information is indicated from a base station, the term base station may be replaced with a gNB, TRP, MTRP, etc.

[0077] A WTRU may be configured with one or more TRPs to which the WTRU may transmit and / or receive from, or may receive configurations of one or more TRPs. A WTRU may be configured with one or more TRPs for one or more cells. The cells may be serving cells and / or secondary cells.

[0078] The WTRU may be configured with at least one RS for channel measurement purposes. This RS may be denoted as a channel measurement resource (CMR) and may include a CSI-RS, SSB, or other downlink RS transmitted from a TRP to the WTRU. A CMR may be configured with or associated with a TCI state. The WTRU may be configured with CMR groups in which CMRs transmitted from the same TRP may be configured. Each group may be identified by a CMR group index (e.g., group 1). The WTRU may be configured with one CMR group per TRP, and the WTRU may receive linkage between one CMR group index and another CMR group index, or between one RS index from one CMR group and another RS ​​index from another group.

[0079] A WTRU may be configured with or receive a configuration of one or more path loss (PL) reference groups (e.g., sets) and / or one or more SRS groups, SRS resource indicators (SRIs), or SRS resource sets.

[0080] A PL Reference Group may correspond to or be associated with a TRP. A PL Reference Group may include, identify, correspond to, or be associated with one or more of a TCI state, an SRI, a reference signal set (e.g., a CSI-RS set, an SRI set), a CORESET index, and / or a reference signal (e.g., a CSI-RS, an SSB).

[0081] The WTRU may receive a configuration (e.g., any configuration described herein). The configuration may be received from a base station and / or a TRP. For example, the WTRU may receive configuration for one or more TRPs, one or more PL reference groups, and / or one or more SRI sets. The WTRU may implicitly determine the association between an RS set / group and a TRP. For example, if the WTRU is configured with two SRS resource sets, the WTRU may determine to transmit on TRP1 with an SRS in the first resource set and on TRP2 with an SRS in the second resource set. The configuration may be via RRC signaling.

[0082] As described herein, the terms TRP, PL reference group, SRI group, and SRI set may be used interchangeably. The terms set and group may be used interchangeably herein.

[0083] The WTRU may report a subset of channel state information (CSI) components, which may correspond to at least a CSI-RS resource indicator (CRI), an SSB resource indicator (SSBRI), an indication of the panel used for reception at the WTRU (such as panel identification or group identification), measurements such as L1-RSRP, L1-SINR (e.g., cri-RSRP, cri-SINR, ssb-Index-RSRP, ssb-Index-SINR) obtained from SSB or CSI-RS, and other channel state information such as at least a rank indicator (RI), a channel quality indicator (CQI), a precoding matrix indicator (PMI), and a layer index (LI).

[0084] As described herein, the properties of a grant or allocation may include at least one of the following: frequency allocation, time allocation aspects such as duration, priority, modulation and coding scheme, transport block size, number of spatial layers, number of transport blocks, TCI state, CRI or SRI, number of repetitions, whether the repetition scheme is Type A or Type B, whether the grant is a configuration grant Type 1 or Type 2 or dynamic grant, whether the allocation is a dynamic allocation or a semi-persistent scheduling (configuration) allocation, configuration grant index or semi-persistent allocation index, periodicity of the configuration grant or allocation, Channel Access Priority Class (CAPC), and any parameters provided in the DCI by the MAC or by the RRC to schedule the grant or allocation.

[0085] As described herein, the indication by the DCI may include at least one of an explicit indication by a DCI field or by an RNTI used to mask the CRC of the PDCCH, and / or an implicit indication by properties such as DCI format, DCI size, CORESET or search space, aggregation level, first resource element of the received DCI (e.g., index of the first control channel element), and the mapping between properties and values ​​may be signaled by RRC or MAC.

[0086] As described herein, signal may be used interchangeably with one or more of: sounding reference signal (SRS), channel state information-reference signal (CSI-RS), demodulation reference signal (DM-RS), phase tracking reference signal (PT-RS), synchronization signal block (SSB), message, transmission, etc.

[0087] As described herein, channel may be used interchangeably with one or more of a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), and / or a physical random access channel (PRACH).

[0088] As described herein, downlink reception may be used interchangeably with Rx occasion, PDCCH, PDSCH, and SSB reception.

[0089] As described herein, uplink transmission may be used interchangeably with Tx occasion, PUCCH, PUSCH, PRACH, and SRS transmission.

[0090] As described herein, RS may be used interchangeably with one or more of RS resource, RS resource set, RS port, and RS port group.

[0091] As described herein, RS may be used interchangeably with one or more of SSB, CSI-RS, SRS, and DM-RS.

[0092] As described herein, time instance may be used interchangeably with slot, symbol, and subframe.

[0093] As described herein, UTCI may be used interchangeably with TCI, UTCI state, and TCI status.

[0094] A WTRU may be configured with multiple transmission configuration indicator (TCI) states, such as unified TCI (UTCI) states, each applicable to one or more channels / signals. The one or more channels / signals may be sent to the WTRU in a configuration message or may be predetermined or defined (e.g., in the form of a list) by higher layer signaling (e.g., RRC and / or MAC-CE), which may include (e.g., in combination) one or more of the following: one or more CORESETs, one or more PDCCH candidates, one or more search spaces, one or more PDSCHs (e.g., PDSCH occasions / configurations / instances, etc.), one or more RSs (e.g., CSI-RS, DMRS, SSB index, PRS, PTRS, and / or SRS), one or more PUSCHs (e.g., PUSCH occasions / configurations / instances, etc.), one or more PUCCH resources (e.g., PUCCH resource sets / groups), and / or one or more PRACH occasions / resources / RSs.

[0095] The multiple TCI states may be configured via RRC signaling (e.g., and / or via MAC-CE signaling, indication, or activation). The WTRU may receive information content (e.g., via MAC-CE or separate signaling) including a mapping between one or more codepoints of a DCI field (e.g., a TCI field and / or a TCI selection field) and at least one TCI state of the multiple TCI states. The WTRU may receive a DCI message including the DCI field. The WTRU may indicate one or more TCI states of a plurality of TCI states mapped to a code point of the one or more code points of the DCI field, each of the one or more TCI states being applicable after a time period determined based on a beam application time (BAT) parameter; in other words, there may be a BAT (e.g., a configured parameter), so that the WTRU may need to wait until the BAT has passed to apply the one or more TCI states (e.g., the one or more TCI states are known before the BAT has passed), and further, if the BAT has not passed, the one or more TCI states may not be applied (e.g., not yet, or never, until at least the BAT has passed and / or until some other indication / trigger occurs for using the one or more TCI states as disclosed herein).

[0096] In some cases, there may be a DCI field (e.g., a TCI field) of the DCI for a unified TCI state indication. The WTRU may receive a mapping between code points (e.g., of a DCI field) and one or more TCI states (e.g., via MAC-CE signaling) as shown in the figure. For example, code point 2 is mapped to {UTCI3, UTCI7}, and the WTRU may apply at least one of {UTCI3, UTCI7} to multiple channels / signals (e.g., based on a list of multiple channels / signals configurable by higher layer signaling from the base station). In an example, a list of multiple channels / signals may be provided for each UTCI instance, and the UTCI instance may correspond to each column of a mapping table between code points and one or more TCI states, as shown in the figure.

[0097] 2 shows example DCI fields (e.g., TCI fields) of a DCI for a unified TCI status indication. A WTRU may receive a control transmission over a control channel, which may include a downlink control information (DCI) message (e.g., having a particular format, size, number and / or type of fields, purpose, etc.), and the DCI message may include a mapping between codepoints (e.g., of DCI fields) and one or more TCI states, as shown in 200 (e.g., via MAC-CE signaling). Generally, the DCI may include a table / list / field containing one or more columns and one or more rows, among other indications. As shown in the figure, there may be a correlation between codepoints (e.g., numbers) and rows, and each row may have a set (e.g., an ordered set) of UTCIs (e.g., UTCIs shown as 201-216). For example, code point 0 is mapped to a set of UTCIs {UTCI2 and UTCI9}, where UTCI2 is the first UTCI of the set and UTCI9 is ​​the second UTCI of the set. For example, code point 2 is mapped to {UTCI3, UTCI7}, and the WTRU may apply at least one of {UTCI3, UTCI7} to one or more channels / signals (e.g., based on a set / list of one or more channels / signals configurable by higher layer signaling from the base station). In an example, a set / list of one or more channels / signals may be provided for each UTCI instance (e.g., as shown in 217 and 218), and a UTCI instance may correspond to each column of a mapping table between code points and one or more TCI states, as shown in the figure. It may be understood from this figure that the WTRU may support various numbers of UTCIs depending on the code point; for example, the WTRU may support one UTCI and the WTRU may support two UTCIs.From this figure, it may be understood that the WTRU may support two UTCIs to be maintained depending on the code point, for example, when code point 1 is indicated, the WTRU may update the first UTCI to UTCI23, while the WTRU may not update the second UTCI and may continue to use the current second UTCI (e.g., an exemplary TCI field may be used as "UTCI (Beam) Update").

[0098] In some cases, the device may determine the PDSCH default beam based on the UTCI selector in the DL-DCI.

[0099] In one case, a WTRU may receive configuration of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states each applicable to one or more channels or signals), where the one or more channels or signals associated with the TCI states may be sent to the WTRU in a configuration message (e.g., in the form of a list) by higher layer signaling (e.g., RRC and / or MAC-CE) (or may be predetermined or defined).

[0100] The WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may send a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0101] The WTRU may receive DCI2 using at least one of {TCI1, TCI2} (e.g., after sending the first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., TCI field) of DCI2 and schedules PDSCH2. DCI2 further indicates a selector via a second field (e.g., TCI selection field), where the selector indicates one of the TCI states {TCI1, TCI2} indicated by DCI1. In some instances, the TCI selection field in the DCI may indicate a value (e.g., codepoint "11") that may correspond to applying both TCIs, as described further herein.

[0102] The WTRU may receive PDSCH2 using a TCI state determined based on at least one of a selector indicated by DCI2, a time offset k0 between transmission (or reception) of DCI2 and transmission (or reception) of PDSCH2, a default TCI state, and / or a previously indicated TCI state. In an example, the value of k0 is indicated in DCI2. In an example, if the value of k0 is less than a threshold, the WTRU uses the default TCI state, TCI X, to receive PDSCH2. In an example, if the value of k0 is greater than a threshold, the WTRU uses the TCI state indicated by the selector to receive PDSCH2. In an example, the threshold is part of a WTRU capability parameter (e.g., reported to the base station).

[0103] The WTRU may send a second ACK in response to receiving (eg, successfully receiving) DCI2 and / or PDSCH2.

[0104] In one example, after receiving PDSCH2, the WTRU may use TCI3 or TCI4 to receive another PDSCH or PDCCH.

[0105] In an example, the default TCI X may be or may be determined based on at least one of: a default UTCI state, such as a UTCI associated with a CORESET with a predefined or preconfigured CORESET index, a UTCI associated with a CORESET with the lowest (or highest) ID, and / or a previously selected TCI state (e.g., a recently selected TCI state) according to a TCI selection field in DCI3 received before DCI2 (e.g., scheduling PDSCH3) that satisfies the condition that the WTRU sent an ACK for DCI3 or PDSCH3 (e.g., indicating successful reception of DCI3 or PDSCH3) at least a time period (e.g., a configured time period) before transmission (or reception) of DCI2. In one case, the time period may be determined based on a beam application time (BAT) parameter configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters.

[0106] In one case, a WTRU may receive a configuration of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU (or may be predetermined or defined) in a configuration message, such as in the form of a list, by higher layer signaling (e.g., RRC and / or MAC-CE).

[0107] The WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may send a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0108] The WTRU receives DCI2 using at least one of {TCI1, TCI2} (e.g., after sending a first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., a TCI field) of DCI2, and schedules PDSCH2. DCI2 may further indicate a selector via a second field (e.g., a TCI selection field), where the selector indicates one of {TCI1, TCI2} indicated by DCI1. The WTRU may determine that the selector indicates a second one of {TCI1, TCI2}, i.e., TCI2. In response to the determination, the WTRU may receive the scheduled PDSCH2 by using the selected TCI2. The WTRU may send a second ACK (e.g., using any applicable TCI state based on the current TCI state and / or current rules) in response to receiving (e.g., successfully receiving) DCI2 and / or PDSCH2.

[0109] The WTRU may receive DCI3 using at least one of {TCI3, TCI4} (e.g., after sending a second ACK), where DCI3 indicates {TCI5, TCI6} via a first field (e.g., a TCI field) of DCI3, and schedule PDSCH3 to be transmitted k0 after DCI3 was transmitted. The value of k0 may be indicated in the same DCI3. The WTRU may determine that the value of k0 is less than a threshold, where the threshold is part of a WTRU capability parameter (e.g., reported to the base station). The WTRU may receive the scheduled PDSCH3 using default TCI X, provided that the value of k0 is less than the threshold. The WTRU may transmit a third ACK in response to receiving (e.g., successfully receiving) DCI3 and / or PDSCH3. In one example, the WTRU uses TCI5 or TCI6 to receive another PDSCH or PDCCH after receiving PDSCH3 or after sending the third ACK.

[0110] The default TCI X may be determined based at least on the most recently selected TCI by the TCI selection field of the DCI, and the WTRU determines that the DCI is DCI2 and that the most recently selected TCI is TCI2, provided that DCI3, which schedules PDSCH3, is received a time period after transmitting the second ACK in response to receiving DCI2. The time period may be determined based on a beam application time (BAT) parameter configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters.

[0111] The default UTCI state, which may be a TCI Y, may be associated with a CORESET with a predefined or preconfigured CORESET index (eg, the UTCI associated with the CORESET with the lowest (or highest) ID).

[0112] In some cases, there may be a UTCI update timeline and UTCI selection for data reception. The WTRU may currently use and / or apply {TCI3, TCI7} for communication with a base station (e.g., gNB). The WTRU may receive DCI1 (e.g., via the TCI field of DCI1) indicating {TCI3, TCI7} as the same as the currently used one and scheduling PDSCH1 (e.g., a data packet) to be transmitted k0 after DCI1 was transmitted, where the value of k0 may be indicated in the same DCI1 or via separate signaling. DCI1 may further indicate a selector (e.g., via the TCI selection field), and the selector may select at least one of the currently used ones, such as {TCI3, TCI7}. The currently used one may be determined with respect to the time instance at which DCI1 is received. Examples of TCI selection fields may be configured by at least one of the following codepoints: codepoint "00" in the TCI selection field, applies the first one; codepoint "01" in the TCI selection field, applies the second one; codepoint "10" in the TCI selection field, applies both; codepoint "11" in the TCI selection field, reserved; codepoint "X" in the TCI selection field, applies none (e.g., meaning to apply the default TCI and / or beam); codepoint "Y" in the TCI selection field, applies the one used for CORESET or PDCCH reception; codepoint "Z" in the TCI selection field, applies the third one (if more than two UTCI states are used at once); codepoint "Z1" in the TCI selection field, applies the first and third ones (if more than two UTCI states are used at once), etc.

[0113] In an example, the WTRU may determine that the TCI selection field of DCI1 indicates a value (e.g., codepoint "00") corresponding to applying the first one of those currently in use, i.e., {TCI3}, among {TCI3, TCI7}, etc. The WTRU may determine that the indicated k0 (e.g., as a scheduling offset) is greater than a threshold value, denoted as Th, which may be based on the WTRU's capabilities, which may be reported by the WTRU. If k0 is greater than (or equal to) the threshold value, the WTRU may (is able to) decode the content carried by DCI1, such as by having sufficient decoding time required for the WTRU to interpret the content indicated by DCI1. Otherwise, the WTRU may not apply the content due to insufficient decoding time before receiving PDSCH1, in which case the WTRU may need to receive PDSCH1 by using the default TCI state. This may be because when the WTRU receives PDSCH1, there is at least one parameter or component (e.g., a spatial domain (receive) filter or analog filter coefficients) that cannot be changed or adjusted by post-processing on the received PDSCH1 (e.g., after receiving PDSCH1).

[0114] The WTRU may receive the scheduled PDSCH1 based on the {TCI3} indicated by the selector (eg, by the TCI selection field).

[0115] The WTRU may apply the {TCI3, TCI7} indicated by the TCI field of DCI1 after (1) receiving the scheduled PDSCH1, (2) transmitting a corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured or indicated to the WTRU (e.g., from the base station). In one case, applying the indicated {TCI3, TCI7} in response to DCI1 may be equivalent to maintaining the currently used {TCI3, TCI7}, since the same {TCI3, TCI7} is being used.

[0116] In some instances, there may be one or more actions of the WTRU upon receiving DCI2. The WTRU may receive DCI2 indicating {TCI5, TCI8} different from those currently in use {TCI3, TCI7} (e.g., via the TCI field of DCI2) and scheduling PDSCH2 (e.g., data packets) to be transmitted k0 after DCI2 was transmitted, where the value of k0 may be indicated in the same DCI2 or via separate signaling. DCI2 may further indicate a selector (e.g., via the TCI selection field), and the selector may select at least one of those currently in use {TCI3, TCI7} but not yet among the newly indicated ones {TCI5, TCI8}. The currently in use may be determined upon receiving DCI2.

[0117] In an example, the WTRU may determine that the TCI selection field of DCI2 indicates a value (e.g., codepoint "01") corresponding to applying the second one (e.g., of those currently in use {TCI3, TCI7}), i.e., {TCI7}, which is not yet {TCI8}. The WTRU may determine that the indicated k0 (e.g., as a scheduling offset) is greater than a threshold value denoted as Th, which may be based on the WTRU's capabilities, which may be reported by the WTRU. The WTRU may receive the scheduled PDSCH2 based on {TCI7} indicated by the selector (e.g., by the TCI selection field).

[0118] The WTRU may apply the {TCI5, TCI8} indicated by the TCI field of DCI2 after (1) receiving the scheduled PDSCH2, (2) transmitting a corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured (or indicated) to the WTRU (e.g., from the base station). In an example, applying the indicated {TCI5, TCI8} in response to DCI2 may be interpreted as a "beam or TCI update" because the indicated {TCI5, TCI8} are different from the currently used {TCI3, TCI7}.

[0119] In some instances, there may be one or more actions of the WTRU upon receiving DCI3. The WTRU may receive DCI3 indicating {TCI5, TCI8} that are the same as those currently in use {TCI5, TCI8} (e.g., via the TCI field of DCI3) and scheduling a PDSCH3 (e.g., a data packet) to be transmitted k0 after DCI3 was transmitted, where the value of k0 may be indicated in the same DCI3 (or via separate signaling). DCI3 may further indicate a selector (e.g., via the TCI selection field), and the selector may select at least one of those currently in use {TCI5, TCI8}. The currently in use may be determined upon receiving DCI3.

[0120] In an example, the WTRU may determine, Th after receiving DCI3, that the TCI selection field of DCI3 indicates a value (e.g., codepoint "11") that may correspond to applying both of the currently used {TCI5, TCI8}, i.e., {TCI5, TCI8}. However, the WTRU may receive PDSCH3 earlier than the determination of the value of DCI3 because the scheduling offset k0 indicated by DCI3 is less than a threshold Th (e.g., a parameter of the WTRU's capability for DCI decoding and / or processing time (or latency)). The WTRU may receive the scheduled PDSCH3 before determining that k0 is less than Th, which means that the WTRU may determine at least one default beam (or TCI) for storing (e.g., any) downlink signals (including actual PDSCH3 packets) until it identifies (or decodes) the content carried by DCI3.

[0121] 3 shows an example of a UTCI update timeline and UTCI selection for data reception. From this figure, it may be understood that in a given scenario, the WTRU may have an initial TCI state (e.g., pre-configured or configured from a DCI such as 301 as described herein), where the DCI may include a 3-bit TCI field 305, and the DCI may also have a TCI selection field 309. Prior to 300, the WTRU may have been initially configured with, used, and / or applied a set of TCIs (e.g., {TCI3, TCI7} at 313) for communication with a base station (e.g., a gNB). After 300, the example scenario of FIG. 3 may begin, and the base station may transmit one or more DCIs to the WTRU. The WTRU may receive DCI1 (e.g., at 302) indicating {TCI3, TCI7} (e.g., at 306). In this example, the TCI in DCI1 is the same TCI as the initially used TCI (e.g., via the TCI field of DCI1). In one case, DCI1 may include scheduling PDSCH1 (e.g., a data packet) to be transmitted k0 after DCI1 was transmitted, where the value of k0 may be indicated in the same DCI1 or via separate signaling. DCI1 may further indicate a selector (e.g., via the TCI selection field at 310), and the selector may select at least one of the currently used TCIs, such as {TCI3, TCI7}. The initial set of TCIs may be determined with respect to the time instance at which DCI1 is received. While particular code points in the TCI selection field (e.g., with particular meanings) are shown in FIG. 3, it may be understood that the code points may be different with meanings different from those shown.For example, the TCI selection field may include at least one codepoint, such as one of the following: codepoint "00" in the TCI selection field, apply the first one; codepoint "01" in the TCI selection field, apply the second one; codepoint "10" in the TCI selection field, apply both; codepoint "11" in the TCI selection field, reserved; codepoint "X" in the TCI selection field, apply none (e.g., meaning to apply the default TCI and / or beam); codepoint "Y" in the TCI selection field, apply the one used for CORESET or PDCCH reception; codepoint "Z" in the TCI selection field, apply the third one (if more than two UTCI states are used at once); codepoint "Z1" in the TCI selection field, apply the first and third ones (if more than two UTCI states are used at once), etc.

[0122] In an example, the WTRU may determine that the TCI selection field of DCI1 indicates a value (e.g., codepoint "00") corresponding to applying the first TCI, i.e., {TCI3}, among the currently used TCIs {TCI3, TCI7}, etc. (e.g., at 310). The WTRU may determine that the indicated k0 (e.g., as a scheduling offset) is greater than a threshold indicated as Th (e.g., see k0 greater than Th in 331); in one case, the threshold may be based on the capabilities of the WTRU, and in one case, the capabilities may be reported by the WTRU. If k0 (e.g., at 331) is greater than (or equal to) the threshold, the WTRU may (or may be able to) decode the content carried by DCI1, such as by having sufficient decoding time required for the WTRU to interpret the content indicated by DCI1. Otherwise, the WTRU may not apply the content due to insufficient decoding time (e.g., as shown in 332 where k0 is less than Th), and in such a case, the WTRU may not apply the content before receiving PDSCH1, in which case the WTRU may need to receive PDSCH1 by using a default TCI state (e.g., not shown, but as apparent from one or more depicted elements / aspects of the example of FIG. 3 and / or as described further herein). This may be because, once the WTRU receives PDSCH1, there may be at least one parameter or component (e.g., spatial domain (receive) filter or analog filter coefficients, etc.) that cannot be changed or adjusted by post-processing on the received PDSCH1 (e.g., after receiving PDSCH1).As is apparent from the above, it should be noted that one or more permutations of the example shown in FIG. 3 are described herein that do not necessarily correspond to what is illustrated; this emphasizes that the example of FIG. 3 is intended to serve as a basis for one or more possible permutations using one or more elements / aspects from the illustration, which may not be fully described but may be obvious from one or more elements / aspects of what is illustrated and what is generally described herein; in other words, it is intended that one or more elements / aspects of any given illustration (e.g., as described or illustrated) are optional and are intended to serve as a basis for one or more permutations.

[0123] As shown, the WTRU may receive the scheduled PDSCH1 based on {TCI3} indicated by the selector (eg, by the TCI selection field).

[0124] The WTRU may apply the {TCI3, TCI7} indicated by the TCI field of DCI1 after (1) receiving the scheduled PDSCH1, (2) transmitting a corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured or indicated to the WTRU (e.g., from the base station). In one case, applying the indicated {TCI3, TCI7} in response to DCI1 may be equivalent to maintaining the TCIs already in use, since the same {TCI3, TCI7} were initially used before receiving DCI1.

[0125] In some instances, there may be one or more actions of the WTRU upon receiving DCI2 (e.g., at 303). The WTRU may receive DCI2 (e.g., via the TCI field of DCI2 at 307) indicating {TCI5, TCI8} different from a set of currently used TCIs, such as {TCI3, TCI7}, and scheduling PDSCH2 (e.g., data packets) to be transmitted k0 after DCI2 was transmitted, where the value of k0 may be indicated in the same DCI2 or via separate signaling. DCI2 may further indicate a selector (e.g., via the TCI selection field at 311), and the selector may select at least one of the currently used TCIs {TCI3, TCI7} but not yet among the newly indicated TCIs {TCI5, TCI8}. The currently used TCI may be determined upon receiving DCI2.

[0126] In an example, the WTRU may determine that the TCI selection field of DCI2 indicates a value (e.g., codepoint "01") corresponding to applying the second (e.g., of the currently used TCIs {TCI3, TCI7}), i.e., {TCI7}, which is not yet {TCI8}. The WTRU may determine that the indicated k0 (e.g., as a scheduling offset) is greater than a threshold denoted Th, where in one example the threshold may be based on the capabilities of the WTRU, and in one example the capabilities may be reported by the WTRU. The WTRU may receive the scheduled PDSCH2 based on {TCI7} indicated by the selector (e.g., by the TCI selection field).

[0127] The WTRU may apply the {TCI5, TCI8} indicated by the TCI field of DCI2 after (1) receiving the scheduled PDSCH2, (2) transmitting a corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured (or indicated) to the WTRU (e.g., from a base station) (e.g., as shown in 318). In an example, applying the indicated {TCI5, TCI8} in response to DCI2 may be interpreted as a "beam or TCI update" because the indicated TCI {TCI5, TCI8} is different from the currently used TCI {TCI3, TCI7}.

[0128] In some instances, there may be one or more actions of the WTRU upon receiving DCI3 (e.g., at 304). The WTRU may receive DCI3 (e.g., via the TCI field of DCI3 at 308) indicating {TCI5, TCI8} that is the same as the currently used TCI {TCI5, TCI8}, where the value of k0 may be indicated in the same DCI3 (or via separate signaling). DCI3 may further indicate a selector (e.g., via the TCI selection field at 312), and the selector may select at least one of the currently used TCIs {TCI5, TCI8}. The currently used TCI may be determined upon receiving DCI3.

[0129] In an example, the WTRU may determine, after receiving DCI3 Th, that the TCI selection field of DCI3 indicates a value (e.g., codepoint "11") that may correspond to applying both TCIs, i.e., {TCI5, TCI8}, of the currently used TCIs {TCI5, TCI8}. However, the WTRU may receive PDSCH3 earlier than the determination of the value of DCI3 because the scheduling offset k0 indicated by DCI3 is less than a threshold Th (e.g., a parameter of the WTRU's capability for DCI decoding and / or processing time (or latency), as shown in 332, etc.). The WTRU may receive the scheduled PDSCH3 before determining that k0 is less than Th, which means that the WTRU may decide to use at least one default beam (or TCI) to store (e.g., any) downlink signals (including actual PDSCH3 packets) until it identifies (or decodes) the content carried by DCI3. From FIG. 3 , it may be generally understood that a WTRU may receive a DCI indicating a TCI field and / or a TCI selection field, and one or more TCIs may be applied for receiving and / or transmitting signals / messages after the BAT has elapsed, and the applied TCI may depend on the indication in the offset k0 and / or the TCI selection field, and in one case, whether the offset k0 is before or after some threshold (e.g., Th) may affect the TCI used. Although three DCIs are shown in FIG. 3 , other permutations of the shown examples may exist, including one or more of the DCIs as shown and one or more subsequent actions as shown, and do not necessarily require every element or event to occur as shown. Stated differently, it is intended that the illustrated / described behavior of a WTRU after receiving a DCI with respect to the example of FIG. 3 may be implemented with respect to one or more other examples described herein. Stated differently, with reference to FIG. 3 , a WTRU may have a threshold (Th) that is a WTRU capability parameter (e.g., such that the WTRU may report a minimum required time to decode a received DCI).For demonstration purposes, Th may be X ms, so "X ms after receiving DCI3" may mean that the WTRU may be able to decode the TCI selection field value="11" only X ms after receiving DCI3; as shown in the example, since k0 is shorter than Th, PDSCH3 is received before the complete decoding of DCI3, which means that the WTRU cannot decode the DCI3 content and so a "default (analog) beam" needs to be determined so that it can store PDSCH3.

[0130] In some cases (e.g., as described herein and / or shown in one or more figures), a device may determine a default beam or TCI for DL ​​reception. In one case, at least one default beam or TCI used to receive (e.g., store and decode) one or more downlink signals (e.g., including a PDSCH scheduled by a third DCI, such as DCI3) may be defined, predetermined, or pre-configured based on one or more factors, as described herein.

[0131] For example, a default beam / TCI for one or more downlink signals may be determined based on a TCI most recently selected by a TCI selection field of a second DCI (e.g., DCI 2) among one or more TCI states indicated by a TCI field of a first / initial DCI (e.g., DCI 1). DCI 3 may be received after DCI 2, which may be received after DCI 1. In other words, although the DCIs described herein are numbered, the numbers may or may not be read in the order implied by the numbering (e.g., reception by a WTRU and / or transmission by a base station), which means that it is intended that a given DCI described herein with a particular number may occur before or after another DCI regardless of numbering. 3, the WTRU may determine that the TCI most recently selected by the TCI selection field of DCI2 is the second one of {TCI3, TCI7} indicated by the TCI field of DCI1 to be {TCI7} (corresponding to codepoint "01" in the TCI selection field). In response to the determination, the WTRU may receive (e.g., store and decode) one or more downlink signals (including a PDSCH scheduled by DCI3) using TCI7 as the determined at least one default beam or TCI, even though the WTRU may decode (e.g., later, after Th) DCI3, which indicates a different codepoint (e.g., "11") in the TCI selection field of DCI3.

[0132] For example, a default beam / TCI for one or more downlink signals may be determined based on a recently selected TCI by a TCI selection field of a second DCI (e.g., DCI2) among one or more TCI states indicated by a TCI field of a first DCI (e.g., DCI1), where the recently selected TCI is used as the at least one default beam or TCI after a time offset upon receiving DCI2. In one example, the time offset may be determined as between receiving DCI2 and transmitting an acknowledgment (e.g., HARQ-ACK) in response to DCI2. This may provide benefits in terms of beam control robustness, as the determined at least one default beam or TCI is applicable only after a corresponding ACK transmission from the WTRU. In one example, the time offset may be explicitly configured (or indicated) to the WTRU.

[0133] For example, a default beam / TCI for one or more downlink signals may be determined based on a predetermined TCI based on a current mapping table between code points and one or more TCI states indicated by the TCI field of a recently received DCI on the condition that a BAT in response to the DCI has passed, as shown in Figure 2, where at least one default beam (or TCI) may be determined by a column index j (e.g., j = 0, 1) and / or a row index c (e.g., c = 0, 1, 2, ... 7 in the case of a 3-bit TCI field). In one example, at least one default beam (or TCI) may be defined (or determined) as the TCI (e.g., the first-shown TCI) corresponding to (j = 0, c = 0), which is UTCI2 for the example of Figure 2. In one case, at least one default beam (or TCI) may be defined (or determined) as a TCI corresponding to some combination of j and c, such as (j=0, c=7), which TCI is UTCI5 for the example of Figure 2; in other words, based on the example of Figure 2 and as further described above, it may be understood that the default beam may be one or more of the TCIs indicated in the index as shown in Figure 2, and that the indication of the default beam may be indicated for the mapping of code points to TCIs (e.g., an index, list, table, etc.).

[0134] For example, a default beam / TCI for one or more downlink signals may be determined based on a UTCI associated with a CORESET having a predefined or preconfigured CORESET index, e.g., the UTCI is associated with a CORESET with the lowest (or highest) ID.

[0135] For example, a default beam / TCI for one or more downlink signals may be determined based on a default TRP, and the primary or default TRP may be determined, pre-configured, or indicated (e.g., in an acknowledgement signal such as an ACK transmitted from the WTRU). In an example, the default TRP may be represented by a column index j of a current mapping table between code points and one or more TCI states, as shown in FIG.

[0136] For example, a default beam / TCI for one or more downlink signals may be determined based on two or more default UTCIs that may be defined, configured, or used (e.g., for joint transmission (JT) cases from two or more TRPs, such as coherent JT (CJT)).

[0137] In an example, the WTRU may determine that DCI3 does not include a TCI field, such as DCI format 1_0, while DCI1 and / or DCI2 may be DCIs that include a TCI field, such as DCI format 1_1 or 1_2. In response to the determination, the WTRU may receive a PDSCH scheduled by DCI3 by using at least one default beam or TCI.

[0138] In some cases, a device (e.g., a WTRU, a base station, etc., as described herein) may determine a default beam, or TCI, for DL ​​reception when a TCI selection field is not present in the DCI. In one case, at least one default beam / TCI used to receive (e.g., store and decode) one or more downlink signals (e.g., including a scheduled PDSCH) may be defined, predetermined, or pre-configured when a TCI selection field is not included or is not present in the DCI (e.g., the presence of the TCI selection field may be configurable by higher layer signaling). The default beam / TCI used to receive one or more downlink signals may be based on one or more factors.

[0139] For example, a default beam / TCI used to receive one or more downlink signals may be based on a predetermined TCI based on a current mapping table between code points and one or more TCI states, as indicated by the TCI field of a recently received DCI on the condition that a BAT in response to the DCI has passed, as shown in FIG. 2 , and at least one default beam (or TCI) may be determined by a column index j (e.g., j = 0, 1) and / or a row index c (e.g., c = 0, 1, 2, ... 7 in the case of a 3-bit TCI field). In one case, at least one default beam (or TCI) may be defined (or determined) as the TCI (e.g., the first-shown TCI) corresponding to (j = 0, c = 0), which is UTCI2 for the example of FIG. 2. In another case, at least one default beam (or TCI) may be defined (or determined) as the TCI corresponding to some other combination of j and c, such as (j = 0, c = 7), which is UTCI5 for the example of FIG. 2.

[0140] For example, the default beam / TCI used to receive one or more downlink signals may be based on a UTCI associated with a CORESET with a predefined or preconfigured CORESET index (e.g., a UTCI associated with a CORESET with the lowest (or highest) ID).

[0141] For example, the default beam / TCI used to receive one or more downlink signals may be based on a default TRP, e.g., the primary or default TRP may be determined or pre-configured or indicated (e.g., in an acknowledgement signal such as an ACK transmitted from the WTRU). For example, the default TRP may be represented by a column index j of a current mapping table between code points and one or more TCI states, as shown in FIG.

[0142] For example, the default beam / TCI used to receive one or more downlink signals may be based on two or more default UTCIs that may be defined, configured, or used (e.g., for joint transmission (JT) cases from two or more TRPs, such as coherent JT (CJT)).

[0143] In some cases, there may be a timeline for UL beam determination based on the UTCI selector in the UL-DCI. In one case, the WTRU may receive configurations of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU in a configuration message (e.g., in the form of a list, index, table, etc. as described herein) or may be pre-determined or defined by higher layer signaling (e.g., RRC and / or MAC-CE).

[0144] The WTRU may receive a first indication of a first one or more TCI states, such as via a TCI field in a first DCI (e.g., a DL-DCI that may schedule PDSCH1) of the multiple TCI states, and the WTRU begins using the first one or more TCI states at time T1.

[0145] The time T1 may be determined based on at least one of the timing of receiving the first DCI, the timing of receiving PDSCH1, the timing of transmitting an ACK in response to receiving PDSCH1, and / or a beam application time (BAT) parameter (e.g., configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters).

[0146] After the first indication, the WTRU may receive a second indication of one or more second TCI states, such as via the TCI field in a second DCI (e.g., a DL-DCI that can schedule PDSCH2), from among the plurality of TCI states, and the WTRU may begin using the one or more second TCI states at time T2. Time T2 may be determined based on at least one of the reception timing of the second DCI, the reception timing of PDSCH2, the ACK transmission timing in response to receiving PDSCH2, and / or BAT parameters.

[0147] The WTRU may receive a UL-DCI that schedules a PUSCH and selects a TCI to be applied to the transmission of the scheduled PUSCH from either the first one or more TCI states or the second one or more TCI states. The UL-DCI may include one or more of a UL-TCI selection field or an existing DCI field that selects a TCI.

[0148] The WTRU may determine to apply either the first one or more TCI states or the second one or more TCI states based on at least one of the relationship between T1 and T2 (e.g., whether T1 < T2), when the WTRU receives the UL-DCI with respect to T1 and T2 (e.g., whether the reception is between T1 and T2 or after T2), when the WTRU transmits or is scheduled to transmit the PUSCH (e.g., whether the transmission is between T1 and T2 or is scheduled to be so, or after T2 or is scheduled to be so), and the WTRU transmitting the PUSCH using either the first one or more TCI states or the second one or more TCI states based on the determination.

[0149] In one case, the WTRU may apply or determine to apply the first one or more TCI states or the second one or more TCI states based on what was most recently started being used before receiving the UL-DCI. In one example, the WTRU selects a TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU receives the UL-DCI after T2. In another example, the WTRU selects a TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU receives the UL-DCI after T1 and before T2.

[0150] In one case, the WTRU may apply or determine to apply the first one or more TCI states or the second one or more TCI states based on what was most recently started being used before transmitting the PUSCH scheduled by the UL-DCI. In one example, the WTRU selects a TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T2. In another example, the WTRU selects a TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T1 and before T2.

[0151] In one case, the WTRU may apply or determine to apply the first one or more TCI states or the second one or more TCI states based on the most recently started being used at least before a time offset at which the PUSCH scheduled by the UL-DCI is transmitted, the time offset being configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters. In one example, the WTRU selects the TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T2 + time offset. In another example, the WTRU selects the TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T1 + time offset and before T2 + time offset.

[0152] FIG. 4 shows an example of a UTCI update timeline and UTCI selection for UL transmission. From this figure, in a given scenario, it may be understood that the WTRU may have an initial TCI state (preconfigured or configured from a DCI such as DCI 401 as described herein), the DCI may include a 3-bit TCI field 405, and the DCI may also have a TCI selection field 409. Before 400, the WTRU may initially use and / or apply a set of TCIs such as {TCI3, TCI7} at 413 (e.g., as a unified TCI applicable to multiple channels / signals) for communication with the base station (e.g., gNB). After 400, the exemplary scenario of FIG. 4 may start and the base station may transmit one or more DCIs to the WTRU. The WTRU may receive a DCI1 (e.g., DL-DCI) that schedules a PDSCH1 (e.g., a data packet) to be transmitted after k0 at which the DCI1 is transmitted, indicating the same TCI {TCI3, TCI7} (e.g., 406, 414) as the currently used TCI (e.g., via the TCI field of DCI1 at 413), and the value of k0 may be indicated in the same DCI1 (or via separate signaling).

[0153] The WTRU may apply the {TCI3, TCI7} indicated by the TCI field of DCI1 after (1) receiving the scheduled PDSCH1, (2) transmitting the corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured or indicated to the WTRU (e.g., from the base station). In an example, applying the indicated {TCI3, TCI7} (e.g., as a unified TCI applicable to multiple channels / signals) in response to DCI1 may be equivalent to maintaining the currently used TCI since the same {TCI3, TCI7} is being used (e.g., as shown in 417).

[0154] The WTRU may receive DCI2 (e.g., DL-DCI) at 403 indicating (e.g., via the TCI field of DCI2 at 407) a different TCI {TCI5, TCI8} from the currently used TCI {TCI3, TCI7} and scheduling PDSCH2 (e.g., a data packet) to be transmitted k0 after DCI2 was transmitted, where the value of k0 may be indicated in the same DCI2 (or via separate signaling).

[0155] The WTRU may apply the TCI {TCI5, TCI8} indicated by the TCI field of DCI2 after (1) receiving the scheduled PDSCH2, (2) transmitting a corresponding acknowledgment (e.g., HARQ-ACK), and (3) the BAT parameters, which may be pre-configured or indicated to the WTRU (e.g., from a base station). In an example, applying the indicated TCI {TCI5, TCI8} (e.g., 415) in response to DCI2 (e.g., as a unified TCI applicable to multiple channels / signals) may be interpreted as a "beam or TCI update" because the indicated TCI {TCI5, TCI8} is different from the currently used TCI {TCI3, TCI7} (e.g., see the transition of use from one set of TCIs to another set of TCIs in 417 and 418).

[0156] In one case, the WTRU may schedule a PUSCH and receive a UL-DCI (e.g., DCI format 0_1, 0_2) at 419 including a TCI selector (e.g., via the UL-TCI selection field or one or more of the existing DCI fields), and the selector may select at least one of the currently used TCIs (e.g., the selector may indicate the first one indicating TCI3). In another case, the selector may apply a new TCI and may apply one of the new TCIs (e.g., an indication of the first one of the new TCIs would mean to apply TCI5). The currently used TCI may be determined with respect to one or more factors.

[0157] In an example, the currently used TCI may be determined for the time instance at which the UL-DCI is received. Then, in FIG. 4, the WTRU may determine that the currently used TCI for this time instance is {TCI3, TCI7} (e.g., at 417) because the time instance at which the UL-DCI is received is before the BAT in response to DCI2 has passed.

[0158] In an example, the currently used TCI may be determined for a time instance to transmit a PUSCH scheduled by the UL-DCI (e.g., the PUSCH transmission timing may be based on the "k2" parameter indicated by the UL-DCI) (e.g., the PUSCH transmission timing may be k2 after receiving the UL-DCI) (see, e.g., time considerations in 451 and related PUSCH). Then, in FIG. 4, the WTRU may determine that the currently used TCI for this time instance to transmit a PUSCH is {TCI5, TCI8} because this time instance is after the BAT in response to DCI2 has passed.

[0159] In an example, the currently used TCI may be determined for a time instance that is before Th_UL for transmitting a PUSCH scheduled by the UL-DCI (e.g., the PUSCH transmission timing may be based on the “k2” parameter indicated by the UL-DCI) (e.g., the PUSCH transmission timing may be k2 after receiving the UL-DCI). Then, in FIG. 4, the WTRU may determine that the currently used TCI for the time instance that is before Th_UL for transmitting a PUSCH is {TCI5, TCI8} because this time instance is after the BAT in response to DCI2 (e.g., at 451) has passed. Although not shown, two or more UL threshold parameters (e.g., Th_UL1, Th_UL2) may be configured or used (e.g., each UL threshold parameter may apply to each WTRU panel). This may be based on assuming that the base station may know which WTRU panel is the currently activated panel. If a deactivated panel is indicated by the UL-TCI selection field or one or more of the existing DCI fields, then Th_UL2 (e.g., greater than Th_UL1) may apply. As is apparent from the above, it should be noted that one or more permutations of the example shown in Figure 4 are described herein that do not necessarily correspond to what is illustrated; this emphasizes that the example of Figure 4 is intended to serve as a basis for one or more possible permutations using one or more elements / aspects from the illustration, which may not be fully described but may be obvious from one or more elements / aspects of what is illustrated and what is generally described herein; in other words, it is intended that one or more elements / aspects of any given illustration (e.g., as described or illustrated) are optional and are intended to serve as a basis for one or more permutations.

[0160] In an example, the currently used TCI may be determined for a time instance that is (based on) a configurable period, such as n>=0 slots / symbols, after a time reference point, which may be reception of the UL-DCI, completion of a scheduled PUSCH transmission according to the UL-DCI, etc. The WTRU may determine and apply the received indicated (e.g., selected) TCI state upon completion of the PUSCH transmission. In one approach, the WTRU may apply the received indicated (e.g., selected) TCI state immediately after completion of the scheduled PUSCH transmission, or alternatively, n slots / symbols after completion of the PUSCH transmission. For example, in FIG. 4, the WTRU may receive updated UTCI information as part of the UL-DCI (e.g., explicitly or implicitly, where, by way of example, the UL-DCI may also include a TCI field, which may indicate the updated UTCI information), but it continues to use TCI5 and TCI8 until completion of the PUSCH transmission. The WTRU may then apply the newly indicated TCI state (e.g., updated UTCI information) for future transmissions, either immediately or n slots / symbols later, which in one case may also include downlink transmissions. The configurable period (e.g., n) may be configured by the RRC and / or MAC CE, or alternatively may be indicated in the DCI (e.g., UL-DCI).

[0161] The UL-TCI selection field, or one or more examples of existing DCI fields, may include at least one of the following codepoints: codepoint "00" in the UL-TCI selection field, applying the first one; codepoint "01" in the UL-TCI selection field, applying the second one; codepoint "10" in the UL-TCI selection field, applying both; codepoint "11" in the UL-TCI selection field, reserved; codepoint "X" in the UL-TCI selection field, applying none (e.g., meaning applying the default TCI and / or beam); codepoint "Y" in the UL-TCI selection field, applying the one used for CORESET or PDCCH reception; codepoint "Z" in the UL-TCI selection field, applying the third one (if more than two UTCI states are used at a time); and / or codepoint "Z1" in the UL-TCI selection field, applying the first and third ones (if more than two UTCI states are used at a time).

[0162] Generally, as described herein, a WTRU may transmit a PUSCH using at least one of the currently used ones (e.g., TCI) determined for a time instance (e.g., a WTRU such as that described with respect to the example of FIG. 4).

[0163] In one case, there may be linked beam control for UL channels / signals associated with dynamic PUSCH beam selection. In one approach, the determined at least one of the currently used ones (e.g., TCI) determined for a time instance may be (also) applicable to other UL channels / signals (e.g., configuration grant (CG)—PUSCH, PUCCH, SRS, PRACH, etc.) based on the base station configuration for the linked beam control mechanism. For such an approach, at least one of the following may be applied: for each specific channel / signal, configuration grant (CG)-PUSCH resource or configuration, PUCCH resource and / or resource group, SRS resource and / or resource set, PRACH resource or configuration, the base station may configure or indicate a flag (or parameter) indicating that this channel and / or signal follows the UL-TCI selection field (of the UL-DCI) or the most recent indication by one or more of the existing DCI fields, and / or in the case of a type 2 CG-PUSCH, after being activated by an activating DCI, beam control may be linked to the UL-TCI indication field (of the UL-DCI, such as scheduling a dynamic grant PUSCH).

[0164] The WTRU may send transmissions using any of several uplink channels, such as PUSCH, PUCCH, SRS, or PRACH. Furthermore, the WTRU may employ one of several transmission strategies, such as single or multiple TRP transmission. Therefore, procedures related to indicating, maintaining, and updating the UL-TCI may be applicable to all channels and transmission methods. Because uplink beam changes often result from changes in the transmission environment, such as mobility, obstructions, etc., the WTRU may perform updates of more than one UL-TCI state at a time to reduce signaling overhead.

[0165] In one approach, the WTRU may be configured with (or indicated by) at least one beam or UL-TCI per channel, and the configured UL-TCI combination may be configured jointly by RRC signaling or by a combination of RRC and MAC signaling. Table 1 shows an example configuration of the UL-TCI per channel.

[0166] [Table 1]

[0167] In one approach, when a WTRU receives a scheduling DCI for an uplink transmission, it may also receive a UL-TCI selection field for selecting a UL-TCI for the transmission. The TCI selection field may include one or more indications for the selection of a UL-TCI. In an example, the WTRU may first receive a configuration (e.g., an RRC configuration) for a configured number of DCI fields intended for simultaneous indication of the UL-TCI. For example, an RRC configuration (e.g., ulTCI_FieldConfig) with parameters related to the UL TCI configuration may be considered (e.g., and / or may be received by the WTRU) as follows: field 1, N1 entries for PUSCH; field 2, N2 entries for PUCCH; field 3, N3 entries for SRS; and / or field 4, N4 entries for PRACH.

[0168] Once configured, in one situation, a WTRU may receive a DCI with M fields, each field may select the UL-TCI for its corresponding configured channel. In another situation, a WTRU configured for multi-TRP operation may be configured with two or more fields for one or more of its uplink channels or signals. For example, a WTRU may be configured with two or more fields for the PUSCH to support uplink multi-TRP transmission.

[0169] In one scenario, a WTRU may operate multiple antenna panels. The WTRU may report one or more WTRU capability parameters associated with the multiple WTRU panels, such as the number of WTRU panels, how many WTRU panels can be simultaneously activated to communicate with a TRP (e.g., a cell, a gNB, a base station, a WTRU, etc.). Each WTRU panel of the multiple WTRU panels may have one or more of the following functionality: a separate group of antennas or antenna ports (e.g., subarrays) for receiving or transmitting signals based on independent spatial domain filters (e.g., spatial Rx parameters, analog beamforming coefficients, and / or polarization domain parameters or coefficients, etc.); an independent power control entity, meaning that different power control mechanisms or indications may be applied to different WTRU panels; and / or an independent timing control entity, meaning that different timing control mechanisms or indications may be applied to different WTRU panels. The WTRU may receive a configuration of multi-panel WTRU (MPWTRU)-related parameters, which may include multiple SRS resource sets, each associated with a respective WTRU panel.

[0170] When a WTRU reports multi-panel capability (MPWTRU), the configuration of the UTCI may relate to antenna panel grouping based on full, partial, and / or non-coherent characteristics of the WTRU antenna system for UL transmission, from which it may be understood that the indication of configuration in the report may be implicit or explicit.

[0171] An MPWTRU reporting "non-coherent" and fullPowerMode2 may be configured with two SRS resource sets that may be split between non-coherent antenna subgroups (e.g., panels). In this case, an SRS resource set may be associated with each panel, and the UTCI selector for beam selection may follow the SRS resource set associated with the panel. In this case, PUSCH transmission in STxMP mode per panel is associated with the SRS resource set mapped per panel.

[0172] An MPWTRU reporting "partial and non-coherent" may have panel coherence and inter-panel non-coherence capabilities. In this case, SRS resource sets may be associated with panel (e.g., panel group) coherency splits. If fullPowerMode2 is configured, the WTRU may expect at least two sets of SRS resource sets that may be associated with panel beams by the UTCI selector.

[0173] An MPWTRU that reports "fully and partially coherent" capability for its antenna system can be configured with one or two SRS resource sets. If the MPWTRU is configured with fullPowerMode1 and one SRS resource set, the UTCI active panel is considered for the current transmission on the current beam.

[0174] If the WTRU is configured with fullPowerMode2 and two SRS resource sets, the UTCI selector may be associated with the SRS resource set and may be linked to the coherent panel or panel group associated with the beam.

[0175] In one case, the WTRU may determine the UL TCI state on a panel-by-panel basis. When the WTRU transmits simultaneously on two or more panels in the same timeslot / symbol, the WTRU may be considered to be operating in a simultaneous transmission on multiple panels (STxMP) mode of operation. The WTRU may receive a dynamic indication in the DCI (e.g., an SRS resource set indicator), and the WTRU may decide to switch between single-panel and STxMP transmission in response to the dynamic indication.

[0176] In one approach, a WTRU may receive a UL-DCI, which may include an indication with multiple TCI states and an indication for selecting one or more (UL) TCI states (e.g., a UL TCI state selector, such as based on a UL-TCI selection field of the UL-DCI or one or more of existing DCI fields). The UL-DCI may include a grant for scheduling a PUSCH, and the WTRU may transmit the PUSCH in the selected TCI state. The WTRU may determine that the PUSCH may be transmitted in an operating mode in which two or more panels may be used simultaneously. The TCI state selector may indicate an association between the TCI state and one or more SRS resources configured in an SRS resource set. The TCI state selector may indicate a panel index associated with each of the SRS resource sets. For example, a first panel may be associated with a first SRS resource set or a second SRS resource set. The WTRU may determine power control parameters (e.g., P0, alpha, TPC) for each SRS resource set according to the associated panel indicated by the UL TCI state selector.

[0177] If the UL TCI state selector indicates two UL TCI states to use, the WTRU may transmit a PUSCH in STxMP operation mode with the two indicated UL TCI states. As part of its WTRU capabilities, the WTRU may signal a threshold timing per panel. If the WTRU is scheduled for a PUSCH transmission that occurs at a time T1 greater than both threshold timings per panel from the time of UL TCI state reception, the WTRU may use the newly indicated UL TCI state for STxMP. If the WTRU is scheduled for a PUSCH transmission that occurs at a time T1 that is less than at least one of the per-panel threshold timings from the time of UL TCI state reception, the WTRU may not apply the newly indicated UL TCI state for the STxMP until the next grant for STxMP transmission is received, and the WTRU may apply the UL TCI state for the current STxMP transmission using one of the following rules: the WTRU may transmit in the STxMP using the per-panel UL TCI state that was active at the time of receipt of the UL DCI, the WTRU may fall back to a single-panel transmission where one of the panels is pre-configured as default single-panel operation with the default UL TCI state, and / or the WTRU may fall back to a single-panel transmission on a panel with a threshold timing less than T1.

[0178] Alternatively, the UL TCI state selector may indicate a single UL TCI state, and the WTRU may decide to transmit on a single panel. The WTRU may determine the panel from among multiple panels based on the indication in the UL TCI state selector.

[0179] In another approach, if a separate indicator in the UL DCI indicates STxMP operation mode and the TCI state selector indicates only one UL TCI state, the WTRU may transmit in STxMP operation mode using the newly indicated TCI state on the first panel and an implicitly predetermined UL TCI state on the second panel. The predetermined UL TCI state may be one of the following: a pre-configured UL TCI state paired with the indicated UL TCI state (e.g., TCI states 1 and 2 may be pre-configured with an association for STxMP, and if the WTRU receives a UL TCI state indication for TCI state 1, the WTRU may implicitly decide to use TCI state 2 in STxMP simultaneously), the last UL TCI state used on the second panel in either a single panel or STxMP, or the UL TCI state associated with the lowest PUCCH resource ID of the second panel.

[0180] If the UL DCI indicates STxMP operation mode and the UL TCI state selector does not indicate any UL TCI states, the WTRU may transmit in STxMP operation mode using a default configured pair of UL TCI states for STxMP. The default pair may be explicitly pre-configured or implicitly determined, for example, the last pair of UL TCI states used for STxMP, the UL TCI state associated with the SRS resource with the lowest ID per panel or with the lowest ID in the SRS resource set, and / or the UL TCI state associated with the lowest PUCCH resource ID per panel.

[0181] In some circumstances, the MPWTRU may operate with one or more specific behaviors as described herein.

[0182] The WTRU may receive a configuration of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU (or may be predetermined or defined) in a configuration message, such as in the form of a list, by higher layer signaling (e.g., RRC and / or MAC-CE).

[0183] The WTRU may receive an indication of one or more TCI states of a plurality of TCI states, such as via a TCI field in a first DCI (e.g., a DL-DCI that may schedule PDSCH1), and the WTRU begins using the one or more TCI states at time T1. Time T1 may be determined based on at least one of a reception timing of the first DCI, a reception timing of PDSCH1, a timing of an ACK transmission in response to receiving PDSCH1, and a beam application time (BAT) parameter, such as configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters.

[0184] The WTRU may schedule a PUSCH and receive a UL-DCI (e.g., after T1 and / or using one of the one or more TCI states) that selects at least one TCI from one or more TCI states to apply to at least one transmission of the scheduled PUSCH, one or more SRS resources, a second PUSCH, a PUCCH, and / or a PRACH. The WTRU may decide on the at least one transmission based on an explicit configuration from the base station or an implicit decision. The UL-DCI may include a UL-TCI selection field or one or more existing DCI fields that select the at least one TCI. The one or more SRS resources may be within at least one SRS resource set of multiple SRS resource sets each associated with a respective WTRU panel and / or a UL Tx mode, such as a codebook-based UL Tx mode or a non-codebook-based UL Tx mode.

[0185] In one example, provided that the at least one transmission decision includes a scheduled PUSCH, the WTRU transmits the scheduled PUSCH by the UL-DCI, such as simultaneous transmission from multiple WTRU panels (STxMP) by applying each of the at least one TCI to each WTRU panel for STxMP transmission based on the selected at least one TCI.

[0186] In a second example, the WTRU transmits a PUSCH scheduled by the UL-DCI, such as an STxMP transmission by applying each of the at least one TCI to each WTRU panel, based on the selected at least one TCI, provided that the at least one transmission decision includes a scheduled PUSCH and one or more SRS resources, and / or at time T2, the WTRU begins transmitting one or more SRS transmissions via one or more SRS resources based on the selected at least one TCI. Time T2 may be determined based on at least one of the reception timing of the UL-DCI, the transmission timing of the PUSCH scheduled by the UL-DCI, and UL-BAT parameters (which may be different from the BAT parameters), such as configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters. After time T2, the WTRU may schedule a second PUSCH with or without selecting a TCI (e.g., via the UL-TCI selection field or one or more of existing DCI fields) and receive a second UL-DCI that includes multiple SRS resource indication (SRI) fields, where the SRI fields are each associated with a respective WTRU panel. Provided that the WTRU determines that the second PUSCH should be transmitted by following the same UL beam (or TCI) as used for a previous (e.g., most recent) SRS transmission via the at least one SRS resource indicated by the SRI field, the WTRU may transmit the second PUSCH using the determined same UL beam or TCI associated with the at least one SRS resource indicated by the SRI field of the UL-DCI. The WTRU may receive a second UL-DCI that may dynamically inform the WTRU to apply a TCI selected (e.g., by the UL-TCI selection field or one or more of the existing DCI fields) or to apply the same UL beam or TCI associated with at least one SRS resource indicated by the SRI field of the UL-DCI.

[0187] In a third example, provided that the at least one transmission decision includes one or more SRS resources, the WTRU transmits the PUSCH scheduled by the UL-DCI based on following the same UL beam (or TCI) as used for a previous (e.g., most recent, before receiving the UL-DCI) SRS transmission via the at least one SRS resource indicated by the SRI field of the UL-DCI. At time T2, the WTRU begins transmitting one or more SRS transmissions via the one or more SRS resources based on the selected at least one TCI. Time T2 may be determined based on at least one of the reception timing of the UL-DCI, the transmission timing of the PUSCH scheduled by the UL-DCI, and UL-BAT parameters (which may be different from the BAT parameters), such as configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters.

[0188] In some circumstances, a MPWTRU may operate with multiple SRI and / or TPMI fields. The WTRU may receive a DCI including a first SRS resource indicator field (SRI field), a second SRI field, a first transmit precoding matrix indicator field (TPMI field), and a second TPMI field. In an example, the first SRI field indicating at least one SRS resource and the first TPMI field indicating the precoding matrix and rank (number of PUSCH layers) are associated with (e.g., mapped to, correspond to) a first WTRU panel. In an example, the second SRI field indicating at least one SRS resource and the second TPMI field indicating the precoding matrix and rank (number of PUSCH layers) are associated with (e.g., mapped to, correspond to) a second WTRU panel.

[0189] In at least one case, the WTRU may be assumed to have received (e.g., via a TCI field in a DL-DCI) an indication of one or more TCI states (e.g., UTCIs) that are currently (e.g., at the time of receiving the DCI) assumed to be used as a UTCI (e.g., UL-DCI) some amount of time ago.

[0190] In one approach, there may be beam determination / update per WTRU panel using UTCI (e.g., via a UTCI selector field (e.g., 2 bits)) (e.g., in DL-DCI or UL-DCI).

[0191] The WTRU may receive control signals (e.g., via MAC-CE and / or RRC) in which at least one code point (e.g., “00”, “01”, “10”, “11”) in the UTCI selector field may be described (or configured) to perform an action based on one or more behaviors.

[0192] In a first scenario, the WTRU may receive control signals (e.g., via MAC-CE and / or RRC) in which at least one code point (e.g., “00”, “01”, “10”, “11”) in the UTCI selector field may be described (or configured) to perform an action based on applying / updating a first or second (e.g., one or more TCI states) to a first or second SRS resource set (e.g., with respect to a scheduled PUSCH transmission and / or beam determination for a next SRS transmission via one or more SRS resources in the applied SRS resource set).

[0193] In this scenario, as described with respect to one or more examples herein, a first of the one or more TCI states may be assumed to be indicated by a codepoint in the UTCI selector field corresponding to the first SRS resource set.

[0194] In a first example (e.g., an indication by a UTCI selector that applies only to the currently scheduled PUSCH transmission), the WTRU may transmit a scheduled PUSCH (e.g., STxMP) based on a first PUSCH beam determined by the UTCI selector (e.g., corresponding to a first WTRU panel) (e.g., SRS resource selection by a first SRI field serves as at least a port determination for the PUSCH transmission) and / or a second PUSCH beam determined by a second SRI field (e.g., corresponding to a second WTRU panel).

[0195] In a second example, (e.g., as indicated by a UTCI selector that applies only to the next SRS transmission), the WTRU may transmit a scheduled PUSCH (e.g., STxMP) based on a first PUSCH beam (e.g., corresponding to a first WTRU panel) determined by a first SRI field (e.g., the next SRS transmission via SRS resources in a first SRS resource set may be based on an indicated first one of one or more TCI states, e.g., the indicated first one may be applied to a predetermined (e.g., first) SRS resource and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to other (remaining) SRS resources in the first SRS resource set) and / or a second PUSCH beam (corresponding to a second WTRU panel) determined by a second SRI field.

[0196] In a third example, (e.g., as indicated by a UTCI selector that applies to both the currently scheduled PUSCH transmission and the next SRS transmission), the WTRU may transmit a scheduled PUSCH (e.g., STxMP) based on a first PUSCH beam (e.g., corresponding to a first WTRU panel) determined by the UTCI selector (e.g., the SRS resource selection by the first SRI field serves as a port determination for at least the PUSCH transmission, and the next SRS transmission via SRS resources in the first SRS resource set may be based on an indicated first one of one or more TCI states, e.g., the indicated first one may be applied to a predetermined (e.g., first) SRS resource in the first SRS resource set, and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to other (remaining) SRS resources in the first SRS resource set) determined by the UTCI selector and / or a second PUSCH beam (e.g., corresponding to a second WTRU panel) determined by the second SRI field.

[0197] In a second scenario, the WTRU may receive control signals (e.g., via MAC-CE and / or RRC) in which at least one code point (e.g., “00”, “01”, “10”, “11”) in the UTCI selector field may be described (or configured) to perform an action based on applying / updating both (one or more TCI states) to both SRS resource sets (e.g., with respect to a scheduled PUSCH transmission and / or beam determination for the next SRS transmission via one or more SRS resources in each SRS resource set).

[0198] In this scenario, in one example, both TCI states may be applied / updated as STxMP spatial domain multiplexing (SDM) (if the UTCI selector field of the UL-DCI is used) based on the first {SRS resource set and TPMI field} for the first WTRU panel and the second {SRS resource set and TPMI field} for the second WTRU panel, respectively, for at least port / layer / precoding decisions.

[0199] In this scenario, in another case, both TCI states may be applied / updated as STxMP Single Frequency Network (SFN) (if the UTCI selector field of the UL-DCI is used), and the total number of layers may be determined by the first TPMI field for the CB-PUSCH and the first SRS field for the NCB-PUSCH, respectively.

[0200] In a first example (e.g., an indication by a UTCI selector that applies only to the currently scheduled PUSCH transmission), the WTRU may transmit a scheduled PUSCH (e.g., STxMP) based on a first PUSCH beam determined by the UTCI selector (e.g., corresponding to a first WTRU panel) (e.g., SRS resource selection by a first SRI field serves as at least the port determination for the PUSCH transmission) and / or a second PUSCH beam determined by the UTCI selector (e.g., corresponding to a second WTRU panel) (e.g., SRS resource selection by a second SRI field serves as at least the port determination for the PUSCH transmission).

[0201] In a second example, (e.g., as indicated by a UTCI selector to be applied only to the next SRS transmission), the WTRU may select a first PUSCH beam (e.g., corresponding to a first WTRU panel) determined by a first SRI field (e.g., the next SRS transmission via SRS resources in the first SRS resource set may be based on an indicated first one of one or more TCI states, e.g., the indicated first one may be applied to a predetermined (e.g., first) SRS resource and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to the other (remaining) SRS resources in the first SRS resource set), and / or Alternatively, the WTRU may transmit a scheduled PUSCH (e.g., STxMP) based on a second PUSCH beam (corresponding to a second WTRU panel) determined by the second SRI field (e.g., the next SRS transmission via the SRS resources in the second SRS resource set may be based on an indicated second one of one or more TCI states, e.g., the indicated second one may be applied to a predetermined (e.g., first) SRS resource in the second SRS resource set, and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to the other (remaining) SRS resources in the second SRS resource set).

[0202] In a third example, (as indicated by a UTCI selector applied to both the currently scheduled PUSCH transmission and the next SRS transmission), the WTRU selects a first PUSCH beam (e.g., corresponding to a first WTRU panel) determined by the UTCI selector. The SRS resource selection by the first SRI field serves as a port determination for at least the PUSCH transmission, and the next SRS transmission via the SRS resources in the first SRS resource set may be based on an indicated first one of one or more TCI states, e.g., the indicated first one may be applied to a predetermined (e.g., first) SRS resource, and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to the other (remaining) SRS resources in the first SRS resource set. obtained), and / or a second PUSCH beam (corresponding to the second WTRU panel) determined by the UTCI selector (e.g., the SRS resource selection by the second SRI field serves as at least a port determination for the PUSCH transmission, and the next SRS transmission via SRS resources in the second SRS resource set may be based on an indicated second one of the one or more TCI states, e.g., the indicated second one may be applied to a predetermined (e.g., first) SRS resource in the second SRS resource set, and a predefined (or preconfigured) pattern of varying beams (spatial domain filter coefficients) may be applied to the other (remaining) SRS resources in the second SRS resource set).

[0203] A new parameter for "BAT_UL" may be configured / used, and the application of the first or second scenario or any situation described herein may occur after the BAT_UL time interval (e.g., not immediately after receiving DL / UL DCI). For example, in the case of UL-DCI, the UTCI selector field may apply to a later-scheduled UL (e.g., PUSCH and / or SRS transmission, and / or other UL channels / signals).

[0204] In one case, there may be joint coding on the SRS Resource Set Indicator (SRSI) field codepoint (e.g., in the UL-DCI case). In STxMP, the existing SRSI field may have one or more reinterpreted code points (e.g., as joint coding with a UTCI selector) based on at least one of the following selections: select a first SRS resource set (e.g., as sTRP fallback) and apply a first one (e.g., of one or more TCI conditions indicated by a TCI field such as DL-DCI) for the PUSCH Tx; select a second SRS resource set (e.g., as sTRP fallback) and apply a second one (e.g., of one or more TCI conditions indicated by a TCI field such as DL-DCI) for the PUSCH Tx; select a first and a second SRS resource set (e.g., as STxMP) and apply a first and a second one, respectively, of one or more TCI conditions (e.g., indicated by a TCI field such as DL-DCI) for the PUSCH Tx; select a first and a second SRS resource set (e.g., as STxMP) and apply a first and a second one, respectively, of one or more TCI conditions (e.g., indicated by a TCI field such as DL-DCI) for the PUSCH Tx; Apply the second and first of one or more TCI states (e.g., indicated by a TCI field such as DL-DCI) for Tx, respectively. In this last selection option, which may benefit the MPWTRU and sTRP cases, an STxMP transmission with a swapped pair of beams (e.g., based on applying the second and first) may go towards sTRP, providing benefits in terms of beam selection flexibility.

[0205] In some situations, the examples and scenarios described herein may apply to one of the following: the currently scheduled PUSCH transmission only, the next SRS transmission only, or both the currently scheduled PUSCH transmission and the next SRS transmission.

[0206] In some cases, there may be a UTCI deactivation process in a multi-stage UTCI management framework. In one case, a WTRU may receive configurations of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU in a configuration message or may be predetermined or defined (e.g., in the form of a list) by higher layer signaling (e.g., RRC and / or MAC-CE).

[0207] The WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may send a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0208] The WTRU may receive DCI2 using at least one of {TCI1, TCI2} (e.g., after sending the first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., a TCI field) of DCI2 and schedules PDSCH2. DCI2 may further indicate a selector via a second field (e.g., a TCI selection field), where the selector indicates one of the TCI states {TCI1, TCI2} indicated by DCI1.

[0209] In response to receiving DCI2, the WTRU may determine that a TCI state different from the TCI state selected by the selector is the deactivated TCI state after a time offset. The time offset may be determined based on at least one of the reception timing of DCI2, the reception timing of PDSCH2, the timing of an ACK transmission in response to receiving PDSCH2, and a beam application time (BAT) parameter (e.g., configured from the gNB and / or reported by the WTRU as part of the WTRU capability parameters). For example, if the selector indicates TCI1, the WTRU determines that TCI2 is the deactivated TCI after a time offset.

[0210] The WTRU may apply or decide to apply at least one of the following actions based on the deactivated TCI: the WTRU performs and / or reports measurements associated with the deactivated TCI at a different rate (e.g., longer periodicity) and / or with one or more different parameters compared to measurements performed and / or reported when the TCI state is not deactivated, and / or the WTRU stops or discontinues quasi-co-location (QCL) tracking on the deactivated TCI, which QCL tracking may imply measurements on an RS associated with the TCI state (e.g., the deactivated TCI) and the derivation or estimation of at least one channel or signal property among {average delay, delay spread, Doppler shift, Doppler spread, spatial Rx parameters, average power, etc.}.

[0211] In another case, the WTRU may apply or decide to apply one or more actions based on a deactivated TCI. For example, based on a deactivated DCI, the WTRU may decide to apply or decide to apply a default RS, TCI, or QCL source in a second RS resource (e.g., CSI-RS, SRS) or channel (e.g., PDCCH, PDSCH, PUCCH, PUSCH) on the condition that a third TCI state associated with the second RS resource or channel is identified as a deactivated TCI.

[0212] The WTRU may transmit or receive signals over a second RS resource or channel based on a default RS, TCI, or QCL source (e.g., instead of a third TCI state). The default RS, TCI, or QCL source may be predetermined or configured based on at least one of an SSB index (e.g., used for (or associated with) a recent PRACH transmission to the serving cell), a tracking RS (TRS) (e.g., with a predetermined ID, such as the lowest indexed TRS configured in the serving cell), and / or a predetermined TCI state (e.g., associated with a CORESET, such as CORESET#0). Based on the decision to stop QCL tracking on the deactivated TCI, the WTRU may not expect to receive an indication associated with the RS of the deactivated TCI to transmit UL signals (or channels) and / or receive DL signals (or channels). This may imply that the base station needs to indicate another RS ​​instead of the RS when scheduling DL reception at and / or UL transmission from the WTRU.

[0213] For example, based on a deactivated DCI, the WTRU may maintain at least one (e.g., minimal) measurement and / or reporting behavior based on the deactivated TCI, such as long-term (e.g., with longer periodicity and / or separate configuration parameters, such as separate Layer 3 filtering formula-based) RRM measurements and / or reports (e.g., separate event-based reporting) based on the deactivated TCI.

[0214] In some cases, there may be UTCI deactivation based on UTCI selection. The WTRU may currently use and / or apply {TCI3, TCI7} (e.g., as a unified TCI applicable to multiple channels / signals) for communication with the base station. The WTRU may receive DCI1 (e.g., DL-DCI) indicating {TCI3, TCI7} to be the same as those currently in use (e.g., via the TCI field of DCI1) and scheduling PDSCH1 (e.g., a data packet) to be transmitted k0 after DCI1 was transmitted, where the value of k0 may be indicated in the same DCI1 or via separate signaling.

[0215] In or associated with the DCI (e.g., DCI1), the WTRU may receive a separate indication selecting a UTCI (e.g., a first one of {TCI3, TCI7}, e.g., TCI3) to be applied to at least one particular channel or signal (e.g., PDSCH1). In response to determining a UTCI selection (e.g., TCI3) from among multiple UTCIs (e.g., {TCI3, TCI7}) currently available to be applied to multiple channels and / or signals (e.g., associated with a list of multiple channels / signals, such as configured by higher layer signaling), the WTRU may determine a second UTCI (e.g., TCI7, i.e., another (or other) UTCI not selected from among the multiple UTCIs) that may be deactivated after a time offset (e.g., associated with receiving the UTCI selection).

[0216] 5 shows an example of UTCI deactivation based on UTCI selection. From this figure, it may be understood that in a given scenario, the WTRU may have an initial TCI state (e.g., pre-configured or configured from a DCI such as 501 as described herein), where the DCI may include a 3-bit TCI field 505, and the DCI may also have a TCI selection field 509. Prior to 500, the WTRU may currently use and / or apply {TCI3, TCI7} in 513 (e.g., as a unified TCI applicable to multiple channels / signals) for communication with the base station. After 500, the WTRU may receive DCI1 (e.g., DL-DCI) indicating {TCI3, TCI7} at 506 to be the same as those currently in use (e.g., via the TCI fields of DCI1, 513) and scheduling PDSCH1 (e.g., a data packet) to be transmitted k0 after DCI1 was transmitted, where the value of k0 may be indicated in the same DCI1 or via separate signaling.

[0217] In or associated with the DCI (e.g., DCI1), the WTRU may receive a separate indication selecting a UTCI (e.g., a first one of {TCI3, TCI7}, e.g., TCI3) to be applied to at least one particular channel or signal (e.g., PDSCH1). In response to determining a UTCI selection (e.g., TCI3) from among multiple UTCIs (e.g., {TCI3, TCI7}) currently available to be applied to multiple channels and / or signals (e.g., associated with a list of multiple channels / signals, such as configured by higher layer signaling), the WTRU may determine a second UTCI (e.g., TCI7, i.e., another (or other) UTCI not selected from among the multiple UTCIs) that may be deactivated after a time offset (e.g., associated with receiving the UTCI selection). In other words, as can be understood from the illustration of FIG. 4, the WTRU may apply the first TCI based on the indication received at 510, and then the WTRU may be able to decide to deactivate the second TCI.

[0218] In an example, the time offset that may be sent in a configuration message or indicated to the WTRU (e.g., from a base station) may be based on (e.g., determined with respect to or associated with) at least one of the following: the timing of reception of a DCI (e.g., DCI1), the timing of reception of a separate indication that selects the UTCI (e.g., based on a TCI selection field), and / or the timing of transmission of an ACK in response to receiving the DCI.

[0219] Deactivation of a second UTCI (eg, TCI7, which may be different from the selected one {TCI3}) may imply (eg, trigger, cause, result in, etc.) one or more actions.

[0220] In an example, deactivation of the second UTCI may imply that the WTRU may cease or stop quasi-co-location (QCL) tracking on the second TCI, which provides a benefit of reducing WTRU complexity. QCL tracking may imply measurements on an RS associated with the second TCI and derivation or estimation of at least one channel or signal property {average delay, delay spread, Doppler shift, Doppler spread, spatial Rx parameters, average power, etc.}. The WTRU may not expect to receive an indication associated with the RS of the second TCI to transmit an UL signal (or channel) and / or receive a DL signal (or channel). This may imply that the base station needs to indicate another RS ​​instead of the RS when scheduling DL reception at the WTRU and / or UL transmission from the WTRU. If the WTRU receives an indication associated with an RS of a second TCI (e.g., after a time period has elapsed or passed for transmitting an UL signal (or channel) and / or receiving a DL signal (or channel)), the WTRU may apply a third RS other than the default TCI or beam or RS for transmitting an UL signal (or channel) and / or receiving a DL signal (or channel). If the WTRU receives an indication associated with an RS of a second TCI (e.g., after a time period has elapsed or passed for transmitting an UL signal (or channel) and / or receiving a DL signal (or channel)), the WTRU may transmit (return) a negative ACK (NACK) message informing the base station of its current status, such as the message indicating that the WTRU has deactivated the second TCI.

[0221] In an example, deactivating the second UTCI may imply that the WTRU may not include (e.g., exclude) the RS of the second TCI in the CSI or beam or mobility measurement resources associated with the CSI or beam or mobility-related reporting procedure. This may imply that the WTRU may cease or stop measuring the RS of the second TCI for CSI, beam, and / or mobility measurement and reporting purposes, and the WTRU may remove the RS from the configured list of RSs in the corresponding measurement resources. The base station may need to reconfigure the measurement resources if the base station intends to include the RS in the list later.

[0222] In an example, deactivation of the second UTCI may cause the WTRU to perform at least one (e.g., minimal) measurement and / or reporting action, such as (one or more) long-term (e.g., specifically configured or indicated Layer 3 filtering-based) measurements and event-based reporting, (minimal) RRM measurements / reports based on the second TCI, and the deactivated TCI to be checked for RLF with a lower priority (compared to other RSs configured or associated with Radio Link Monitoring (RLM) or Radio Link Failure (RLF) procedures). This may imply that (minimum) RLM and / or RLF relationship measurements / reports based on the second TCI may include a separate RLM check condition at the deactivated TCI (e.g., the second TCI), a (minimum) Beam Failure Recovery (BFR) relationship measurement / reports based on the second TCI, which may include a separate BFR check condition at the deactivated TCI (e.g., the second TCI) to be checked for BFR with a lower priority (compared to other RSs configured in or associated with the BFR procedure), and / or others (e.g., as described herein).

[0223] In some situations, there may be one or more conditions for determining that a second TCI (UTCI) should be activated. In such situations, it may be assumed (e.g., for purposes of illustrating an example, but not intended to be limiting) that the WTRU received, some amount of time ago, an indication (e.g., via a TCI field in a DL-DCI) of one or more TCI states (e.g., UTCIs) that are currently assumed to be used as the UTCI (e.g., at the time of receiving the DCI (discussed herein)).

[0224] One condition that may be used to determine that the second TCI (UTCI) should be deactivated may be based on a code point of a DCI field in the DCI, where the code point may explicitly indicate which TCI should be deactivated, such as among one or more TCI states. For example, the code point may directly indicate the second TCI to be deactivated. For example, the code point may indicate a TCI to be used for DL / UL communication, and the WTRU may determine a second TCI other than that TCI among one or more TCI states.

[0225] One condition that may be used to determine that a second TCI (UTCI) should be deactivated may be based on a code point in the DCI field in the DCI, which may indicate applying whatever TCI was most recently selected / used before receiving the DCI, determining a second TCI other than that TCI in one or more TCI states, and deactivating the second TCI.

[0226] For example, for the DCI field (e.g., 2 bits): "00" applies / selects a first one of one or more TCI states; "01" applies / selects a second one of one or more TCI states; "10" applies / selects both (or all) of one or more TCI states; and "11" (such as a codepoint in UL-DCI) applies whatever TCI was most recently selected / used before receiving the DCI, determines a second TCI other than that TCI among the one or more TCI states, and deactivates the second TCI. For example, if the previous indication was "00" to select the first TCI, continue using the first TCI (for communication with TRP1) and deactivate the second TCI (no more QCL tracking on the second TCI), which may mean falling back to sTRP(TRP1). This may be beneficial because it reduces WTRU complexity for QCL tracking. The deactivated TCI may be deactivated not only for the PUSCH, but also for other channels / signals (e.g., PDCCH, PDSCH, and / or PUCCH, etc. (e.g., based on base station configuration / indication)).

[0227] For example, for a codepoint in a DL-DCI, a condition is added that one or more TCI states are not changed by a second DCI field (e.g., "TCI field") in the same DL-DCI (compared to a previous indication by "TCI field"). In "11" (a codepoint such as in a DL-DCI), it may apply whatever TCI was recently selected / used before receiving the DCI, determine a second TCI that is other than that TCI among the one or more TCI states, and deactivate the second TCI when one or more TCI states indicated by a TCI field in the same DL-DCI are not changed (from a recent indication by the TCI field). For example, if the previous indication was "00" to select the first TCI, when one or more TCI states indicated by the TCI field in the same DL-DCI remain unchanged (from the most recent indication by the TCI field), the first TCI continues to be used (for communication with TRP1) and the second TCI is deactivated (there is no more QCL tracking on the second TCI), which may mean falling back to sTRP(TRP1). This may be beneficial because it reduces the WTRU complexity for QCL tracking. The deactivated one may be deactivated not only for the PDSCH, but also for other channels / signals (e.g., PDCCH, PUSCH, and / or PUCCH, etc. (based on the base station configuration / indication)).

[0228] In some situations, there may be activity on other channels / signals with deactivated UTCIs. For PDCCH and / or SPS-PDSCH reception when the corresponding UTCI is deactivated by the UTCI selector field, the WTRU may apply at least one of: CORESET and PDCCH monitoring and / or SPS-PDSCH Rx is discontinued / stopped, and / or CORESET and PDCCH monitoring and / or SPS-PDSCH Rx is continued with the non-deactivated ones (e.g., beam switching, e.g., sTRP fallback, e.g., it may always fall back to the primary TRP). For PUCCH, or CG-PUSCH, or SRS, or PRACH transmissions when the corresponding UTCI is deactivated by the UTCI selector field, at least one of the following applies: PUCCH, CG-PUSCH, SRS, and / or PRACH Tx (e.g., of a PUCCH resource group) is discontinued, and / or PUCCH, CG-PUSCH, SRS, and / or PRACH Tx (e.g., of a PUCCH resource group) is continued using the non-deactivated ones (e.g., beam switching, e.g., sTRP fallback, e.g., it may always fall back to the primary TRP).

[0229] In some cases, there may be cross-carrier scheduling based on a multi-stage UTCI management framework. In one case, a WTRU may receive configuration information indicating multiple TCI states. The WTRU may receive a first indication of a first one or more TCI states of the multiple TCI states in CC1 (e.g., via a TCI field in a first DCI (e.g., a DL-DCI that schedules PDSCH1)), and the WTRU begins using the first one or more TCI states (e.g., in at least CC1 (e.g., as a default)) at time T1. The WTRU may receive a second indication of a second one or more TCI states of the multiple TCI states in CC2 (e.g., via a TCI field in a second DCI (e.g., a DL-DCI that schedules PDSCH2)), and the WTRU begins using the second one or more TCI states (e.g., in at least CC2 (e.g., as a default)) at time T2.

[0230] After at least T1 and / or T2, the WTRU may receive a third DCI (e.g., DL-DCI) in CC1 using at least one of the first one or more TCI states, which schedules PDSCH3 to be transmitted in CC2 (e.g., by a carrier indicator field, CIF, e.g., based on the carrier indicator) in the third DCI as cross-carrier scheduling, and / or selects a TCI state from among the first one or more TCI states or the second one or more TCI states (e.g., by a TCI selection field of the third DCI) based on a CC decision rule, which may be explicitly configured by the base station and / or implicitly determined based on a rule or condition.

[0231] The CC decision rule may be at least one or more of the following examples, and the rule to be used may be configured: Example Rule 1 (following a "scheduling CC"), the WTRU receives PDSCH3 in CC2 using a TCI state selected from a first one or more TCI states indicated by a first DCI received in CC1 (e.g., indicated by a TCI selection field of a third DCI); Example Rule 2 (following a "scheduled CC"), the WTRU receives PDSCH3 in CC2 using a TCI state selected from a second one or more TCI states indicated by a second DCI received in CC2 (e.g., indicated by a TCI selection field of a third DCI); and / or according to example rule 3 ("TCI Reference CC"), the WTRU receives PDSCH3 in CC2 using a selected state TCI (e.g., indicated by the TCI selection field of the third DCI) from among a fourth one or more TCI states indicated by a fourth DCI received in a TCI Reference CC (e.g., CC3), which TCI Reference CC may be sent in a configuration message (e.g., by the base station) and / or may be determined by the WTRU (e.g., the lowest indexed CC configured for the WTRU).

[0232] The WTRU may report one or more WTRU capability parameters associated with carrier aggregation (CA) functionality, such as the maximum number of supported component carriers (CCs), the maximum number of supported primary cells (e.g., to support dual connectivity), the supported band combinations, whether a unified TCI framework is supported per CC (or CC group), and / or whether multi-TRP (mTRP) operation is supported per CC (or CC group).

[0233] The WTRU may receive a configuration of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) in a CC that are each applicable to multiple channels or signals in the CC and / or a second CC (e.g., provided that the reported WTRU capability parameter(s) included support for a unified TCI framework for the CC (or CC group). The multiple channels or signals associated with the TCI states may be sent to the WTRU in a configuration message or may be predetermined or defined (e.g., by higher layer signaling (e.g., RRC and / or MAC-CE) in the form of a list applicable to at least one CC).

[0234] The WTRU may receive in CC1 a first indication of a first one or more TCI states of a plurality of TCI states (e.g., via a TCI field in the first DCI) (e.g., a DL-DCI scheduling PDSCH1), and the WTRU may begin using the first one or more TCI states (e.g., at least in CC1 (e.g., as a default)) at time T1. Time T1 may be determined based on at least one of a reception timing of the first DCI, a reception timing of PDSCH1, a timing of an ACK transmission in response to receiving PDSCH1, and a beam application time (BAT) parameter (e.g., configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters).

[0235] The WTRU may receive a second indication of a second one or more TCI states of the plurality of TCI states in CC2 (e.g., via a TCI field in the second DCI) (e.g., a DL-DCI scheduling PDSCH2), and the WTRU begins using the second one or more TCI states (e.g., as a default, at least in CC2) at time T2. Time T2 may be determined based on at least one of the reception timing of the second DCI, the reception timing of PDSCH2, the timing of an ACK transmission in response to receiving PDSCH2, and BAT parameters (e.g., configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters).

[0236] In one case, there may be cross-carrier scheduling via DL-DCI. After at least T1 and / or T2 (e.g., for another example herein), the WTRU may receive a third DCI (e.g., DL-DCI) in CC1 using at least one of the first one or more TCI states, the third DCI indicating, notifying, and / or enabling the WTRU to perform an action, such as scheduling PDSCH3 to be transmitted in CC2 based on a carrier indicator (e.g., via a carrier indicator field, CIF) in the third DCI as cross-carrier scheduling, to the base station. and / or indicating (e.g., via a TCI field in the third DCI) a third TCI state or states among the plurality of TCI states, wherein the WTRU begins to use the third TCI state or states at time T3.

[0237] The CC decision rule may consist of at least one or more rules. In one example, Rule 1 (following "Scheduling CC") may indicate selecting a TCI in the CC on which a DCI is transmitted (e.g., by a TCI selection field of the DCI). On the condition that the WTRU applies (e.g., decides to apply) Rule 1, the WTRU may receive PDSCH3 in CC2 using a TCI selected (e.g., by a TCI selection field of a third DCI) from among the first one or more TCI states indicated by the first DCI in CC1. This may correspond to a cross-beam, or TCI, indication case or mode. CC1 may be (e.g., configured as) a reference or special CC with and / or coming unified TCI (e.g., to be applied to the same CC and / or other CCs). The WTRU may apply this Rule 1 in the condition of an in-band CC case, which may mean that CC1 and CC2 are in (e.g., are within) an in-band CC combination (e.g., configured in the WTRU). In one instance, applying the in-band CC condition may be because, in the in-band CC case, CC1 and CC2 may not be located too far from each other in the frequency domain, and therefore, selected TCI from CC1 may be applicable in CC2 (e.g., as a cross-beam indication, e.g., without performance loss in terms of beam mismatch). This may provide a benefit in that Rule 1 may not need to be explicitly configured in the WTRU.

[0238] In another example, Rule 2 (following "scheduled CC") may indicate selecting a TCI (e.g., by a TCI selection field of a DCI) in the CC on which a PDSCH (e.g., scheduled by a DCI) is transmitted (e.g., when the CIF indicates cross-carrier scheduling). On the condition that the WTRU applies (e.g., decides to apply) Rule 2, the WTRU may receive PDSCH3 using a TCI selected (e.g., by a TCI selection field of a third DCI) from among the second one or more TCI states indicated by the second DCI in CC2. The WTRU may apply this Rule 2 in the condition of an inter-band CC case, which may mean that CC1 and CC2 are in an inter-band CC combination (e.g., configured to the WTRU). For example, applying the inter-band CC condition may be because in the inter-band CC case, CC1 and CC2 may be located far away from each other in the frequency domain, and therefore, selected TCI from CC2 (e.g., rather than from CC1) to be applicable in CC2 may provide robustness in beam, or TCI, management. This may provide a benefit in that Rule 2 may not need to be explicitly configured in the WTRU.

[0239] In yet another example, Rule 3 (subject to "TCI Reference CC") may indicate selecting a TCI in a CC that is explicitly configured as a TCI Reference CC or implicitly determined (e.g., by a TCI selection field of a DCI) to be a predefined or predetermined CC (e.g., the lowest indexed CC configured for the WTRU). Conditional on the WTRU applying (e.g., deciding to apply) Rule 3, the WTRU may receive PDSCH3 using a TCI selected (e.g., by a TCI selection field of a third DCI) from among a fourth one or more TCI states indicated (e.g., via a TCI field of a DCI in a TCI Reference CC (e.g., CC3)).

[0240] In one case, there may be cross-carrier scheduling via UL-DCI. After at least T1 and / or T2, the WTRU may receive a fourth DCI (e.g., a UL-DCI) in CC1 using at least one of the first one or more TCI states, where the fourth DCI indicates, notifies, and / or enables the WTRU to perform an action, and the third DCI includes one or more of: scheduling a PUSCH to be transmitted in the CC (e.g., based on a carrier indicator (e.g., by a CIF)) in the fourth DCI as cross-carrier scheduling, and / or selecting a TCI from either the first one or more TCI states or the second one or more TCI states (e.g., by a UL-TCI selection field of the fourth DCI or one or more of existing DCI fields) based on a CC decision rule.

[0241] Provided that the WTRU applies (e.g., decides to apply) Rule 1 ("Follow Scheduling CC"), the WTRU may transmit a scheduled PUSCH in CC2 using a TCI selected (e.g., by the UL-TCI selection field of the fourth DCI or one or more of the existing DCI fields) from among the first one or more TCI states indicated by the first DCI in CC1. This may correspond to a cross-beam, or TCI, indication case or mode. CC1 may be (e.g., may be configured as) a reference or special CC on which a unified TCI is configured and / or comes (e.g., to be applied to the same CC and / or other CCs).

[0242] Provided that the WTRU applies (e.g., decides to apply) Rule 2 (following "scheduled CC"), the WTRU may transmit a scheduled PUSCH in CC2 using a TCI selected from the second one or more TCI states indicated by the second DCI in CC2 (e.g., by the UL-TCI selection field of the fourth DCI or one or more of the existing DCI fields).

[0243] Provided that the WTRU applies (e.g., decides to apply) Rule 3 (following the "TCI Reference CC"), the WTRU may transmit a scheduled PUSCH in CC2 using a TCI selected (e.g., by the UL-TCI selection field of the fourth DCI or one or more of the existing DCI fields) from among the fourth one or more TCI states indicated (e.g., via the TCI field of the DCI in the TCI Reference CC (e.g., CC3)).

[0244] In an example, the PDSCH default beam may be determined based on a UTCI selector in the DL-DCI. The WTRU may receive configurations of multiple transmission configuration indicator (TCI) states, such as unified TCI (UTCI) states, each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU in a configuration message, such as in the form of a list, or may be predetermined or defined by higher layer signaling (e.g., RRC and / or MAC-CE).

[0245] The WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may send a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0246] The WTRU may receive DCI2 using at least one of {TCI1, TCI2} (e.g., after sending the first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., a TCI field) of DCI2 and schedules PDSCH2. DCI2 may further indicate a selector via a second field (e.g., a TCI selection field), where the selector indicates one of the TCI states {TCI1, TCI2} indicated by DCI1.

[0247] The WTRU may receive PDSCH2 using a TCI state determined based on at least one of a selector indicated by DCI2, a time offset k0 between transmission (or reception) of DCI2 and transmission (or reception) of PDSCH2, a default TCI state, and / or a previously indicated TCI state. In an example, the value of k0 is indicated in DCI2. In an example, if the value of k0 is less than a threshold, the WTRU uses the default TCI state, TCI X, to receive PDSCH2. In an example, if the value of k0 is greater than a threshold, the WTRU uses the TCI state indicated by the selector to receive PDSCH2. In an example, the threshold is part of a WTRU capability parameter (e.g., reported to the gNB).

[0248] The WTRU may send a second ACK in response to receiving (e.g., successfully receiving) DCI 2 and / or PDSCH 2. In an example, after receiving PDSCH 2, the WTRU uses TCI 3 or TCI 4 to receive another PDSCH or PDCCH.

[0249] In some situations, there may be a default TCI state. In an example, the default TCI X may be or may be determined based on one or more factors, such as a previously selected TCI state (e.g., a recently selected TCI state) due to a TCI selection field in DCI3 (e.g., scheduling PDSCH3) received before DCI2, satisfying the condition that the WTRU sent an ACK for DCI3 or PDSCH3 (e.g., indicating successful reception of DCI3 or PDSCH3) at least a time period (e.g., a configured time period) before the transmission (or reception) of DCI2. The time period may be determined based on a beam application time (BAT) parameter configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters. Additionally / alternatively, the default TCI X may be or may be determined based on a default UTCI state, which may be TCI Y, associated with a CORESET with a predefined or preconfigured CORESET index, e.g., a UTCI associated with the CORESET with the lowest or highest ID.

[0250] In an example, the one or more UL beams may be determined based on the timing of several received indications / messages / configurations and / or based on a UTCI selector in the UL-DCI. The WTRU may receive configurations of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU (or may be pre-determined or defined) in a configuration message, such as in the form of a list, by higher layer signaling (e.g., RRC and / or MAC-CE).

[0251] The WTRU may receive a first indication of a first one or more TCI states (of a plurality of TCI states (e.g., via a TCI field in a first DCI (e.g., a DL-DCI that may schedule PDSCH1)), and the WTRU begins using the first one or more TCI states at time T1. Time T1 may be determined based on at least one of a reception timing of the first DCI, a reception timing of PDSCH1, a timing of an ACK transmission in response to receiving PDSCH1, and / or a beam application time (BAT) parameter (e.g., configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters).

[0252] After the first indication, the WTRU may receive a second indication of a second one or more TCI states (e.g., via a TCI field in a second DCI (e.g., a DL-DCI that may schedule PDSCH2)) of the plurality of TCI states, and the WTRU begins using the second one or more TCI states at time T2. Time T2 may be determined based on at least one of a reception timing of the second DCI, a reception timing of PDSCH2, a timing of an ACK transmission in response to receiving PDSCH2, and / or a BAT parameter.

[0253] The WTRU may receive an UL-DCI that schedules a PUSCH and selects a TCI to be applied to the scheduled PUSCH transmission from either the first one or more TCI states or the second one or more TCI states. The UL-DCI may include an UL-TCI selection field or one or more of existing DCI fields that select the TCI.

[0254] The WTRU may determine to apply either the first one or more TCI states or the second one or more TCI states based on at least one of the relationship between T1 and T2 (e.g., whether T1 < T2), when the WTRU receives UL-DCI with respect to T1 and T2 (e.g., whether the reception is between T1 and T2 or after T2), and / or when the WTRU transmits or is scheduled to transmit PUSCH (e.g., whether the transmission is between T1 and T2 or is scheduled to be so, or after T2 or is scheduled to be so).

[0255] The WTRU may transmit PUSCH using either the first one or more TCI states or the second one or more TCI states based on the determination.

[0256] In one exemplary scenario, the WTRU may apply (or determine to apply) either the first one or more TCI states or the second one or more TCI states based on the most recently used (e.g., started to be used) one before receiving UL-DCI. In one instance, the WTRU may select a TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU receives UL-DCI after T2. In another instance, the WTRU may select a TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU receives UL-DCI after T1 and before T2.

[0257] In one exemplary situation, the WTRU may apply (or determine to apply) the first one or more TCI states or the second one or more TCI states based on the most recently used (e.g., started being used) one before transmitting the PUSCH scheduled by the UL-DCI. In one example, the WTRU selects a TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T2. In another example, the WTRU may select a TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T1 and before T2.

[0258] In one exemplary scenario, the WTRU may apply (or determine to apply) the first one or more TCI states or the second one or more TCI states based on the most recently used (e.g., started being used) one at least a time offset before transmitting the PUSCH scheduled by the UL-DCI, the time offset being configured by the base station and / or reported by the WTRU as part of the WTRU capability parameters. In one example, the WTRU selects a TCI from among the second one or more TCI states indicated by a second DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T2 + the time offset. In one example, the WTRU may select a TCI from among the first one or more TCI states indicated by a first DCI on the condition that T1 < T2 and the WTRU transmits the PUSCH after T1 + the time offset and before T2 + the time offset.

[0259] In an example, there may be a UTCI deactivation mechanism in a multi-stage UTCI management framework. The WTRU may receive configurations of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be sent to the WTRU in a configuration message, such as in the form of a list, or may be predetermined or defined by higher layer signaling (e.g., RRC and / or MAC-CE).

[0260] The WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may send a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0261] The WTRU may receive DCI2 using at least one of {TCI1, TCI2} (e.g., after sending the first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., a TCI field) of DCI2 and schedules PDSCH2. DCI2 may further indicate a selector via a second field (e.g., a TCI selection field), where the selector indicates one of the TCI states {TCI1, TCI2} indicated by DCI1.

[0262] In response to receiving DCI2, the WTRU may determine that a TCI state different from the TCI state selected by the selector is the deactivated TCI state after a time offset (e.g., the WTRU may be configured to perform deactivation based on mode / operation (e.g., RRC signaling, etc.)). The time offset may be determined based on at least one of the reception timing of DCI2, the reception timing of PDSCH2, the timing of an ACK transmission in response to receiving PDSCH2, and / or a beam application time (BAT) parameter (e.g., configured from the base station and / or reported by the WTRU as part of the WTRU capability parameters). For example, if the selector indicates TCI1, the WTRU determines that TCI2 is the deactivated TCI after a time offset.

[0263] The WTRU may apply (or decide to apply) one or more actions based on the deactivated TCI, for example, the WTRU performs and / or reports measurements associated with one or more different parameters compared to measurements performed associated with the deactivated TCI at a different rate (e.g., longer periodicity) and / or reported when the TCI state was not deactivated (e.g., reported before the time offset). The WTRU may apply (or decide to apply) one or more actions based on the deactivated TCI, for example, the WTRU stops or discontinues quasi-co-location (QCL) tracking on the deactivated TCI (e.g., after the time offset), where QCL tracking may imply measurements on an RS associated with the TCI state (e.g., the deactivated TCI) and the derivation or estimation of at least one channel or signal property (e.g., average delay, delay spread, Doppler shift, Doppler spread, spatial Rx parameters, average power, etc.).

[0264] In an example, there may be cross-carrier scheduling based on a multi-stage UTCI management framework. The WTRU may receive configuration information indicating multiple TCI states.

[0265] The WTRU may receive a first indication of a first one or more TCI states of a plurality of TCI states in CC1 (e.g., via a TCI field in a first DCI (e.g., a DL-DCI scheduling PDSCH1)), and the WTRU begins using the first one or more TCI states (e.g., in at least CC1 (e.g., as a default)) at time T1.

[0266] The WTRU may receive a second indication of a second one or more TCI states of the plurality of TCI states in CC2 (e.g., via a TCI field in a second DCI (e.g., a DL-DCI scheduling PDSCH2)), and the WTRU begins using the second one or more TCI states (e.g., at least in CC2 (e.g., as a default)) at time T2.

[0267] After at least T1 and / or T2, the WTRU may receive a third DCI (e.g., a DL-DCI) in CC1 using at least one of the first one or more TCI states. The third DCI may provide one or more actions, which may trigger one or more actions. The third DCI may schedule PDSCH3 to be transmitted in CC2 (e.g., based on a carrier indicator (e.g., by a carrier indicator field, CIF) in the third DCI as cross-carrier scheduling). Additionally / alternatively, the third DCI may select a TCI state (e.g., by a TCI selection field of the third DCI) from among either the first one or more TCI states or the second one or more TCI states based on a CC decision rule, which may be explicitly configured by the base station and / or implicitly determined based on a rule or condition.

[0268] There may be one or more CC decision rules, and the rule to be used may be configured. For example, a first rule (following the "scheduling CC") may be where the WTRU receives PDSCH3 in CC2 using a selected TCI state (e.g., as indicated by a TCI selection field of a third DCI) from among the first one or more TCI states indicated by the first DCI received in CC1.

[0269] For example, the second rule (following "scheduled CC") may be when the WTRU receives PDSCH3 in CC2 using a TCI state selected from among the second one or more TCI states indicated by the second DCI received in CC2 (e.g., as indicated by the TCI selection field of the third DCI).

[0270] For example, a third rule (following "TCI Reference CC") may be that the WTRU receives PDSCH3 in CC2 using a state TCI selected (e.g., indicated by a TCI selection field of the third DCI) from among a fourth one or more TCI states indicated by a fourth DCI received in a TCI Reference CC (e.g., CC3), where the TCI Reference CC may be sent in a configuration message (e.g., by a base station) and / or determined by the WTRU (e.g., the lowest indexed CC configured for the WTRU).

[0271] Note that for the above rules, for the first rule, it follows the scheduling CC (e.g., CC1, the CC on which the DCI that schedules the PDSCH is transmitted) (e.g., the first TCI(s) are important). For the second rule, it follows the scheduled CC (e.g., CC2, the CC on which the PDSCH scheduled by the DCI is transmitted) (e.g., the second TCI(s) are important).

[0272] In an example, the device may determine the PDSCH default beam based on a previously selected TCI state (e.g., a recently selected TCI state) according to a TCI selection field in DCI3 received before DCI2 (e.g., scheduling PDSCH3), which satisfies the condition that the WTRU sent an ACK for DCI3 or PDSCH3 (e.g., indicating successful reception of DCI3 or PDSCH3) at least a time period (e.g., a configured time period) before the transmission (or reception) of DCI2.

[0273] In an example, the UL beam decision timeline may be based on a UTCI selector, e.g., the WTRU may apply or decide to apply the first TCI state(s) or the second TCI state(s) based on the one that most recently began to be used at least a time offset before transmitting the PUSCH scheduled by the UL-DCI.

[0274] In an example, there may be a UTCI deactivation mechanism, and the WTRU determines that a TCI state different from the TCI state selected by the selector is the deactivated TCI state. The WTRU may perform and / or report measurements associated with the deactivated TCI at a different rate (e.g., longer periodicity) and / or with one or more different parameters compared to measurements performed and / or reported when the TCI state is not deactivated.

[0275] In an example, there may be cross-carrier scheduling based on a UTCI selector. In one case, to comply with the "scheduling CC," the WTRU receives PDSCH3 in CC2 using a TCI state selected from a first one or more TCI states indicated by a first DCI received in CC1 (e.g., as indicated by a TCI selection field of a third DCI). In another case, to comply with the "scheduled CC," the WTRU receives PDSCH3 in CC2 using a TCI state selected from a second one or more TCI states indicated by a second DCI received in CC2 (e.g., as indicated by a TCI selection field of a third DCI).

[0276] 6 illustrates an example method in accordance with one or more techniques described herein. In this example, there may be a UTCI deactivation mechanism in a multi-stage UTCI management framework. At 601, a WTRU may receive configurations of multiple transmission configuration indicator (TCI) states (e.g., unified TCI (UTCI) states) each applicable to multiple channels or signals. The multiple channels or signals associated with the TCI states may be configured in the WTRU by higher layer signaling (e.g., RRC and / or MAC-CE), such as in the form of a list, or may be predetermined or defined.

[0277] At 602, the WTRU may receive DCI1, which indicates {TCI1, TCI2} via a first field (e.g., a TCI field) of DCI1, and schedule PDSCH1. The WTRU may transmit a first ACK in response to receiving (e.g., successfully receiving) DCI1 and / or PDSCH1.

[0278] At 603, the WTRU may receive DCI2 using at least one of {TCI1, TCI2} (e.g., after sending the first ACK), where DCI2 indicates {TCI3, TCI4} via a first field (e.g., a TCI field) of DCI2, and schedule PDSCH2. DCI2 may further indicate a selector via a second field (e.g., a TCI selection field), where the selector indicates one of the TCI states {TCI1, TCI2} indicated by DCI1.

[0279] In response to receiving DCI2, the WTRU may determine that a TCI state different from the TCI state selected by the selector is the deactivated TCI state after a time offset (e.g., the WTRU may be configured to perform deactivation based on mode / operation (e.g., RRC signaling, etc.)). The time offset may be determined based on at least one of the reception timing of DCI2, the reception timing of PDSCH2, the timing of an ACK transmission in response to receiving PDSCH2, and / or a beam application time (BAT) parameter (e.g., configured from the gNB and / or reported by the WTRU as part of the WTRU capability parameters). For example, if the selector selected TCI1, the WTRU determines that TCI2 is the deactivated TCI after a time offset.

[0280] At 604, the WTRU may apply (or decide to apply) one or more actions based on the deactivated TCI, for example, the WTRU performs and / or reports measurements associated with one or more different parameters compared to measurements performed associated with the deactivated TCI at a different rate (e.g., longer periodicity) and / or reported when the TCI state was not deactivated (e.g., reported before the time offset). The WTRU may apply (or decide to apply) one or more actions based on the deactivated TCI, for example, the WTRU stops or discontinues quasi-co-location (QCL) tracking on the deactivated TCI (e.g., after the time offset), where QCL tracking may imply measurements on an RS associated with the TCI state (e.g., the deactivated TCI) and the derivation or estimation of at least one channel or signal property (e.g., average delay, delay spread, Doppler shift, Doppler spread, spatial Rx parameters, average power, etc.).

[0281] FIG. 7 shows an example of a UTCI update timeline and UTCI selection. In this example, a WTRU may be in communication with or have established communication with a base station prior to 700. For example, at some point in time, the WTRU may receive a DCI at 701. Generally, the DCI (e.g., at 701) may include a 3-bit TCI field 705, and the DCI 701 may include a TCI selection field 709, or the DCI 701 may include both a TCI field and a selection field. Prior to 700, the WTRU may be configured with TCIs (e.g., TCI3 and TCI7, as shown in 713). At some point prior to 700, the WTRU may be configured with a list / index / set of TCIs (e.g., such as those shown in FIG. 2 or similar). After 700, the WTRU may receive DCI1 at 702. DCI1 may include an ordered set of TCI states (e.g., of multiple TCIs received in a previously configured list / index). At 703, the WTRU may receive DCI2, which may include a second ordered set of TCI states (e.g., TCI5 and TCI8) that differ from the previous ordered set. The second ordered set of TCI states may begin to apply after receiving PDSCH2 scheduled by DCI2 and sending an ACK for PDSCH2, and after BAT. At 704, the WTRU may receive DCI3 that schedules for PDSCH3. DCI3 may also include a TCI selection field, and in one case, the TCI state indicated by the TCI selection field may indicate at least one TCI state that differs from the default TCI state. The WTRU may determine that the default TCI state is the first ordered TCI state (e.g., TCI5) of the second ordered set of TCI states based on determining that the second ordered set has begun to apply. DCI3 may also include an indication of a time offset (e.g., k0 for PDSCH3). DCI3 may be received in a PDCCH transmission using at least one TCI state from the second ordered set of TCI states from DCI2.At some point after receiving DCI3, PDSCH3 may be received using a default TCI state. The WTRU may determine to receive PDSCH3 based on the default TCI state and the time offset (e.g., k0) being less than a threshold, and based on these one or more factors, the default TCI state may be determined to be the first TCI state indicated in the second ordered set of TCI states from DCI2.

[0282] 8 shows an example of TCI determination for use in transmission / reception. At 801, a WTRU may receive configuration information. At 802, the WTRU may receive first control information. At 803, the WTRU may receive second control information. At 804, the WTRU may perform an action based on one or more of the configuration information, the first control information, and / or the second control information. The action may include deactivating a TCI state, using one or more indicated TCI states, using a default TCI state (e.g., based on one or more other factors in combination with the control information), and / or another action disclosed herein.

[0283] As described herein, a higher layer may refer to one or more layers in a protocol stack or a specific sublayer within a protocol stack. A protocol stack may be composed of one or more layers in a WTRU or a network node (e.g., an eNB, a gNB, other functional entity, etc.), and each layer may have one or more sublayers. Each layer / sublayer may be responsible for one or more functions. Each layer / sublayer may communicate directly or indirectly with one or more of the other layers / sublayers. In some cases, these layers may be numbered as Layer 1, Layer 2, and Layer 3. For example, Layer 3 may be composed of one or more of a Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 may be composed of one or more of a Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Medium Access Control (MAC). For example, Layer 3 may be composed of physical (PHY) layer type operations. The higher the layer number, the higher it is relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the aforementioned examples may themselves be referred to as layers / sublayers regardless of the layer number and may be referred to as upper layers as described herein. For example, from highest to lowest, the upper layer may refer to one or more of the following layers / sublayers: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference herein to an upper layer in conjunction with a process, device, or system refers to a layer higher than the layer of the process, device, or system. In some cases, a reference herein to an upper layer may refer to a function or operation performed by one or more layers described herein. In some cases, a reference herein to an upper layer may refer to information sent or received by one or more layers described herein.In some cases, references herein to higher layers may refer to configurations sent and / or received by one or more layers described herein.

[0284] Although features and elements are described above in particular combinations (e.g., embodiments, methods, examples, etc.), those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. For example, as disclosed herein, there may be a method that is described in connection with figures for illustrative purposes, and those skilled in the art will appreciate that one or more features or elements from that method can be used alone or in combination with one or more features from another method described elsewhere. The symbol " / " (e.g., a slash) may be used herein to represent "and / or," e.g., "A / B" may imply "A and / or B." As used herein, "a" and "an" and similar phrases should be interpreted as "one or more" and "at least one." Similarly, any term ending in the suffix "(s)" should be interpreted as "one or more" and "at least one." The term "may" should be interpreted as "e.g., may" or to indicate that something "happens" or "is capable of happening." Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a wireless transmit / receive unit, comprising: receiving configuration information for a plurality of transmit configuration indicator (TCI) states; receiving first downlink control information (DCI), the first DCI indicating an ordered set of TCI states among the plurality of TCI states, the ordered set of TCI states including a first TCI state in a first order and a second TCI state in a second order, the first TCI state preceding the second TCI state; sending an ACK after receiving the first DCI; receiving a second DCI, the second DCI indicating a schedule of a PDSCH and a time offset of the PDSCH, the second DCI being received in a physical downlink control channel (PDCCH) transmission, the PDCCH transmission being received using at least one TCI state from the ordered set of TCI states; receiving the PDSCH using a TCI state and using the time offset, wherein the TCI state is determined to be a default TCI state based on the time offset being less than a threshold, the default TCI state being the first TCI state of the ordered set of TCI states, and the default TCI state is further based on a beam application time having elapsed after transmission of the ACK; A method comprising:

2. The method of claim 1 , wherein the second DCI further indicates a TCI state selector, the TCI state selector indicating at least one TCI state different from the default TCI state.

3. receiving a third DCI, the third DCI indicating a schedule of another PDSCH, a TCI selector, and a time offset of another PDSCH; receiving the other PDSCH using a different TCI state based on the other time offset being greater than the threshold, the other TCI state being determined from the other TCI selector; The method of claim 1 further comprising:

4. The method of claim 3 , wherein the alternative TCI state selector indicates both TCI states of an ordered set of alternative TCI states.

5. The method of claim 1 , wherein any TCI state corresponds to a beam for receiving or transmitting a signal.

6. 1. A wireless transmit receive unit (WTRU), comprising: means for receiving configuration information for a plurality of transmit configuration indicator (TCI) states; means for receiving first downlink control information (DCI), the first DCI indicating an ordered set of TCI states among the plurality of TCI states, the ordered set of TCI states including a first TCI state in a first order and a second TCI state in a second order, the first TCI state preceding the second TCI state; means for transmitting an ACK after receiving the first DCI; means for receiving a second DCI, the second DCI indicating a schedule of a PDSCH and a time offset of the PDSCH, the second DCI being received in a Physical Downlink Control Channel (PDCCH) transmission, the PDCCH transmission being received using at least one TCI state from the ordered set of TCI states; means for receiving the PDSCH using a TCI state and using the time offset, wherein the TCI state is determined to be a default TCI state based on the time offset being less than a threshold, the default TCI state being the first TCI state of the ordered set of TCI states, and the default TCI state is further based on a beam application time having elapsed after transmission of the ACK; A WTRU comprising:

7. The WTRU of claim 6 , wherein the second DCI further indicates a TCI state selector, the TCI state selector indicating at least one TCI state different from the default TCI state.

8. means for receiving a third DCI, the third DCI indicating a schedule of another PDSCH, a TCI selector, and a time offset of another PDSCH; means for receiving the other PDSCH using another TCI state based on the other time offset being greater than the threshold, the other TCI state being determined from the other TCI selector; The WTRU of claim 6, further comprising:

9. The WTRU of claim 8 , wherein the alternative TCI state selector indicates both TCI states of an ordered set of alternative TCI states.

10. The WTRU of claim 6 , wherein any TCI state corresponds to a beam for receiving or transmitting a signal.

Images