Method and apparatus for timeline management related to unified TCI display.

Abstract

Disclosed are methods, apparatus, and procedures for timeline management for transmission configuration indication in wireless communications. For example, the method, performed by a wireless transmit / receive unit (WTRU), includes receiving configuration information indicating a set of transmission configuration indicator (TCI) states, a beam application time (BAT), and a BAT offset, receiving downlink control information (DCI) indicating scheduling of a downlink data transmission and a TCI state from the set of TCI states, and transmitting a transmission using the indicated TCI state, the transmission being transmitted at a time offset associated with at least the BAT and / or the BAT offset after transmitting hybrid automatic repeat request (HARQ) feedback associated with the downlink data transmission.

Description

Technical Field

[0001] This application relates to a method and apparatus for timeline management for unified TCI display.

Background Art

[0002] Cross-reference to Related Applications This application claims the priority and benefit of U.S. Patent Provisional Application No. 63 / 411,475, filed with the United States Patent and Trademark Office on September 29, 2022, and U.S. Patent Provisional Application No. 63 / 465,747, filed with the United States Patent and Trademark Office on May 11, 2023, the entire contents of each of which are hereby incorporated by reference as if fully set forth herein in their entirety and for all applicable purposes.

[0003] In some cellular / wireless standards (e.g., 3GPP Release 16, Release 17, Release 18, and / or later), the continuous evolution of 5G New Radio (NR) may continue to optimize the management of wireless communication and enhance performance.

[0004] In 3GPP Release 17, a unified transmission configuration indicator (TCI) framework is supported. For example, a unified TCI (e.g., a joint or pair of separate DL / UL) may be shown and / or maintained to be applicable simultaneously to both control channels and / or data channels in a wireless transmit / receive unit (WTRU). This is different from per-channel individual beam control (e.g., up to 3GPP Release 16).

[0005] 3GPP Release 16 and / or 17 supports Multiple Transmit / Receive Points (MTRP). For example, multi-DCI based MTRP (MDCI-MTRP) supports eMBB based on CORESETPoolIndex=0 or 1. In another example, single-DCI based MTRP (SDCI-MTRP) is based on associating up to two TCI states with a code point in the TCI field of the DCI, enabling repeated transmissions across multiple TRPs for improved reliability.

[0006] In 3GPP Release 18, MIMO WID (Non-Patent Literature 1) captures one relevant aspect, which specifies an extension of the Rel-17 Unified TCI Framework to display multiple DL and UL TCI states, focusing on multi-TRP use cases, using the Rel-17 Unified TCI Framework. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] 3GPP RP-213598 [Overview of the project]

[0008] The embodiments disclosed herein generally relate to wireless and / or wired communication networks. One or more embodiments disclosed herein relate to methods, apparatus, and procedures for timeline management relating to TCI display in wireless communications (e.g., 5G NR networks).

[0009] In one embodiment, a method implemented by a wireless transmit / receive unit (WTRU) for wireless communication includes the steps of receiving configuration information indicating a set of transmission configuration indicator (TCI) states, beam application time (BAT), and BAT offset. The method includes scheduling a downlink data transmission and receiving downlink control information (DCI) indicating TCI states from the set of TCI states. The method also includes the step of transmitting a transmission using the indicated TCI states, wherein the transmission is transmitted at a time offset associated with at least the BAT and / or BAT offset, after transmitting hybrid automatic retransmission request (HARQ) feedback associated with the downlink data transmission.

[0010] In one embodiment, a method implemented by a wireless transmit / receive unit (WTRU) for wireless communication includes the step of receiving configuration information indicating a set of TCI states, a BAT, and a BAT offset. The method includes scheduling a downlink data transmission and receiving a DCI indicating a TCI state from the set of TCI states. The method also includes the step of receiving a transmission using the indicated TCI state, wherein the transmission is received at a time offset associated with at least the BAT and / or BAT offset after transmitting HARQ feedback associated with the downlink data transmission.

[0011] In one embodiment, a WTRU for wireless communication, comprising a circuit including a processor, a receiver, a transmitter, and a memory, is configured to: 1) receive configuration information indicating a set of TCI states, a BAT, and a BAT offset; 2) receive a DCI indicating a scheduling of downlink data transmissions and TCI states from the set of TCI states; and 3) transmit a transmission using the indicated TCI states, wherein the transmission is transmitted at a time offset associated with at least the BAT and / or the BAT offset after transmitting HARQ feedback associated with the downlink data transmission.

[0012] In one embodiment, a WTRU for wireless communication, comprising a processor, a receiver, a transmitter, and a memory, is configured to: 1) receive configuration information indicating a set of TCI states, a BAT, and a BAT offset; 2) receive a DCI indicating a scheduling of downlink data transmissions and TCI states from the set of TCI states; and 3) receive a transmission using the indicated TCI states, wherein the transmission is received at a time offset associated with at least the BAT and / or the BAT offset after sending HARQ feedback associated with the downlink data transmission.

[0013] In a typical embodiment, the WTRU consists of a beam application time (BAT) parameter and a paired / associated "Delta" offset parameter, where each of the BAT and "BAT plus Delta" may be associated with a list of channels / signals, which may be predefined, determined based on WTRU capability, and / or independently configurable by the network (e.g., gNB). In one example, the WTRU may consist of a BAT associated with a first list of channels / signals, and further consisting of a Delta, where BAT plus Delta may be associated with a second list of channels / signals. In one example, in response to receiving a control command (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a second time instance (T2) based on T1 and BAT (e.g., as T1+BAT or T1+Alpha+BAT), in this time instance, the WTRU may update (and / or begin using) the indicated at least one UTCI for a first list of channels / signals, but may not update the indicated at least one UTCI (in T2) for other channels / signals not included in the first list. In one example, the WTRU may determine a third time instance (T3) based on T1, BAT, and Delta (for example, as T1+BAT+Delta or T1+Alpha+BAT+Delta), in which time instance the WTRU may update (and begin using) at least one indicated UTCI for a second list of channels / signals, but may not update at least one indicated UTCI (in T3) for other channels / signals not included in the second list.

[0014] In a typical embodiment, the WTRU determines that the time offset is BAT if the channel (or signal) type is a first type of channel (or signal) or is included in a first set of channel (or signal) types (or based on that). The WTRU may determine that the time offset is BAT plus BAT offset if the channel or signal type is a second type of channel or signal or is included in a second set of channel or signal types. For example, the WTRU may determine that i) the first type of channel or signal is at least one of the data channels associated with SRS or CSI-RS (e.g., for channel acquisition) or low-latency related types (e.g., URLLC), and ii) the second type of channel or signal is at least one of the PUSCH, PDSCH, or control channels (e.g., CORESET, PDCCH, search space, or PUCCH). [Brief explanation of the drawing]

[0015] A more detailed understanding can be obtained from the following detailed explanation, which is provided as an example in conjunction with the attached drawings. The figures in such drawings, as well as the detailed explanation, are examples. Therefore, the drawings (figures) and detailed explanation should not be considered limiting, and other equally effective examples are possible and likely. Furthermore, similar reference numbers in the figures indicate similar elements.

[0016] [Figure 1A] This is a system diagram illustrating an exemplary communication system. [Figure 1B] Figure 1A is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown. [Figure 1C] Figure 1A is a system diagram showing exemplary radio access networks (RANs) and exemplary core networks (CNs) that may be used within the communication system shown. [Figure 1D]Figure 1A is a system diagram showing further exemplary RANs and further exemplary CNs that may be used within the communication system shown. [Figure 2] This figure shows an exemplary timeline using beam application time (BAT) or paired / associated offset parameter (Delta) for the indicated UTCI, according to one or more embodiments. [Figure 3] This figure shows an exemplary timeline for coherent joint transmission (CJT) operation using BAT or paired / associated offset parameters (Delta) according to one or more embodiments. [Figure 4] This figure shows a first example of a management procedure, which includes determining the type of channel or signal for wireless communication, according to one or more embodiments. [Figure 5] This figure shows a second example of a transmit / receive management procedure, which includes determining and using a time offset and channel or signal type for wireless communication, according to one or more embodiments. [Modes for carrying out the invention]

[0017] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or essentially described, disclosed, or otherwise provided herein (collectively "provided"). In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc., and / or any element thereof, performs, or is configured to perform, an operation, process, algorithm, function, etc., and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof, is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0018] Exemplary Communication Systems, Networks, and Devices

[0019] The methods, procedures, apparatuses, and systems provided herein are well-suited for communication including both wired and wireless networks. With respect to FIGS. 1A - 1D, an overview of various types of wireless devices and infrastructure is provided, and various elements of the network may utilize, execute, be arranged in accordance with, and / or be adapted and / or configured in accordance with the methods, apparatuses, and systems provided herein.

