Unified TCI update for MTRP including simultaneous BFR
By introducing multi-TCI status monitoring and unified TCI mechanisms in the wireless transmitting/receiving unit (WTRU), the problem of low resource management and channel monitoring efficiency in the prior art is solved, and more efficient wireless communication system performance and flexibility are achieved.
Patent Information
- Application Number
- CN202380038219.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-14
- Filing Date
- 2023-03-27
- Publication Date
- 2024-12-13
AI Technical Summary
When existing wireless communication systems perform transmission configuration indicators (TCI) and beam failure recovery (BFR), there are problems with low resource management and channel monitoring efficiency, especially in multiple access technologies, base stations and wireless transmission/ The coordination and channel control between the receiving units (WTRUs) are of high complexity, resulting in limited system performance.
A wireless transmission/receiving unit (WTRU) is designed, which can receive and process information associated with multiple control resource sets (CORESETs) and TCI state instances, and realize the Dynamic monitoring and management of multiple TCI states supports a variety of channel access technologies, such as OFDMA and MIMO, and uses a unified TCI mechanism to improve resource utilization and channel switching efficiency.
Improve the resource management efficiency and channel monitoring accuracy of wireless communication systems, enhance the flexibility and performance of the system, especially in multiple access technology, which realizes more efficient beamforming and channel allocation, and improves mobile broadband access quality and reliability.
Smart Images

Figure CN119137880A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 326,683 filed on April 1, 2022, U.S. Provisional Patent Application No. 63 / 395,563 filed on August 5, 2022, U.S. Provisional Patent Application No. 63 / 411,247 filed on September 29, 2022, and U.S. Provisional Patent Application No. 63 / 445,555 filed on February 14, 2023, the entire contents of which are incorporated herein by reference. Technical Field
[0003] Aspects of the present disclosure relate to wireless communications, and more particularly, to techniques for performing transmit configuration indicator (TCI) and / or beam failure recovery (BFR). Background Art
[0004] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, broadcast, etc. These wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, etc.). Examples of such multiple access systems include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) system, the LTE Advanced (LTE-A) system, the Code Division Multiple Access (CDMA) system, the Time Division Multiple Access (TDMA) system, the Frequency Division Multiple Access (FDMA) system, the Orthogonal Frequency Division Multiple Access (OFDMA) system, the Single Carrier Frequency Division Multiple Access (SC-FDMA) system, and the Time Division Synchronous Code Division Multiple Access (TD-SCDMA) system, etc.
[0005] In some examples, a wireless multiple access communication system may include multiple base stations (BSs), each of which is capable of supporting communication of multiple communication devices (also referred to as user equipment (UE)) simultaneously. In an LTE or LTE-A network, a collection of one or more base stations may define an eNodeB (eNB). In other examples, a wireless multiple access communication system may include multiple distributed units (DUs) (e.g., edge units (EUs), edge nodes (ENs), radio heads (RHs), smart radio heads (SRHs), transmit receive points (TRPs), etc.) communicating with multiple central units (CUs) (e.g., central nodes (CNs), access node controllers (ANCs), etc.), wherein a collection of one or more DUs communicating with a CU may define an access node (e.g., which may be referred to as a BS, 5G NB, next generation node B (gNB or gNodeB), transmit receive point (TRP), etc.). A BS or DU may communicate with a collection of WTRUs on a downlink channel (e.g., for transmission from a BS or DU to a WTRU) and an uplink channel (e.g., for transmission from a WTRU to a BS or DU).
[0006] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at a city, country, region, or even global level. NR (e.g., New Radio or 5G) is an example of an emerging telecommunication standard. NR is a collection of enhancements to the LTE mobile standard released by 3GPP. NR is designed to better support mobile broadband Internet access by using OFDMA with a cyclic prefix (CP) on the downlink (DL) and uplink (UL) to improve spectrum efficiency, reduce costs, improve services, utilize new spectrum, and better integrate with other open standards. To this end, NR supports beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation.
[0007] However, as the demand for mobile broadband access continues to increase, further improvements in NR and LTE technologies are needed. Summary of the invention
[0008] The following presents a simplified summary of the invention related to one or more aspects and / or embodiments disclosed herein. Therefore, the following summary of the invention should neither be regarded as a broad overview related to all considered aspects and / or embodiments, nor should it be regarded as identifying key or extremely important elements related to all considered aspects and / or embodiments or delineating the scope associated with any particular aspect and / or embodiment. Therefore, the sole purpose of the following summary of the invention is to present certain concepts related to one or more aspects and / or embodiments disclosed herein in a simplified form before the specific embodiments presented below.
[0009] According to an exemplary aspect, the present disclosure is directed to a wireless transmit / receive unit (WTRU) including a processor and a memory, the wireless transmit / receive unit (WTRU) configured to receive information indicating that a first control resource set (CORESET) is associated with a first transmit configuration indicator (TCI) state instance and a second CORESET is associated with a second TCI state instance. According to an exemplary aspect, the WTRU is configured to receive downlink control information (DCI) including a TCI field indicating a TCI value. In one example, the WTRU may be configured to monitor a physical downlink control channel (PDCCH) transmission via at least one of the first CORESET or the second CORESET, wherein when the TCI value indicates that a first TCI state is associated with the first TCI state instance and when the first CORESET is associated with the first TCI state instance, the first TCI state is used to monitor the PDCCH transmission in the first CORESET, and wherein when the TCI value indicates that a second TCI state is associated with the second TCI state instance and when the second CORESET is associated with the second TCI state instance, the second TCI state can be used to monitor the PDCCH transmission in the second CORESET. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;
[0011] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;
[0012] Figure 1C is an example of an embodiment in which Figure 1A a system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;
[0013] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;
[0014] Figure 2 is a diagram illustrating parameters for monitoring DCI.
[0015] Figure 3 is an example configuration of the UL-TCI IE.
[0016] Figure 4is a diagram illustrating an example unified TCI with M-TRP across multiple BWPs and / or CCs.
[0017] Figure 5 is a diagram illustrating an example unified TCI with M-TRP across multiple BWPs and / or CCs.
[0018] Figure 6 is a diagram illustrating an example unified TCI with M-TRP across multiple BWPs and / or CCs.
[0019] Figure 7 is a diagram illustrating an example unified TCI with M-TRP across multiple BWPs and / or CCs.
[0020] Figure 8 is a diagram illustrating an example unified TCI with M-TRP across multiple BWPs and / or CCs.
[0021] Fig. 9 is a diagram illustrating an example of a TCI field table for DCI.
[0022] Fig.10 is a diagram illustrating an example of a Tx / Rx scheme selection table per TCI code point.
[0023] Fig.11 is a diagram illustrating example physical downlink control channel (PDCCH) TCI state usage that associates a control resource set (CORESET) with a TCI state instance. DETAILED DESCRIPTION
[0024] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.
[0025] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.
[0026] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0027] The base station 114a may be part of the 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), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.
[0028] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over 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).
[0029] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).
[0030] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).
[0031] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).
[0032] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).
[0033] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.
[0034] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.
[0035] The RAN 104 / 113 may be in communication with the CN 106 / 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 the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text, the CN 106 / 115 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
[0036] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.
[0037] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0038] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
[0039] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0040] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In one embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.
[0041] Although the transmit / receive element 122 Figure 1B 1 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0042] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.
[0043] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0044] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.
[0045] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.
[0046] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.
[0047] The WTRU 102 may include a full-duplex radio component for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio component may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio component for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.
[0048] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.
[0049] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.
[0050] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.
[0051] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0052] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.
[0053] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.
[0054] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0055] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.
[0056] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) use a wired communications interface with a communications network.
[0057] In a representative embodiment, the other network 112 may be a WLAN.
[0058] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
[0059] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.
[0060] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.
[0061] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).
[0062] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).
[0063] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.
[0064] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
[0065] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.
[0066] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0067] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different components of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).
[0068] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the evolved Node-B 160a, 160b, 160c. For example, the WTRU 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRU 102a, 102b, 102c.
[0069] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.
[0070] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0071] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.
[0072] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.
[0073] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.
[0074] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
[0075] Given that Figures 1A to 1D as well as Figures 1A to 1D , one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.
[0076] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.
[0077] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.
[0078] As used herein, "a" and "an" and similar phrases are interpreted as "one or more" and "at least one". Similarly, any term with the phrase "plurality" may be interpreted as "one or more" or "at least one". The term "may" may be interpreted as "may, for example". As used herein, unless otherwise specifically mentioned, the sign, symbol or mark of the forward slash " / " may be interpreted as "and / or", where, for example, "A / B" may imply "A and / or B".
[0079] The WTRU may send or receive at least one physical channel or reference signal based on at least one spatial domain filter. The term "beam" may be used to refer to the spatial domain filter. The WTRU may send a physical channel or signal using the same spatial domain filter used to receive a reference signal (RS) (e.g., channel state information RS (CSI-RS)) or synchronization signal (SS) block. The WTRU transmission may be referred to as a "target". The received RS or SS block may be referred to as a "reference" or "source". In one example, the WTRU may send a target physical channel and / or signal based on a spatial relationship with reference to the RS and / or SS blocks.
[0080] In one embodiment, the WTRU may transmit a first physical channel and / or signal according to the same spatial domain filter as used to transmit a second physical channel and / or signal. The first transmission may be referred to as a "target". The second transmission may be referred to as a "reference" and / or "source". The WTRU may transmit a first physical channel or signal (e.g., a target physical channel and / or signal) according to a spatial relationship with reference to a second physical channel and / or signal (e.g., a reference physical channel and / or signal).
[0081] The spatial relationship may be implicit, configured by the radio resource control (RRC) and / or signaled by the MAC control element (MACCE) and / or downlink control information (DCI). For example, the WTRU may implicitly send a physical uplink shared channel (PUSCH) and / or a demodulation reference signal (DM-RS) for the PUSCH according to the same spatial domain filter as a sounding reference signal (SRS) indicated by an SRS resource indicator (SRI) indicated in the DCI or configured by the radio resource control (RRC). In one example, the spatial relationship may be configured by the RRC for SRI and / or signaled by the MAC CE for the physical uplink control channel (PUCCH). Such a spatial relationship may be referred to as a "beam indication".
[0082] The WTRU may receive a first (target) downlink channel or signal based on the same spatial domain filter or spatial reception parameters as a second (reference) downlink channel or signal. For example, an association may exist between a physical channel (such as a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) and its corresponding DM-RS. In one example, when the first signal and / or the second signal is a reference signal, the association may exist when the WTRU is configured with a quasi co-location (QCL) assumption type D between corresponding antenna ports. In one example, the association may be configured as a transmission configuration indicator (TCI) state. The WTRU may indicate the association between the CSI-RS and / or SS blocks and the DM-RS, for example, by an index to a TCI state set (configured by the RRC and / or signaled by the MAC CE). Such an indication may be referred to as a "beam indication".
[0083] Herein, while being consistent with an implementation, “RS” may be used interchangeably with one or more of “RS resource,” “RS resource set,” “RS port,” and / or “RS port group.” Herein, while being consistent with an implementation, “RS” may be used interchangeably with one or more of “synchronization signal block” or “SSB,” “CSI-RS,” “SRS,” and / or “DM-RS.”
[0084] A unified TCI (e.g., common TCI, common beam and / or common RS, etc.) may refer to a beam and / or RS used for multiple physical channels and / or signals. In one example, a unified TCI may refer to a beam and / or RS to be used for multiple physical channels and / or signals simultaneously. The term "TCI" may include at least a TCI state including at least one source RS that may provide a reference (e.g., WTRU assumption) that may determine a QCL and / or a spatial filter.
[0085] In one example, the WTRU may receive (e.g., from a gNB) an indication of a first unified TCI that may be used and / or applied to one or both of a PDCCH and a PDSCH (e.g., and a downlink RS). One or more source reference signals in the first unified TCI may provide common QCL information for at least WTRU-specific reception on a PDSCH and / or for all or a subset of a CORESET in a component carrier (CC). In one example, the WTRU may receive (e.g., from a gNB) an indication of a second unified TCI to be used and / or applied to one or both of a PUCCH and a PUSCH (e.g., and an uplink RS). One or more source reference signals in the second unified TCI may provide a reference for determining a common uplink transmit (UL TX) spatial filter for at least one PUCCH resource, a subset of PUCCH resources, or all PUCCH resources in a PUSCH and a dedicated PUCCH resource in a CC based on a dynamic grant and / or a configured grant.
[0086] The WTRU may be configured with a first mode for one or more unified TCIs (e.g., SeparateDLULTCI mode), where the indicated first unified TCI may be applicable to one or more downlinks, and the indicated second unified TCI may be applicable to one or more uplinks. For example, the WTRU may be configured with a first mode for one or more unified TCIs, where the indicated first unified TCI may be applicable to a downlink (e.g., downlink only), and the indicated second unified TCI may be applicable to an uplink (e.g., uplink only).
[0087] The WTRU may be configured with one or more of the second modes for one or more unified TCIs (e.g., JointTCI mode), where the indicated unified TCI (e.g., a third unified TCI) may be applicable to one or both of the downlink and / or uplink (e.g., based on the third unified TCI). In one example, the WTRU may be configured with a second mode for one or more unified TCIs (e.g., JointTCI mode), where the indicated unified TCI (e.g., a third unified TCI) may be applicable to one or both of the downlink and / or uplink (e.g., based on the third unified TCI).
[0088] In one example, the WTRU may receive an indication of a third unified TCI to be commonly used and / or applied to PDCCH, PDSCH, PUCCH, PUSCH, downlink reference signal (DL RS) and / or uplink reference signal (UL RS) based on a second mode (e.g., JointTCI mode) (e.g., from a gNB).
[0089] Herein, while being consistent with the implementation scheme, unified TCI may be used interchangeably with one or more of unified TCI state, TCI and / or TCI state. Herein, while being consistent with the implementation scheme, transmit and receive point (TRP) may be used interchangeably with one or more of transmit point (TP), receive point (RP), radio remote head (RRH), distributed antenna (DA), base station (BS), sector (e.g., sector of BS) and cell (e.g., geographic cell area served by BS). Herein, while being consistent with the implementation scheme, multiple TRP may be used interchangeably with one or more of MTRP, M-TRP and / or multiple TRPs.
[0090] The WTRU may be configured with one or more TRPs to which the WTRU may send and / or from which the WTRU may receive, and / or may receive configuration of the one or more TRPs. The WTRU may be configured with one or more TRPs for one or more cells. A cell may be a serving cell and / or a secondary cell.
[0091] The WTRU may be configured with at least one RS for channel measurement purposes. The RS may be a channel measurement resource (CMR). The RS may include one or more CSI-RS, SSB and / or any downlink RS. The downlink RS may be sent to the WTRU from the TRP. The CMR may be configured with one or more TCI states and / or associated with one or more TCI states. The WTRU may be configured with one or more CMR groups, in which one or more CMRs sent from the same TRP may be configured. Each group may be identified by a CMR group index (e.g., group 1). The WTRU may be configured with one CMR group per TRP. The WTRU may receive one or more links between one or more CMR group indexes and one or more other CMR group indexes, and / or one or more links between one or more RS indexes from one or more CMR groups and one or more other RS indexes from one or more other CMR groups.
[0092] The WTRU may be configured with, and / or receive configuration of, one or more path loss (PL) reference groups (e.g., sets) and / or one or more SRS groups, one or more SRS resource indicators (SRIs) and / or one or more SRS resource sets.
[0093] A PL reference group may correspond to one or more TRPs and / or may be associated with one or more TRPs. A PL reference group may include, identify, correspond to, and / or be associated with one or more of the following: a TCI state, an SRI, a reference signal set (e.g., a CSI-RS set, an SRI set), a control resource set (CORESET) index, and / or a reference signal (e.g., a CSI-RS, an SSB, etc.).
[0094] The WTRU may receive one or more configurations (e.g., any one or more of the configurations described herein). Each of these configurations may be received from a gNB and / or a TRP. For example, the WTRU may receive one or more configurations of one or more TRPs, one or more PL reference groups, and / or one or more SRI sets. The WTRU may implicitly determine the association between the RS set / group and the TRP. For example, if the WTRU is configured with two SRS resource sets, the WTRU may determine to use SRS in the first resource set to transmit to TRP1, and to use SRS in the second resource set to transmit to TRP2. In one example, the configuration may be obtained via RRC signaling.
[0095] In the examples and embodiments described herein, "TRP", "PL reference group", "SRI group", and "SRI set" may be used interchangeably. The terms "set" and "group" may be used interchangeably herein. The WTRU may report a subset of channel state information (CSI) components, where the CSI components may correspond to at least one or more CSI-RS resource indicators (CRI), one or more SSB resource indicators (SSBRI), one or more indications of one or more panels for reception at the WTRU (e.g., one or more panel identifiers and / or group identifiers), one or more measurement results such as L1-RSRP, L1-SINR (e.g., cri-RSRP, cri-SINR, ssb-Index-RSRP, ssb-Index-SINR) obtained from SSB and / or CSI-RS, and / or any channel state information. For example, the channel state information may include at least one or more of a rank indicator (RI), a channel quality indicator (CQI), a precoding matrix indicator (PMI), and / or a layer index (LI), etc.
[0096] A unified TCI (e.g., joint DL / UL or a pair of separate DL / UL) may be indicated and / or maintained at the WTRU. The unified TCI may be applicable to either or both of the control channel and / or the data channel. The individual beam steering of each channel may exhibit different or identical characteristics.
[0097] Multiple TRPs (MTRPs) based on multiple DCIs (MDCI-MTRPs) can be based on CORESETPoolIndex = 0 or 1 to support eMBB. Single DCI-based MTRPs (SDCI-MTRPs) can be based on associating up to two TCI states for code points in the TCI field in the DCI, for example, for repeated transmission across TRPs and / or for reliability enhancement.
[0098] One or more unified TCIs (e.g., unified TCIs mapped to each TRP) may be associated and / or updated. For example, the WTRU may detect one or more indications from one or more TRPs (e.g., indications delivering one or more updates of the unified TCI). The WTRU may identify the one or more TRPs to be applied. One or more MTRP unified TCIs may be updated simultaneously across multiple component carriers (CCs) / bandwidth parts (BWPs), which may, for example, save signaling overhead. The reliability and / or latency of the BFR may be improved for the MTRP with unified TCI.
[0099] The attributes of a grant or assignment may include one or more of the following: frequency allocation; aspects of time allocation (e.g., duration); priority; modulation and / or coding scheme; transport block size; number of spatial layers; number of transport blocks; TCI state, CRI and / 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 a dynamic grant; whether the assignment is a dynamic assignment or a semi-persistently scheduled (e.g., configured) assignment; configuring a grant index and / or a semi-persistent assignment index; configuring the periodicity of grants and / or assignments; channel access priority class (CAPC); any parameters provided by the MAC and / or by the RRC in the DCI for scheduling grants and / or assignments.
[0100] The indication by DCI may include one or more of the following: an explicit indication by a DCI field and / or by a radio network temporary identifier (RNTI) that can be used to mask a cyclic redundancy check (CRC) of a PDCCH; and / or an implicit indication by an attribute. For example, the implicit indication by the attribute may include at least one or more of the following: DCI format, DCI size, CORESET or search space, aggregation level, first resource element of the received DCI (e.g., index of the first control channel element (CCE)). The mapping between the attribute and the value may be signaled by RRC and / or MAC.
[0101] A unified TCI pool may refer to one or more unified TCI sets (e.g., candidate unified TCI sets) configured for one or more WTRUs. The unified TCI sets may be configured by RRC. One or more unified TCIs of the unified TCI pool may be indicated to the WTRU to apply to multiple downlink and / or uplink channels (e.g., for multiple control and data channels).
[0102] One or more TRP1 pools may be separate from one or more TRP2 pools. For example, each unified TCI pool for each TRP may be configured by RRC (e.g., individually or independently). For example, each unified TCI pool for (e.g., based on and / or associated with) each WTRU panel may be configured by RRC. For example, each unified TCI pool for each TRP may be associated with a CORESETPoolIndex value (e.g., 0, 1, 2, 3, etc.). For example, the CORESETPoolIndex value may range from zero (0) to the number of TRPs with which the WTRU communicates. For example, the CORESETPoolIndex value may include one or more of the following: a TRP index, a TRP indicator, a TRP identification-related parameter, a CORESET group index, etc. In one example, for TRP1, Pool1 may be associated with CORESETPoolIndex=0. In one example, for TRP2, Pool2 may be associated with CORESETPoolIndex=1. The WTRU may be configured with an independent unified TCI mode (e.g., either JointTCI or SeparateDLULTCI) for Pool1 and Pool2. In one example, Pool1 may be configured with a JointTCI mode. In one example, Pool2 may be configured with a SeparateDLULTCI mode. In one example, Pool1 may be configured with a JointTCI mode. In one example, Pool2 for DL (e.g., including a candidate DL unified TCI) and Pool3 for UL (e.g., including a candidate UL unified TCI) may be configured with a SeparateDLULTCI mode. In one example, the WTRU may be configured with one or more TCI states in a TCI state (e.g., a unified TCI state). For example, each TCI state may be constructed based on an aggregated form of one or more separate pools (e.g., a separate pool for each TRP). In one example, a component (e.g., a portion, or a first one or more TCI states) of a plurality of TCI states (e.g., in aggregate form) may be associated with one or more TRPs (e.g., TRP1), wherein the TCI state IDs of the first one or more TCI states in the component may be assigned in ascending order from a reference TCI state ID. For example, the reference TCI state ID may be 0 for TRP1, X (>0) for TRP2, Y (>X) for TRP3, and so on.
[0103] TRP1 may have a common and / or shared pool with TRP2. The WTRU may be configured with one or more common and / or shared unified TCI pools for multiple TRPs. For example, the WTRU may determine and / or identify that a first unified TCI of a common unified TCI pool may be used and / or indicated for communication with TRP1. For example, the WTRU may determine and / or identify that a second unified TCI of a common unified TCI pool may be used and / or indicated for communication with TRP2. For example. The WTRU may determine and / or identify the unified TCI based on one or more predefined rules and / or behaviors. For example. The WTRU may determine and / or identify the unified TCI based on explicit indications from the gNB (e.g., per TCI state, per unified TCI within a common unified TCI pool). For example. The WTRU may determine and / or identify the unified TCI based on a value associated with a CORESETPoolIndex (e.g., TRP index, TRP indicator, TRP identification related parameter, CORESET group index, etc.) per TCI state and / or per unified TCI. For example, each TCI state and / or unified TCI within the common pool may be associated with a CORESETPoolIndex value. For example, one TCI state may be associated with CORESETPoolIndex=0 within the common pool for TRP1. For example, one TCI state may be associated with CORESETPoolIndex=1 within the common pool for TRP2.
[0104] In one example, the WTRU may make one or more determinations and / or identifications of a unified TCI based on a source RS of the unified TCI, which source RS may correspond to one or more TRPs. For example, the WTRU may make one or more determinations and / or identifications of a unified TCI based on an indirect QCL rule. In response to determining that the source RS corresponds to, is associated with, and / or is sent from a first TRP, the WTRU may determine and / or identify that the unified TCI is used for the first TRP (e.g., for communication with the first TRP). In response to determining that the source RS corresponds to, is associated with, and / or is sent from a second TRP, the WTRU may determine and / or identify that the unified TCI is used for a second TRP (e.g., for communication with the second TRP).
[0105] In one example, the source RS may be a first CSI-RS for tracking, such as a tracking reference signal (TRS). The first TRS may be configured with its source RS as a non-serving cell RS, such as a non-serving cell SSB having a different physical cell ID than the first TRS. In response to determining that the first TRS including its source RS is a non-serving cell RS (e.g., SSB), the WTRU may identify and / or determine that a unified TCI (e.g., including the source RS) can be used for inter-cell beam management and / or inter-cell TRP operations. For example, the unified TCI can be used to communicate with an inter-cell TRP. The source RS may be a second CSI-RS for tracking (e.g., a TRS). The second TRS may have an association and / or relationship with one or more CORESETPoolIndex values, which may include, for example, one or more of a TRP index, a TRP indicator, a TRP identification-related parameter, a CORESET group index, and the like. In one example, in response to determining that a second TRS is associated with a CORESETPoolIndex value, the WTRU may identify and / or determine that a unified TCI (e.g., including the source RS) may be used for the TRP associated with the CORESETPoolIndex value.
[0106] A common unified TCI pool for both TRPs may be configured by RRC. In one example, the WTRU may be configured with a common and / or single unified TCI mode for both TRP1 and TRP2, for example, applicable to a common unified TCI pool. For example, the common and / or single unified TCI mode may be JointTCI or SeparateDLULTCI. The WTRU may perform symmetric behavior in communications with TRP1 and TRP2, which may result in reduced complexity in the WTRU implementation.
[0107] In one example, the WTRU may be configured with an independent unified TCI mode for each TCI state within a common pool (e.g., for each unified TCI). For example, the independent unified TCI mode may be JointTCI or SeparateDLULTCI. The configuration with an independent unified TCI mode for each TCI state (e.g., within a common pool) may enable more flexible and efficient operation for each TRP. For example, each TRP may utilize an independent unified TCI mode, e.g., in exchange for increased WTRU complexity. The independent unified TCI mode may be, for example, JointTCI or SeparateDLULTCI.
[0108] In one example, the WTRU may be configured with the same unified TCI pattern across different TCI states (e.g., different unified TCIs), all of which are mapped to TRPs, which may be the same TRP. In one example, if a first unified TCI mapped to a first TRP (e.g., via CORESETPoolIndex=0, etc.) is associated with a first unified TCI pattern (which may be, for example, JointTCI or SeparateDLULTCI), the WTRU may identify and / or determine that a second unified TCI mapped to the same first TRP (which may be the same TRP) will be associated with the first unified TCI pattern (which may be the same unified TCI pattern).
[0109] In one embodiment, unified TCI activation (e.g., using MAC-CE) of an M-TRP may have separate MAC-CE activations for TRP1 and / or TRP2. The WTRU may receive an indication (e.g., via MAC-CE) including a TRP indicator that activates one or more TCI states (e.g., unified TCI states) of a plurality of TCI states (e.g., unified TCI states) configured for a TRP associated with the TRP indicator. The TRP indicator may be a parameter of and / or associated with CORESETPoolIndex. For example, the WTRU's activation of one or more TCI states may be associated with the WTRU mapping the one or more TCI states to one or more codepoints of the TCI field in the DCI (e.g., for elements and / or entries based on a one-to-one mapping).
[0110] In one example, a WTRU may receive an indication (e.g., via a MAC-CE) including one or more TRP indicators that activates a first one or more TCI states (e.g., a unified TCI state) of a first plurality of TCI states (e.g., a unified TCI state) configured for TRP1 associated with a first TRP indicator of the one or more TRP indicators. The first plurality of TCI states may be, for example, Pool1. The WTRU may receive an indication (e.g., via a MAC-CE) including one or more TRP indicators that activates a second one or more TCI states (e.g., a unified TCI state) of a second plurality of TCI states (e.g., a unified TCI state) configured for TRP2 associated with a second TRP indicator of the one or more indicators. The indication including one or more TRP indicators may include an aggregation structure that signals the indication. For example, the aggregation structure may imply one or more individual TCI activation formats per TRP and / or associated with each TRP indicator in the same MAC-CE indication message.
[0111] In one embodiment, unified TCI activation of the M-TRP (e.g., using MAC-CE) may be associated with TRP1 and TRP2 with common MAC-CE activation. The WTRU may receive an indication (e.g., via MAC-CE) including parameters for monitoring DCI that activates one or more TCI states (e.g., unified TCI states) in a plurality of TCI states (e.g., unified TCI states). In one example, activation of one or more TCI states may indicate that the WTRU may map the one or more TCI states to one or more code points of a TCI field in the DCI based on the parameters for monitoring DCI (e.g., on a one-to-one mapping basis for elements and / or entries).
[0112] In one example, in response to determining that the parameters for monitoring DCI indicate a first parameter (e.g., a first value), the WTRU may map one or more TCI states to one or more code points of a TCI field of the DCI, wherein the WTRU may receive the DCI based on a first one or more CORESETs. For example, the first one or more CORESETs may be associated with a first TRP, associated with a first group of CORESETs, associated with a first TRP indicator, associated with a first CORESETPoolIndex value, etc.).
[0113] In one example, in response to determining that the parameter for monitoring the DCI indicates a second parameter (e.g., a second value), the WTRU may map one or more TCI states to one or more code points of a TCI field of the DCI, wherein the WTRU may receive the DCI based on a second one or more CORESETs. For example, the second one or more CORESETs may be associated with a second group of CORESETs, associated with a second TRP indicator, associated with a second CORESETPoolIndex value, etc.
[0114] When DCI is received via a CORESET set of multiple CORESETs (e.g., configured for the WTRU), the parameters for monitoring the DCI may indicate that the content of the indication (e.g., via the MAC-CE) for activating one or more TCI states (e.g., unified TCI states) may be valid for (e.g., mapped and / or used for) one or more code points of the DCI. For example, the CORESET set may be one or more CORESETs associated with a TRP (e.g., a TRP indicator and / or a CORESETPoolIndex value).
[0115] Figure 2200 is a diagram illustrating an example of parameters for monitoring DCI. In one embodiment, the parameters for monitoring DCI may be indicated via a reserved field (R field) 202 for activating the TCI state in a MAC-CE message. The parameters for monitoring DCI may be indicated by replacing a field in the MAC-CE message indicating a CORESETPoolIndex value for activating the TCI state (e.g., for one or more multi-TRP operations and / or features). The serving cell ID field 204 may indicate an identifier (ID) of a serving cell (e.g., component carrier (CC), serving cell, and / or cell) to which the indication (e.g., MAC CE) applies. The length of the serving cell ID field may be 5 bits. If the indicated serving cell is configured as part of a CC list for simultaneous TCI updates (e.g., simultaneousTCI-UpdateList1, simultaneousTCI-UpdateList2, etc.), the indication (e.g., the MAC CE) may apply to all serving cells configured in the CC list (e.g., simultaneousTCI-UpdateList1 or simultaneousTCI-UpdateList2 set respectively).
[0116] The BWP ID field 206 may indicate the DL BWP to which the indication (eg, MAC CE) applies, which is applicable to the code point of the bandwidth part indicator field of the DCI. The length of the BWP ID field 204 may be, for example, 2 bits. N Field 208 may indicate whether there is a TCI status ID N,2 In one example, if this field is set to 1, there is a TCI status ID. N,2 , which may indicate that two unified TCIs (e.g., one for TRP1 and another for TRP2) may be based on the code point of the TCI field of the DCI (e.g., associated with index N, such as TCI state ID N,1 and TCI Status ID N,2 ) is also indicated by the DCI. In one example, if this field is set to "0", there may be no TCI state ID. N,2 , which indicates that a unified TCI (e.g., for TRP1 as the primary and / or default TRP) may be based on the second code point of the TCI field of the DCI (associated with index N, e.g., TCI state ID N,1 ) is indicated by DCI. TCI Status ID N,MField 210 may indicate a TCI state (eg, unified TCI state) identified by a TCI state ID (eg, TCI-StateId), where N may be an index of a code point of a TCI (Transmission Configuration Indication) field of a DCI. N,M The TCI state of the TCI field (eg, corresponding to the TCI state ID) may represent, imply, and / or correspond to the Mth TCI state of the Nth code point in the TCI field indicated for the DCI. N,M ) is mapped to) one or more code points that can be mapped to) by using the code points with TCI status ID N,M The TCI state may be determined by the ordinal position in one or more TCI code points of the set of fields 210 (eg, in a MAC CE message).
[0117] In one example, if Figure 2 As shown, with TCI status ID 0,1 and / or TCI Status ID 0,2 The first TCI code point (e.g., in a MAC CE message) may be mapped to a code point value of 0 in the TCI field. 1,1 and / or TCI Status ID 1,2 The second TCI code point is mapped to the TCI field code point value 1, and so on. TCI State ID N,2 May be optional and / or may be based on the C i The maximum number of activated TCI code points (e.g., in a MAC CE message) may be 8. The maximum number of TCI states mapped to a TCI code point (e.g., a single TCI code point) may be 2. A TCI code point may belong to a MAC CE message. For example, the two TCI states mapped to a TCI code point may be TCI state IDs. N,1 and / or TCI Status ID N,2 The R field 202 may indicate and / or be set to a reserved bit. For example, the R field 202 may be set to 0. The first R field 202 (e.g., Figure 2 Oct 1) may be used to indicate a field of parameters used, for example, to monitor DCI.
[0118] exist Figure 2In the example shown, the R field 202 reserved in Oct 1 may be enhanced (e.g., used, replaced and / or changed) to a new field indicating parameters for monitoring DCI, which may indicate one or more TCI pools (e.g., Pool 1 or Pool 2, etc.). The TCI pool may be a unified TCI pool. The new field indicating parameters for monitoring DCI may be associated with one or more CORESETPoolIndex parameters, for example, one or more: TRP index, TRP indicator, TRP identification related parameters, CORESET group index, etc. The value of the parameter for monitoring DCI indicated by the MAC CE may indicate and / or select one or more TCI pools (e.g., Pool 1 or Pool 2, etc.). The TCI pool may be a unified TCI pool. The activated and / or indicated TCI in the MAC CE (e.g., which may be composed of one or more TCI state IDs) i,j Field indication) can be selected and / or activated in the indicated TCI pool, and the indicated TCI pool can be a unified TCI pool. For example, the indicated TCI pool (which can be a unified TCI pool) can be configured with a TRP (e.g., TRP1 and / or TRP2, etc.) and / or associated with it.
[0119] If the indication value of the new field indicating the parameter for monitoring DCI is 0, the WTRU may determine that the MAC CE message activates one or more TCI states (e.g., which may be, for example, a unified TCI state) of a pool (e.g., Pool1 and / or Pool1D for DL and Pool1U for UL, etc.) of the first TRP (e.g., the default TRP and / or the primary TRP). For example, the WTRU may be configured with two or more separate unified TCI pools for TRP (e.g., Pool1D for DL and Pool1U for UL). In one example, Pool1D includes one or more DL TCI states for DL beam indication (e.g., DL unified TCI state). Pool1U may include one or more UL TCI states for UL beam indication (e.g., UL unified TCI state). In one example, the TCI state of one or more UL TCI states (e.g., UL unified TCI state) may be further associated with one or more UL-related parameters. For example, the one or more UL-related parameters may be power control (PC) parameters and / or timing control parameters (e.g., timing advance (TA)), etc.
[0120] In one example, if the new field indicating the parameters for monitoring DCI is set to 0 and the C N field is set to 0, the WTRU may determine the TCI state ID based on determining that the new field indicating the parameters for monitoring DCI is set to 0. N,2The octet does not exist and the one unified TCI (which may be based on the TCI state ID, for example) N,1 ) for TRP1 (e.g., used as a primary TRP and / or a default TRP). Beam indication flexibility and efficiency can be increased. For example, a single unified TCI associated with a code point of the TCI field of the DCI (e.g., which can be based on the TCI state ID N,1 ) may be flexibly selected (e.g., by MAC CE) from one or more unified TCI pools (e.g., Pool1 for TRP1 and / or Pool2 for TRP2, etc.), and may or may not be fixed to the primary TRP and / or default TRP (e.g., TRP1). Increased beam indication flexibility and efficiency may be provided based on, for example, a new field in the MAC CE indicating a parameter for monitoring DCI (e.g., the parameter may be set to 0 or 1).
[0121] If the indication value of the new field indicating the parameter for monitoring DCI is 1, the WTRU may determine that the MAC CE message activates a second one or more TCI states (e.g., which may be a unified TCI state) of a pool (e.g., Pool2 or Pool2D for DL and Pool2U for UL, etc.) of a second TRP (e.g., a secondary TRP). For example, the WTRU may be configured with two or more separate unified TCI pools for TRPs (e.g., Pool2D for DL and Pool2U for UL, etc.). Pool2D may consist of one or more DL TCI states (which may be, for example, a unified TCI state) for DL beam indication. Pool2U may consist of one or more UL TCI states (which may be, for example, a unified TCI state) for UL beam indication. In one example, the TCI state of one or more UL TCI states (which may be, for example, a unified TCI state) may be further associated with one or more UL-related parameters. The UL-related parameters may be, for example, power control (PC) parameters and / or timing control (e.g., timing advance (TA)) parameters, etc.).
[0122] In one example, if the new field indicating the parameters for monitoring DCI is set to 1 and the C i field is set to 0, the WTRU may determine that there is no TCI State ID N,2 Based on determining that a new field indicating the parameters for monitoring DCI is set to 1, a unified TCI (which may be based on, for example, a TCI state ID N,1 ) can be used for TRP2 (which can be used as a secondary TRP, for example). Beam indication flexibility and efficiency can be increased. For example, a single unified TCI associated with the code point of the TCI field of the DCI (which can be based on the TCI state ID, for example) N,1) may be flexibly selected (e.g., selected by MAC CE) from one or more unified TCI pools (e.g., Pool1 for TRP1 and / or Pool2 for TRP2, etc.), and may or may not be fixed to the primary TRP and / or default TRP (e.g., TRP1). Increased beam indication flexibility and efficiency may be provided based on, for example, a new field in the MAC CE indicating a parameter for monitoring DCI (e.g., the parameter may be set to 0 or 1).
[0123] In one example, separate one or more DCI indications for each of one or more TRPs (e.g., TRP1 and TRP2) may implement a unified TCI indication for an M-TRP (e.g., via DCI). In one example, separate one or more DCI indications may be used for an MTRP based on multi-DCI (MDCI). For example, DCI1 received via a first one or more CORESETs (e.g., CORESET group 1) may indicate a unified TCI for TRP1 (e.g., a TRP associated with the first one or more CORESETs). DCI2 received via a second one or more CORESETs (e.g., CORESET group 2) may indicate a unified TCI for TRP2 (e.g., a TRP associated with the second one or more CORESETs). For example, the DCI for indicating the unified TCI (e.g., DCI1 and / or DCI2) may include DL-related DCI (e.g., DCI format 1_1 and / or DCI format 1_2, etc.). In one example, the DCI may include a DL assignment (e.g., DL data and / or PDSCH scheduling grant). In one example, the DCI may not include a DL assignment, eg, where the DCI may be applicable with or without a DL assignment.
[0124] In one embodiment, one or more common and / or single DCI indications for both TRP1 and TRP2 may implement a unified TCI indication for M-TRP (e.g., via DCI). One or more common and / or single DCI indications may be used for MTRP based on a single DCI (SDCI). For example, a DCI for indicating a unified TCI (e.g., with or without DL assignment) may include an explicit indicator (e.g., a TRP indicator) indicating whether the content of the DCI is used for and / or corresponds to TRP1. The explicit indicator (e.g., the TRP indicator) indicates whether the content of the DCI is used for and / or corresponds to TRP2. In an example, a DCI for indicating a unified TCI (e.g., with or without DL assignment) may include at least two parts of information content, wherein a first part of the at least two parts may include one or more first unified TCIs corresponding to TRP1, and a second part of the at least two parts may include one or more second unified TCIs corresponding to TRP2. In an example, both parts may be in a single DCI. For example, the WTRU may receive a DCI indicating a unified TCI (e.g., with or without a DL assignment). In response to the reception, the WTRU may determine whether the DCI is for and / or corresponds to TRP1 or TRP2 based on which CORESET is used to deliver the DCI. In one example, in response to determining that the DCI is received at the WTRU via a first CORESET (e.g., a first CORESET group), the WTRU may determine that the content of the DCI is for and / or corresponds to TRP1. In response to determining that the DCI is received at the WTRU via a second CORESET (e.g., a second CORESET group), the WTRU may determine that the content of the DCI is for and / or corresponds to TRP2.
[0125] When the indicated unified TCI (e.g., via DCI) is applied to one or more physical channels and / or signals (e.g., including at least CORESET), one or more of the following example examples may apply. In an example example, the WTRU may be configured with multiple unified TCIs (e.g., UTCIs) (e.g., as a unified TCI pool). In an example example, for example, when UTCI1 is indicated by DCI, the WTRU may be configured / indicated with information content that associates a first UTCI (e.g., UTCI1) of the multiple UTCIs with a first list of one or more physical channels and / or signals to which UTCI1 is applied. When UTCI2 may be indicated by DCI, the WTRU may be configured / indicated with information content that associates a second UTCI (e.g., UTCI2) of the multiple UTCIs with a second list of one or more physical channels and / or signals to which UTCI2 may be applied. In an example, when UTCI3 may be indicated by DCI, the WTRU may be configured / indicated with information content that associates a third UTCI (e.g., UTCI3) of the multiple UTCIs with a third list of one or more physical channels and / or signals to which UTCI3 may be applied. In one example, when UTCI4 may be indicated by DCI, the WTRU may be configured / indicated with information content associating a fourth UTCI (e.g., UTCI4) among the plurality of UTCIs with a fourth list of one or more physical channels and / or signals to which UTCI4 may be applicable. In one example, when UTCI3 may be indicated by DCI, the WTRU may be configured / indicated with information content associating a (e.g., first, second, third, fourth, etc.) UTCI (e.g., UTCI3) among the plurality of UTCIs with a (e.g., first, second, third, fourth, etc.) list of one or more physical channels and / or signals to which UTCI3 may be applicable. In an example instance, a list of one or more physical channels and / or signals (e.g., a first list, a second list, a third list, a fourth list, etc.) may include any one or a combination of one or more of the following: one or more CORESETs; one or more PDCCH candidates; one or more search spaces; one or more PDSCHs (e.g., PDSCH opportunities / configurations / instances / etc.); one or more RSs (e.g., CSI-RS, DMRS, SSB indexes, PRS, PTRS, and / or SRS); one or more PUSCHs (e.g., PUSCH opportunities / configurations / instances / etc.); one or more PUCCH resources (e.g., PUCCH resource sets / groups / etc.); one or more PRACH opportunities / resources / RSs, etc.
[0126] In one example instance, a method (e.g., regarding how to apply an indicated UTCI) may be applied. In the method for applying the indicated UTCI, the WTRU may determine which CORESET to apply, and the WTRU may (e.g., then) apply the indicated UTCI to the determined CORESET. For example, the WTRU may determine which CORESET to apply based on one or more of the following: based on determining that the DCI indicating the UTCI is sent via the CORESET, the WTRU may apply the indicated UTCI to the CORESET (which may include at least the determined CORESET); based on determining that the DCI indicating the UTCI is sent via the first CORESET, the WTRU may determine a second CORESET (which is different from the first CORESET and paired with the first CORESET) based on predefined or preconfigured parameters / information (e.g., at least TRP1 associated with the first CORESET and at least TRP2 associated with the second CORESET). The WTRU may apply the indicated UTCI to the CORESET based on determining that the DCI may indicate the CORESET through which the UTCI may be sent. In one example, the WTRU may receive a DCI that may indicate UTCI1, where the DCI may be sent via CORESET1 (e.g., corresponding to TRP1). In response to receiving the DCI and determining that the DCI is sent via CORESET1, the WTRU may apply the indicated UTCI1 to the determined CORESET1 (e.g., after beam application time (BAT) timing). In one example, the WTRU may receive a DCI that may indicate UTCI1 and UTCI2, where the DCI may be sent via CORESET1 (e.g., corresponding to TRP1). In response to receiving the DCI and determining that the DCI is sent via CORESET1, the WTRU may further determine that there is predefined and / or preconfigured TRP pair information (e.g., CORESET pair information, CORESET grouping information, etc.), for example, when two UTCIs are indicated together in a single DCI, CORESET1 and CORESET2 may be paired. For example, based on the TRP pair information (eg, a pair of {CORESET1, CORESET2}, etc.), the WTRU may determine that the indicated UTCI2 is applicable to CORESET2, and the WTRU may apply the indicated UTCI1 to CORESET1 and the indicated UTCI2 to CORESET2.In one example, a (e.g., individual) TRP may control its own UTCI beam update by signaling DCI using at least one CORESET associated with the TRP, which may, for example, improve UTCI update effectiveness and / or flexibility and / or reduce the complexity of UTCI update because the TRP may directly update UTCI for at least one CORESET associated with the TRP.
[0127] At a given time, one CORESET beam in a TRP may be updated with a UTCI indicated by a DCI sent from the TRP. In one example, the WTRU may determine a second CORESET (which may be different from the first CORESET and may be paired with the first CORESET) based on determining that the DCI indicating the UTCI is sent via the first CORESET. In one example, in combination or alternatively, the WTRU may determine the second CORESET based on predefined or preconfigured parameters / information (e.g., at least TRP1 associated with the first CORESET and at least TRP2 associated with the second CORESET). In one example, the WTRU may apply the indicated UTCI to the CORESETs (e.g., including at least the second CORESET). In one example, the WTRU may receive a DCI that may indicate UTCI1, where the DCI may be sent via CORESET1 (e.g., corresponding to TRP1). In response to receiving the DCI and determining that the DCI may be sent via CORESET1, the WTRU may further determine that CORESET2 may be associated with CORESET1 based on predefined and / or preconfigured parameters / information. In one example, the WTRU may apply the indicated UTCI1 to the determined CORESET2 (eg, after the BAT timing).
[0128] A WTRU may receive a DCI indicating UTCI1 and UTCI2, wherein the DCI is sent via CORESET1 (e.g., corresponding to TRP1). In response to receiving the DCI and determining that the DCI is sent via CORESET1, the WTRU may determine, for example, based on predefined or preconfigured parameters / information, that CORESET2 is associated with CORESET1, and there is predefined or preconfigured TRP pair information (e.g., CORESET pair information, CORESET grouping information, etc.), such that CORESET2 and CORESET3 are paired when two UTCIs are indicated together in a single DCI. For example, based on the TRP pair information (e.g., a pair of {CORESET2, CORESET3}, etc.), the WTRU may determine that the indicated UTCI2 is applicable to CORESET3. For example, based on the TRP pair information (e.g., a pair of {CORESET2, CORESET3}, etc.), the WTRU may apply the indicated UTCI1 to CORESET2 and apply the indicated UTCI2 to CORESET3. In one example, the UTCI indicated by the DCI delivered via a CORESET (e.g., corresponding to TRP1) may be applied to a second CORESET (e.g., corresponding to a TRP different from TRP1), which may improve the reliability of CORESET beam updates by avoiding self-beam update errors, such as when the DCI may be erroneously received at the WTRU.
[0129] A method for applying an indicated UTCI may be implemented. For example, based on information content associated with the indicated UTCI (in the indicated UTCI), the WTRU may determine which CORESET is associated with the indicated UTCI, and the WTRU may (e.g., then) apply the indicated UTCI to the determined CORESET. The WTRU may receive a DCI indicating UTCI1 and UTCI2 (e.g., as indicated by a TCI code point of the DCI). The WTRU may receive a DCI indicating a TCI value (e.g., where the TCI value may be indicated in a TCI field). The WTRU may determine, for example, based on first information content associated with UTCI1, that a first CORESET set may be associated with UTCI1. The WTRU may determine, for example, based on second information content associated with UTCI2, that a second CORESET set may be associated with UTCI2. In response to determining that the first CORESET set is associated with UTCI1 and the second CORESET set may be associated with UTCI2, the WTRU may apply the indicated UTCI1 to the first CORESET set and apply the indicated UTCI2 to the second CORESET set. In one example, the UTCI indicated by the DCI may be applied (e.g., simultaneously) to (e.g., at least one or more) CORESETs that may be pre-associated with the UTCI. For example, the WTRU may determine (e.g., based on information received by the WTRU) that a first CORESET is associated with a first TCI state instance and a second CORESET is associated with a second TCI state instance.
[0130] In an example UL aspect that may be based on a unified TCI for an MTRP, one or more UL TCIs may be updated for one or more partial and / or complete sets of TRPs. The WTRU may determine the UL-TCI and may apply it to transmissions to a subset of TRPs. For example, the WTRU may be associated with more than one (e.g., N) TRPs. The WTRU may receive an UL TCI indication that applies only to transmissions to a subset of n TRPs out of the N TRPs. The WTRU may receive an UL TCI command with an indication for one or more TRPs. For example, the indication for one or more TRPs may be a source RS, and the WTRU may determine that any UL-TCI with the same source RS ID may apply the UL-TCI. For example, the WTRU may be configured with TRP1 and TRP2, and the WTRU may determine that the UL-TCI is divided into TRP groups through source RS association (e.g., the source RS index for the UL TCI may belong to a group of RSs configured into the RS group for TRP1, such as a channel measurement resource (CMR) group). If the WTRU receives a grant for UL transmission to TRP1, the WTRU may determine to switch its spatial filter based on the UL TCI. If the WTRU receives a grant for UL transmission to TRP2, the WTRU may determine to use the spatial filter configured for TRP2. For example, the UL TCI may or may not be applicable to TRP2.
[0131] In one example, the WTRU may receive a unified UL TCI indication and an indication that the UL TCI may apply to all configured TRPs. For example, a UL TCI state may be configured with an additional flag. If the WTRU receives a UL TCI state with the flag turned on, the WTRU may determine to switch the UL spatial filter for any subsequent UL transmissions. For example, the WTRU may determine to switch the UL spatial filter without regard to the target TRP. If the WTRU receives a UL TCI state with the flag turned off, the UL TCI may apply to transmissions to the TRP associated with the UL TCI.
[0132] In one embodiment, one or more implicit UL TCI states may update one or more second TRPs using a first UL TCI state, which may be based on a unified TCI for the MTRP. The WTRU may determine the association between one or more UL TCI states from different pools (e.g., different TRPs) and / or UL TCI states within a pool (e.g., two TRPs in the same pool). For example, one or more pairings of UL TCI states may correspond to one or more pairings of TRPs. One or more pairings may be through a bitmap in the TCI state configuration, and / or through an association between source RS pairs (e.g., CSI-RS IDs from different CMR groups paired together). If the WTRU receives a UL TCI state indication for one index in the pair, the WTRU may determine to update its UL TCI state for the other index in the pair based on the linked TCI state. For example, the WTRU may be configured with UL TCI1 and UL TCI2 for TRP1 and TRP2, respectively, and the UL TCIs may be associated together. If the WTRU receives a UL TCI indication with UL TCI1 for TRP1, the WTRU may implicitly determine that the UL TCI for TRP2 is the UL TCI associated with UL TCI1, such as UL TCI2.
[0133] UL TCI may be provided for simultaneous UL transmission to multiple TRPs. In one example, the WTRU may receive a UL TCI with a TCI state associated with a transmission mode and / or assumption. For example, the transmission mode may be simultaneous transmission, where the WTRU may transmit to two TRPs in the same time unit (e.g., time slot, symbol). For example, the WTRU may receive a UL TCI in which one TCI code point may be configured with two TCI states associated with two different TRPs. The WTRU may determine that the code point can be used for simultaneous UL transmission. If the WTRU receives a grant with the code point and the TCI states are associated with different panels, the WTRU may determine to adjust its spatial filter to transmit simultaneously on the same time resource using different panels. If the TCI states are associated with the same panel, the WTRU may determine to adjust its spatial filter in a time division multiplexing (TDM) mode. The TDM mode may be preconfigured (e.g., cyclic and / or sequential, etc.) and / or configurable. The TDM mode may be configured in the TimeDomainResourceAllocation (TDRA) table so that the TDRA table index may indicate a mapping of the UL TCI state to one or more scheduled granted resources. In one example, a UL TCI codepoint with two TCI states may be configured with an explicit flag to signal the associated transmission mode. The WTRU may determine whether to use the TCI states simultaneously based on the flag. If the flag is on, the WTRU may determine that both TCI states can be used for simultaneous uplink transmission. If the flag is off, the WTRU may determine that both TCI states can be used for non-simultaneous transmission.
[0134] In one embodiment, power control parameters may be associated with UL TCI states. For example, the WTRU may determine a set of one or more power control parameters (e.g., closed-loop and open-loop parameters such as pathlossReferenceRS-Id, TPC, P0, and / or α, etc.) associated with one or more UL TCI states based on the UL TCI pool index. For example, when separate UL TCI pools are configured (e.g., Pool1 for TRP1 and Pool2 for TRP2, etc.), the WTRU may determine to use one set of power control parameters for TRP1 upon receiving an indication to use UL TCI from Pool1, and may determine to use a second set of power control parameters for TRP2 upon receiving an indication to use UL TCI from Pool2.
[0135] In one example, if one or more UL TCIs for one or more TRPs are configured in a single pool, the WTRU may receive a configuration with two power control parameter sets per UL TCI state. For example, each power control parameter set may be associated with a TRP identity (e.g., such as by RS index or CORESETpoolindex). For example, one UL TCI state may be configured with pathlossReferenceRS-Id1 and pathlossReferenceRS-Id2 as path loss references for TRP1 and TRP2, respectively.
[0136] Figure 3 An example process 300 for UL-TCI is illustrated. For example, the UL-TCI IE may be configured with two pathlossreferenceRS, such as Figure 3 As shown. The power control parameter set in the UL-TCI state may be semi-statically configured (e.g., RRC) or dynamically indicated (e.g., MAC-CE and / or DCI, etc.) per UL TCI pool or per UL TCI state. For example, the WTRU may receive a UL TCI state with two configured power control parameter sets. The WTRU may receive a MAC-CE indicating activation of a UL TCI state with a first power control parameter set. The WTRU may receive a flag (e.g., 0 or 1) in the MAC-CE indicating whether the first power control parameter set or the second power control parameter set is activated. The activation MAC-CE may include an explicit field for configuring the power control parameters. For example, the WTRU may activate the UL TCI with a P0 value indicated in the MAC-CE. The WTRU may determine its transmit power for the UL TCI state based on the power control parameter set activated by the received flag.
[0137] In one embodiment, both power control sets may be activated in a single UL TCI state. The MAC-CE may include a flag per power control parameter set and the flag may be activated for both sets. The WTRU may determine its transmit power for the UL TCI state based on the two activated power control parameter sets and based on the received scheduling grant. For example, the WTRU may receive a scheduling grant indicating PUSCH repetitions or multiple PUSCH transmissions toward more than one TRP and having an indication to use a UL TCI state with more than one activated power control parameter set. In one example, the WTRU may adjust its UL spatial filter to the indicated UL TCI and may use a first power control parameter set when transmitting to TRP1 and a second power control parameter set when transmitting to TRP2. The WTRU may determine the association between the power control parameter set and the TRP based on a mapping of the PUSCH transmission to the timeslot index indicated in the DCI (e.g., based on the time domain resource assignment (TDRA) field). The PUSCH transmission may be, for example, a repetition of a codeword and / or a different codeword (e.g., one or more multiple PUSCH transmissions).
[0138] In one embodiment, the WTRU may be configured in SeparateDL ULTCI, where the first indicated unified TCI state and the second indicated unified TCI state (e.g., the first RS and the second RS) may be used as the source RS for the downlink transmission and the uplink transmission, respectively. In one example, the WTRU may be configured in JointTCI mode, where the same RS may be used as the source reference signal for both the uplink transmission and the downlink transmission.
[0139] For example, a WTRU equipped with multiple panels may be configured with more than one unified TCI configuration. For a multi-panel WTRU, different combinations of unified TCI configurations may be considered. In one example, the WTRU may be configured with more than one SeparateDL ULTCI configuration, where each configuration may be applied to a different panel. In this configuration, for example, the WTRU may use different RS sources for UL transmission and DL transmission of each panel respectively. In one example, the WTRU may be configured with a semi-SeparateDL ULTCI configuration, where the WTRU may use the first RS as the RS source for uplink transmission of all panels, and then use the remaining RS as the source RS for downlink transmission of the remaining panels (e.g., a panel set, a first one or more panels, etc.). In one example, the WTRU may be configured with a semi-SeparateDL ULTCI configuration, where the WTRU may use the first RS as the RS source for downlink transmission of all panels, and then use the remaining RS as the source RS for uplink transmission from the remaining panels (e.g., a panel set, a second one or more panels, etc.). In one example, the WTRU may be configured with more than one JointTCI configuration, where each configuration may be applied to a different panel. In an example configuration, the WTRU may use the same RS source for UL transmissions and / or DL transmissions from and / or to each panel. In one solution, the WTRU may be configured with at least one of each SeperateDLULTCI and JointTCI configurations, where each configuration may apply to at least one panel. In this configuration, for at least one panel, the WTRU may use the same RS as the source RS for both uplink and downlink transmissions, while for the remaining panels, the WTRU may use different RS sources for UL and DL transmissions.
[0140] In one embodiment, a multi-panel WTRU may be semi-statically configured using a combination of the above-described unified TCI configurations, and the WTRU may dynamically determine a preferred operating mode based on the combination of the unified TCI configurations. In one example, the dynamic indication may be accomplished through explicit signaling (e.g., MAC CE, DCI, etc.). In one example, the dynamic indication may be implicitly accomplished based on other system operating characteristics and / or features. In one example, the WTRU may determine the type of unified TCI configuration adopted based on the transmission mode (e.g., single TRP and / or multiple TRPs, etc.). In one example, the WTRU may use one mode of the unified TCI configuration per panel for a single TRP transmission, and another mode for multiple TRP transmissions. In one example, a WTRU configured with a secondary uplink (SUL) operation may use one type of unified TCI configuration for the main link, and may use a simplified unified TCI (e.g., UL TCI) for the SUL link. In one example, the WTRU may be configured with more than one unified TCI configuration, where the WTRU may determine the type of unified TCI configuration adopted (e.g., for a panel and / or for all activated panels, etc.) based on the number of configured SRS ports, the number of activated panels, antenna groups, etc.
[0141] In an example multi-TRP transmission scenario, the WTRU may determine the mode of unified TCI configuration for each panel. For example, the WTRU may determine the mode of unified TCI configuration based on one or more of the following embodiments. In one embodiment, the WTRU may determine the mode of unified TCI configuration based on the TRP associated with the panel. In an exemplary embodiment, the WTRU may use an operating mode, such as SeparateDLULTCI for transmission involving the main TRP, and another operating mode, such as JointTCI for another TRP. For example, a WTRU equipped with only a single panel may apply a similar method to determine the unified TCI configuration. In one embodiment, the WTRU may determine the mode of unified TCI configuration based on signal quality measurements (e.g., RSRP, etc.). In one example, if the measured RSRP is higher than the configured threshold, the WTRU may use the JointTCI configuration. For example, a WTRU equipped with only a single panel may apply a similar method to determine the unified TCI configuration.
[0142] In one example, the WTRU may determine the mode of the unified TCI configuration based on a blockage or proximity metric. For example, if the signal quality measurement is impaired due to signal blockage, the WTRU may switch from one mode of the unified TCI configuration to another mode. For example, if the WTRU is initially configured with a JointTCI configuration, it may switch to a configured SeparateDLULTCI configuration to have more reliable transmission and reception. In a multi-panel WTRU, the WTRU may independently determine the mode of the unified TCI configuration based on the blockage of each panel. Once the WTRU changes the mode of the unified TCI configuration of a panel, the corresponding mode of another panel may be changed to the same or another preconfigured mode. In one example, the WTRU may receive a value as the validity period of the configured unified TCI configuration. For example, the WTRU may receive a first indication for turning on the applicability of the unified TCI configuration, and a second indication for terminating such applicability. Once the applicability period expires, the WTRU may fall back to a default mode of TCI configuration (e.g., where the default mode of TCI configuration may be predefined or preconfigured by the gNB, which may be a JointTCI mode, a SeparateDLULTCI mode, or a legacy TCI mode (e.g., as an individual TCI indication mode)). The WTRU may receive one or more time and / or frequency usage patterns to determine the validity period of one or more configured unified TCI configurations per portion of time and / or frequency units (e.g., time slot, frequency band, bandwidth part (BWP), subband, CC, etc.).
[0143] The WTRU may be configured and / or indicated with one or more BWP and / or CC lists containing one or more BWPs and / or CCs for simultaneous TCI update. For example, a first list in the one or more BWP and / or CC lists may include a first one or more BWP and / or CC index, and a second list in the one or more BWP and / or CC lists may include a second one or more BWP and / or CC index, and so on. In one example, the WTRU may receive a first indication of a unified TCI via a first BWP and / or CC of the first list. In response to receiving the first indication of the unified TCI, the WTRU may apply the first one or more unified TCIs to one or more or all BWPs and / or CCs (e.g., including the first BWP and / or CC) in the first list simultaneously based on the first indication. In one example, when indicating the first one or more unified TCIs across multiple BWPs and / or CCs (e.g., included in the first list) by using a single indication message (e.g., the first indication), overhead and latency may be reduced. The WTRU may receive a second indication of the unified TCI via a second BWP and / or CC of the second list. In response to the reception, the WTRU may apply the second one or more unified TCIs to one or more or all BWPs and / or CCs in the second list (including, for example, the second BWP and / or CC) simultaneously based on the second indication. This may provide benefits in terms of reducing overhead and latency when indicating the second one or more unified TCIs across multiple BWPs and / or CCs (e.g., included in the second list) using a single indication message (e.g., the second indication).
[0144] In one example, a list in one or more BWP and / or CC lists (e.g., a first list, a second list, etc.) may include one or more BWP and / or CC indexes, wherein a first index in the one or more BWP and / or CC indexes may be associated with a single TRP for communicating with the WTRU (including, for example, corresponding to, including, indicating, using, adopting, mapped / linked to and / or configured / activated / indicated, etc.), and a second index in the one or more BWP and / or CC indexes may be associated with more than one TRP (e.g., M-TRP, for example, TRP1 and / or TRP2, etc.) for communicating with the WTRU (including, for example, corresponding to, including, indicating, using, adopting, mapped / linked to and / or configured / activated / indicated, etc.). Hereinafter, for simplicity, the list may be and / or may include a first list, wherein the first list may include at least a first BWP and / or CC index associated with TRP1a (e.g., as a single TRP) and / or a second BWP and / or CC index associated with TRP2a and TRP2b (e.g., as 2 TRPs), however, the proposed solution and process may be similarly (or equivalently or extendedly, etc.) applied to other lists (e.g., a second list) of the one or more BWP and / or CC lists for the case of simultaneous TCI updates, wherein the second list may include more than one BWP and / or CC index each associated with a single TRP, and / or more than one BWP and / or CC index each associated with more than one TRP. The WTRU may be configured with a reference (unified) TCI state pool (e.g., via RRC and / or MAC-CE), wherein the reference TCI state pool may be configured in reference BWPs and / or CCs (e.g., in the first list, included in the first list, or individually configured to not be included in the first list, etc.). In one example, the WTRU may determine that the configuration / parameters for the (unified) TCI state pool are not configured for (e.g., not present in the PDSCH configuration (e.g., PDSCH-config) of) the first BWP and / or CC index. In response to the determination, the WTRU may apply the reference (unified) TCI state pool to the first BWP and / or CC index, for example based on a parameter indicating the reference TCI state pool or through a default / predefined / preconfigured WTRU behavior. In one example, the necessary unified TCI state pool in the first BWP and / or CC index (where, in one example, the unified TCI may be further indicated) may be replaced by the reference (unified) TCI state pool for further indication of the unified TCI in the first BWP and / or CC associated with the first BWP and / or CC index.
[0145] In one example, if at least one BWP and / or CC in the first list is configured with / associated with an M-TRP, the WTRU may expect, assume, identify and / or determine (e.g., the gNB should configure, apply and / or ensure) that the reference BWP and / or CC (e.g., of the first list) may be configured with / associated with an M-TRP. In one example, the WTRU may receive a first indication (e.g., via a DCI) of more than one TCI (which may be, for example, a unified TCI). The indication may be, for example, TCI#X and / or TCI#Y (which may be, for example, outside of a pool of one or more reference TCI states configured in the reference BWP and / or CC). In response to receiving the first indication, the WTRU may apply a first located unified TCI (e.g., TCI#X) among more than one TCI (which may be, for example, a unified TCI) as a unified TCI for communicating with TRP1a, and may apply (in one example, simultaneously) the first located unified TCI (e.g., TCI#X) and the second located unified TCI (e.g., TCI#Y), respectively, and may be two unified TCIs for communicating with TRP2a and TRP2b. A reduction in overhead and / or latency for indicating one or more more unified TCIs may be achieved. For example, a reduction in overhead and / or latency may be achieved by using a single indication message (e.g., a first indication) to indicate one or more more unified TCIs (which may, for example, include a list, such as a first list for simultaneous TCI updates) for M-TRP scenarios and / or operations across one or more BWPs and / or CCs. Based on an efficient strategy for network planning and / or deployment, each of one or more BWPs and / or CCs may be flexibly adopted and / or associated with a single TRP and / or more than one TRP.
[0146] In one example, the WTRU may determine that the BWP and / or CC ID (e.g., BWP and / or CC indicator, BWP-ID, cell, etc.) of one or more source RSs with RS IDs in QCL-related parameters (such as, for example, QCL-Info) included in the indicated TCI (e.g., at least one large-scale radio channel parameter and / or at least one quasi-co-location (QCL) type parameter among Doppler spread, Doppler shift, average delay, delay spread, and / or spatial Rx) may not be present. The indicated TCI may be, for example, a unified TCI. The indicated TCI may be, for example, TCI#X and / or TCI#Y of more than one unified TCI indicated by the first indication. In one example, the BWP and / or CC ID is not included in the one or more source RSs of the QCL-related parameters, such as TCI#X and / or TCI#Y. In response to the WTRU determining that the BWP and / or CC ID of one or more source RSs with RS IDs may not exist, the WTRU may apply a first one or more RSs including, having and / or associated with the one or more RS IDs in a first BWP and / or CC (e.g., associated with a first BWP and / or CC index) for communicating with the gNB via the first BWP and / or CC. In one example, the one or more RS IDs may be the same RS ID and / or may be the same as the one or more source RSs of the QCL type for the indicated unified TCI. In response to the WTRU determining that the BWP and / or CC ID of one or more source RSs with RS IDs may not exist, the WTRU may apply a second one or more RSs including, having and / or associated with the one or more RS IDs in a second BWP and / or CC (e.g., associated with a second BWP and / or CC index) for communicating with the gNB via the second BWP and / or CC. For example, the second one or more RSs may be the same RS ID and / or may be the same as the source RS of the QCL type for the indicated unified TCI.
[0147] In one embodiment, the WTRU may determine that a first BWP and / or CC ID (e.g., BWP and / or CC indicator, bwp-ID, cell, etc.) included in an indicated TCI of one or more source RSs having an RS ID does not exist. For example, the indicated TCI may be an indicated unified TCI. For example, TCI#A may be an indicated single unified TCI. For example, the first BWP and / or CC ID may not be included in one or more source RSs of the QCL-related parameters, such as TCI#A. In response to the WTRU determining that a first BWP and / or CC ID of one or more source RSs having an RS ID included in the indicated TCI does not exist, the WTRU may apply a first one or more RSs including, having and / or associated with the RS ID in a first BWP and / or CC (associated with the first BWP and / or CC index) for communicating with a single TRP (e.g., TRP1a) (of the gNB) via the first BWP and / or CC. For example, the RS ID may be the same RS ID and / or may be the same as the source RS of the QCL type used for the indicated unified TCI (e.g., TCI#A). In response to the WTRU determining that a first BWP and / or CCID of one or more source RSs (having an RS ID included in the indicated TCI) is not present, the WTRU may apply a second one or more RSs including, having and / or associated with the RS ID in a second BWP and / or CC (e.g., associated with a second BWP and / or CC index) for communicating with a first TRP (e.g., TRP2a, i.e., a primary TRP / default TRP) of a plurality of TRPs (e.g., TRP2a and TRP2b) via the second BWP and / or CC. For example, the RSID may be the same ID and / or may be the same as the source RS of the QCL type for the indicated unified TCI (e.g., TCI#A). In one example, the WTRU may be (e.g., explicitly) indicated and / or configured (e.g., based on parameters for indication and / or explicit TRP indicators) to which TRP (e.g., TRP2a or TRP2b) the indicated TCI (which may be, for example, a unified TCI) is to be applied. For example, when the WTRU receives a single TCI indication (which may be, for example, a unified TCI indication), for example, via a DCI, the WTRU may be indicated and / or configured to apply to BWPs and / or CCs that employ more than one (e.g., configured / activated) TRP. Operational efficiency and / or flexibility may be achieved. For example, the gNB may flexibly configure and / or indicate BWPs and / or CCs to the WTRU based on an efficient strategy for network planning / deployment of multiple TRPs, for example, with respect to the geographic location of each TRP across different BWPs and / or CCs (e.g., flexibly configured and / or indicated to the WTRU).
[0148] In one example, the WTRU may determine that a first BWP and / or CC ID of a first one or more source RSs having a first RS ID included in a first TCI in an indicated TCI, and / or a second BWP and / or CC ID of a second one or more source RSs having a second RS ID included in a second TCI in an indicated TCI, do not exist, and / or a second BWP and / or CC ID of a second one or more source RSs having a second RS ID included in a second TCI in an indicated TCI, the first TCI may be, for example, a unified TCI (e.g., TCI#A), the second TCI may be, for example, a unified TCI (e.g., TCI#B), the indicated TCI may be, for example, a unified TCI (e.g., TCI#A and TCI#B as more than one unified TCI indicated) do not exist. In response to the WTRU determining that the first BWP and / or CC ID and / or the second BWP and / or CC ID do not exist, the WTRU may determine (e.g., apply) a first one or more RSs including and / or associated with the first RS ID in a first BWP and / or CC (e.g., associated with the first BWP and / or CC index) for communicating with a single TRP (e.g., TRP1a and / or the like) (of the gNB) via the first BWP and / or CC. In one example, the first RS ID may be the same RS ID and / or may be the same RS ID as one or more source RSs of the QCL type of the indicated unified TCI (eg, TCI#A, etc.).
[0149] In response to the WTRU determining that the first BWP and / or CC ID and / or the second BWP and / or CC ID do not exist, the WTRU may determine (e.g., apply) in the second BWP and / or CC (associated with the second BWP and / or CC index) a second one or more RSs including (e.g., having, associated with) the (same) first RS ID (as a source RS of the QCL type for the indicated first unified TCI (e.g., TCI#A)) for communicating with a first TRP (e.g., TRP2a, i.e., the primary TRP / default TRP) of a plurality of TRPs (e.g., TRP2a and TRP2b) via the second BWP and / or CC, and determine a third one or more RSs including, having and / or associated with the second RSID for communicating with a second TRP (e.g., TRP2b) of the plurality of TRPs. In an example, the one or more second RS IDs may be the same second RS ID and / or may be the same as the one or more source RSs of the QCL type for the indicated second unified TCI (e.g., TCI#B, etc.). In one example, for example, when the WTRU receives multiple unified TCIs indicated, for example, via DCI, to be applied to BWPs and / or CCs by adopting a single (configured / activated) TRP, the WTRU may be (e.g., explicitly) indicated and / or configured, for example, based on a parameter for indication and / or an explicit TCI indicator (which may be, for example, a location indicator), as to which indicated TCI (which may be a unified TCI (e.g., TCI#A or TCI#B)) of the indicated multiple unified TCIs (e.g., TCI#A and TCI#B) to apply to a single TRP (e.g., TRP1a). Increased operational efficiency and flexibility may be achieved, for example, because the gNB may flexibly configure and / or indicate BWPs and / or CCs to the WTRU based on an efficient strategy for network planning / deployment of multiple TRPs, for example, in terms of the geographical location of each TRP across different BWPs and / or CCs (which may, for example, be flexibly configured and / or indicated to the WTRU).
[0150] In one embodiment, for example, where the gNB configuration of the WTRU does not allow mixing of S-TRPs and M-TRPs across BWPs and / or CCs in the first list, the WTRU may expect, assume, identify and / or determine (e.g., the gNB should configure, apply and / or ensure) that all BWPs and / or CCs in the first list are configured with (e.g., indicated, activated and / or associated with) more than one TRP (e.g., as M-TRPs) for each BWP and / or CC in the first list, or are configured with (e.g., indicated, activated and / or associated with) a single TRP (e.g., as an S-TRP) for each BWP and / or CC in the first list. For example, by simplifying one or more allowed configurations for M-TRP operations and / or scenarios, a reduction in implementation complexity (e.g., for the WTRU) and an improvement in efficiency may be achieved. In one example, the WTRU may expect, assume, identify and / or determine (e.g., the gNB should configure, apply and / or ensure) that one or more or all BWPs and / or CCs in the first list are configured, indicated, activated and / or associated with more than one TRP (e.g., as M-TRPs) for each BWP and / or CC in the one or more or all BWPs and / or CCs in the first list. In one example, the WTRU may receive a secondary cell (SCell) (e.g., CC, BWP, cell, BWP and / or CC) activation message (e.g., via MAC-CE), wherein the SCell activation message may include parameters for selecting, selecting and / or determining which TRP of more than one TRP (e.g., S-TRP or M-TRP with TRP-ID indication) is used for an activated CC (e.g., activated based on the Scell activation message). Increased operational efficiency and flexibility may be achieved, for example, because the gNB may flexibly configure and / or indicate the BWP and / or CC being operated / used based on which TRP will communicate with the WTRU more dynamically (e.g., based on which TRP is selected on a per BWP and / or CC basis). For example, the TRP may communicate with the WTRU via MAC-CE.
[0151] Figure 4 is a diagram illustrating an example of a unified TCI with M-TRP across multiple BWPs and / or CCs. Figure 4As shown, the WTRU 402 may receive (e.g., from the gNB 404 via RRC) one or more of the following configurations: CC1 is configured with an S-TRP (e.g., TRP1a), CC2 is configured with an M-TRP (e.g., TRP2a, TRP2b), CC3 is configured with an S-TRP (e.g., TRP3a), CC4 is configured with an M-TRP (e.g., TRP4a, TRP4b), and / or those CCs (e.g., CC1, CC2, CC3, CC4) are included in a list of one or more BWP and / or CC lists for (e.g., configured) simultaneous TCI updates. The WTRU may receive DCI 406 from a CC (e.g., CC1 408) that includes a single TRP, which indicates a unified TCI, e.g., TCI1, based on a code point (e.g., '000') of the TCI field of the DCI. In response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list. In one example, this may occur where (in CC1) TCI1 is available / applied as a unified TCI for communicating with a single TRP (e.g., TRP1a). In some examples, this may occur where (in CC2) TCI1 is available / applied as a unified TCI for communicating with a TRP in multiple TRPs (the TRP being, for example, TRP2a (e.g., by default as a primary TRP and / or default TRP) or TRP2b (if (e.g., explicitly) configured and / or instructed to do so)). In some examples, this may occur where (in CC3) TCI1 is available / applied as a unified TCI for communicating with a single TRP (e.g., TRP3a). Further, in some examples, this may occur where (in CC4) TCI1 may be used / applied as a unified TCI for communicating with a TRP in multiple TRPs, such as TRP4a (e.g., by default as a primary / default TRP) or TRP4b (if (explicitly) configured / instructed to do so). Any of the foregoing examples may occur alone or in combination with any of the other examples, or all together. The beams and / or TCIs used to communicate with TRPs to which the unified TCI is not applied (e.g., TRP2b and / or TRP4b, etc.) may remain unchanged (e.g., their current beams and / or TCIs may be maintained).
[0152] Figure 5 is a diagram illustrating an example of a unified TCI with M-TRP across multiple BWPs and / or CCs. Figure 5As shown, the WTRU 502 may receive (e.g., via RRC, from a gNB 504 and / or the like) one or more of the following configurations: CC1 is configured with an S-TRP (e.g., TRP1a), CC2 is configured with an M-TRP (e.g., TRP2a, TRP2b), CC3 is configured with an S-TRP (e.g., TRP3b*), CC4 is configured with an M-TRP (e.g., TRP4a, TRP4b), and / or those CCs (e.g., CC1, CC2, CC3, CC4) are included in a list of one or more BWP and / or CC lists for (configured) simultaneous TCI updates. The WTRU may receive DCI 506 from a CC (e.g., CC3 508) that includes a single TRP, which indicates a unified TCI, e.g., TCI11, based on the code point (e.g., '001') of the TCI field of the DCI. In response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI11) to multiple CCs in the list. In some examples, in response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI11) to multiple CCs in the list, where, in CC1, no beam / TCI may be changed / updated in response to the DCI. In some examples, in response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI11) to multiple CCs in the list, where, in CC2, TCI11 may be used / applied as a unified TCI for communicating with a TRP in multiple TRPs (the TRP is, for example, TRP2b, based on being (explicitly) configured / instructed to do so). In addition, in some examples, in response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI11) to multiple CCs in the list, where, in CC3, TCI11 may be used / applied as a unified TCI for communicating with a single TRP (e.g., TRP3b*).
[0153] For example, CC3 may be configured with a single TRP ("S-TRP") (TRP3b*). TRP3b* may be associated with a secondary TRP in another CC having an MTRP. In one example, this may occur where (in CC4) TCI11 may be used / applied as a unified TCI for communicating with a TRP in multiple TRPs (the TRP being, for example, TRP4b, based on being (explicitly) configured / instructed to do so). Any of the foregoing examples may appear alone or in combination with any of the other examples, or all together. In one example, a BWP and / or CC (e.g., configured with a single TRP, e.g., TRP3b*) may be (e.g., explicitly) configured, associated and / or indicated as follows: a single TRP (e.g., TRP3b*) may be associated with a second position and / or order of TRPs in multiple TRPs in other BWPs and / or CCs that employ more than one TRP (M-TRP). The second position / order of the TRPs may be, indicate and / or include a TRP that is not a primary TRP and / or a default TRP. Increased operational efficiency and / or flexibility may occur, for example, because the gNB may flexibly configure and / or indicate BWPs and / or CCs to the WTRU based on an efficient strategy for network planning / deployment of multiple TRPs, for example, in terms of the geographical location of each TRP across different BWPs and / or CCs. For example, TRP1a, TRP2a, and TRP4a may be located at a first geographical location (which may be, for example, close to the first geographical location), and TRP2b, TRP3b*, TRP4b may be located at a second geographical location (which may be, for example, close to the first geographical location), so that the indicated unified TCI may be simultaneously applicable to TRPs located at the same geographical location, which further provides benefits in terms of reduced overhead for indicating a unified TCI across multiple BWPs and / or CCs.
[0154] Figure 6 is a diagram illustrating an example of a unified TCI with M-TRP across multiple BWPs and / or CCs. Figure 6As shown, the WTRU 602 may receive (e.g., from the gNB 604 via RRC) one or more of the following configurations: CC1 is configured with an S-TRP (e.g., TRP1a), CC2 is configured with an M-TRP (e.g., TRP2a, TRP2b, etc.), CC3 is configured with an S-TRP (e.g., TRP3a), CC4 is configured with an M-TRP (e.g., TRP4a, TRP4b, etc.), and / or those CCs (e.g., CC1, CC2, CC3, CC4, etc.) are included in a list of one or more BWP and / or CC lists for (e.g., configured) simultaneous TCI updates. The WTRU may receive DCI 606 from a CC (e.g., CC2 608) that includes more than one TRP, the DCI indicating a unified TCI, e.g., TCI1, of a first TRP (e.g., TRP2a) from more than one TRP based on a code point (e.g., 000) of the TCI field of the DCI.
[0155] In response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list. For example, in response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list, in which scenario, in CC1, TCI1 may be used / applied as a unified TCI for communication with a single TRP (e.g., TRP1a). For example, in response to receiving the DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list, in which scenario, in CC2, TCI1 may be used / applied as a unified TCI for communication with a TRP in multiple TRPs (the TRP is, for example, TRP2a (e.g., defaulted as the primary TRP / default TRP) or TRP2b (if (explicitly) configured / instructed to do so)). For example, in response to receiving a DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list, in which scenario, in CC3, TCI1 may be used / applied as a unified TCI for communicating with a single TRP (e.g., TRP3a). For example, in response to receiving a DCI, the WTRU may simultaneously update and / or apply a unified TCI (e.g., TCI1) to multiple CCs in the list, in which scenario, in CC4, TCI1 may be used / applied as a unified TCI for communicating with a TRP in multiple TRPs (the TRP being, for example, TRP4a (e.g., defaulting to the primary TRP / default TRP) or TRP4b (if (explicitly) configured / instructed to do so)). Any of the foregoing examples may appear alone or in combination with any of the other examples, or all together. In one example, the beam and / or TCI used to communicate with a TRP (e.g., TRP2b, TRP4b) to which the unified TCI is not applied may remain unchanged (e.g., its current beam and / or TCI may be maintained). In one example, in response to receiving a DCI, the WTRU may (be configured to) simultaneously update and / or apply a unified TCI (e.g., TCI1) to one or more CCs (e.g., CC1 and / or CC3), each CC including a single TRP (e.g., neither including more than one TRP), and / or not update and / or apply a unified TCI (e.g., TCI1) to at least one TRP in CC2 and CC4 (e.g., because each of CC2 and CC4 includes more than one TRP).
[0156] Figure 7 is a diagram illustrating an example of a TCI with M-TRP across multiple BWPs and / or CCs. Figure 7As shown, the WTRU 702 may receive (e.g., via RRC, from the gNB 704) one or more of the following configurations: CC1 is configured with an S-TRP (e.g., TRP1a), CC2 is configured with an M-TRP (e.g., TRP2a, TRP2b), CC3 is configured with an S-TRP (e.g., TRP3b*), CC4 is configured with an M-TRP (e.g., TRP4a, TRP4b), and / or those CCs (e.g., CC1, CC2, CC3, CC4) are included in a list of one or more BWPs and / or CC lists for (configured) simultaneous TCI updates. For example, CC3 may be configured with an S-TRP (TRP3b*). TRP3b* may be associated with a secondary TRP in other CCs that have an MTRP. The WTRU may receive a DCI 706 from a CC (eg, CC2 708) that includes more than one TRP, which indicates a unified TCI, eg, TCI11, of a second TRP (eg, TRP2b) from the more than one TRP based on the code point (eg, '001') of the TCI field of the DCI.
[0157] In response to receiving a DCI, the WTRU may simultaneously update / apply a unified TCI (e.g., TCI11) to multiple CCs in the list. In response to receiving a DCI, the WTRU may simultaneously update / apply a unified TCI (e.g., TCI11) to multiple CCs in the list, wherein, in CC1, for example, based on determining that the unified TCI (TCI11) is indicated from the second position / order of a TRP (TRP2b) in CC2 and TRP1a in CC1 may correspond to the first position / order of a TRP (TRP1a, e.g., as a primary TRP / default TRP), no beam / TCI may be changed / updated in response to the DCI. For example, in response to receiving a DCI, the WTRU may simultaneously update / apply a unified TCI (e.g., TCI11) to multiple CCs in the list, wherein, in CC2, TCI11 may be used / applied as a unified TCI for communicating with a TRP (e.g., TRP2b, as the aligned (second) position / order of the TRP) among multiple TRPs. For example, in response to receiving a DCI, the WTRU may simultaneously update / apply a unified TCI (e.g., TCI11) to multiple CCs in the list, wherein, in CC3, TCI11 may be used / applied as a unified TCI for communicating with a single TRP (the TRP is, for example, TRP3b*, based on being (explicitly) configured / instructed to do so). For example, in response to receiving a DCI, the WTRU may simultaneously update / apply a unified TCI (e.g., TCI11) to multiple CCs in the list, wherein, in CC4, TCI11 may be used / applied as a unified TCI for communicating with a TRP (e.g., TRP4b, as the aligned (second) position / order of the TRPs) among multiple TRPs.
[0158] Any of the foregoing examples may appear alone or in combination with any of the other examples, or all together. In one example, a BWP and / or CC (e.g., configured with a single TRP, e.g., TRP3b*) may be (explicitly) configured, associated, and / or indicated as follows: a single TRP (e.g., TRP3b*) may be associated with a second position / order of TRPs among multiple TRPs in other BWPs and / or CCs that employ more than one TRP (M-TRP). The second position / order of the TRPs may be (e.g., indicating, including) a TRP that is not a primary TRP / default TRP. This can provide benefits in terms of improving operational efficiency and flexibility as the gNB can enable efficient strategies for network planning / deployment based on multiple TRPs, for example, flexibly configuring / indicating BWPs and / or CCs to the WTRU with respect to the geographical location of each TRP across different BWPs and / or CCs (for example, where TRP1a, TRP2a, and TRP4a may be located at a first geographical location (close), and TRP2b, TRP3b*, TRP4b may be located at a second geographical location (close), so that the indicated unified TCI can be simultaneously applicable to TRPs located at the same geographical location, which further provides benefits in terms of reducing overhead when indicating a unified TCI across multiple BWPs and / or CCs).
[0159] Figure 8 is a diagram illustrating one or more example unified TCIs with M-TRPs across multiple BWPs and / or CCs. Figure 8 As shown, the WTRU 802 may receive (e.g., via RRC, from the gNB 804) one or more of the following configurations: CC1 is configured with an S-TRP (e.g., TRP1a), CC2 is configured with an M-TRP (e.g., TRP2a, TRP2b), CC3 is configured with an S-TRP (e.g., TRP3b*), CC4 is configured with an M-TRP (e.g., TRP4a, TRP4b), and / or those CCs (e.g., CC1, CC2, CC3, CC4) are included in a list of one or more BWPs and / or CC lists for (configured) simultaneous TCI updates. In one example, CC3 may be configured with an S-TRP (TRP3b*). TRP3b* may be associated with a secondary TRP in other CCs having an MTRP. The WTRU may receive DCI 806 from a CC including more than one TRP (eg, CC2 808) indicating more than one unified TCI, eg, TCI2 and TCI4, of a second TRP (eg, TRP2b) from the more than one TRP based on the code point (eg, '010') of the TCI field of the DCI.
[0160] In response to receiving the DCI, the WTRU may update / apply more than one unified TCI (e.g., TCI2 and TCI4) to multiple CCs in the list simultaneously. For example, in response to receiving the DCI, the WTRU may update / apply more than one unified TCI (e.g., TCI2 and TCI4) to multiple CCs in the list simultaneously. For example, in response to receiving the DCI, the WTRU may update / apply more than one unified TCI to multiple CCs in the list simultaneously, wherein, in CC1, TCI2 (corresponding to the first position / order of the TRP) may be used / applied as a unified TCI for communicating with a TRP (e.g., TRP1a, based on the (aligned) first position / order of the TRP). For example, in response to receiving a DCI, the WTRU may simultaneously update / apply more than one unified TCI to multiple CCs in the list, wherein, in CC2, TCI2 (corresponding to the first position / order of the TRP) may be used / applied as the first unified TCI for communicating with a first TRP (e.g., TRP2a, based on the (aligned) first position / order of the TRP), and TCI4 (corresponding to the second position / order of the TRP) may be used / applied as the second unified TCI for communicating with a second TRP (e.g., TRP2b, based on the (aligned) second position / order of the TRP). For example, in response to receiving a DCI, the WTRU may simultaneously update / apply more than one unified TCI to multiple CCs in the list, wherein, in CC3, TCI4 (corresponding to the second position / order of the TRP) may be used / applied as the unified TCI for communicating with a single TRP (the TRP is, for example, TRP3b*, based on being (explicitly) configured / instructed to do so, for example, as aligned with the second position / order of the TRP). For example, in response to receiving a DCI, the WTRU may simultaneously update / apply more than one unified TCI to multiple CCs in the list, wherein, in CC4, TCI2 (corresponding to the first position / order of the TRP) may be used / applied as the first unified TCI for communicating with the first TRP (e.g., TRP4a, based on the (aligned) first position / order of the TRP), and TCI4 (corresponding to the second position / order of the TRP) may be used / applied as the second unified TCI for communicating with the second TRP (e.g., TRP4b, based on the (aligned) second position / order of the TRP). Any of the foregoing examples may appear alone or in combination with any of the other examples, or all together.
[0161] A BWP and / or CC (configured with a single TRP, e.g., TRP3b*) may be (e.g., explicitly) configured, associated, and / or indicated as follows: The single TRP (e.g., TRP3b*) may be associated with a second position and / or order of TRPs among multiple TRPs in other BWPs and / or CCs that employ more than one TRP (e.g., M-TRP). The second position and / or order of the TRPs may be (e.g., indicate and / or include, etc.) a TRP that is not a primary TRP and / or default TRP. This may provide benefits in terms of improving operational efficiency and flexibility, as the gNB may flexibly configure / indicate BWPs and / or CCs to the WTRU based on efficient strategies for network planning / deployment of multiple TRPs, for example, in terms of the geographical location of each TRP across different BWPs and / or CCs. For example, where TRP1a, TRP2a and / or TRP4a may be located at (close to) a first geographic location and TRP2b, TRP3b*, TRP4b may be located at (close to) a second geographic location, the indicated unified TCI may be simultaneously applicable to TRPs located at the same geographic location, which further provides benefits in terms of reducing the overhead of indicating a unified TCI across multiple BWPs and / or CCs.
[0162] Carrier aggregation (CA) and beamforming may be closely related to the RF front-end WTRU capabilities as common beam management (CBM) and / or independent beam management (IBM). Since some component carriers (CCs) may be configured with M-TRP transmission and / or reception, under the unified TCI concept, some overhead can be reduced by using rules for CC grouping, which may be related to cell groups (CGs), RF chain availability (WTRU capabilities). Since the beams may be the same for a group of cells, common beam management may be assumed, and therefore the QCL assumptions may be the same or mapped to similar RSs. In one example, the cell portion of the CG may be handled using, for example, the commonality of common beam management. In one example, the timing advance group (TAG) may be used interchangeably with the CG as a cell grouping criterion. In one embodiment, the M-TRP configuration of the CC may include a primary TRP (P-TRP) and a secondary TRP (S-TRP). The cells can be grouped into MCG (Master Cell Group) and SCG (Secondary Cell Group), where each group has a primary cell (PCell) and / or a primary special cell (PSCell) and secondary cells in each group. In the following solution, we will describe the operations within the MCG, as the SCG may be similar but uses a different notation.
[0163] In one example, a DCI received on a PCell that updates the TCI state may update a portion of a cell group or the entire cell group. For example, a DCI received on a secondary cell may update the TCI of the secondary cell. In one example, the WTRU may be configured with a first CG including CC1, CC2, and / or CC3, wherein CC1 is a PCell, CC2 is a first SCell, and / or CC3 is a second SCell. The WTRU may receive a DCI (indicating a unified TCI) via CC1 (e.g., PCell). In response to receiving the DCI, the WTRU may apply and / or update the indicated unified TCI to CC1, CC2, and / or CC3 (e.g., part or all of the CCs in the first CG) at the same time. The WTRU may receive a second DCI (e.g., indicating a unified TCI) via CC2 (e.g., SCell). In response to receiving the second DCI, the WTRU may apply and / or update the indicated unified TCI only to CC2 (e.g., from which the second DCI is received). If in a CG, one or more cells are configured with an M-TRP instead of a PCell, the DCI received on the PCell may update the TCI of the entire CG and the configured primary TRP (P-TRP) of the CC with an M-TRP configuration given by the RRC and active. For example, a Pcell may not have a configured S-TRP, and part or all of the S-TRPs configured in the CG may be updated by the DCI of the first cell index after the PCell with a configured S-TRP.
[0164] In one example, the designated SCell may be the S-TRP that drives the TCI update. The designated SCell may be signaled by the RRC and / or by the MAC along with the active TTI. In one example, the DCI received on any SCell carrying the TCI update may have a flag for the S-TRP that will allow the TCI to update one or more or all of the S-TRPs. In one example, if the PCell has an M-TRP configuration, the DCI received on the PCell may update the TCI of the S-TRP (secondary TRP) and the TCI of all configured S-TRPs of the active CC in the CG, as well as the TCI of the Pcell P-TRP and the TCI of the rest of the CC and the configured and active P-TRPs. In one example, a DCI received on any SCell of the CG carrying a flag indicating an update to a P-TRP or S-TRP may update all configured and active P-TRPs or S-TRPs in the CG. In one example, MAC-CE activation may indicate a P-TRP or S-TRP (e.g., if the M-TRP is configured by the RRC for the CC). For example, the indication may be a flag that is 0 for P-TRP and 1 for S-TRP. In one example, if there are other CCs configured with M-TRP that have both activated P-TRP and S-TRP, the CC configured with M-TRP operation by RRC may activate both P-TRP and S-TRP. In one example, it may activate the CC using only P-TRP as the default TRP, and wait for the first DCI in the CG that may activate the S-TRP with a TCI code point for M-TRP-related configuration. In one example, the beam application time (BAT) may be the same for all cells within a CG.
[0165] In one embodiment, the WTRU may determine the TCI state applicable to a transmission or reception by first determining a unified TCI state instance applicable to the transmission or reception, and then determining the TCI state corresponding to the unified TCI state instance. The transmission may consist of at least PUCCH, PUSCH and / or SRS. The reception may consist of at least PDCCH, PDSCH and / or CSI-RS. The unified TCI state instance may also be referred to as a unified TCI (UTCI) instance, a TCI instance, a TCI state instance, a TCI state group, a TCI state process, a unified TCI pool, a set of TCI states, a set of time domain instances / stamps / time slots / symbols and / or frequency domain instances, a set of RBs and / or subbands, etc. In some solutions, the unified TCI state instance may be equivalent to or identified as a CORESET pool identifier (e.g., CORESETPoolIndex, TRP indicator, etc.).
[0166] In one example, the WTRU may determine whether a unified TCI state instance is applicable for transmission or reception, and / or an identification of a unified TCI state instance applicable for transmission or reception based on one of the following solutions. For example, if the WTRU determines that a unified TCI state instance is not applicable for transmission or reception, the WTRU may set a spatial filter according to a conventional solution. In one example, the WTRU may receive RRC signaling that configures a unified TCI state instance applicable for transmission or reception. Such a configuration may, for example, be specific to a bandwidth portion or a serving cell. For example, if the WTRU does not receive a configuration for an applicable unified TCI state instance, the WTRU may determine that no unified TCI state instance is applicable. In one example, the WTRU may determine a default unified TCI state instance. Such a default unified TCI state instance may, for example, be predefined or configured separately.
[0167] Fig. 9 9 is a diagram illustrating an example of a TCI field (e.g., 3 bits) table 900 of a DCI for indicating at least one UTCI. In an example, a WTRU may receive MAC-CE signaling (e.g., a MAC-CE command or message) that activates / updates / indicates a unified TCI state instance applicable for transmission or reception. In an example, a unified TCI (UTCI) state instance (e.g., a UTCI instance) may correspond to (e.g., be associated with, point to, or indicate) a column of a TCI field table of a DCI.
[0168] In one example, code point 902 of the TCI field (e.g., Fig. 9Each code point in the TCI field (e.g., 0, 1, ..., 7) may be associated with up to S (>=1) UTCIs (e.g., activated via MAC-CE), where the value of S may correspond to the maximum number of UTCI instances (e.g., S=3 in the figure). The UTCI instance may be considered as a position index of the code point 902 of the TCI field (e.g., based on the indicated UTCI order, corresponding to the column in the figure). In one example, the WTRU may be configured / indicated with an association between a UTCI instance (e.g., UTCI indicates an order #J, where J=1, 2, ..., or S) (e.g., for a code point 902 of the TCI field) and a target channel / signal (e.g., a list / set thereof). For example, order #J=1 (e.g., UTCI instance #1) may be associated with the first group of CORESETs, the first group of CSI-RS, the first group of PUCCH resources, the PDSCH / PUSCH of TRP1, etc. For example, order #J=2 (e.g., UTCI instance #2) may be associated with a second set of CORESETs, a second set of CSI-RS, a second set of PUCCH resources, a PDSCH / PUSCH of TRP2, etc. The WTRU may receive a configuration (or indication) of an S value, which may be based on (e.g., may correspond to) the maximum number of UTCIs that may be simultaneously indicated by a codepoint of the TCI field of the DCI. The WTRU may receive different configurations (or indications) within the same UTCI instance and / or across different codepoints. For example, each configuration (or indication) may be associated with a different and applicable channel / signal list / set. In some examples, a default UTCI instance #J may be set (e.g., predefined or preconfigured) per target channel / signal (e.g., where the default UTCI instance may be UTCI instance #1 (e.g., the lowest value of J)). In one example, if, for example, PUCCH is configured by default, it may follow the UTCI indicated with a #J=1 position (e.g., mapped to UTCI instance #1). If it is known / configured for the target channel / signal, the default value may be #J per target channel / signal corresponding to the TRP index (TRP#J), CORESETpoolIndex, or TAG index, etc. of the target channel / signal. For example, if the PUCCH resources are configured for TRP2, the PUCCH resources may (e.g., by default) follow the UTCI indicated with #J=2 position (e.g., mapped to UTCI instance #2). In one example, the default value may not be #J=1. For example, if the target channel (e.g., PUSCH, PDSCH, etc.) is associated with TRP#J (=1 or 2) (which may be known / configured for the WTRU), the default value may be #J=1 or may be #J=2, e.g., depending on the target channel / signal.For example, the WTRU may be scheduled to receive a PDSCH, and the WTRU may determine that the PDSCH is from TRP2 (#J=2) (e.g., via the CORESETpoolIndex value being set to "1" instead of "0"). Then, for example, the WTRU may also apply a default value of #J=2, which may instruct the WTRU to read the second UTCI instance (J=2).
[0169] Fig.10 is a diagram illustrating an example of a Tx / Rx scheme selection table 1000 per TCI codepoint. The WTRU may receive a configuration (or indication) that one of the codepoints 1002 of the TCI field of the DCI is associated with one of the applicable Tx (and / or Rx) schemes 1004. The applicable Tx (and / or Rx) schemes may include one or more of the following: STRP (single TRP) Tx and / or Rx; NCJT (non-coherent JT) as an MTRP scheme; CJT type 1 as an MTRP scheme of a single frequency network (SFN) type based on CJT (coherent JT); CJT type 2 as an MTRP scheme; a Tx (and / or Rx) scheme that may be configured by the gNB; and / or the like. The WTRU may receive a configuration (or indication) that a codepoint of the TCI field of the DCI may be associated with a STRP (e.g., single TRP) Tx and / or Rx. In some examples, the WTRU may receive a configuration (or indication) that the codepoint of the TCI field of the DCI may be associated with NCJT (Non-Coherent JT) as an MTRP scheme. For example, when a codepoint 0 is received at the WTRU (e.g., Fig.10 As shown, for reception of a scheduled PDSCH (e.g., sent from two TRPs as NCJT), a first (spatial domain) layer set of the PDSCH may be applied by a first indicated UTCI (e.g., UTCI3) and a second layer set of the PDSCH may be applied by a second indicated UTCI (e.g., UTCI9). The WTRU may receive the PDSCH using the first indicated UTCI for decoding the first layer set and the second indicated UTCI for decoding the second layer set.
[0170] The WTRU may receive a configuration (or indication) that the codepoint for the TCI field of the DCI may be associated with CJT (Coherent JT) type 1 as an MTRP scheme, for example, based on the single frequency network (SFN) type of CJT. For example, a codepoint 2 (in Fig.10), for reception of a scheduled PDSCH (sent from two TRPs as CJT (Type 1)), the WTRU may assume that the PDSCH DM-RS port may be in QCL with respect to QCL-TypeA (e.g., as SFN-PDSCH) and the DL RS of at least one UTCI indicated (e.g., UTCI2 and UTCI14). The WTRU may receive the PDSCH in a single frequency network (SFN) manner using both UTCI2 and UTCI14 based on the assumed QCL type (e.g., QCL-TypeA which may indicate at least one of {average delay, delay spread, Doppler shift, Doppler spread}). In one example, the WTRU may receive a configuration (or indication) that codepoint 1002 of the TCI field of the DCI may be associated with CJT Type 2 as an MTRP scheme. For example, when codepoint 3 is received at the WTRU (in Fig.10 In some examples, the WTRU may receive a PDSCH using a QCL-Type A (UTCI16) and a QCL-Type B (UTCI3) for the first indicated UTCI of QCL-TypeA and the remaining UTCI of QCL-TypeB (UTCI3). Based on different combinations of QCL attributes applied to each UTCI, the WTRU may receive the PDSCH using both UTCI16 and UTCI3 in a CJT manner, for example, using UTCI16 applied with QCL-TypeA that may indicate at least one of {average delay, delay spread, Doppler shift, Doppler spread}, and using UTCI3 applied with QCL-TypeB that may indicate at least one of {Doppler shift, Doppler spread}. In some examples, the WTRU may receive a configuration (or indication) that the codepoint of the TCI field for the DCI may be associated with a Tx (and / or Rx) scheme that can be configured by the gNB.
[0171] For example, upon receiving a TCI code point indicating at least one UTCI and / or Tx / Rx scheme, the WTRU may receive a configuration (or indication) that may inform the WTRU of channel / signal specific WTRU behavior, wherein one or more of the following may apply. In one example, in operation 1 (e.g., upon receiving TCI code point 2 in the figure), the WTRU may monitor a first set of CORESETs using UTCI2 and a second set of CORESETs using UTCI14, and the WTRU may receive a scheduled PDSCH based on the use of both UTCI2 and UTCI14 (e.g., as a CJT-PDSCH reception). In one example, in operation 2 (e.g., upon receiving TCI code point 2 in the figure), the WTRU may monitor all CORESETs (e.g., all configured CORESETs to be monitored) using the first indicated UTCI (UTCI2), and the WTRU may receive a scheduled PDSCH based on the use of both UTCI2 and UTCI14 (e.g., as a CJT-PDSCH reception). In one example, in operation 3 (e.g., when TCI codepoint 2 is received in the figure), the indicated codepoint 2 (e.g., with CJT, or for any other PDSCH associated with the TCI codepoint) may not affect (e.g., any) CORESET reception, and the WTRU may receive the scheduled PDSCH based on using both UTCI2 and UTCI14 (e.g., as a CJT-PDSCH reception). For example, this may mean that all CORESETs may monitor with the current UTCI (e.g., UTCI5, if it is the UTCI previously indicated by the second codepoint). In one example, at least in terms of control channel monitoring behavior (e.g., via one or more CORESETs), the WTRU may be configured (or instructed) to follow at least one of operations 1, 2, and 3.
[0172] The scheme selection may be applied when DCI indicating a TCI code point is received, but the actual application time of at least one UTCI indicated by the TCI code point may be applied based on a configured (or indicated) beam application time (BAT) parameter (e.g., which may be defined or preconfigured to be applied after the ACK transmission timing in response to receiving the DCI).
[0173] In one example, RRC may configure a unified TCI state instance applicable to PUCCH transmission. For example, RRC may configure a unified TCI state instance applicable to scheduling request (SR) resources. The configuration may be specific to each SR resource of the PUCCH configuration or common to all SR resources. For example, RRC may configure a unified TCI state instance applicable to resources for periodic CSI reporting. The configuration may be included as part of the CSI report configuration or as part of the PUCCH resource configuration. For example, RRC may configure a unified TCI state instance applicable to resources for HARQ-ACK reporting. The configuration may be specific to each PUCCH resource of the PUCCH configuration associated with the HARQ-ACK codebook or common to all PUCCH resources. For example, RRC may configure a unified TCI state instance applicable to all resources that follow a specific PUCCH format. For example, RRC may configure a unified TCI state instance applicable to PUCCH resources that carry payloads within a specific range. For example, the RRC may configure a payload threshold for at least one PUCCH resource and configure a first unified TCI state instance for a PUCCH carrying a payload below the threshold and a second unified TCI state instance for a PUCCH carrying a payload above the threshold. In one example, if the WTRU is configured with two PUCCH configuration parameters corresponding to the corresponding HARQ-ACK codebook of the URLLC, each PUCCH configuration may include and / or contain a configuration of which unified TCI pool is associated. In this case, the priority indication of the DCI may be overloaded to indicate the unified TCI pool.
[0174] In one example, the RRC may configure a unified TCI state instance applicable to certain SRS transmissions. The configuration may be specific to an SRS resource or an SRS resource set. In one embodiment, the RRC may configure a unified TCI state instance applicable to PUSCH transmissions. For example, the RRC may configure a unified TCI state instance applicable to configuration grant (CG) type 1 or type 2. The configuration may be specific to each CG configuration, or common to all CG configurations. For example, the RRC may configure a unified TCI state instance applicable to a unified TCI state instance that may be explicitly configured as part of a CG configuration. For example, the WTRU may follow a unified TCI state instance that is configured as part of an SRS resource or an SRS resource set configured for the CG configuration.
[0175] In one example, RRC may configure a unified TCI state instance applicable to PDCCH reception. This configuration (e.g., via a parameter of "PDCCH TCI state usage") may be provided for each Coreset (e.g., Coreset group) or each Coreset pool index. In one example, the Coreset pool index may be the same as the unified TCI state instance. For example, this configuration may be provided for each search space, DCI format, DCI size, etc.
[0176] Fig.11 1 is a diagram illustrating an example diagram 1100 of PDCCH TCI state usage that associates a CORESET with a TCI state instance. Fig.11 As shown, the WTRU may receive information, for example, via a "PDCCH TCI state usage" parameter, indicating one or more of: (i) a first CORESET is associated with a first transmission configuration indicator (TCI) state instance, and / or (ii) a second CORESET is associated with a second TCI state instance. The WTRU may receive an information element (e.g., via an RRC (or other higher layer) parameter, such as "PDCCH TCI state usage") that indicates whether to apply a first joint / DL TCI state, a second joint / DL TCI state, both, or none of the joint / DL (e.g., unified) TCI states indicated by a DCI or MAC-CE to a CORESET or a group of CORESETs. In one example, the first joint / DL (e.g., unified) TCI state (e.g., indicated by a DCI or MAC-CE) may correspond to a first TCI state instance in a currently used unified TCI, such as indicated by a TCI field of the DCI. The second joint / DL (eg, unified) TCI state (eg, indicated by DCI or MAC-CE) may correspond to a second TCI state instance in the currently used unified TCI, eg, indicated by a TCI field of the DCI.
[0177] The WTRU may receive a DCI including a TCI field indicating a TCI value (or code point), such as Fig.11As shown in Value2 in . The WTRU may determine whether the indicated TCI value (e.g., Value2) is associated with one TCI state, or whether the indicated TCI value (e.g., Value2) is associated with more than one TCI state. In one example, if the WTRU determines that the indicated TCI value is associated with one TCI state, the WTRU may use the one indicated TCI state to receive the PDSCH and / or monitor the second (e.g., later) PDCCH. If the UE determines that the indicated TCI value is associated with more than one TCI state (e.g., two TCI states), the WTRU may use the more than one TCI state to receive the PDSCH, and the WTRU may use one or more of the more than one TCI states to monitor the second (e.g., later) PDCCH based on the received information (e.g., through the "PDCCH TCI state usage" parameter).
[0178] The WTRU may monitor Physical Downlink Control Channel (PDCCH) transmissions via the first CORESET and / or the second CORESET, for example, based on the received information (e.g., via the "PDCCH TCI state usage" parameter). For example, when the TCI value indicates that the first TCI state is associated with a first TCI state instance and when the first CORESET is associated with the first TCI state instance, the first TCI state may be used to monitor PDCCH transmissions in the first CORESET. For example, when the TCI value indicates that the second TCI state is associated with a second TCI state instance and when the second CORESET is associated with the second TCI state instance, the second TCI state may be used to monitor PDCCH transmissions in the second CORESET.
[0179] The WTRU may receive information (e.g., in a MAC CE) associating a TCI value with one or more of a first TCI state for a first TCI state instance or a second TCI state for a second TCI state instance. The WTRU may receive information (e.g., RRC, via a "PDCCH TCI state usage" parameter as shown in the figure) indicating that a first CORESET may be associated with a first TCI state instance and / or a second CORESET may be associated with a second TCI state instance.
[0180] In one example, RRC may configure a unified TCI state instance applicable to certain PDSCH receptions. For example, the configuration may be provided for semi-persistent scheduling (SPS) PDSCH. The configuration may be specific to each SPS configuration, or may be common to all SPS configurations. In one embodiment, RRC may configure a unified TCI state instance for certain non-zero power (NZP) CSI-RS receptions. For example, RRC may configure a unified TCI state instance for one or more NZP CSI-RS resources listed in the associated CSI report configuration for an aperiodic CSI trigger state. For example, RRC may configure a unified TCI state instance for one or more periodic NZP CSI-RS resources. This configuration may, for example, be included as part of the configuration of the NZP CSI-RS resource itself. In one example, a unified TCI state may be configured as part of a CSI report configuration. In the latter case, this configuration may replace the TCI state configured within the NZP CSI-RS resource (if any).
[0181] The WTRU may receive a MAC CE or DCI signaling indicating a unified TCI state instance for one or more of: at least one PUCCH resource corresponding to a PUCCH resource index, a PUCCH configuration index, a HARQ-ACK codebook, an SR resource configuration, and / or a CSI reporting configuration; at least one SRS resource or an SRS resource set; at least one CG configuration or an SPS configuration; at least one Coreset, wherein at least one Coreset may be identified by at least one Coreset ID or may include all Coresets with a configured Coreset pool index; at least one DCI format, DCI size, and / or search space; and at least one NZP CSI-RS. For example, a MAC CE activating at least one semi-persistent NZP CSI-RS resource may indicate a unified TCI state instance for each of the at least one resource. The DCI signaling may consist of at least one indication of a DCI.
[0182] In some examples, the DCI field may explicitly indicate an applicable unified TCI state instance for the transmission or reception indicated by the DCI. The DCI field may be a new field dedicated to the indication, or may be an existing field that is also used to indicate other information. For example, each possible value of the TCI field may indicate one of the combinations of a unified TCI state instance and an index to the TCI state. For example, a WTRU may receive a DCI indicating a unified TCI state instance and a possible TCI state index. The WTRU may determine the applicable Coreset or Coreset pool index based on an explicit indication from the DCI or implicitly from an explicit indication from a Coreset for decoding a PDCCH. Possibly after a fixed delay, the WTRU may apply the unified TCI state instance and possible TCI state index to subsequent reception of a PDCCH using a Coreset with a determined Coreset index or Coreset pool index. For example, a WTRU may receive a DCI that indicates a PUSCH or a PUSCH repetition set and includes an SRS resource indicator and / or an SRS resource set indicator. The WTRU may use conventional solutions to determine the SRS resource set and / or SRS resources for PUSCH or for each PUSCH repetition. The WTRU may determine the applicable unified TCI state instance for PUSCH or for each PUSCH repetition as the unified TCI state instance configured for the SRS resource set and / or SRS resources determined for the corresponding PUSCH or PUSCH repetition.
[0183] In one example, the WTRU may first receive signaling that provides a unified TCI state instance for each configured TCI state or each activated TCI state. Such signaling may be performed by RRC, MAC CE and / or DCI. For example, the RRC may configure an IE indicating a unified TCI state instance for each TCI state, or the RRC may provide a first TCI state set and a second TCI state set corresponding to a first unified TCI state instance and a second unified TCI state instance, respectively. For example, the MAC CE may include a unified TCI state instance in a MAC CE that activates and / or deactivates a TCI state, so that all activated TCI states are associated with the unified TCI state instance. In one example, upon receiving a DCI that includes a TCI state field, the WTRU may determine that the applicable and / or indicated unified TCI state for the DCI corresponds to a unified TCI state associated with the indicated TCI state. In one example, for one or more TCI states, the WTRU may not receive a configuration or indication of a unified TCI state instance. In this case, the WTRU may assume that the TCI state corresponds to a default unified TCI state instance. In one example, the WTRU may determine that the TCI state is independent of any unified TCI state instance. In one example, the WTRU may receive a DCI with a time domain resource allocation field indicating that the PDSCH is repeated K times. The WTRU may determine the unified TCI state instance for each repetition based on the configured pattern. For example, the WTRU may be configured to apply a cyclic mapping. The unified TCI state instance may be incremented (e.g., the number of unified TCI state instances is adjusted), for example, for each PDSCH repetition.
[0184] In some examples, the WTRU may determine the applicable unified TCI state instance based on the attributes of the authorization or assignment. For example, the RRC and / or MAC CE may first indicate or configure a unified TCI state instance for each possible value of the priority index. The WTRU may determine that the unified TCI state instance applicable to PUSCH or PUCCH is the unified TCI state instance configured or indicated for the priority index. In one example, the RRC and / or MAC CE may first indicate or configure a unified TCI state instance for each possible value of the bandwidth part indication. The WTRU may determine that the unified TCI state instance applicable to PUSCH or PUCCH is the unified TCI state instance configured or indicated for the bandwidth part indication. In one example, the WTRU may determine (e.g., implicitly determine) that the unified TCI state instance applicable to the first transmission or reception corresponds to the unified TCI state instance applicable to the second transmission or reception. For example, the unified TCI state instance applicable to PDSCH reception, PUSCH transmission and / or PUCCH transmission may correspond to the unified TCI state instance applicable to the indicated PDCCH and / or the latest indicated PDCCH. For example, a unified TCI state instance applicable for a PUCCH transmission for HARQ-ACK may correspond to a unified TCI state instance applicable for a corresponding PDSCH and / or a latest PDSCH. In one example, the WTRU may receive signaling indicating an applicable unified TCI state instance for a set of symbols and / or time slots. The signaling may consist of RRC signaling or DCI (such as a group common DCI) and may consist of an indication of a time pattern (e.g., signaled as a bitmap) in which the indicated unified TCI state is applicable. If a transmission or reception completely overlaps with the indicated time pattern for a unified TCI state instance, the WTRU may apply the unified TCI state instance to the transmission or reception.
[0185] In one example, the WTRU may receive signaling indicating an applicable unified TCI state instance for a set of resource blocks. The signaling may consist of RRC signaling or DCI (e.g., a group common DCI), and may consist of an indication of at least one RB range or RB subset to which the indicated unified TCI state is applicable. If a transmission or reception completely overlaps with the indicated RB subset for the unified TCI state instance, the WTRU may apply the unified TCI state instance to the transmission or reception. In one example, the WTRU may determine whether to apply the unified TCI state instance to the transmission or reception based on the indication made by the DCI. For example, if the WTRU receives a value in a predefined or configured subset of values for the TCI field of the DCI, the WTRU may determine that there is no applicable unified TCI state instance for the indicated PDSCH. The WTRU may apply the indicated TCI state to the PDSCH indicated by the DCI, and may or may not affect subsequent transmissions or receptions. In one example, if the WTRU receives a value in a predefined or configured subset of values for the SRS resource indicator field or the SRS resource set indicator field, the WTRU may apply the indicated SRS resource or SRS resource set and may or may not affect subsequent transmission and / or reception. In one example, the WTRU may receive signaling indicating a TCI state corresponding to a unified TCI state instance. The WTRU applies the TCI state to subsequent transmissions or receptions (if any) to which the unified TCI state applies. In one example, if the signaling indicates that the TCI state corresponding to the unified TCI state instance is changed, the WTRU may apply the changed N symbols after receiving the signaling (e.g., the end of the last symbol) or sending its confirmation. The value of N may depend on the subcarrier spacing and the type of transmission or reception. In one example, if no unified TCI state instance is applicable, subsequent transmission and / or reception may not be affected. In one example, the signaling indicating the TCI state for the unified TCI state instance may include one or more of the following: indicating a DCI for a PDSCH or PUSCH. For example, the WTRU may determine the TCI state from the TCI field of the DCI used to indicate the PDSCH; a DCI for which there is no assignment or grant. For example, the CRC of such DCI may be scrambled with a specific RNTI (e.g., CS-RNTI, etc.) and have predefined values for certain DCI fields. For example, such DCI may be referred to as a TCI state update.
[0186] In some examples, the WTRU may determine the unified TCI state instance for signaling using any of the solutions outlined in the previous paragraphs. For example, the WTRU may determine the unified TCI state instance as the Coreset pool ID of the Coreset from which the PDCCH is decoded. In one example, the WTRU may determine the unified TCI state instance from a field of the DCI. In one example, the WTRU may determine the unified TCI state instance as the unified TCI state associated with the indicated TCI state based on the RRC configuration and / or MAC CE.
[0187] For example, a beam failure recovery (BFR) procedure may be initiated, performed, implemented and / or triggered by the WTRU based on determining and / or detecting that the quality of a communication link (e.g., between the WTRU and the gNB) is below a threshold. The communication link quality may be determined, predefined, configured and / or indicated based on one or more CORESETs configured for the WTRU. The threshold may be preconfigured (e.g., via RRC) and / or indicated for the WTRU. The threshold may be based on an RSRP value (e.g., a layer 1 RSRP value / metric), an SINR value (e.g., a layer 1 SINR value / metric), a bit error rate (BER), a block error rate (BLER) and / or an assumed BLER (e.g., based on RSRP and / or SINR), etc. The WTRU may be configured to initiate a first BFR procedure for a first communication link between the WTRU and a first TRP (e.g., RRH, TP, RP, gNB, cell), for example, based on detecting that the quality of the first communication link is below a threshold. The WTRU may also detect that the signal and / or channel quality of a second communication link between the WTRU and a second TRP is below a threshold. In response to the detection, the WTRU may initiate a second BFR process for the second communication link, for example, while performing the first BFR process (e.g., in parallel, as an independent BFR process). Independent BFR processes for the first BFR process and the second BFR process may increase the latency to complete the restoration of all (failed) beams.
[0188] Independent BFR processes may reduce the reliability of maintaining one or more communication links, for example, where a WTRU may detect a maximum permissible exposure (MPE) event and the WTRU may experience, detect and / or determine that a first signal / channel quality of a first communication link and a second signal and / or channel quality of a second communication link are both below a threshold (e.g., may be below a threshold at the same time) based on, due to and / or attributable to the MPE event. An MPE event may refer to an event in which the WTRU may experience excessive signal and / or channel power (e.g., exceeding a threshold) in a certain direction that may be harmful to a user using the WTRU. For example, based on an event in which an MPE has occurred, the WTRU may experience that both the first signal / channel quality and the second signal / channel quality are below a threshold.
[0189] In some examples, the WTRU may be configured to initiate a simultaneous BFR process (e.g., an MTRP simultaneous BFR process), where the simultaneous BFR process may imply and / or mean that the WTRU simultaneously initiates, implements, executes and / or performs more than one BFR process (e.g., each corresponding to a communication link between the WTRU and a TRP (and / or for CC / BWP), etc.). Hereinafter, for simplicity of discussion, the more than one BFR process (of the simultaneous BFR process) may include a first BFR process for TRP1 and a second BFR process for TRP2, however, the proposed solution and process may be equally applicable to situations where more than 2 TRPs are applied based on the simultaneous BFR process. In one example, one of the TRPs may be a primary TRP (e.g., TRP1).
[0190] Based on a simultaneous BFR process (e.g., configured by the gNB), the WTRU may be configured with more than one beam failure detection (BFD) RS set. In one example, the WTRU may be configured with a first q0 set (as a first BFD RS set from TRP1) including one or more RSs (e.g., RS1a and RS1b) configured in a first q0 set, and a second q0 set (as a second BFD RS set from TRP2) including one or more RSs (e.g., RS2a and RS2b). Based on and / or in response to determining the radio link quality of one or more RSs (e.g., all RSs, all corresponding resource configurations) of at least one of the first q0 set and the second q0 set, the physical layer in the WTRU may provide an indication of the (MTRP) simultaneous BFR process to a higher layer, for example, the WTRU uses the indication to determine and / or evaluate that the radio link quality is worse than a threshold (e.g., a threshold parameter of Qout,LR). In some examples, the value of the threshold (e.g., Qout,LR) can be configured (e.g., independently configured) for each TRP, e.g., Qout,LR1 for TRP1 and Qout,LR2 for TRP2, which can provide benefits in terms of flexibility and efficiency because each TRP can have a different priority level initiated by the BFR process, e.g., TRP1, as the primary TRP of the WTRU, can have a higher priority and can have a higher value of the threshold, while TRP2, as a secondary TRP, can have a lower value of the threshold.
[0191] For example, based on at least one configuration and / or parameter of the unified TCI applied to the WTRU, the WTRU may be configured with (and / or have predefined rules for) one or more conditions to initiate, trigger, execute, implement and / or conduct a (MTRP) simultaneous BFR process. In one embodiment, an example condition may be if all beams at TRP1 (e.g., the main TRP) fail, and some beams and / or at least one beam at TRP2 fail. In one embodiment, an example condition may be if all beams at TRP1 (e.g., the main TRP) fail, and regardless of the other TRP beam states (e.g., as an active MTRP simultaneous BFR). In one embodiment, an example condition may be if some beams and / or at least one beam at TRP1 (e.g., the main TRP) fail, and some beams and / or at least one beam at TRP2 fail. In one embodiment, an example condition may be if some and / or at least one beam at TRP1 (e.g., the main TRP) fail, and regardless of the other TRP beam states (e.g., as an active MTRP simultaneous BFR). In one example, based on active MTRP simultaneous BFR, the robustness and quality of the communication link between the gNB (e.g., employing TRP1 and TRP2) and the WTRU can be improved, for example, because the initiation of the simultaneous BFR process can be carried out without waiting for (e.g., being delayed until) more stringent conditions are met (e.g., all beams fail, all beams of at least one TRP fail, etc.).
[0192] The WTRU may apply two or more BFD counters (e.g., based on the MTRP simultaneous BFR process) based on satisfying at least two of the following: BFD-Counter1 (e.g., used only to check the primary TRP state, e.g., TRP1 (when the BFD conditions are met or not met), which may operate when the first condition set is met); BFD-Counter2 (e.g., used only to check the secondary TRP state, e.g., TRP2 (when the BFD conditions are met or not met), which may operate when the second condition set is met); BFD-Counter3 (e.g., used to check two and / or all MTRP states, which may operate when the third condition set is met). In one example, based on the MTRP simultaneous BFR process, the WTRU may apply two or more thresholds (e.g., CounterThresholds, BFD-CounterThresholds, etc.). For example, when at least the beam of the primary TRP may be faulty, the WTRU may apply a threshold based on CounterThreshold1 (e.g., set to 10, and / or continuously on measured samples). A higher priority may be given and applied to the primary TRP, which may improve flexibility, efficiency, and / or performance in terms of network implementations where the gNB may set a TRP as a higher priority for communicating with the WTRU. For example, when a beam other than the primary TRP beam fails, the WTRU may apply a threshold based on CounterThreshold2 (e.g., set to 20, and / or continuously over measured samples). A lower priority may be given and / or applied to other TRPs, which may improve flexibility, efficiency, and / or performance in terms of network implementations where the gNB may set a TRP as a higher priority for communicating with the WTRU.
[0193] For example, based on the MTRP simultaneous BFR process, the WTRU may be configured with a candidate beam index (e.g., q_new) associated with more than one beam (e.g., as paired beam information for the MTRP BFR, e.g., corresponding to each paired beam in the paired beams for each TRP). In one example, a PRACH resource associated with a multi-beam pair (which may be, for example, a common resource) may be configured / indicated to the WTRU, e.g., where each beam included in the multi-beam pair may correspond to each TRP. For example, when configuring PRACH resources for a BFR process for an MTRP, e.g., based on the MTRP simultaneous BFR process, resource overhead may be saved, and / or benefits may be gained in terms of network implementation flexibility and efficiency in that the gNB may configure a preferred multi-beam pair (e.g., q_new1 and q_new2) on a single PRACH resource.
[0194] When at least one BFRR condition is met, the WTRU may send (or, for example, be configured to send) a BFR request (BFRR) message for the MTRP simultaneous BFR process, for example based on and / or by using a PRACH resource associated with a multi-beam pair (which may, for example, be a common PRACH resource), the at least one BFRR condition including: BFRR-Condition1, a strict condition for sending BFRR, for example, based on all beams failing for TRP1 (for example, as the main TRP) and partial BFR being used for TRP2; BFRR-Condition2, a condition for mainly considering the main TRP, for example, based on all beams failing for TRP1 (for example, as the main TRP) regardless of other TRPs); and BFRR-Condition3, a relaxed condition for MTRP, for example, based on partial BFR being used for TRP1 and partial BFR being used for TRP2. In one example, for example, when at least one communication link (e.g., between the TRP and the WTRU) is active (e.g., not above a threshold, not completely failed, etc.) and / or when one or more or any of the above-mentioned BFRR conditions are not met, the WTRU may send and / or be configured to send a BFR request (BFRR) message for the MTRP simultaneous BFR process based on (by using) uplink resources that may or may not be PRACH resources (e.g., PUCCH, scheduling request (SR), MAC-CE via PUSCH, etc.).
[0195] The WTRU may be configured with a BFR CORESET, for example, based on an MTRP simultaneous BFR procedure for M-TRP (e.g., which may be common and / or shared), and a response message from the gNB may be received by the WTRU via the MTRP simultaneous BFR procedure in response to a BFRR message sent by the WTRU. The number of configured CORESETs on a per-BWP basis may be limited in terms of network implementation and efficient operation, which may provide the benefit of saving resource overhead when multiple BFR-CORESETs are configured for M-TRP. Configuring multiple BFR-CORESETs may not be efficient because the beams for the BFR-CORESETs may not need to be configured initially.
[0196] In response to the BFD condition being met, the WTRU may determine, for example, a first beam index (e.g., q_new1) associated with TRP1, and may send a first BFRR message indicating / including the first beam index, for example, where a first PRACH (or, for example, PUCCH / SR / MAC-CE, etc.) resource may be used to send the first BFRR message. In response to determining the first beam index (and sending the first BFRR message), the WTRU may determine, assume and / or identify that the beam (e.g., TCI and / or unified TCI, etc.) used for the BFR-CORESET (which may be common and / or shared) is based on, equal to, the same as, equivalent to, becomes, and / or has other similar relationship with the first beam index used by TRP1. The WTRU may monitor downlink signals (e.g., DCI, control channel information content) via the BFR-CORESET (which may be common and / or shared among multiple TRPs) using a first spatial (domain) filter determined based on the first beam index. This may provide the following benefit: resource overhead may be saved / reduced based on using a BFR-CORESET for M-TRP (which may be public and / or shared) and whose beam is determined by the WTRU's BFRR message transmission (e.g., associated with a first beam index), rather than initially configuring multiple BFR-CORESETs.
[0197] In response to the BFD condition being met, the WTRU may determine a second beam index (e.g., q_new2) associated with, for example, TRP2, and may send a second BFRR message indicating / including the second beam index, for example, where a second PRACH (or, for example, PUCCH, SR, MAC-CE, etc.) resource may be used to send the second BFRR message. In response to determining the second beam index and / or sending the second BFRR message, the WTRU may determine, assume and / or identify that the beam (e.g., TCI, unified TCI, etc.) used for the BFR-CORESET (which may be common and / or shared) is based on, equal to, the same as, equivalent to, becomes, and / or has a similar relationship to, the second beam index used by, for example, TRP2. The WTRU may monitor downlink signals (e.g., DCI, control channel information content) via the BFR-CORESET (which may be common and / or shared) using a second spatial (domain) filter determined based on the second beam index. This may provide the following benefit: resource overhead may be saved / reduced based on using a BFR-CORESET for M-TRP (which may be public and / or shared) and whose beam is determined by the WTRU's BFRR messaging (e.g., associated with a second beam index), rather than initially configuring multiple BFR-CORESETs.
[0198] For example, based on the MTRP simultaneous BFR process for M-TRP (which may be common and / or shared), the WTRU may be configured with more than one recovery search space associated with the BFR-CORESET. In one example, a first recovery search space for monitoring BFR responses (e.g., DCI1, e.g., sent from TRP1) and a second recovery search space for monitoring BFR responses (e.g., DCI2, e.g., sent from TRP2) may be configured and / or activated, and / or one or both of them may be associated with the BFR-CORESET (which may be common and / or shared for M-TRP). In one example, in response to receiving DCI1 via the first recovery search space, the WTRU may determine that at least q_new1 (e.g., not q_new2, even if reported by the WTRU) may be applied and / or become a beam for the BFR-CORESET (which may be common and / or shared). In one example, in response to receiving DCI2 via the second recovery search space, the WTRU may determine that at least q_new2 (e.g., not q_new1, even if reported by the WTRU) may be applied and / or become a beam for a BFR-CORESET (which may be common and / or shared). This may provide the following benefits: resource overhead may be saved / reduced based on using a BFR-CORESET (which may be common and / or shared) for M-TRP and whose beam is determined by the WTRU's BFRR messaging (e.g., associated with q_new1 or q_new2, etc.), rather than initially configuring multiple BFR-CORESETs.
[0199] In response to the BFRR message sent by the WTRU, the WTRU may receive a response message, for example, based on a simultaneous BFR procedure (e.g., a BFR response) of a (MTRP) from the gNB. The response message may include one or more information blocks (e.g., block-by-block information, e.g., similar to or shared with a DCI (format 2 and / or format 3) for a group-by-group power control command), wherein a first block of the one or more information blocks may include a first BFR response from TRP1, and a second block of the one or more information blocks may include a second BFR response from TRP2. The block-by-block information may also include blocks for different BWPs and / or CCs (e.g., a third BFR response, etc.). In one example, the first BFR response and the second BFR response may be for a first BWP and / or CC based on a BWP and / or CC indicator (e.g., a first BWP and / or CC indicator), and the third BFR response may be for a second BWP and / or CC based on a BWP and / or CC indicator (e.g., a second BWP and / or CC indicator).
[0200] The WTRU may receive an acknowledgement message via a single DCI (e.g., as a BFR response DCI, via BFR-CORESET) indicating (e.g., including) a unified TCI, e.g., based on a (MTRP) simultaneous BFR procedure (which may be common and / or a single acknowledgement message) for both q_new1 and q_new2. In response to receiving the single DCI (e.g., based on a configured / indicated (MTRP) simultaneous BFR procedure and / or mode), the WTRU may (and / or be configured to) re-interpret the (e.g., special and / or default) codepoint (e.g., 000) of the TCI field in the single DCI, where the special / default codepoint will be automatically re-described and / or rewritten into q_new1 and / or q_new2 (e.g., replacing the current description / mapping of the special codepoint, e.g., given by a previous MAC-CE message). In one example, the WTRU may apply a special and / or default code point indication and / or change to indicate a redescription / rewrite of q_new1 and / or q_new2 in response to (only) determining that q_new1 and / or q_new2 are not, are not included, are not described, are not contained, are not associated, are not indicated in any code point of the TCI field (which may be the current code point (e.g., in the case of a 3-bit TCI field, code points 000, 001...111, etc.)) and / or have no other similar relationship thereto.
[0201] In response to determining that q_new1 and / or q_new2 are (e.g., already) included, described, contained, associated and / or indicated in a (e.g., current) codepoint of the TCI field (e.g., in the case of a 3-bit TCI field, codepoints 000, 001, ... 111, etc.), the WTRU may not apply a special and / or default codepoint indication and / or re-description and / or rewrite of the indication q_new1 and / or q_new2. In one example, the WTRU may determine that q_new1 is (e.g., already) included, described, contained, associated or indicated in a (e.g., current) codepoint 001 of the TCI field, and the gNB may send a DCI including the TCI field (e.g., as a BFR response DCI, via BFR-CORESET) by indicating codepoint 001 of the TCI field, e.g., based on q_new1 being (e.g., already) in codepoint 001. In response to receiving the DCI at the WTRU, the WTRU may apply q_new1 (e.g., indicated by code point 001) as a (e.g., new) unified TCI (e.g., applied as / used as a beam / TCI for multiple channels and / or signals), for example for communicating with TRP1 (e.g., via an uplink and / or downlink).
[0202] The WTRU may determine that q_new2 is (already) included, described, contained, associated, or indicated in the (e.g., current) code point ‘011’ of the TCI field, and the gNB may send a DCI including the TCI field (e.g., as a BFR response DCI, via BFR-CORESET) by indicating the code point ‘011’ of the TCI field, for example, based on q_new2 (already) being in the code point ‘011’. In response to receiving the DCI at the WTRU, the WTRU may apply q_new2 (e.g., indicated by the code point 011) as the (e.g., new) unified TCI (e.g., applied as / used as a beam / TCI for multiple channels / signals), for example for communication with TRP2 (e.g., via uplink and / or downlink). In one example, the WTRU may determine that q_new1 and q_new2 are (e.g., already) included, described, contained, associated, or indicated in the (e.g., current) code point ‘101’ of the TCI field. The gNB may send a DCI including a TCI field (eg, as a BFR response DCI, via BFR-CORESET) by indicating codepoint '101' of the TCI field, eg, based on q_new1 and q_new2 being (eg, already) in codepoint '101'.
[0203] In response to receiving the DCI at the WTRU, the WTRU may apply q_new1 and q_new2 (e.g., indicated by codepoint 101) as a (e.g., new) unified TCI (e.g., q_new1 is applied / used as a first beam and / or TCI for multiple channels / signals for communicating with TRP1 (via uplink and / or downlink), and q_new2 is applied / used as a second beam / TCI for multiple channels / signals for communicating with TRP2 (e.g., via uplink and / or downlink)). In one example, the WTRU may not expect to receive (e.g., the gNB should not send, or the gNB is not allowed to send) a DCI (via BFR-CORESET, e.g., as a BFR response DCI based on a (MTRP) simultaneous BFR procedure) that indicates a second codepoint that is not (at all) associated with q_new1 and / or q_new2.
[0204] The WTRU may receive a first BFR response (e.g., DCI1) via a first BFR-CORESET (e.g., BFR-CORESET#1) from TRP1, e.g., based on a (MTRP) simultaneous BFR procedure, e.g., after sending a first BFRR message associated with a first beam index (e.g., q_new1). In response to receiving the first BFR response, the WTRU may apply, determine, and / or update the set q_new1 to a first position of a description (e.g., behavior) for each of one or more or all codepoints of a TCI field for DCI indicating a unified TCI. The other positions (e.g., second positions) of the behavior description for each of the one or more codepoints may remain unchanged. In one example, for a first codepoint of the TCI field, where the behavior description of the first codepoint is currently mapped (e.g., described) as "TCI ID#X, TCI ID#Y", e.g., via MAC-CE, the WTRU may remap (e.g., re-describe) the first position of the behavior description (which is TCI ID#X) updated to q_new1. The second position of the behavior description (which is TCI ID#Y) may remain unchanged, for example, the first code point may now be described as "q_new1, TCI ID#Y" as a code point suitable for indication of a unified TCI (e.g., for M-TRP). This may provide benefits in reducing overhead and latency in indicating a unified TCI based on a code point description (e.g., which may be automatically updated / activated / indicated based on a (MTRP) simultaneous BFR process in response to receiving a first BFR response) rather than updating the behavior description on the code point via MAC-CE.
[0205] The WTRU may receive a second BFR response (e.g., DCI2) from TRP2 via a second BFR-CORESET (e.g., BFR-CORESET#2), e.g., based on a (MTRP) simultaneous BFR procedure, e.g., after sending a second BFRR message associated with a second beam index (e.g., q_new2). In response to receiving the second BFR response, the WTRU may apply (e.g., determine, update) the set q_new2 to a second position of the (behavior) description of each of the one or more (or all) code points of the TCI field of the DCI indicating the unified TCI. The other position (e.g., the first position) of the behavior description of each of the one or more code points may remain unchanged. In one example, for a second code point of the TCI field, where the behavior description of the second code point is currently mapped (e.g., described) as "TCI ID#A, TCI ID#B", e.g., via MAC-CE, the WTRU may remap (e.g., re-describe) the second position of the behavior description (which is TCI ID#B) updated to q_new2. The first position of the behavior description (which is TCI ID#A) may remain unchanged, for example, and then the second codepoint may now be described as "TCI ID#A, q_new2" as a codepoint suitable for indication of a unified TCI (e.g., for M-TRP). This may provide benefits in reducing overhead and latency on indicating a unified TCI based on a codepoint description (e.g., which may be automatically updated / activated / indicated based on a (MTRP) simultaneous BFR process in response to receiving a second BFR response) rather than updating the behavior description on the codepoint via MAC-CE. Whether the first one or more codepoints of the first TCI field of DCI1 (e.g., via the first BFR-CORESET from TRP1) and the second one or more codepoints of the second TCI field of DCI2 (e.g., via the second BFR-CORESET from TRP2) are shared with each other may be configured / indicated (e.g., can be configured) from the gNB (e.g., via RRC and / or MAC-CE).
[0206] In response to receiving a control command from the gNB that the first one or more code points of the first TCI field of DCI1 (e.g., via the first BFR-CORESET from TRP1) and the second one or more code points of the second TCI field of DCI2 (e.g., via the second BFR-CORESET from TRP2) are shared with each other, the result of the remapping (e.g., re-describing) behavior with respect to the one or more code points of the first TCI field of the first DCI may be used for the next remapping (e.g., re-describing) behavior (e.g., with respect to the one or more code points of the second TCI field of the second DCI) that occurs by the next reception of a DCI (e.g., the second DCI) as a BFR response. In one example, based on the first code point of the TCI field of DCI1 being updated to q_new1, TCI ID#Y, in response to (e.g., again) receiving DCI2 indicating the first code point, the WTRU may remap (e.g., re-describing) the second position of the updated behavior description (which is currently TCI ID#Y) to q_new2. The first position of the behavior description (which is currently q_new1) may remain unchanged, for example, then the (e.g., shared) first code point may now be described as "q_new1, q_new2" as a code point suitable for indication of a unified TCI (e.g., for M-TRP). This may provide benefits in reducing overhead and latency in indicating a unified TCI based on a code point description (e.g., which may be automatically updated / activated / indicated based on a (MTRP) simultaneous BFR process in response to receiving a BFR response) rather than updating the behavior description on the code point via MAC-CE.
[0207] The WTRU may receive separate configuration of BFR-related parameters for each TRP, for example, based on a (MTRP) simultaneous BFR procedure. For example, the BFR-related parameters may include at least one of: rootSequenceIndex-BFR; rach-ConfigBFR; rsrp-ThresholdSSB; candidateBeamRSList (e.g., including q_new1, q_new2, ...); ssb-perRACH-Occasion; ra-ssb-OccasionMaskIndex; recoverySearchSpaceId; ra-Prioritization; beamFailureRecoveryTimer; powerRampingStep (e.g., power ramping factor, PREAMBLE_POWER_RAMPING_STEP); and PREAMBLE_POWER_RAMPING_COUNTER. In one example, at least one parameter for RACH-BFR in the MAC-CE may be configured / indicated separately per TRP (and / or per unified TCI pool). In one example, the powerRampingStep of at least one parameter may be individually configurable / indicated per TRP, which may provide the following benefits: a more aggressive power ramping step for a first TRP (e.g., a TRP based on a latency-critical service) may be applied at the WTRU (e.g., based on the indication / configuration of the gNB), and a less aggressive power ramping step for a second TRP (e.g., a TRP based on other services) may be applied at the WTRU (e.g., based on the indication / configuration of the gNB).
Claims
1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor, the processor being configured to: receiving information indicating that a first control resource set (CORESET) is associated with a first transmit configuration indicator (TCI) state instance and a second CORESET is associated with a second TCI state instance; receiving downlink control information (DCI), the downlink control information (DCI) including a TCI field indicating a TCI value; as well as monitoring a physical downlink control channel (PDCCH) transmission via at least one of the first CORESET or the second CORESET; wherein when the TCI value indicates that a first TCI state is associated with the first TCI state instance and when the first CORESET is associated with the first TCI state instance, the first TCI state is used to monitor the PDCCH transmission in the first CORESET; and Wherein when the TCI value indicates that a second TCI state is associated with the second TCI state instance and when the second CORESET is associated with the second TCI state instance, the second TCI state is used to monitor the PDCCH transmission in the second CORESET.
2. The WTRU of claim 1 , wherein the processor is configured to: Information indicating an association of the TCI value with the first TCI state for the first TCI state instance and the second TCI state with the second TCI state instance is received.
3. The WTRU of claim 2, wherein the information is received in a medium access control (MAC) control element (CE).
4. The WTRU of claim 1 , wherein the processor is configured to: Information indicating that the first CORESET is associated with the first TCI state instance and the second CORESET is associated with the second TCI state instance is received.
5. The WTRU of claim 4, wherein the information is received in a radio resource control (RRC) message.
6. The WTRU of claim 5, wherein the information indicating that the first CORESET is associated with the first TCI state instance and the second CORESET is associated with the second TCI state instance is specific to a bandwidth part or a serving cell.
7. The WTRU of claim 1 , wherein the processor is configured to: Based on determining that the TCI value is associated with both the first TCI state instance and the second TCI state instance, a PDSCH transmission is received using the first TCI state instance and the second TCI state instance.
8. The WTRU of claim 1 , wherein the processor is configured to: Based on determining that the TCI value is associated with one of the first TCI state instance or the second TCI state instance, a PDSCH transmission is received using the first TCI state instance or the second TCI state instance.
9. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving information indicating that a first control resource set (CORESET) is associated with a first transmit configuration indicator (TCI) state instance and a second CORESET is associated with a second TCI state instance; receiving downlink control information (DCI), the downlink control information (DCI) including a TCI field indicating a TCI value; as well as monitoring a physical downlink control channel (PDCCH) transmission via at least one of the first CORESET or the second CORESET; wherein when the TCI value indicates that a first TCI state is associated with the first TCI state instance and when the first CORESET is associated with the first TCI state instance, the first TCI state is used to monitor the PDCCH transmission in the first CORESET; and Wherein when the TCI value indicates that a second TCI state is associated with the second TCI state instance and when the second CORESET is associated with the second TCI state instance, the second TCI state is used to monitor the PDCCH transmission in the second CORESET.
10. The method according to claim 9, further comprising: Information indicating an association of the TCI value with the first TCI state for the first TCI state instance and the second TCI state with the second TCI state instance is received.
11. The method of claim 10, wherein the information is received in a Medium Access Control (MAC) Control Element (CE).
12. The method according to claim 9, further comprising: Information indicating that the first CORESET is associated with the first TCI state instance and the second CORESET is associated with the second TCI state instance is received.
13. The method of claim 12, wherein the information is received in a Radio Resource Control (RRC) message.
14. The method of claim 13, wherein the information indicating that the first CORESET is associated with the first TCI state instance and the second CORESET is associated with the second TCI state instance is specific to a bandwidth part or a serving cell.
15. The method according to claim 9, further comprising: Based on determining that the TCI value is associated with both the first TCI state instance and the second TCI state instance, a PDSCH transmission is received using the first TCI state instance and the second TCI state instance.
16. The method according to claim 9, further comprising: Based on determining that the TCI value is associated with one of the first TCI state instance or the second TCI state instance, a PDSCH transmission is received using the first TCI state instance or the second TCI state instance.