[0020] Figure 1A is a system diagram showing an exemplary 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, and broadcast to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content by sharing 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-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block-filtered OFDM, and filter bank multicarrier (FBMC).

[0021] As shown in FIG. 1A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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 may each be referred to as a “station” and / or “STA” and may be configured to transmit and / or receive wireless signals and may be a 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., a robot and / or other wireless devices operating in the context of an industrial and / or automated processing chain), a home electronic device, and devices operating in commercial and / or industrial wireless networks, among others (or may be any of them). Any of the WTRUs 102a, 102b, 102c, and 102d may optionally be referred to interchangeably as a UE.

[0022] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106 / 115, the Internet 110, and / or network 112. For example, base stations 114a and 114b may be any of the following: base station transceiver station (BTS), Node-B (NB), eNode-B (eNB), home Node-B (HNB), home eNode-B (HeNB), gNode-B (gNB), NR Node-B (NR NB), site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0023] Base station 114a may be part of RAN 104 / 113, 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), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be within the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell can provide coverage for a wireless service in a particular geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, which may utilize multiple transceivers for each sector of the cell or any sector. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0024] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via an 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).

[0025] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0026] In an embodiment, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Advanced UMTS Terrestrial Radio Access (E-UTRA) that can establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0027] In one embodiment, the base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0028] In embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base stations 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0029] In embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Global Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced High Speed ​​Data Rate (EDGE), and GSM EDGE (GERAN).

[0030] The base station 114b in Figure 1A can be, for example, a wireless router, home Node-B, home eNode-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), and roads. In embodiments, base stations 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In embodiments, base stations 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In embodiments, base stations 114b and WTRU 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a small cell, picocell, or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0031] RAN104 / 113 can communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, in addition to connecting to RAN104 / 113 which may be using NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0032] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using 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. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0033] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which can employ cellular-based radio technology, and base station 114b, which can employ IEEE 802 radio technology.

[0034] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while maintaining consistency with the embodiment.

[0035] The processor 118 could be a general-purpose processor, a dedicated 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) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can 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 a transceiver 120 that can be coupled to the transmit / receive element 122. Figure 1B shows the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together, for example, in an electronic package or chip.

[0036] The transmit / receive element 122 may be configured to transmit signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in an 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 signals, UV signals, or visible light signals. In an embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0037] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in embodiments, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0038] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0039] The processor 118 of the WTRU102 can be coupled to 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) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and can store data in those memories. 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. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information in memory located on a server or home computer (not shown) that is not physically located on the WTRU 102, and can store data in that memory.

[0040] The processor 118 can receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.), a solar cell, a fuel cell, etc.

[0041] 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 the information from the GPS chipset 136, the WTRU 102 may determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any suitable location determination method while maintaining consistency with the embodiment.

[0042] The processor 118 may be further coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, elements / 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, and the like. Elements / peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a compass 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, and / or a humidity sensor.

[0043] WTRU102 may include a full-duplex radio, and with respect to the full-duplex radio, the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., chokes) or via signal processing by a processor (e.g., by separate processors (not shown) or processor 118). In embodiments, WTRU102 may also include a half-duplex radio, and with respect to the half-duplex radio, the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception).

[0044] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 employs E-UTRA wireless technology and can communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 can also communicate with CN106.

[0045] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In the embodiment, eNode-B160a, 160b, and 160c can implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU102a.

[0046] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0047] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the above elements is shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] The MME162 may be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0049] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during eNode-B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0050] SGW164 may be connected to PGW166, which provides WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0051] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional land-line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0052] In Figures 1A to 1D, the WTRU is described as a wireless terminal; however, in certain representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).

[0053] In a typical embodiment, the other network 112 may be a WLAN.

[0054] 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 an interface to a distribution system (DS), or another type of wired / wireless network carrying traffic within and / or outside the BSS. Traffic originating outside the BSS to an STA may reach or be delivered to the STA via the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP for delivery to its respective destination. Traffic between STAs within the BSS may be sent via the AP; for example, a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode does not need to have an AP, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. Communication in IBSS mode is sometimes referred to as “ad-hoc” mode communication in this specification.

[0055] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel may have a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set by signaling. The primary channel may also be the operating channel of the BSS, which may be used by the STA to establish a connection with the AP. In a particular representative embodiment, for example in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. In CSMA / CA, the STA, including the AP (e.g., all STAs), can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that STA may backoff. One STA (e.g., only one station) can transmit at any given time on a given BSS.

[0056] High-throughput (HT) STAs can use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0057] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels may be formed by combining consecutive 20MHz channels. 160MHz channels may be formed by combining eight consecutive 20MHz channels or two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In an 80+80 configuration, data may, after channel coding, be passed through a segment parser that can 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 80MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation for the 80+80 configuration may be reversed, and the combined data may be sent to a medium access control (MAC) layer, entities, etc.

[0058] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidth and carrier are reduced compared 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 the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications (MTC), such as MTC devices in a macro-coverage area. MTC devices may have limited capabilities, including support for specific bandwidths and / or limited bandwidths (e.g., support for only that bandwidth). MTC devices may include batteries with above-a-threshold battery life (e.g., maintaining a very long battery life).

[0059] WLAN systems capable of supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the 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 the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may have a width of 1MHz for an STA (e.g., an MTC type device) that supports 1MHz mode (e.g., only supports 1MHz mode). Carrier detection and / or network assignment vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, for an STA (which only supports 1MHz operating mode) transmitting to an AP, the entire available frequency band may be considered busy, even if a large portion of the frequency band could remain idle and available.

[0060] In the United States, the available frequency band that may be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.

[0061] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 employs NR radio technology and can communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 can also communicate with CN115.

[0062] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In embodiments, gNB180a, 180b, and 180c can implement MIMO technology. For example, gNB180a and 180b can use beamforming to transmit signals to and / or receive signals from WTRU102a, 102b, and 102c. Thus, gNB180a can, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a. In embodiments, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on an unauthorized spectrum, and the remaining component carriers may be on an authorized spectrum. In embodiments, gNB180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0063] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary depending on different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (e.g., containing a varying number of OFDM symbols and / or lasting for varying lengths of absolute time).

[0064] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in an unauthorized band. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU102a, 102b, and 102c.

[0065] Each of the gNB180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, routing of control plane information to access and mobility management functions (AMF) 182a and 182b, etc. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0066] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and at least one Data Network (DN)185a, 185b. While each of the above elements is shown as part of CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established depending on different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on extended capacity mobile broadband (eMBB) access, and / or services for MTC access. The AMF162 can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0068] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0069] UPF184a and 184b may be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of downlink packets, and providing mobility anchoring.

[0070] CN115 can facilitate communication with other networks. For example, CN115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. CN115 can also provide WTRU102a,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 embodiments, WTRU102a,102b,102c may be connected to DN185a,185b via UPF184a,184b through an N3 interface to UPF184a,184b, and an N6 interface between UPF184a,184b and local data networks (DNs) 185a,185b.

[0071] In view of Figures 1A to 1D and their corresponding descriptions, one or more or all of the functions described herein may be performed by one or more emulation elements / devices (not shown) with respect to any of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b and / or any other elements / devices described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0072] Emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or carrier network environment. For example, one or more emulation devices may perform one, more or all of the functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in a communication network. One or more emulation devices may perform one, more or all of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for testing and / or may perform testing using wireless communication.

[0073] One or more emulation devices may perform one or more functions, including all of the above, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used 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 also be test equipment. Wireless communication via direct RF coupling and / or RF circuitry (e.g., including one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0074] Introduction

[0075] The 3GPP Release 17 (Rel-17) Unified TCI Framework supports a single Unified TCI (e.g., a joint or pair of separate DL / ULs) that can be demonstrated and maintained to be simultaneously applicable to both control and data channels in a WTRU (or UE), which differs from individual beam controls per channel (e.g., up to 3GPP Rel-16).

[0076] 3GPP Rel-16 or Rel-17 supports multiple transmit / receive points (MTRP). For example, multi-DCI based MTRP (MDCI-MTRP) supports eMBB based on CORESETPoollndex=0 or 1. In another example, single-DCI based MTRP (SDCI-MTRP) is based on associating up to two TCI states with a code point in the TCI field of the DCI, enabling repeated transmission across multiple TRPs for improved reliability.

[0077] In 3GPP Release 18, MIMO WID (e.g., Non-Patent Document 1) captures one relevant aspect, which here specifies an extension of the Rel-17 Unified TCI Framework to focus on multi-TRP use cases and to display multiple DL and UL TCI states using the Rel-17 Unified TCI Framework.

[0078] The ongoing evolution of 5G New Radio (NR) has the potential to continue optimizing and enhancing the performance of wireless communication management. Therefore, it is desirable to 1) improve the Unified TCI application timeline to account for latency-sensitive channels / signals, 2) improve the robustness of Unified TCI updates in the event of reception errors at WTRUs receiving Unified TCI, and / or 3) improve the accuracy and performance of Coherent Joint Transmit (CJT) based operations in accordance with or using Unified TCI updates.

[0079] In the following, “a” and “an” and similar phrases are interpreted as “one or more” and “at least one.” Similarly, terms ending in the suffix “(s)” are interpreted as “one or more” and “at least one.” The term “may” is interpreted as “for example, may.” The forward slash “ / ” is interpreted as “and / or” unless otherwise specified; for example, “A / B” may mean “A and / or B.”

[0080] overview

[0081] beam

[0082] In various embodiments, the WTRU can transmit or receive a physical channel or reference signal according to at least one spatial domain filter. The term "beam" may be used to refer to the spatial domain filter.

[0083] The WTRU can transmit a physical channel or signal using the same spatial domain filter used to receive a reference signal (RS) (e.g., channel status information (CSI)-RS) or synchronization signal (SS) block. A WTRU transmission may be referred to as a "target," and the received RS or SS block may be referred to as a "reference" or "source." In such cases, the WTRU may be considered to transmit the target's physical channel or signal by referencing such an RS or SS block, according to its spatial relationship.

[0084] A WTRU may transmit a first physical channel or signal according to the same spatial domain filter 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 considered to transmit the first (target) physical channel or signal according to a spatial relationship with respect to the second (reference) physical channel or signal.

[0085] Spatial relationships may be implicit, constituted by radio resource control (RRC) messages, or signaled by MAC control elements (CE) or downlink control information (DCI). For example, a WTRU may implicitly transmit PUSCH and PUSCH's DM-RS according to the same spatial domain filter as the sounding reference signal (SRS) indicated by an SRS resource indicator (SRI) indicated by a DCI or constituted by an RRC. In another example, a spatial relationship may be constituted by an RRC for an SRI, or signaled by a MAC CE for PUCCH. Such spatial relationships are sometimes referred to as "beam indications."

[0086] A WTRU can receive a first (target) downlink channel or signal according to the same spatial domain filter or spatial receive parameters as the 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 demodulated reference signal (DM-RS). Such an association may exist when the WTRU is configured with a quasi-colocation (QCL) assumption of type D between the corresponding antenna ports, provided that at least the first and second signals are reference signals. Such an association may be configured as a Transmission Configuration Indicator (TCI) state. The WTRU may indicate an association between a CSI-RS or SS block and a DM-RS by indexing to a set of TCI states configured by the RRC and / or signaled by the MAC CE. Such an indication is sometimes called a "beam indication".

[0087] unified TCI

[0088] A unified TCI (e.g., common TCI, common beam, common RS, etc.) may refer to a beam / RS used (simultaneously) for multiple physical channels / signals. The term "TCI" may include at least a TCI state that includes at least one source RS to provide a criterion (e.g., a WTRU assumption) for determining the QCL and / or spatial filter.

[0089] In one example, the WTRU may receive (e.g., from a gNB) a representation of a first unified TCI used / applied to both the downlink control channel (PDCCH) and the downlink shared channel (PDSCH) (e.g., further downlink RS). The source reference signal in the first unified TCI can provide common QCL information for at least the WTRU-dedicated reception on the PDSCH and all (or some) of the CORESET in the CC. In another example, the WTRU may receive (e.g., from a gNB) a representation of a second unified TCI used / applied to both the uplink control channel (PUCCH) and the uplink shared channel (PUSCH) (e.g., further uplink RS). The source reference signal in the second unified TCI can provide a reference for determining a common UL Tx spatial filter for at least the dynamic grant / configured grant-based PUSCH and all (or some) of the dedicated PUCCH resources in the CC.

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

[0091] For example, a WTRU may receive (e.g., from a gNB) a second unified TCI designation that is commonly used / applicable to PDCCH, PDSCH, PUCCH, and PUSCH (as well as DL RS and / or UL RS).

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

[0093] A WTRU can determine the TCI states applicable to a transmit or receive by first determining the unified TCI state instance applicable to that transmit or receive, and then determining the TCI states corresponding to the unified TCI state instance. A transmit may consist of at least PUCCH, PUSCH, and SRS. A receive may consist of at least PDCCH, PDSCH, and CSI-RS. A unified TCI state instance may also be called 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. A unified TCI state instance is equivalent to, or can be identified by, Coreset pool identification information (e.g., CORESETPoolIndex and / or TRP indicator).

[0094] A Unified TCI can be used interchangeably with one or more of the Unified TCI State, Unified TCI Instance, TCI, and TCI State, while still being consistent with the present invention.

[0095] TRP, MTRP, M-TRP

[0096] A transmit and receive point (TRP) can be used interchangeably with one or more of the transmit point (TP), receive point (RP), radio remote head (RRH), distributed antenna (DA), base station (BS), sector (of the BS), and cell (e.g., geographic cell area served by the BS), but is still consistent with the present invention. A multi-TRP can be used interchangeably with one or more of the MTRP, M-TRP, and multiple TRP, but is still consistent with the present invention.

[0097] Configuration of TRP, SRI, and / or Path Loss (PL) Reference Signals

[0098] A WTRU may consist of one or more TRPs that can be the destination and / or the source of a WTRU (or may receive a configuration of such TRPs). A WTRU may consist of one or more TRPs for one or more cells. A cell may be a serving cell or a secondary cell.

[0099] A WTRU may consist of at least one RS intended for channel measurement. This RS may be identified as a Channel Measurement Resource (CMR) and may include CSI-RS, SSB, and / or other downlink RS transmitted from a TRP to the WTRU. A CMR may consist of or be associated with a TCI state. A WTRU may consist of a group of CMRs that may constitute CMRs transmitted from the same TRP. Each group may be identified by a CMR group index (e.g., Group 1). A WTRU may consist of one CMR group per TRP, and a WTRU may receive links 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.

[0100] A WTRU may consist of (or receive) one or more path loss (PL) criterion groups (e.g., sets) and / or one or more SRS groups, SRS resource indicators (SRIs), or SRS resource sets.

[0101] A PL criterion group may correspond to or be associated with a TRP. A PL criterion group may include, identify, correspond to, or be associated with one or more TCI states, SRIs, reference signal sets (e.g., CSI-RS set, SRI set), CORESET indices, and / or reference signals (e.g., CSI-RS, SSB).

[0102] A WTRU may receive configurations (e.g., any configurations described herein). Configurations may be received from gNBs or TRPs. For example, a WTRU may receive configurations for one or more TRPs, one or more PL criteria groups, and / or one or more SRI sets. A WTRU may implicitly determine the association between RS sets / groups and TRPs. For example, if a WTRU consists of two SRS resource sets, the WTRU may decide to send to TRP1 for the SRS in the first resource set and to TRP2 for the SRS in the second resource set. Configurations may be received via RRC signaling.

[0103] In the examples and embodiments described herein, TRP, PL criterion group, SRI group, and / or SRI set may be used interchangeably. The terms set and group may be used interchangeably herein.

[0104] CSI Components

[0105] A WTRU may report a subset of Channel Status Information (CSI) components, where the CSI components may correspond to at least the CSI-RS Resource Indicator (CRI), SSB Resource Indicator (SSBRI), the display of the panel used for reception in the WTRU (such as panel identification information or group identification information), measured values ​​such as L1-RSRP and L1-SINR obtained from SSB or CSI-RS (e.g., cri-RSRP, cri-SINR, ssb-Index-RSRP, ssb-Index-SINR), and other channel status information such as at least the Rank Indicator (RI), Channel Quality Indicator (CQI), Precoding Matrix Indicator (PMI), and / or Layer Index (LI).

[0106] Grant or allocation characteristics

[0107] The characteristics of a grant or allocation may include at least one of the following: frequency allocation, time allocation mode (e.g., duration), priority, modulation and coding scheme, transport block size (TBS), 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 configured grant type 1, type 2, or dynamic grant, whether the allocation is a dynamic allocation or a semi-persistent scheduling (configured) allocation, configured grant index or semi-persistent allocation index, periodicity of the configured grant or allocation, channel access priority class (CAPC), and / or any parameters provided in DCI, MAC, or RRC for scheduling the grant or allocation.

[0108] A DCI representation may include at least one of the following: 1) an explicit representation by a DCI field or by an RNTI used to mask the CRC of a PDCCH, and / or 2) an implicit representation by properties such as the DCI format, DCI size, Coreset or search space, aggregation level, and the first resource element of the received DCI (e.g., the index of the first control channel element), where the mapping between properties and values ​​may be signaled by an RRC message or a MAC (e.g., MAC CE) message.

[0109] The signal may be used interchangeably with one or more of the following: sounding reference signal (SRS), channel status information-reference signal (CSI-RS), demodulation reference signal (DM-RS), phase tracking reference signal (PT-RS), and / or synchronization signal block (SSB).

[0110] The channel may be used interchangeably with one or more of the following: physical downlink control channel (PDCCH), physical downlink sharing channel (PDSCH), physical uplink control channel (PUCCH), physical uplink sharing channel (PUSCH), and physical random access channel (PRACH).

[0111] Downlink reception can be used interchangeably with reception (Rx) opportunities, PDCCH, PDSCH, and SSB reception, but is still consistent with the present invention.

[0112] Uplink transmission can be used interchangeably with transmission (Tx) opportunities, PUCCH, PUSCH, PRACH, and SRS transmission, but is still consistent with the present invention.

[0113] RS can be used interchangeably with one or more of RS resources, RS resource sets, RS ports, and / or RS port groups, while still being consistent with the present invention. RS can also be used interchangeably with one or more of SSB, CSI-RS, SRS, and / or DM-RS, while still being consistent with the present invention.

[0114] Time instances can be used interchangeably with slots, symbols, and subframes, but are still consistent with the present invention.

[0115] Typical procedures for channel / signal-specific UTCI timelines

[0116] In one embodiment, the WTRU may consist of one or more parameters of the beam application time (BAT), each of which may be associated with a list of channels / signals, the list of channels / signals may be predefined and / or determined based on WTRU capability and / or comprised (e.g., independently comprised) of a network (e.g., gNB).

[0117] For example, referring to Figure 2, a timeline is provided using one or more BATs (e.g., BAT1 and / or BAT2) or paired / associated offset parameters (Delta) for the given UTCI. In this example, the association may be provided by higher-layer signaling (e.g., RRC and / or MAC-CE) if the association is configured by gNB. In this example, the WTRU may consist of a first BAT (BAT1) associated with a first list of channels / signals, and a second BAT (BAT2) associated with a second list of channels / signals. One or more of the following operations may apply:

[0118] A BAT1 (for example, shorter than BAT2) may consist of one or more delay-sensitive channels / signals (e.g., at least part of a first list of channels / signals). For example, the first list of channels / signals may include a first group of CORESETs, a first group of CSI-RSs, a first group of PUCCH resources, a first set of PDSCHs (e.g., excluding CJT-PDSCHs), a first set of PUSCHs (e.g., excluding STxMP PUSCHs), and / or CJT-CSI-RS or SRS (e.g., for channel interoperability). The first set of one or more PDSCHs may include PDSCHs that carry delay-sensitive (e.g., delay-sensitive) packet-type data (e.g., URLLC packets) (e.g., PDSCHs scheduled by higher layers, such as semi-persistent scheduling (SPS)-PDSCHs or dynamic grant-based PDSCHs). A first set of one or more PUSCHs may include PUSCHs that carry delay-sensitive (e.g., delay-sensitive) packet-type data transmissions from a WTRU (e.g., for URLLC) (e.g., PUSCHs scheduled by higher layers, such as configured-grant (CG)-PUSCHs or dynamic grant-based PUSCHs).

[0119] In response to receiving control commands / messages (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a second time instance (T2) based on T1 and BAT1 (e.g., as T1+BAT1 or T1+Alpha+BAT1), in this time instance, the WTRU may update (and begin using) the indicated at least one UTCI for a first list of channels / signals, but may not update the indicated at least one UTCI (in T2) for other channels / signals not included in the first list.

[0120] In one example, "Alpha" may include a first duration between T1 and the PDSCH receive time instance (where, when the PDSCH is scheduled by DCI, the WTRU may receive the PDSCH using a previous UTCI (e.g., currently in use, previously used) independent of at least one indicated UTCI).

[0121] In one example, "Alpha" may include a second duration, in addition to the first duration, between the PDSCH receive time instance and the corresponding ACK transmit time instance, where the corresponding ACK transmit may be performed based on a PUCCH resource (e.g., for HARQ-ACK) that can carry information about whether the PDSCH was successfully received at the WTRU and / or whether at least one indicated UTCI was successfully received at the WTRU.

[0122] BAT2 (for example, longer than BAT1) may be configured for a second set of channels / signals, which may be less sensitive / less sensitive to delay and / or used as a “recoverable” backup channel before falling into a Beam Fault Recovery (BFR) procedure or Radio Link Recovery (RLM / RLF) procedure and / or require more CSI acquisition time when receiving a DCI indicating at least one UTCI. The second set of channels / signals may be at least part of a list of second channels / signals. For example, the second list of channels / signals may include a second group of CORESETs, a second group of CSI-RSs, a second group of PUCCH resources, CJT-PDSCHs (for example, for the required CSI acquisition time), a second set of one or more PDSCHs, an STxMP PUSCH (for having SRS-based acquisition time for STxMP), and / or a second set of one or more PUSCHs, etc. A second set of one or more PDSCHs may include PDSCHs that carry data of packet types that are not so sensitive to latency (e.g., eMBB packets) (e.g., PDSCHs scheduled by a higher layer, such as semi-persistent scheduling (SPS)-PDSCHs or dynamic grant-based PDSCHs). A second set of one or more PUSCHs may include PUSCHs that carry data transmission of packet types that are not so sensitive to latency (e.g., for eMBBs) from the WTRU (e.g., PUSCHs scheduled by a higher layer, such as configuration grant (CG)-PUSCHs or dynamic grant-based PUSCHs).

[0123] In response to receiving control commands / messages (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a third time instance (T3) based on T1 and BAT2 (e.g., as T1+BAT2 or T1+Alpha+BAT2), in this time instance, the WTRU may update (and begin using) the indicated at least one UTCI for a second list of channels / signals, but may not update the indicated at least one UTCI (in T3) for other channels / signals not included in the second list.

[0124] In one example, "Alpha" may include a first duration between T1 and the PDSCH receive time instance (where, when the PDSCH is scheduled by DCI, the WTRU may receive the PDSCH using a previous UTCI (e.g., currently in use, previously used) independent of at least one indicated UTCI).

[0125] In one example, "Alpha" may include a second duration, in addition to the first duration, between the PDSCH receive time instance and the corresponding ACK transmit time instance, where the corresponding ACK transmit may be performed based on a PUCCH resource (e.g., for HARQ-ACK) that can carry information about whether the PDSCH was successfully received at the WTRU and / or whether at least one indicated UTCI was successfully received at the WTRU.

[0126] A WTRU can transmit a WTRU capability report that may include WTRU capability components / elements associated with BAT1, where the WTRU can report its supported (e.g., implemented) application time (e.g., the duration required by the hardware / software implementation to update / apply at least one UTCI when received by DCI). Based on receiving this WTRU capability report from the WTRU, the gNB can configure (or indicate) the parameters of BAT1 to the WTRU (e.g., for confirmation based at least on the receipt of the WTRU capability report). In response to receiving the parameters / values ​​of BAT1, the WTRU can use BAT1 (e.g., shorter than BAT2) based on at least one embodiment presented in this disclosure. In one example, BAT2 may not be based on the WTRU capability report. The WTRU can receive BAT2 and decide to use / apply BAT2 to a particular set of channels / signals that may correspond to a second list of channels / signals. Even if a WTRU determines that BAT2 is not based on WTRU capability reporting (e.g., its supported enforcement time for updating / applying at least one UTCI when received by DCI), the WTRU may be configured (or indicated) to use / apply BAT2.

[0127] BAT2 may be dynamically updated from the gNB to the WTRU, for example via MAC-CE and / or DCI, which can offer the advantage that BAT2 can be a controllable parameter for a particular set of channels / signals without being based on WTRU capabilities.

[0128] The list of channels / signals associated with BAT1 may be mutually exclusive with the list of channels / signals associated with BAT2.

[0129] The list of channels / signals associated with BAT1 and BAT2 may vary based on the availability of channel state information in gNB for the given UTCI.

[0130] If a WTRU reports a CSI associated with a UTCI within a time window prior to receiving the indicated UTCI, or if the WTRU recognizes that a gNB has CSI information associated with the indicated UTCI, BAT2 may be updated to have the same value as BAT1 (e.g., BAT2 = BAT1). In some cases, the time window may be predetermined, configured, or indicated by the gNB.

[0131] In one embodiment, the WTRU may consist of a BAT (e.g., parameters of the BAT) and a paired / associated "Delta" offset parameter, each of which the BAT and "BAT plus Delta" may be associated with a list of channels / signals, which may be predefined, determined based on WTRU capability, and / or constituted (independently constituted) by a gNB (e.g., shown in Figure 2). If the association is constituted by a gNB, the association may be given by higher-layer signaling (e.g., RRC and / or MAC-CE). In one example, the WTRU may consist of a BAT associated with a first list of channels / signals, and further consist of a Delta, where the BAT plus Delta may be associated with a second list of channels / signals. One or more of the following operations may apply:

[0132] A BAT may be used / applied to one or more delay-sensitive channels / signals (e.g., at least part of a first list of channels / signals). For example, the first list of channels / signals may include a first group of CORESETs, a first group of CSI-RSs, a first group of PUCCH resources, a first set of one or more PDSCHs (e.g., other than CJT-PDSCHs), a first set of one or more PUSCHs (e.g., other than STxMP PUSCHs), and / or CJT-CSI-RS or SRS (e.g., for channel interoperability). The first set of one or more PDSCHs may include PDSCHs that carry delay-sensitive (e.g., delay-sensitive) packet-type data (e.g., URLLC packets) (e.g., PDSCHs scheduled by higher layers such as semi-persistent scheduling (SPS)-PDSCHs or dynamic grant-based PDSCHs). A first set of one or more PUSCHs may include PUSCHs that carry delay-sensitive (e.g., delay-sensitive) packet-type data transmissions from a WTRU (e.g., for URLLC) (e.g., PUSCHs scheduled by higher layers, such as configuration grant (CG)-PUSCHs or dynamic grant-based PUSCHs).

[0133] In response to receiving a control command / message (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a second time instance (T2) based on T1 and BAT (e.g., as T1+BAT or T1+Alpha+BAT), in this time instance, the WTRU may update (and begin using) the indicated at least one UTCI for a first list of channels / signals, but may not update the indicated at least one UTCI (in T2) for other channels / signals not included in the first list.

[0134] In one example, "Alpha" may include a first duration between T1 and the PDSCH receive time instance (where, when the PDSCH is scheduled by DCI, the WTRU may receive the PDSCH using a previous UTCI (e.g., currently in use, previously used) independent of at least one indicated UTCI).

[0135] In one example, "Alpha" may include a second duration, in addition to the first duration, between the PDSCH receive time instance and the corresponding ACK transmit time instance, where the corresponding ACK transmit may be performed based on a PUCCH resource (e.g., for HARQ-ACK) that can carry information about whether the PDSCH was successfully received at the WTRU and / or whether at least one indicated UTCI was successfully received at the WTRU.

[0136] BAT plus Delta may be used / applied to a second set of channels / signals, which may be less sensitive / less sensitive to delay and / or used as a “recoverable” backup channel before falling into a Beam Fault Recovery (BFR) procedure or Radio Link Recovery (RLM) procedure, and / or require more CSI acquisition time when receiving a DCI indicating at least one UTCI. The second set of channels / signals may be at least part of a second list of channels / signals. For example, the second list of channels / signals may include a second group of CORESETs, a second group of CSI-RSs, a second group of PUCCH resources, CJT-PDSCHs (for example, due to the required CSI acquisition time), a second set of one or more PDSCHs, an STxMP PUSCH (for having SRS-based acquisition time for STxMP), and / or a second set of one or more PUSCHs, etc. A second set of one or more PDSCHs may include PDSCHs that carry data of packet types that are not so sensitive to latency (e.g., eMBB packets) (e.g., PDSCHs scheduled by a higher layer, such as semi-persistent scheduling (SPS)-PDSCHs or dynamic grant-based PDSCHs). A second set of one or more PDSCHs may include PUSCHs that carry data transmission of packet types that are not so sensitive to latency (e.g., for eMBB) from the WTRU (e.g., PUSCHs scheduled by a higher layer, such as configuration grant (CG)-PUSCHs or dynamic grant-based PUSCHs).

[0137] In response to receiving a control command / message (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a third time instance (T3) based on T1, BAT, and Delta (e.g., as T1+BAT+Delta or T1+Alpha+BAT+Delta), in this time instance, the WTRU may update (and begin using) the indicated at least one UTCI for a second list of channels / signals, but may not update the indicated at least one UTCI (in T3) for other channels / signals not included in the second list.

[0138] In one example, "Alpha" may include a first duration between T1 and the PDSCH receive time instance (where, when the PDSCH is scheduled by DCI, the WTRU may receive the PDSCH using a previous UTCI (e.g., currently in use, previously used) independent of at least one indicated UTCI).

[0139] In one example, "Alpha" may include a second duration, in addition to the first duration, between the PDSCH receive time instance and the corresponding ACK transmit time instance, where the corresponding ACK transmit may be performed based on a PUCCH resource (e.g., for HARQ-ACK) that can carry information about whether the PDSCH was successfully received at the WTRU and / or whether at least one indicated UTCI was successfully received at the WTRU.

[0140] A WTRU may transmit a WTRU capability report that may include WTRU capability components / elements associated with a BAT, where the WTRU may report its supported (e.g., implemented) application time (e.g., the duration required by the hardware / software implementation to update / apply at least one UTCI when received by the DCI). Based on receiving this WTRU capability report from the WTRU, the gNB may configure (or indicate) the parameters of the BAT to the WTRU (e.g., for confirmation based on the receipt of the WTRU capability report). In response to receiving the parameters / values ​​of the BAT, the WTRU may use the BAT based on at least one embodiment presented in this disclosure. For example, Delta may not be based on the WTRU capability report. The WTRU may receive the value of Delta and decide to use / apply the BAT plus Delta for a particular set of channels / signals that may correspond to a second list of channels / signals. Even if a WTRU decides that Delta is not based on WTRU capability reporting (e.g., its supported application time for updating / applying at least one UTCI when received by DCI), the WTRU may be configured (or indicated) to use / apply BAT plus Delta.

[0141] Delta may be dynamically updated from the gNB to the WTRU, for example via MAC-CE and / or DCI, which can offer the advantage that Delta can be a controllable parameter for a particular set of channels / signals without being based on WTRU capabilities.

[0142] The list of channels / signals associated with BAT may be mutually exclusive with the list of channels / signals associated with BAT plus Delta.

[0143] The list of channels / signals associated with BAT and BAT plus Delta may vary based on the availability of channel state information in the gNB for the given UTCI.

[0144] If a WTRU reports a CSI associated with a UTCI within a time window prior to receiving the indicated UTCI, or if the WTRU recognizes that the gNB has CSI information associated with the indicated UTCI, Delta may be updated to have a value of "0" (e.g., Delta=0). In some cases, the time window may be predetermined, configured, or indicated by the gNB.

[0145] In one embodiment, referring to Figure 3, a timeline is provided that uses BATs (e.g., BAT1 and / or BAT2) or paired / associated offset parameters (Delta) for coherent joint transmission (CJT) operation.

[0146] For example, the first list of channels / signals may include at least one or more CSI-RS resources that can be indicated by CJT-CSI-RS resources (e.g., tagged for the use of Coherent Joint Transmit (CJT) operation and enabled for WTRU, e.g.), and the second list of channels / signals may include at least PDSCHs scheduled for CJT operation that can be indicated by CJT-PDSCH. This can provide the advantage of improving the accuracy and performance of the CJT operation by providing a CSI capture time duration between the first time instance indicated by BAT1 (or BAT) and the second time instance indicated by BAT2 (or BAT plus Delta). In one example, up to Q TRPs may be taken into consideration for the CJT operation, e.g., Q=4. The WTRU can receive a DCI indicating at least one UTCI (e.g., in the case of two UTCIs, UTCI1 corresponds to the first TRP out of Q TRPs, and UTCI2 corresponds to the second TRP out of Q TRPs). The first TRP may be one of TRP indices 1, 2, 3, and 4, and the second TRP may be one of TRP indices 1, 2, 3, and 4, and may be different from the first TRP. This TRP selection mechanism may be contained in a DCI-based representation that shows at least one UTCI from the perspective of CJT operation. In a first time instance, the WTRU may determine that UTCI1 is applied on a first CSI-RS resource (for CJT operation) and UTCI2 is applied on a second CSI-RS resource (for CJT operation). Based on this determination, the WTRU may measure the first CSI-RS resource using UTCI1 and measure the second CSI-RS resource using UTCI2, and based on these measurements, it may send one or more CSI reports (for CJT operation).The WTRU may receive a PDSCH (e.g., CJT-PDSCH) in a second time instance or thereafter, and the PDSCH (e.g., CJT-PDSCH) may be scheduled based on one or more CSI reports received by the gNB (e.g., as shown in Figure 3).

[0147] In one embodiment, an example of a timeline management procedure is provided, as shown in Figure 4. In this example, the timeline management procedure may include determining the type of channel (or signal) for wireless communication (for example, using TCI display).

[0148] Referring to Figure 4, for example, a WTRU may receive configuration information indicating a set of TCI states, a BAT, and / or a BAT offset (e.g., Delta) from (e.g., a gNB, a second WTRU, another WTRU for sidelink communication, or another transmitter or node). The WTRU may schedule a PDSCH and receive a first DCI indicating a first TCI state from the set of TCI states. After sending an ACK associated with receiving the PDSCH transmission, the WTRU may apply the indicated first TCI state to the transmission (or reception) of a channel or signal (e.g., a scheduled, configured, or indicated channel or signal) if the channel or signal is transmitted (or received) at a time offset (or using at least a time offset, or one or more time offsets).

[0149] For example, a WTRU may determine that the time offset is BAT if the channel or signal type is a first type of channel or signal (or is included in a first set of channel or signal types). A WTRU may determine that the time offset is BAT plus BAT offset (e.g., BAT+BAT offset) if the channel or signal type is a second type of channel or signal (or is included in a second set of channel or signal types). For example, a WTRU may transmit (or receive) a channel or signal using the displayed first TCI state based on (or using) the determined time offset (e.g., BAT, or BAT plus BAT offset), provided that the channel or signal is transmitted (or received) at least at the determined time offset after sending the ACK associated with the reception of the PDSCH.

[0150] For example, a WTRU may determine that i) the first type of channel or signal is at least one of the data channels associated with SRS or CSI-RS (e.g., for channel acquisition) or low-latency related types (e.g., URLLC), and ii) the second type of channel or signal is at least one of the PUSCH or PDSCH or control channels associated with recovery purposes as described herein (e.g., CORESET, PDCCH, search space, or PUCCH).

[0151] In one example, the WTRU may receive configuration information indicating that i) a first set of channels or signal types includes at least one data channel associated with SRS, or CSI-RS (e.g., for channel acquisition), or a low-latency related type (e.g., URLLC), and ii) a second set of channels or signal types includes at least one of PUSCH, or PDSCH, or a control channel associated with recovery purposes as described herein (e.g., CORESET, PDCCH, search space, or PUCCH).

[0152] In one embodiment, an example of a transmit / receive management procedure is provided, as shown in Figure 5. In this example, the timeline management procedure may include determining the channel or signal type (e.g., using TCI display) and using a time offset for wireless communication.

[0153] Referring to Figure 4, for example, a WTRU may receive configuration information indicating a set of TCI states, a BAT, and / or a BAT offset (e.g., Delta) from (e.g., a gNB, a second WTRU, another WTRU for sidelink communication, or another transmitter or node). The WTRU may schedule a PDSCH and receive a first DCI indicating a first TCI state from the set of TCI states. After sending HARQ feedback (e.g., HARQ-ACK) associated with receiving the PDSCH transmission, the WTRU may apply the indicated first TCI state to the transmission (or reception) of a channel or signal (e.g., a scheduled, configured, or indicated channel or signal) when the channel or signal is transmitted (or received) at a time offset (or using at least a time offset, or one or more time offsets).

[0154] The WTRU can determine the time offset for a channel or signal (e.g., when to apply the first TCI state) as either a BAT or a BAT plus BAT offset. This decision using 1) BAT or 2) BAT plus BAT offset is based on the type of channel or signal, or on the set of channel / signal types to which the channel or signal belongs. For example, the decision is based on the channel / signal type, where the first type is at least SRS or CSI-RS and the second type is at least PUSCH or PDSCH. In another example, the decision is based on the set of channel / signal types to which the channel or signal belongs, i.e., a first set of channel / signal types (e.g., including at least SRS or CSI-RS), or a second set of channel / signal types (e.g., including at least PUSCH or PDSCH).

[0155] In one example, after sending HARQ feedback (e.g., HARQ-ACK) to a first PDSCH, if the transmission time is at least BAT, the WTRU may use a first TCI state to transmit a channel (or signal) of a first type (or type within a first set). In this example, the signal of the first type (or type within a first set) could be SRS or CSI-RS.

[0156] In another example, a WTRU can use a first TCI state to receive a channel (or signal) of a first type (or type within a first set) if, after sending HARQ feedback (e.g., HARQ-ACK) to a first PDSCH, the receive time is at least BAT. In this example, the signal of the first type (or type within a first set) could be SRS or CSI-RS.

[0157] In one example, after sending HARQ feedback (e.g., HARQ-ACK) to a first PDSCH, the WTRU may use the first TCI state to transmit a channel (or signal) of a second type (or type in the second set) if the transmission time is at least BAT plus BAT offset. In this example, the channel of the second type (or type in the second set) could be a PUSCH or a second PDSCH.

[0158] In another example, the WTRU can use the first TCI state to receive a channel (or signal) of a second type (or type in the second set) if, after sending HARQ feedback (e.g., HARQ-ACK) to the first PDSCH, the receive time is at least BAT plus BAT offset. In this example, the channel of the second type (or type in the second set) could be a PUSCH or a second PDSCH.

[0159] In one embodiment, the WTRU may receive configuration information indicating a set of Transmit Configuration Indicator (TCI) states, Beam Application Time (BAT), and / or BAT offset. The WTRU may also receive Downlink Control Information (DCI) indicating 1) scheduling of downlink data transmission and 2) TCI states from the set of TCI states. Based on the type of channel used after transmitting the HARQ feedback associated with the downlink data transmission, the WTRU may determine a time offset associated with the time instance for applying the indicated TCI states. The WTRU may also transmit or receive signals using the indicated TCI states on that type of channel, based on the determined time offset.

[0160] In one example, the WTRU may determine that the time offset is BAT based on whether the channel type is SRS, CSI-RS, or a data channel associated with a low-latency type. In another example, the WTRU may determine that the time offset is BAT plus BAT offset based on whether the channel type is PUSCH, PDSCH, or a control channel.

[0161] Typical Procedures for UTCI Timelines Based on UTCI Mode, TRP, and WTRU Panels

[0162] In one embodiment, the WTRU may consist of multiple sets of BAT values. Each set may consist of multiple BATs (or, for example, BAT plus Delta). To define the overall structure of the BAT configuration, hierarchical configuration levels may be considered and used for the configuration of the WTRU.

[0163] For example, a multi-stage or hierarchical BAT configuration may include one or more of the following steps or actions:

[0164] Mode configuration per UTCI: The first step in configuration is to define whether the UTCI mode is joint (e.g., a joint UTCI for DL ​​and UL) or separate (e.g., separate UTCIs for DL ​​and UL). In a joint UTCI configuration, the WTRU may be configured with the same beam reference for all uplink and downlink channels or signals. Alternatively, separate UTCI configurations may be configured for each downlink transmit and uplink transmit. UTCI-based operation may also be configured per TRP such that the WTRU assumes a separate UTCI operating mode for a first TRP, e.g., a serving TRP, and a joint UTCI operating mode for a second TRP. Depending on the UTCI configuration mode, the WTRU may receive multiple sets of BAT values.

[0165] TRP / Panel-specific BAT configuration: Depending on the gNB and WTRU implementation, the WTRU may receive multiple sets of BAT values.

[0166] In one embodiment, when configured in a multi-TRP transmission, the WTRU can receive multiple sets of BAT values. The same set of BAT values ​​may be used for multiple TRPs. For example, BAT_set1 may be used for TRP1, and BAT_set2 may be used for TRP2 and TRP3.

[0167] In another embodiment, a WTRU may receive multiple sets of BAT values ​​when it demonstrates multi-panel transmission capability. The same set of BAT values ​​may be used for multiple panels (e.g., WTRU panels). For example, BAT_set1 may be used for the first panel, and BAT_set2 for the second and third panels. A similar concept may be adopted for each WTRU antenna group.

[0168] In one embodiment, if the WTRU is configured to operate in a multi-TRP scenario and consists of multiple BAT values, the WTRU can apply the larger BAT value to CJT operation. For example, if the WTRU is configured with BAT1 for PDSCH transmission from TRP1 and BAT2 for PDSCH transmission from TRP2, and BAT2 > BAT1, then the WTRU can assume BAT2 for CJT transmission (e.g., CJT-PDSCH).

[0169] In one embodiment, if the WTRU is configured to operate in a multi-TRP scenario and consists of one BAT plus Delta, the WTRU can apply BAT plus Delta to CJT operation. For example, if the WTRU is configured with BAT for PDSCH transmission from TRP1 and BAT plus Delta for PDSCH transmission from TRP2, then based on Delta (e.g., a positive value), the WTRU can assume BAT plus Delta for CJT transmission (e.g., CJT-PDSCH).

[0170] Similarly, if a multi-panel WTRU is configured to operate in STxMP mode and consists of multiple BAT values, the WTRU can apply the larger BAT value to the STxMP operation. For example, if a multi-panel WTRU is configured with BAT1 for push transmissions from the first panel and BAT2 for push transmissions from the second panel, and BAT2 > BAT1, the WTRU can assume (and use / apply) BAT2 for STxMP transmissions. If a multi-panel WTRU is configured to operate in STxMP mode and consists of one BAT plus Delta, the WTRU can apply BAT plus Delta to the STxMP operation. For example, if a multi-panel WTRU is configured with BAT for push transmissions from the first panel and BAT plus Delta for push transmissions from the second panel, the WTRU can assume (and use / apply) BAT plus Delta for STxMP transmissions based on Delta (e.g., a positive value).

[0171] Channel-specific configuration: If the WTRU is composed of at least one set of BAT values, for example according to the TRP or WTRU panel, then the configured set of values ​​may be divided into multiple subsets depending on the channel and / or signal.

[0172] In one embodiment, a WTRU configured with BAT_set1 for TRP1 can receive multiple subsets of BAT values, where each subset of BAT values ​​can be used for multiple channels and / or signals. For example, in multi-DCI TRP transmission, two different BAT values, e.g., BAT11 and BAT21, may be considered for the same channel, e.g., PDCCH, where BAT11 and BAT21 are BAT values ​​corresponding to TRP1 and TRP2.

[0173] In one embodiment, for a given channel / signal, the BAT value corresponding to the TRP associated with the serving cell may be shorter than the BAT values ​​associated with other TRPs.

[0174] In one embodiment, a hierarchical BAT configuration for a multi-panel WTRU configured with a multi-TRP arrangement may be based on a combination of semi-static and dynamic signaling.

[0175] In one embodiment, the configuration of a general UTCI mode, such as separate TCI mode or joint TCI mode, can be performed through RRC signaling. In one embodiment, the joint TCI configuration can be considered a fallback mode.

[0176] For TRP / panel-specific BAT configurations, a combination of semi-static and dynamic signaling may be used. In one embodiment, the WTRU may consist of multiple TRP-specific and / or panel-specific BAT configurations, where specific selections may be made by dynamic signaling, e.g., MAC CE or DCI.

[0177] Similar to per-TRP / per-panel configurations, per-channel configurations may utilize a combination of semi-static and dynamic signaling. In one embodiment, the WTRU may be configured with multiple per-channel / per-signal configurations, where specific selections may be made by dynamic signaling, such as MAC CE or DCI.

[0178] Typical Procedures for Timeline Management Regarding Unified TCI Display

[0179] In a typical embodiment, the WTRU may consist of a beam application time (BAT) parameter and a paired / associated "Delta" offset parameter, where each of the BAT and "BAT plus Delta" may be associated with a list of channels / signals, which may be predefined, determined based on WTRU capability, and / or configured independently by the network (e.g., gNB). In one example, the WTRU may consist of a BAT associated with a first list of channels / signals, and further consist of a Delta, where BAT plus Delta may be associated with a second list of channels / signals.

[0180] In one example, in response to receiving a control message (e.g., via DCI, via the TCI field of DCI), in a first time instance (T1) indicating at least one unified TCI (UTCI), the WTRU may determine a second time instance (T2) based on T1 and BAT (e.g., as T1+BAT or T1+Alpha+BAT), in this time instance, the WTRU may update (e.g., set and / or start using) the indicated at least one UTCI for a first list of channels / signals, but may not update the indicated at least one UTCI (in T2) for other channels / signals not included in the first list.

[0181] For example, the WTRU may determine a third time instance (T3) based on T1, BAT, and Delta (e.g., as T1+BAT+Delta or T1+Alpha+BAT+Delta), in which time instance the WTRU may update (e.g., set and / or start using) at least one indicated UTCI for the second list of channels / signals, but may not update at least one indicated UTCI (in T3) for other channels / signals not included in the second list.

[0182] In a typical embodiment, the WTRU determines that the time offset is BAT if the channel (or signal) type is a first type of channel (or signal) or is included in a first set of channel (or signal) types. The WTRU may determine that the time offset is BAT plus BAT offset if the channel or signal type is a second type of channel or signal or is included in a second set of channel or signal types. For example, the WTRU may determine that i) the first type of channel or signal is at least one of the data channels associated with SRS or CSI-RS (e.g., for channel acquisition) or low-latency related types (e.g., URLLC), and (ii) the second type of channel or signal is at least one of the PUSCH, PDSCH, or control channels (e.g., CORESET, PDCCH, search space, or PUCCH).

[0183] conclusion

[0184] While features and elements are presented above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. This disclosure is not limited in terms of the specific embodiments described in this application, but rather they are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of this disclosure. No element, operation, or instruction used in the description of this application should be construed as important or essential to the invention unless expressly presented as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the language of the appended claims and the full scope of the equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0185] For the sake of brevity, the embodiments described above discuss the terminology and structure of infrared-compatible devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems and may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves such as sound waves.

[0186] Furthermore, it should be understood that the terms used herein are merely for the purpose of describing specific embodiments and are not intended to limit them. Where used herein, the terms “video” or “image” may mean a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, where referred herein, the terms “user equipment” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” mean or may include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of several embodiments of a WTRU, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired-enabled device configured to have less structure and functionality than all of the structure and functionality of a WTRU, or (iv) an analogue. Details of exemplary WTRUs that may represent any WTRU described herein are presented herein in relation to Figures 1A to 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. Devices other than head-mounted displays may be used, and it will be recognized by those skilled in the art that some or all of the disclosure and the various embodiments disclosed may be modified as appropriate without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide a tailored reality experience.

[0187] In addition, the methods provided herein may be implemented in computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable mediums 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 multipurpose disks (DVDs). Software and associated processors may be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

[0188] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments to which they may be applied, it will be understood that the illustrated embodiments are merely examples and should not be considered as limiting the scope of the appended claims. For example, embodiments provided herein include a handheld device, which may include, or be used with, any suitable voltage source, such as a battery, that provides any suitable voltage.

[0189] Furthermore, the embodiments provided above refer to processing platforms including processors, computing systems, controllers, and other devices. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practice of those skilled in the art in the field of computer programming, references to symbolic representations of actions and operations or instructions may be made by various CPUs and memories. Such actions and operations or instructions may be referred to as "executed," "executed by the computer," or "executed by the CPU."

[0190] Those skilled in the art will understand that operations and symbolically represented operations or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits that can consequently cause a transformation or reduction of electrical signals, and maintains these data bits in memory locations in the memory system, thereby reconfiguring or otherwise modifying the CPU's operations and processing of other signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0191] Data bits may also be held on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by a CPU. Computer-readable media may include cooperative or interconnected computer-readable media that reside exclusively on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. Embodiments are not limited to the memories described above, and it should be understood that other platforms and memories may support the methods provided.

[0192] In exemplary embodiments, any of the operations or processes described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by processors in mobile units, network elements, and / or any other computing devices.

[0193] There is little difference between hardware and software implementations of a system configuration. The use of hardware or software is generally a design choice representing a trade-off between cost and efficiency (though not always, in that the choice between hardware and software can be important in certain contexts). While there may be various means (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other technologies described herein may be effective, the preferred means may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, they may primarily choose hardware and / or firmware means. If flexibility is paramount, the implementer may primarily choose a software implementation. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

[0194] The detailed description above illustrates various embodiments of devices and / or processes using block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In embodiments, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, in whole or in part, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is well within the scope of the art of those skilled in the art in light of this disclosure. In addition, it will be understood by those skilled in the art that mechanisms of the subject matter described herein can be distributed as various forms of program products, and that exemplary embodiments of the subject matter described herein are applicable regardless of the particular type of signal-carrying medium used to actually carry out the distribution.Examples of signal-carrying media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0195] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then integrate such described devices and / or processes into a data processing system using engineering techniques. That is, at least some of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, computing entities such as an operating system, drivers, a graphical user interface, and application programs, one or more interaction devices such as a touchpad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, as is typically found in data computing / communication and / or network computing / communication systems.

[0196] The subject matter described herein may include different components that are contained within or connected to other different components. Such illustrated architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” in such a way that the desired functionality can be achieved. Thus, any two components combined herein to achieve a particular functionality, regardless of architecture or intermediate components, can be considered “associated” with one another in such a way that the desired functionality can be achieved. Similarly, any two components thus associated may be considered “operably connected” or “operably coupled” with one another to achieve the desired functionality, and any two components that can be associated in such a way may be considered “operably coupled” with one another to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, physically matable components and / or physically interacting components, as well as / or wirelessly interacting components and / or wirelessly interacting components, as well as / or logically interacting components and / or logically interactable components.

[0197] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural rearrangements may be explicitly described herein for clarity.

[0198] In general, it will be understood by those skilled in the art that the terms used herein and in particular in the appended claims (e.g., the body of the appended claims) are intended to be generally “open” terms (for example, the term “includes” should be interpreted as “includes but not limited,” the term “has” should be interpreted as “has at least,” and the term “includes” should be interpreted as “includes but not limited,” etc.). Furthermore, it will be understood by those skilled in the art that if a particular number is intended in the description of an introduced claim, such intention is explicitly stated in the claim, and if such statement is not made, such intention does not exist. For example, if only one item is intended, the term “single” or similar word may be used. For the sake of understanding, the description in the appended claims and / or herein may include the use of introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim description by the indefinite article "a" or "an" limits any particular claim containing such introduced description to embodiments containing only one such description, and the same is true if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of the definite article used to introduce a claim description. In addition, it will be recognized by those skilled in the art that even if a particular number of introduced claims is explicitly stated, such description should be interpreted as meaning at least the number stated (for example, the mere statement "two descriptions" without other modifiers means at least two descriptions or two or more descriptions).Furthermore, when conventions similar to "at least one of A, B, and C, etc." are used, such structures are generally intended in a way that a person skilled in the art will understand the convention (for example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). Furthermore, it will be understood by those skilled in the art that substantially any disjunctive word and / or phrase presenting two or more alternative terms in the specification, claims, or drawings should be understood as construing the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B.” Furthermore, as used herein, the term “any of ~” following a list of multiple items and / or a list of multiple categories of items is intended to include “any of,” “any combination of,” “any multiple,” and / or “any combination of multiple,” either individually or in conjunction with other items and / or categories of other items. Furthermore, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “number” is intended to include any number, including zero. Also, as used herein, the term “multiple” is intended to be synonymous with “multiple.”

[0199] Furthermore, if any feature or aspect of this disclosure is described in terms of the Markush group, it will be recognized by those skilled in the art that this disclosure is also described in terms of any individual element or subgroup of elements of the Markush group.

[0200] For all purposes, including providing written explanations, as will be understood by those skilled in the art, all scopes disclosed herein also encompass all possible sub-scopes and combinations of sub-scopes. Any enumerated scope can be readily recognized as making it readily possible and readily explain that the same scope can be broken down into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. As a non-limiting example, each scope described herein can readily be broken down into a lower third, a middle third, an upper third, etc. Also, as will be understood by those skilled in the art, all words such as “up to,” “at least,” “greater than,” and “less than” include the number mentioned and mean a scope that can be further broken down into sub-scopes as described above. Finally, as will be understood by those skilled in the art, a scope includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0201] Furthermore, unless otherwise stated, the claims should not be interpreted as being limited to the order or elements provided. Moreover, the use of the term “means for” in any claim is intended to be in accordance with Section 112(6) of the U.S. Patent Act or the means-plus-function claim format, and claims without the term “means for” are not intended to be in accordance with that format.

[0202] A software-related processor may be used to implement a radio frequency transceiver for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host computer. The WTRU may be used in conjunction with hardware and / or software-implemented modules, including, for example, software-defined radio (SDR), and may also be used in conjunction with other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, near-field communication (NFC) modules, liquid crystal display (LCD) display units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0203] Although the present invention is described in terms of a communication system, it is intended that the system may be implemented in software on a microprocessor / general-purpose computer (not shown). In certain embodiments, one or more functions of various components may be implemented in software that controls the general-purpose computer.

Claims

1. A wireless transmitter / receiver unit (WTRU) for wireless communication, The system receives configuration information indicating the transmission configuration indicator (TCI) status, beam application time (BAT), and BAT offset. 1) scheduling of downlink data transmission, and 2) receiving downlink control information (DCI) indicating the TCI state from the set of TCI states. A first transmission is transmitted using the previously indicated TCI state, and the first transmission is transmitted at least at a first time offset associated with the BAT after sending the Hybrid Automatic Retransmission Request (HARQ) feedback associated with the downlink data transmission. A second transmission is transmitted using the TCI state described above, the second transmission being transmitted at least at a second time offset associated with the BAT and the BAT offset, after transmitting the HARQ feedback associated with the downlink data transmission. A WTRU comprising a circuit including a processor, receiver, transmitter, and memory configured as such.

2. The WTRU according to claim 1, wherein the processor is configured to receive one or more of the configuration information or DCIs using the previously indicated TCI states.

3. The WTRU according to claim 1, wherein the BAT and BAT offset are channel-specific.

4. The WTRU according to claim 1, wherein the processor is configured to apply the indicated TCI by associating the time offset with a time instance.

5. The WTRU of claim 4, wherein the processor is configured to determine that the time offset is the BAT based on the transmission comprising a first type of signal or channel.

6. The WTRU according to claim 5, wherein the first type of signal or channel includes one or more of the following: a sounding reference signal (SRS), a channel state information-reference signal (CSI-RS), a demodulation reference signal (DM-RS), a phase tracking reference signal (PT-RS), and / or a synchronization signal block (SSB).

7. The processor is configured to determine that the time offset is a combination of the BAT and the BAT offset, based on the fact that the transmission includes a second type of signal or channel different from the first type of signal or channel. The WTRU according to claim 6, wherein the second type of signal and channel includes one or more physical downlink control channels (PDCCH), physical downlink sharing channels (PDSCH), physical uplink control channels (PUCCH), physical uplink sharing channels (PUSCH), or physical random access channels (PRACH).

8. The WTRU according to claim 1, wherein the processor is configured to receive the configuration information via a radio resource control (RRC) signal or a MAC control element (CE).

9. The WTRU according to claim 1, wherein the configuration information indicates a set of channel types or signal types.

10. The WTRU according to claim 9, wherein the set of channel types or signal types includes one or more of the following: 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), physical downlink control channel (PDCCH), physical downlink shared channel (PDSCH), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), or physical random access channel (PRACH).

11. A method implemented by a wireless transmitter / receiver unit (WTRU) for wireless communication, Receiving configuration information indicating the transmission configuration indicator (TCI) state, beam application time (BAT), and BAT offset, 1) scheduling of downlink data transmission, and 2) receiving downlink control information (DCI) indicating the TCI state from the set of TCI states, Transmitting a first transmission using the previously indicated TCI state, wherein the first transmission is transmitted at least at a first time offset associated with the BAT after transmitting the Hybrid Automatic Retransmission Request (HARQ) feedback associated with the downlink data transmission, Transmitting a second transmission using the TCI state described above, wherein the second transmission is transmitted at least at a second time offset associated with the BAT and the BAT offset, after transmitting the HARQ feedback associated with the downlink data transmission. Methods that include...

12. The method according to claim 11, wherein the configuration information or one or more of the DCIs are received using the previously indicated TCI states.

13. The method according to claim 11, wherein the BAT and the BAT offset are channel-specific.

14. The method according to claim 11, wherein the time offset is associated with a time instance to which the indicated TCI is applied.

15. The method according to claim 11, further comprising determining that the time offset is the BAT based on the transmission comprising a first type of signal or channel.

16. The method according to claim 15, wherein the first type of signal or channel includes one or more of a sounding reference signal (SRS), a channel state information-reference signal (CSI-RS), a demodulation reference signal (DM-RS), a phase tracking reference signal (PT-RS), and / or a synchronization signal block (SSB).

17. The further includes determining that the time offset is a combination of the BAT and the BAT offset, based on the fact that the transmission includes a second type of signal or channel different from the first type of signal or channel. The method according to claim 16, wherein the second type of signal and channel includes one or more physical downlink control channels (PDCCH), physical downlink sharing channels (PDSCH), physical uplink control channels (PUCCH), physical uplink sharing channels (PUSCH), or physical random access channels (PRACH).

18. The method according to claim 11, wherein the configuration information is received via a radio resource control (RRC) signal or a MAC control element (CE).

19. The method according to claim 11, wherein the configuration information indicates a set of channel types or signal types.

20. The method according to claim 19, wherein the set of channel types or signal types includes one or more of the following: 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), physical downlink control channel (PDCCH), physical downlink shared channel (PDSCH), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), or physical random access channel (PRACH).

Images