TW202533615A - Method and apparatus for wireless transmit and receive unit initiated beam reporting and switching - Google Patents

Abstract

A WTRU may receive configuration for a plurality of available TCI states, and configuration for WTRU initiated beam reporting. The configuration may comprise a first threshold and a second threshold. The WTRU may receive an indication to activate one or more TCI states from the plurality of available TCI states. The WTRU may determine a candidate TCI state. The candidate TCI state may be signaled to the WTRU by the network. The WTRU may determine quality of the candidate TCI state and may determinate that the quality of the candidate TCI state is at least the first threshold higher than the quality of at least a number of active TCI states, wherein the number of active TCI states is equal to the second threshold. The WTRU may send a WTRU initiated beam report to the network.

Description

Method and apparatus for wireless transmit and receive unit initiated beam reporting and switching

This application claims the benefit of U.S. Provisional Patent Application No. 63/617,950, filed January 5, 2024, which is incorporated herein by reference.

The present invention relates to a method and apparatus for wireless transmit and receive unit initiated beam reporting and switching.

A wireless transmit and receive unit (WTRU) may transmit or receive a physical channel or reference signal, also referred to as a "beam," based on at least one spatial domain filter. The WTRU may receive a first downlink channel or signal based on the same spatial domain filter or spatial reception parameters as a second downlink channel or signal. For example, a physical downlink control channel (PDCCH) (a first channel) may be associated with its respective demodulation reference signal (DM-RS) (a second channel). This association may be configured as a transmission configuration indicator (TCI) state. The association may be indicated to the WTRU via an index into a set of TCI states (configured by RRC and/or signaled by MAC CE). This type of indication is also called "beam indication".

Learned beam selection is controlled by the base station (e.g., gNB) based on WTRU reports, such as channel state information (CSI) reports. The WTRU may be configured with measurement resources, such as reference signals (RS), and these resources are linked to the CSI reporting configuration. Based on the CSI reporting configuration (e.g., periodic, semi-persistent, or aperiodic reporting), the WTRU may measure the resources and report the measurement results via the CSI reporting configuration. In the case of aperiodic reporting, the gNB may use downlink control information (DCI) to trigger the measurement report. This learned beam or channel state information (CSI) reporting from the WTRU may be subject to latency and overhead issues, which may result in reduced efficiency.

Various aspects of efficient beam management with reduced latency and overhead by performing WTRU initiated beam measurement reporting (WTRU IBR) are disclosed.

Events may be configured in the WTRU. In one example, an event may be based on a comparison of beam quality to preconfigured thresholds. For example, an event may be based on whether the quality of the current beam is below a first threshold and the quality of at least one candidate beam is above a second threshold. Beam reporting may be initiated based on the quality of the current beam and the candidate beams relative to their respective thresholds. In another example, an event may be based on a relative comparison between the quality of the candidate beam and the quality of the current beam. For example, an event may be based on the difference between the quality of the candidate beam and the current beam being above a third threshold.

Based on these and other aspects described herein, a method for enabling WTRU initiated beam reporting (WTRUIBR) is disclosed.

The following abbreviations may be used in this document: CG Configuration Grant DG Dynamic Grant MAC CE MAC Control Element ACK Acknowledgement BLER Block Error Rate BWP Bandwidth Partition C-JT Coherent Joint Transmission CP Cyclic Preamble CP-OFDM Learned OFDM (Cyclic Preamble Dependent) CQI Channel Quality Indicator CRC Cyclic Redundancy Check CSI Channel Status Information DAI Downlink Assignment Index DCI Downlink Control Information DL Downlink DM-RS Demodulation Reference Signal DRB Data Radio Band HARQ Hybrid Automatic Repeat Request LTE Long Term Evolution (LTE), e.g., from 3GPP LTE Release 8 and above NACK Negative ACK mTRP Multiple Transmitter Relay (MTR) Multiple Transmitter Relay (MTR) MCS Modulation and Coding Scheme MIMO Multiple Input Multiple Output NC-JT Non-Coherent Joint Transmission NR New Radio OFDM Orthogonal Frequency Division Multiplexing PHY Physical Layer PMI Precoding Matrix Indicator PRACH Physical Random Access Channel PSS Primary synchronization signal RACH Random Access Channel (or procedure) RAR Random Access Response RF Radio Front End RLF Radio Link Fault RLM Radio Link Monitor RNTI Radio Network Identifier RRC Radio Resource Control RRM Radio Resource Management RS Reference Signal RSRP Reference Signal Received Power RSSI Received Signal Strength Indicator SDU Service Data Unit SRS Sounding Reference Signal SS Synchronization Signal SSS Secondary Synchronization Signal SPS Semi-persistent Scheduling SUL Supplemental Uplink TB Transmit Block Size TBS Transmit Block Size TCI Transmit Configuration Indicator TRP Transmit/Receive Point UL Uplink URLLC Ultra-Reliable Low Latency Communication WLAN Wireless Local Area Network and related technologies (IEEE 802.xx domain) WTRU Wireless Receive and Transmit Unit

As used herein, “a” and “an” and similar terms are to be interpreted as “one or more” and “at least one.” Similarly, any term ending with the suffix “(s)” is to be interpreted as “one or more” and “at least one.” The term “may” is to be interpreted as “may, for example.”

As used herein, the symbol “/” (forward slash) may be used herein to mean “and,” “or,” or “and/or,” where, for example, “A/B” may imply “A and/or B.”

FIG1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multi-access system that provides content (e.g., voice, data, video, messaging, broadcast, etc.) to multiple wireless users. Communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access schemes 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), and the like.

As shown in FIG1A , a communication system 100 may include wireless transmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. It will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 d 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, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a light-weight notebook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, or a head-mounted display (HMD). The WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

The communication system 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or other networks 112. For example, the base stations 114a and 114b may be a base transceiver station (BTS), a Node-B, an eNode-B (eNB), a local Node-B, a local eNode-B, a next-generation Node-B (e.g., a gNode-B (gNB), a new radio (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 will be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

The base stations 114a and 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as mentioned 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may utilize wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

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) that may utilize Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro) to establish the airborne interplane 116.

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR that may establish NR radio access over the air interface 116.

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 implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Consequently, the airborne medium utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions to and from multiple types of base stations (e.g., eNBs and gNBs).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114b in FIG1A may be a wireless router, a local node B, a local eNode B, or an access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, a skyway (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c and 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 and 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 and 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG1A , the base station 114b may have a direct connection to the internet network 110. Therefore, the base station 114b may not need to access the internet network 110 via the CN 106.

The RAN 104 may communicate with the CN 106, 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 services may have different quality of service (QoS) requirements, such as throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and/or perform advanced security functions, such as user authentication. Although not shown in FIG1A , it will be appreciated that the RAN 104 and/or the CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to connecting to the RAN 104 (which may utilize NR radio technology), the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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 radio links). For example, the WTRU 102c shown in FIG1A may be configured to communicate with a base station 114a that may employ a cellular-based radio technology and with a base station 114b that may employ IEEE 802 radio technology.

FIG1B is a system diagram illustrating an example WTRU 102. As shown in FIG1B , the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the aforementioned elements while remaining consistent with an embodiment.

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

The transmit/receive element 122 can be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from the base station via the air interface 116. For example, in one embodiment, the transmit/receive element 122 can be configured as an antenna that transmits and/or receives RF signals. In another embodiment, for example, the transmit/receive element 122 can be configured as a transmitter/detector that transmits and/or receives IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 can be configured to transmit and/or receive both RF and optical signals. It should be understood that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.

Although the transmit/receive element 122 is depicted as a single element in FIG1B , 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.

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and receive user input from the speaker/microphone 124, keypad 126, and/or 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, keypad 126, and/or display/touchpad 128. Additionally, processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. Non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard drive, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and 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).

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 battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-hydrogen (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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 instead of) the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a and 114b) via 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 obtain location information using any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may be further coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, peripheral device 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, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game console module, an internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, and the like. Peripheral device 138 may include one or more sensors. The sensor 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, a humidity sensor, and the like.

The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous. A full-duplex radio may include an interference management element to reduce and/or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or DL (e.g., for reception)) may be concurrent and/or simultaneous.

FIG1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may utilize E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.

The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it should be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may utilize multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a.

Each of the eNodeBs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG1C , the eNodeBs 160a, 160b, and 160c can communicate with each other via an X2 interface.

1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the above elements are depicted as components of CN 106, it will be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

The SGW 164 may be connected to each of the eNode-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 also perform other functions such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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.

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 landline communications devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in Figures 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may utilize (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a distribution system (DS) or another type of wired/wireless network that loads traffic into and/or out of the BSS. Traffic originating from outside the BSS destined for STAs may reach and be delivered to those STAs through the AP. Traffic originating from STAs destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs within the BSS may be routed through the AP, e.g., where a source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. IBSS communication mode may sometimes be referred to herein as "ad-hoc" communication mode.

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

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

Very High Throughput (VHT) STAs support 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz channel widths. 40 MHz and/or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels (this is referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data is passed through a segment parser that separates the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately for each stream. The streams are mapped onto two 80 MHz channels, and the data is transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).

Sub-1 GHz operation is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequencies in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter type control/machine type communications (MTC), such as MTC devices within a large coverage area. MTC devices may have certain capabilities, including, for example, limited capabilities that support (e.g., only certain and/or limited bandwidths). MTC devices may also include batteries with longer-than-critical battery life (e.g., to maintain a very long battery life).

WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by the STA that supports the lowest-bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC-type devices), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. For example, if the primary channel is busy, for example, due to a STA (which only supports 1 MHz operation) transmitting to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

In the United States, the available frequency bands (which can be used by 802.11ah) are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is between 6 MHz and 26 MHz.

FIG1D illustrates a system diagram of the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, and 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.

The RAN 104 may include gNBs 180a, 180b, and 180c, although it should be understood that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, utilize multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation. For example, gNB 180a may transmit multiple component carriers to 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, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP). For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable set of parameters (numerology). For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or a continuously varying absolute time duration).

The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., eNode-Bs 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 WTRUs 102a, 102b, 102c may communicate with/connect to the gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobile anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102b, 102c.

Each gNB 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, support for network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data to the User Plane Function (UPF) 184a and 184b, routing of control plane information to the Access and Mobility Management Function (AMF) 182a and 182b, and the like. As shown in FIG1D , gNBs 180a, 180b, and 180c can communicate with each other via an Xn interface.

The CN 106 shown in FIG1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include Data Networks (DNs) 185a, 185b. Although these components are depicted as part of the CN 106, it will be understood that any of these components may be owned and/or operated by an entity other than the CN operator.

The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access-stratum (NAS) messages, managing mobility, and the like. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services being used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMFs 182a, 182b may provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies (e.g., LTE, LTE-A, LTE-A Pro) and/or non-3GPP access technologies (e.g., WiFi).

SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure the routing of traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. PDU session types can be IP-based, non-IP-based, Ethernet-based, and the like.

The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the regional DNs 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

In view of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more simulation devices (not shown): WTRUs 102a to 102d, base stations 114a to 114b, eNodeBs 160a to 160c, MME 162, SGW 164, PGW 166, gNBs 180a to 180c, AMFs 182a to 182b, UPFs 184a to 184b, SMFs 183a to 183b, DNs 185a to 185b, and/or any other device(s) described herein may be performed by one or more simulation devices (not shown). The emulation device may be configured to emulate one or more devices that perform one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.

Emulators can be designed to perform one or more tests on other devices in a laboratory environment and/or an operator network environment. For example, one or more emulators can be fully or partially implemented and/or deployed as part of a wired and/or wireless communication network while performing one or more or all functions to test other devices within the communication network. One or more emulators can be temporarily implemented/deployed as part of a wired and/or wireless communication network while performing one or more or all functions. Emulators can be directly coupled to another device for testing purposes and/or perform tests using over-the-air wireless communications.

One or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices can be used in a test lab and/or a test scenario in a non-deployed (e.g., testing) wired and/or wireless communication network to perform testing of one or more components. One or more emulation devices can be test instruments. The emulation devices can transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., which may include one or more antennas).

Artificial intelligence (AI) can be broadly defined as the behavior exhibited by machines. Such behavior can include, for example, simulating cognitive functions to perceive, infer, adapt, and/or act. AI systems can learn and leverage the real world (e.g., existing datasets, entity behavior, sensory information, etc.) to train AI models based on various learning schemes (e.g., deep learning, federated learning, reinforcement learning, and/or combinations thereof). Trained models can automatically discover useful knowledge, make decisions, or acquire application-specific skills.

Machine learning (ML) may refer to a type of algorithm that solves problems based on learning from experience or data, without the need for explicitly programmed or configured rule sets. Machine learning may be considered a subset of AI. Different machine learning paradigms may be envisioned based on the nature of the data or feedback available to the learning algorithm. For example, supervised learning methods may involve learning a function that maps inputs to outputs based on labeled training examples, where each training example may include a pair of an input and a corresponding output. For example, unsupervised learning methods may involve detecting patterns in data that does not have pre-existing labels. For example, reinforcement learning methods may involve executing a sequence of actions in an environment to maximize a cumulative reward. In some solutions, it's possible to apply machine learning algorithms using a combination or interpolation of the methods mentioned above. For example, semi-supervised learning methods can use a combination of a small amount of labeled data and a large amount of unlabeled data during training. In this respect, semi-supervised learning falls between unsupervised learning (without labeled training data) and supervised learning (with only labeled training data).

Deep learning (DL) refers to a class of machine learning algorithms that employ artificial neural networks, specifically deep neural networks (DNNs). DNNs are a special type of machine learning model in which the input is linearly transformed and repeatedly passed through nonlinear activation functions. DNNs typically consist of multiple layers, each of which includes a linear transformation and a nonlinear activation function. DNNs can be trained using training data via a backpropagation algorithm. DNNs are used in a variety of domains, such as speech, vision, and natural language, as well as in various machine learning settings (e.g., supervised, unsupervised, and semi-supervised).

The term AIML (Artificial Intelligence Machine Learning)-based processing refers to the process of implementing behaviors and/or meeting requirements through data-based learning without requiring any explicitly configured sequence of actions. Such approaches can enable learning of complex behaviors that would be difficult to specify and/or implement using traditional methods.

An AIML model may refer to an implementation of an AIML-based method that consists of (1) model parameters and (2) model structure. For example, a DNN-based AIML model may include model parameters (i.e., weights and biases) and model structure (i.e., the type and size of each layer of the deep neural network, such as dense layer, convolutional layer, etc.).

This document discusses spatial domain filters, also referred to as "beams." A WTRU may transmit a physical channel or signal using the same spatial domain filter it uses to receive reference signals (RSs), such as the channel state indicator reference signal (CSI-RS) or synchronization signal blocks (SSBs). The WTRU transmission may be referred to as a "target," and the received RS or SS block may be referred to as a "reference" or "source." In such cases, the WTRU may be said to transmit the target physical channel or signal based on the spatial relationship of the reference to such RS or SSB block.

A WTRU may perform a first transmission using a first physical channel or signal based on the same spatial domain filter used to perform a second transmission on a second physical channel or signal. The first and second transmissions may be referred to as a "target" and a "reference" (or "source"), respectively. In such cases, the WTRU may claim to transmit the first (target) physical channel or signal based on a spatial relationship with respect to the second (reference) physical channel or signal.

Spatial relationships can be implicit, configured by RRC, or signaled by a MAC control element (CE) or downlink control information (DCI). For example, a WTRU may implicitly transmit the physical uplink shared channel (PUSCH) and the demodulation reference signal (DM-RS) for the PUSCH based on the same spatial domain filter as the sounding reference signal (SRS) resource indicator (SRI) indicated in the DCI or configured by RRC. In another example, a spatial relationship can be configured by RRC for the SRI or signaled by a MAC CE for the physical uplink control channel (PUCCH). This type of spatial relationship is also referred to as a "beam indication."

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, such 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 respective DM-RS. At least when the first signal and the second signal are reference signals, such an association may exist when the WTRU is configured with a quasi-colocation (QCL) assumption type D between corresponding antenna ports. Such an association may be configured as a transmission configuration indicator (TCI) state. The WTRU may indicate the association between CSI-RS or SS blocks and DM-RS by an index of a set of TCI states configured by RRC and/or signaled by MAC CE. Such indication may also be referred to as "beam indication."

Unified TCI (UTCI) may refer to beams/RSs used for multiple physical channels/signals (simultaneously) and may include, for example, common TCI, common beams, or common RSs. The term "TCI" may include TCI states that include at least one source RS for reference.

For example, a WTRU may receive (e.g., from a gNB) an indication of a first unified TCI to be used/applied for both the downlink control channel (PDCCH), the physical downlink shared channel (PDSCH), and the downlink RS. The source reference signal(s) in the first unified TCI may provide common QCL information for at least WTRU-specific reception on the PDSCH and for all or a subset of the CORESETs in a component carrier (CC). For example, a WTRU may receive (e.g., from a gNB) an indication of a second unified TCI to be used/applied for both the uplink control channel (PUCCH) and the uplink shared channel (PUSCH) (e.g., and the uplink RS). The source reference signal(s) in the second unified TCI may provide references for determining common UL TX spatial filter(s) for at least all or a subset of the PUSCH and dedicated PUCCH resources in a CC based on dynamically granted/configured granted PUSCH.

The WTRU may be configured with a first mode for unified TCI (e.g., Separate DL ULTCI mode), where the indicated unified TCI (e.g., first unified TCI or second unified TCI) may be applied for downlink (e.g., based on the first unified TCI) or uplink (e.g., based on the second unified TCI).

For example, the WTRU may receive (e.g., from a gNB) an indication of a second unified TCI to be commonly used/applied to PDCCH, PDSCH, PUCCH, and PUSCH (and DL RS and/or UL RS).

The WTRU may be configured with a second mode for unified TCI (eg, JointTCI mode), where an indicated unified TCI (eg, a third unified TCI) may be applied for both downlink and uplink (eg, based on the third unified TCI).

A 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. A transmission may consist of at least PUCCH, PUSCH, SRS. A reception may include at least PDCCH, PDSCH, and/or CSI-RS. A unified TCI state instance may also be referred to as a TCI state group, a TCI state program, a unified TCI pool, a group of TCI states, a set of time domain instances/stamps/slots/symbols, and/or a set of frequency domain instances/RBs/subbands, etc. A unified TCI state instance may be equivalent to or identical to a control resource set pool identifier (e.g., CORESETPoolIndex, TRP indicator, and/or the like).

As used herein, unified TCI may be used interchangeably with one or more of unified TCI state, unified TCI instance, TCI, and TCI state while remaining consistent with the present invention.

Transmission Reception Point (TRP) and Multi-TRP (MTRP) may be used interchangeably with one or more of TP (transmission point), RP (reception point), RRH (radio remote head), DA (distributed antenna), BS (base station), sector (of a BS), and cell (e.g., the geographic cell area served by a BS) while remaining consistent with the present invention. As used herein, Multi-TRP may be used interchangeably with one or more of MTRP, M-TRP, and/or multiple TRPs while remaining consistent with the present invention.

Configuration of TRPs, SRIs, and PL Reference RSs: A WTRU may be configured with one or more TRPs that it may transmit to and/or receive from (or configured to receive such one or more TRPs). A WTRU may be configured with one or more TRPs for one or more cells. A cell may be a serving cell or a secondary cell.

The WTRU may be configured with at least one RS for the purpose of channel measurement. This RS may be denoted as a Channel Measurement Resource (CMR) and may include a CSI-RS, an SSB, or another downlink RS transmitted from a TRP to the WTRU. A CMR may be configured with or associated with a TCI state. The WTRU may be configured with CMR groups, where CMRs transmitted from the same TRP may be configured. Each group may be identified by a CMR group index (e.g., group 1). The WTRU may be configured with one CMR group per TRP, and the WTRU may receive a link between one CMR group index and another CMR group index or between one RS index from one CMR group and another RS index from another group.

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

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

The WTRU may receive a configuration (e.g., any of the configurations described herein). The configuration may be received from the gNB or the TRP. For example, the WTRU may receive a configuration 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 the SRS in the first resource set for transmission to TRP1 and to use the SRS in the second resource set for transmission to TRP2. The configuration may be signaled via RRC.

In the examples and embodiments described herein, TRP, PL reference group, SRI group, and SRI set are used interchangeably. The terms set and group are used interchangeably herein.

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

The properties of a grant or assignment may include at least one of the following: - frequency allocation; - the nature of the time allocation (e.g., duration); - priority; - modulation and coding scheme; - transmission block size; - number of spatial layers; - number of transmission blocks; - TCI status, CRI, or SRI; - number of repetitions; - whether the repetition scheme is type A or type B; - whether the grant is a configured grant type 1, type 2, or dynamic grant; - whether the assignment is a dynamic assignment or a semi-persistently scheduled (e.g., configured) assignment; - a configured grant index or a semi-persistent assignment index; - the configured or assigned periodicity; - a channel access priority class (CAPC); or -Any parameters provided by MAC or RRC in DCI for scheduling authorization or assignment.

As used herein, an indication of a DCI may consist of at least one of: an explicit indication of a DCI field or RNTI used to mask the CRC of the PDCCH; or an implicit indication of a property such as the DCI format, DCI size, control resource set (coreset) or search space, aggregation level, or the index of the first resource element of the received DCI (e.g., the index of the first control channel element), where the mapping between the property and the value may be signaled by RRC or MAC.

As used herein, the terms "prediction" and "estimation" may be used interchangeably while remaining consistent with the present invention.

As used herein, the terms “source cell,” “current cell,” and “serving cell” may be used interchangeably while remaining consistent with the present invention.

As used herein, the terms “candidate cell,” “neighbor cell,” and “target cell” may be used interchangeably while remaining consistent with the present invention.

As used herein, the terms “beam” and “TCI state” are used interchangeably.

As used herein, signal may be used interchangeably with one or more of the following: sounding reference signal (SRS), channel state information reference signal (CSI-RS), demodulation reference signal (DM-RS), phase tracking reference signal (PT-RS), or synchronization signal block (SSB).

As used herein, a channel may be used interchangeably with one or more of the following: physical downlink control channel (PDCCH), physical downlink shared channel (PDSCH), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), physical random access channel (PRACH), or other types of channels.

As used herein, downlink reception can be used interchangeably with Rx timing, PDCCH, PDSCH, and SSB reception.

As used herein, uplink transmission is interchangeable with Tx timing, PUCCH, PUSCH, PRACH, and SRS transmission.

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

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

As used herein, time instance may be used interchangeably with time slot, symbol, or subframe.

As used herein, UTCI may be used interchangeably with TCI, UTCI status, and TCI status.

In one example, aperiodic WTRU-driven reporting specific to an UL channel or signal and based on a maximum duration is provided. In one example, if the next available UL transmission opportunity does not fall within the maximum duration, the WTRU may perform an aperiodic (e.g., contention-based) transmission method for event-based beam reporting, such as contention-based PUCCH transmissions, PRACH+PUSCH transmissions. Note that in some cases, the maximum duration may be configurable.

In one example, the WTRU may receive a configuration for event-based beam reporting, indicating at least what to measure (e.g., a set of RSs, a set of TCI states, etc.), how to determine one or more events, e.g., based on (L1-)RSRP, (L1-)RSRQ, (L1-)SINR, CQI, etc., and what/how to report based on the event.

In one example, a WTRU may receive configuration information indicating a maximum duration for which event-based beam reporting may be performed, for example, because such information needs to be reported quickly (e.g., before beam failure detection/recovery is initiated). The maximum duration may be an offset (e.g., number of slots, frames, etc.) from the time the trigger condition is met. The report may include at least beam information and/or beam quality information.

The WTRU may determine that an event has occurred based on measuring a set of beam quality metrics for a set of RSs and determining an event function by comparing the set of beam quality metrics to one or more thresholds, for example, based on layer 1/2 event measurements.

The WTRU may determine one or more report contents based on an event, where the report contents may include the determined beam(s) (e.g., one or more RSs in a set of RSs), one or more corresponding beam quality metrics, and/or a flag representing the event.

When a triggering event is met, the WTRU may determine whether the next available UL transmission opportunity (e.g., PUSCH, PUCCH, etc.) falls within the maximum duration of the event-based beam reporting. In some cases, the maximum duration may be configurable.

Based on this determination, the WTRU may selectively perform (1) WTRU-driven reporting based on scheduled UL channels (e.g., non-contention), or (2) WTRU-driven reporting based on contention-based transmissions.

Scheduled UL channel transmissions (e.g., non-contention) may be WTRU-driven reporting. If the next available UL transmission opportunity is determined to fall within the maximum duration from the triggering event, the WTRU may use the next available scheduled UL transmission opportunity to perform event-based beam reporting.

In an example, the WTRU may signal the CSI or beam reporting content via the (most recently available or scheduled) PUCCH resource (or PUSCH) for CSI reporting, for example, by adding a new portion of the CSI or beam reporting content (e.g., Part 3 CSI). The WTRU may determine the CSI or beam reporting content by combining (e.g., merging, concatenating) the new portion with the NW-controlled reporting content (e.g., Part 1 and/or Part 2 CSI already scheduled for reporting via PUCCH resources). The WTRU may also or alternatively be configured to swap CSI part(s) and reuse the bit width (e.g., allocated for Part 1 and/or Part 2 CSI) for WTRU-driven reporting, e.g., by inserting zero padding bit(s) to match the bit width, which may include an N-bit flag (e.g., N=1) to indicate new report content based on WTRU-driven reporting.

In the event that the WTRU determines that the PUCCH resources used for CSI reporting include a HARQ-ACK transmission (e.g., when the HARQ-ACK transmission is piggybacked on the CSI report), the WTRU may be configured to discard the CSI portion and reuse the discarded portion for WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not discarded and is concatenated with the report content for WTRU-driven reporting.

In the event that more than one opportunity is found within the maximum duration, the WTRU may be configured or defined to have a priority between the above PUSCH and PUCCH. For example, in one case, the earlier opportunity may be used. In another case, such as when PUSCH and PUCCH conflict in the same time slot or symbol, PUSCH may be used.

Contention-based WTRU-driven reporting may be used. For example, if the next available UL transmission opportunity does not fall within the maximum duration, the WTRU may perform contention-based transmission (e.g., transmission using shared resources) with event-based beam reporting.

For example, a WTRU may be configured to perform PUCCH transmissions on one or more shared PUCCH resources, where the one or more shared PUCCH resources are configured to the WTRU (e.g., via RRC) for such event-based beam reporting. The WTRU may or may be configured to transmit the report content and one or more identifiers (e.g., WTRU-ID, RNTI, jammer ID/parameters, etc.) to identify the WTRU via the PUCCH transmission. This may occur, for example, because one or more PUCCH resources may also be configured for other WTRU(s), causing conflicts among the WTRUs. This may provide benefits, particularly when it is desirable to maintain a current timing advance (TA), such as that determined by the WTRU or signaled (e.g., configured) by the gNB.

In another example, a WTRU may (or may be configured to) perform a RACH transmission and an associated PUSCH transmission, where the RACH transmission may be contention-based. The WTRU may receive an indication or configuration for a two-step transmission procedure (e.g., a PRACH transmission and one or more associated PUSCH transmissions), where the PUSCH payload may convey the report content. This may provide benefits, particularly when a new TA is desired, e.g., determined by the WTRU or signaled by the gNB (e.g., configured).

In some 5G systems, NR-MIMO operation, beams, or CSI reporting from the WTRU is performed by gNB-controlled procedures. Specifically, the WTRU may be configured with measurement resources (NZP-CSI-RS resources and/or SSB indices) including CSI-IM resources, which are linked to the CSI reporting configuration. Based on the CSI reporting configuration (e.g., periodic, semi-persistent, or aperiodic reporting), the WTRU measures the measurement resources and reports the measurement results via the CSI reporting configuration. In the case of aperiodic reporting, the gNB triggers the WTRU to perform the measurement and reporting actions (by sending a Directed Response (DCI)). There is a need to reduce the latency and overhead associated with existing gNB-controlled beam management methods.

According to various embodiments, a WTRU-driven beam reporting method may be provided to reduce beam management latency and overhead.

In one example, a WTRU may be configured with multiple transmission configuration indicator (TCI) states, such as unified TCI (UTCI) states, each state applicable to multiple channels/signals. Multiple channels/signals may be configured (or pre-determined or defined) to the WTRU via higher-layer signaling (e.g., RRC and/or MAC-CE), for example, in the form of a list. The higher-layer signaling may include at least one of the following: One or more CORESETs; One or more PDCCH candidates; One or more search spaces; One or more PDSCHs (e.g., PDSCH timing/configuration/instances, etc.); One or more RSs (e.g., CSI-RS, DMRS, SSB index, PRS, PTRS, and/or SRS); One or more PUSCHs (e.g., PUSCH timing/configuration/instances, etc.); One or more PUCCH resources (e.g., PUCCH resource sets/groups); or One or more PRACH timings/resources/RSs.

A plurality of TCI states may be configured via RRC signaling (e.g., and/or via MAC-CE signaling, indication, or activation). A WTRU may receive, for example, via MAC-CE or separate signaling, information content comprising a mapping between one or more codepoints of a DCI field (e.g., a TCI field and/or a TCI selection field) and at least one TCI state of a plurality of TCI states. The WTRU may receive DCI comprising a DCI field. The WTRU may be configured with one or more TCI states having one of the plurality of TCI states mapped to one or more codepoints of the DCI field, wherein each of the one or more TCI states may be applicable after a duration determined based on a beam application time (BAT) parameter.

Figure 2 shows an example of DCI used for unified TCI status indication.

In this example, codepoint 202 is received in the TCI field in the DCI and mapped to UTCI 201. Specifically, in this example, codepoint 202 includes 3 bits representing TCI states 0 through 7. This example is non-limiting; for example, more or fewer TCI states may be defined. The WTRU may receive a mapping between codepoint 202 in the DCI and UTCI 201. As shown in diagram 203, the WTRU may receive one or more TCI states via, for example, MAC-CE signaling.

For example, codepoint 2 204 may be mapped to {UTCI3 205, UTCI7 206}, where the WTRU may apply at least one of UTCI3 205 or UTCI7 206 to the channel/signal(s). This may be based on a list of channel/signal(s) that may be configured via higher-layer signaling from the gNB. For example, a list of multiple channels/signals may be given per UTCI instance, where, as shown, a UTCI instance may correspond to a row in the mapping table: UTCI instance #1 207 and UTCI instance #2 208. As an example, if two sets of channels/signals are configured, the first set may be associated with UTCI instance #1 209, and the second set may be associated with UTCI instance #2 210.

In one example, a threshold level may be based on the type of candidate beams provided for WTRU-initiated beam reporting. The WTRU may determine that the quality of the current beam is below a first threshold. Based on that determination, the WTRU may determine that the quality of other candidate beam(s) is above a threshold, where the threshold is determined based on the type of the other beam(s) and/or the status of the UTCI (determined to be active or inactive).

In one example, a WTRU may receive a configuration of one or more of the following: a plurality of beam indices (e.g., TCI status, unified TCI status (UTCI), RS resources, etc.), where each beam index may be associated with a beam (e.g., an RS that may be used to determine a beam to use for transmission or reception); (multiple) beam reporting related parameters (e.g., periodicity, (multiple) UL resources for reporting, etc.); one or more thresholds for determining one or more events that may trigger a report; and/or one or more priority parameters or priority information associated with one or more triggering events or reports associated with the events, such as a priority of each event or report or a priority order of events or reports.

The WTRU may receive an indication of one or more activated beam indices (eg, activated UTCI states).

The WTRU may, for example, receive an indication of a first and/or second beam index from a plurality of beam indices (e.g., activated beam indices) for DL and/or UL communication with the gNB, wherein the first beam index (e.g., UTCI3) may be used to determine a first current beam for communication with TRP1 of the gNB, and the second beam index (e.g., UTCI7) may be used to determine a second current beam for communication with TRP2 of the gNB.

The WTRU may perform one or more beam measurements based on the configuration to determine whether a reporting event occurs, where the reporting event may occur based on at least one of event 1, event 2, or event 3, and where the beam quality may be, for example, at least (L1-)RSRP, (L1-)SINR, (L1-)RSRQ, CQI, etc.

Event 1 can be used to improve or assist the gNB in dynamically selecting among activated UTCIs. Event 1 can occur when: the first beam quality of the first current beam (or the second beam quality of the second current beam) is below a first threshold; and the beam quality difference between the first current beam (or the second current beam) and a third beam associated with another activated beam index (e.g., UTCI status) exceeds a second threshold. For example, when the L1-RSRP of UTCI 23 (new) minus the L1-RSRP of UTCI 3 (current) exceeds the second threshold.

Event 2 may be used to improve or assist the gNB in determining a newly activated UTCI. Event 2 may occur when: the first beam quality of the first current beam (or the second beam quality of the second current beam) is below a first threshold; and the beam quality difference between (e.g., any) beam associated with the activated beam index and the candidate beam exceeds a threshold, wherein the WTRU may receive (e.g., via RRC) a configuration of one or more candidate beams, and the configuration may indicate a TCI or UTCI status pool.

For example, event 3 may be used to find a new beam based on beam prediction. Event 3 may occur when the first beam quality of the first current beam (or the second beam quality of the second current beam) is below a first threshold, and the beam quality difference between the beam associated with the activated beam index (e.g., the current or any other beam) and the beam determined based on beam prediction exceeds a threshold.

When the WTRU determines (e.g., declares) that an event (e.g., event 1, event 2, or event 3) occurs, the WTRU may transmit (e.g., report) at least one of the following: a beam index of a beam with a higher beam quality that triggers the event, e.g., the beam index of the third beam for event 1, the beam index of the candidate beam for event 2, or the beam index of the predicted beam for event 3; (multiple) beam quality metrics for the beam associated with the reported beam index, e.g., one or more of (L1-)RSRP, (L1-)SINR, (L1-)RSRQ, CQI, etc.; and a flag indicating the event (of one or more events).

When multiple events are triggered and reports for two or more events conflict (e.g., in the same symbol or time slot), the WTRU may send a report for one of the events, where the event to send the report for is determined by the WTRU based on (multiple) configured priority parameters or information.

The WTRU may or may be configured to determine a priority order (e.g., ranking) among one or more events or reports associated with events based on (multiple) configured priority parameters or information, for example, the priority order may be determined such that event 2 is the highest priority, event 1 is the second highest priority, and event 3 is the lowest priority.

The WTRU may send a report via an UL signal or channel, where the WTRU determines the UL signal or channel to use for transmission based on a configuration that may be associated with the event that triggered the report, for example.

In one example, a WTRU may receive a configuration of multiple beam indices (e.g., TCI status, beam ID, RS, RS resources, unified TCI (UTCI), or unified TCI status (UTCI status), etc.), wherein one or more events may be defined or configured, the one or more events triggering reporting of at least one beam index among the multiple beam indices, wherein one or more thresholds are associated with the one or more events. For example, the configuration may further include (multiple) beam reporting related parameters (e.g., periodicity, (multiple) UL resources used for reporting, etc.), one or more thresholds for determining one or more events that may trigger reporting, and/or one or more priority parameters or priority information associated with one or more triggering events or reports associated with the events, such as the priority of each event or report or the priority order of events or reports.

As mentioned above, Event 1 can be used to improve or help the gNB perform dynamic selection among activated UTCIs.

The WTRU may receive a configuration of multiple unified TCI states (UTCIs) (e.g., multiple beam indices), one or more types of candidate (UTCI) beams, one or more events defined based on the one or more types of candidate (UTCI) beams, one or more thresholds each associated with the event, and/or at least one WTRU-driven reporting configuration.

The WTRU may currently use or maintain a first UTCI (e.g., UTCI 3) and a second UTCI (e.g., UTCI 7). This may be based on timely indications of the first and second UTCIs, such as those provided via DCI reception. The indication must meet a defined beam application timeline, as illustrated in Figure 1. For example, this may involve receiving codepoint 2 of the TCI field of the DL-DCI. This reception must occur sufficiently in advance, meaning that the time required to apply the UTCI, including the beam application time (BAT), has already passed. In one example, the WTRU may be configured to determine the difference in beam quality (e.g., (L1-)RSRP, (L1-)SINR, (L1-)RSRQ, CQI, etc.) between the current (one or more) (UTCI) beams and other candidate (UTCI) beams, which may correspond to one of one or more configured, defined, or indicated events (e.g., event 1). The other candidate (UTCI) beam(s) may be other UTCIs activated/mapped in (the same row of) the TCI field. This may provide benefits to assisting gNBs (e.g., serving gNB, serving cell, TRP, serving TRP) to help the gNB make better dynamic selections among the activated UTCIs.

For example, the current UTCI3 may be compared with UTCI2, UTCI23, UTCI26, UTCI4, UTCI15, and/or UTCI5 (each of which is in the first row of the TCI field and may be the first indicated TCI). The WTRU may determine (e.g., select) UTCI23 to report based on the beam quality comparison between UTCI3 and UTCI23, where the report content may include a first index or value associated with UTCI23, a corresponding first beam quality metric, and/or a flag indicating event 1.

For example, the current UTCI 7 may be compared with UTCI 9, UTCI 4, UTCI 11, UTCI 19, and/or UTCI 8 (each of which is in the second row of the TCI field and may be the second indicated TCI). The WTRU may determine (e.g., select) UTCI 11 to report based on the beam quality comparison between UTCI 7 and UTCI 11, where the report content may include a second index or value associated with UTCI 11 and/or a corresponding second beam quality metric, and/or a flag indicating Event 1.

The WTRU may be (configured to) report report content based on one or more events (eg, event 1) occurring via an UL channel or signal.

As described above, Event 2 may be used to improve or assist the gNB in determining a newly activated UTCI.

In event 2, the WTRU may be configured with a UTCI pool via RRC. The RRC-configured UTCI pool may be large, with up to 256 states. Beyond this initial UTCI pool, the WTRU may obtain a first set of UTCIs activated by the MAC CE, meaning that the associated RS may be used to actively measure and maintain UTCIs for beam management purposes. Because active measurement of activated UTCIs has a defined granularity and specific reporting procedures, including Layer 1 reporting and Layer 3 filtered reporting, the WTRU may receive a second set of UTCIs for beam measurement purposes.

A second set of UTCIs may be added to the measurement procedure in addition to the already activated first set of UTCIs. The maximum size of the second set of UTCIs may be based on the WTRU's reported capabilities, which may be described as the maximum number of UTCIs that can be tracked simultaneously in total, or the number of UTCIs that can be tracked simultaneously that exceed the maximum activated UTCI (e.g., more than 8 UTCI codepoints).

The second UTCI set can also be configured by MAC CE (or by RRC configuration and/or indicated by DCI). The second UTCI set can be part of the RRC configuration pool. The second UTCI measurement command can contain any combination of the following parameters: the second set of UTCI codepoints; and/or an indicator or pointer to an Event 2 configuration, as multiple Event 2 configurations may exist (e.g., permanent measurement, initiated by critical semi-static, or initiated by a DCI command).

The WTRU may be configured with an Event 2 measurement report that may include any combination of the following parameters: a second set of measurement granularity (e.g., this may be measured less frequently than the first set of UTCI measurement granularity); one or more thresholds for measurement activation, since the procedure may only take effect if the quality of a certain number of UTCI states from the first set is below a certain quality; a reporting threshold for the second UTCI set; and/or a trigger time for the second set of measurement reports, meaning that a report is only sent to the network if the measurements of the members of the second UTCI set are above the configured quality measurement within the configured trigger time.

Therefore, the second UTCI set measurements may be initiated by the WTRU only under configured conditions and may not be performed permanently.

Alternatively, a second UTCI set may be measured continuously at an ordered granularity and reported as Event 2 under configured quality and/or time conditions.

Alternatively, the second UTCI set measurement and reporting may be activated by the network using a DCI command. This may be a one-shot measurement of the entire second UTCI set, or an aperiodic measurement setup that may be terminated by a WTRU reporting disable command from the network.

When the conditions for measuring the second UTCI set are met or activated, the WTRU measures a configured number of relevant/associated RS (e.g., RSRP, RSRQ, SINR) and may report, for example, UTCIs that are above a certain quality threshold defined by the Event 2 configuration. The report may contain any combination of the following parameters: index(es) to the UTCI state that met the Event 2 configuration conditions; pointers to UTCI states from the second set; the number of associated UTCI measurements; the difference in measurement quality of the specific UTCI from the second set; and/or index(es) to or pointers to any active UTCI state from the first set that is more reliable (below the quality threshold) and an index to or pointers to UTCI states from the second set that met the quality threshold, e.g., as described by Event 2.

In one example, using the combination of the above conditions, the WTRU may rank the active beams from lower quality to higher quality, and the WTRU may determine whether the beam quality of one or more (e.g., M) active beams is below a threshold. If so, Event 2 measurement is triggered, as described above. The WTRU may then determine whether the beam quality of the candidate beam is better than the beam quality of one or more (e.g., N) active beams. In one example, M = N.

In one example, the second set of UTCI event 2 reports can be sent by UCI via PUSCH, PUCCH, MAC CE, or any RRC report.

Network-driven active UTCI update: When sending an Event 2 report, the WTRU may receive a MAC CE UTCI activation command containing a new first set of UTCI codepoints, which may contain UTCI codepoints for the previously reported TCI from the second set. Additionally, the WTRU may receive a new second set of UTCI for further measurement reporting for Event 2.

WTRU-driven active UTCI update: Alternatively, the WTRU may report the UTCI of the second set that satisfies Event 2 to the network along with the UTCI from the first set to be replaced as part of Event 2. Upon receiving an ACK (as an acknowledgment) of the Event 2 report from the network, the WTRU may autonomously activate/update the new first set.

After updating the first set of active UTCI states, the WTRU may autonomously place the deactivated UTCI states in the second set.

Alternatively, the WTRU may completely discard the declared unreliable state after updating the UTCI active set.

In one embodiment, the WTRU may receive configuration information of a set of available TCI states from the network. The configuration information of a set of available TCI states may be received in an RRC message.

A WTRU may receive one or more configuration parameters for WTRU-initiated beam reporting (WTRUUIBR). The configuration parameters may include a set of reference signals (RS) for WTRUUIBR, thresholds associated with events, and/or information about the UL channel (e.g., PUSCH) to be used by the WTRU to deliver WTRU-initiated beam reporting when a triggering event occurs. The one or more configuration parameters for WTRUUIBR may be received in an RRC message.

The WTRU may receive an indication from the network to activate one or more TCI states from a set of available TCI states. These TCI states are referred to as active TCI states. The indication may be received in an RRC message, a MAC control element (MAC-CE), or downlink control information (DCI).

The WTRU may determine a set of candidate TCI states. Candidate TCI states are TCI states that the WTRU will measure. The set of candidate TCI states may be configured by the network or may be determined independently by the WTRU. Candidate TCI states may be TCI states that are available but not activated.

The WTRU may measure the RSRP of a first RS using (e.g., associated with) a candidate TCI state. The WTRU may compare the measurements performed using the candidate TCI state with measurements performed using the active TCI state. Upon identifying a candidate TCI state that results in a measured RSRP value for the first RS being higher than the RSRP of a second RS measured using one or more (or all) active TCI states, the WTRU may send a measurement report to the network. The measurement report may indicate the identified candidate TCI state and the RSRP value measured using that TCI state.

As mentioned above, for example, event 3 may be used to find a new beam based on beam prediction. In event 3, the WTRU may receive a network request to provide capability information. The request to the WTRU may be based on RRC signaling after a random access procedure. The WTRU may prepare a WTRU capability information message, including support for event-based beam reporting using beam prediction.

The WTRU capability information associated with beam reporting based on a beam prediction event may include information or parameters related to the beam prediction mechanism. In an example where the WTRU utilizes artificial intelligence (AI)/machine learning (ML) for beam prediction, the information may include one or more AI/ML model IDs, processing/training capabilities, datasets, memory, etc.

The WTRU may send WTRU capability information messages via RRC signaling (eg, via PUSCH).

The WTRU may receive a configuration (e.g., a unified TCI status (UTCI)) for multiple beams, where each beam represents a set of transmission configurations, such as a specific beam index, applicable to multiple channels or signals. The WTRU configuration may be predetermined or defined by higher-layer signaling (RRC, MAC-CE, etc.).

The WTRU configuration may also include one or more events related to (UTCI) beam measurement and reporting based on one or more types of candidate (UTCI) beam definitions, one or more thresholds (e.g., triggers for activation), WTRU reporting settings (e.g., granularity, timers, and filters for sending reports), etc. The WTRU configuration may also include a priority between two or more event-based beam reporting event types.

A possible WTRU event type (e.g., Event 3) is a beam reporting based on a beam prediction event. The configuration of this type of event may further include one or more parameters related to beam prediction measurements and reporting, such as prediction metric, domain (spatial, temporal, or both), accuracy/confidence level, backoff mechanism, resources, opportunities, etc.

In one example, the WTRU may be configured to perform beam prediction for a given number of beams, e.g. beams (from possible beams). In one example, the WTRU may be configured to perform beam prediction for one or more time units from a reference time point, e.g., to predict the beams at time slots 、 , ..., etc., where Can be a positive integer. With one or more future transmissions ( ) These time units associated with the network may be fixed, semi-statistically, or dynamically configurable by the network.

The beam prediction mechanism can be AI/ML-based, grid-based, non-grid-based, heuristic, or other methods. In the case of AI/ML, the configuration can include information about the AI/ML model, the training process (e.g., online or offline), input/output, hyperparameter tuning, triggers for reverting to the legacy process, etc.

In one example, a WTRU receives a configuration for offline training of an AI/ML model, including a training reference signal and a training time window. The WTRU may evaluate the accuracy of the AI/ML model used for beam prediction at any given point during the training phase and send an indication to the gNB if a certain beam prediction accuracy is achieved. In one example, if the beam prediction accuracy falls below a certain threshold, the WTRU may request an additional training phase.

In one example, if certain accuracy thresholds (such as beam prediction accuracy) drop below a certain threshold, the WTRU with offline trained AI/ML and/or the WTRU with online AI/ML model training may send a retraining request to the network during the inference phase.

The WTRU may be configured to perform periodic or dynamically indicated aperiodic or other aperiodic beam measurements for event-based beam reporting.

The WTRU may receive the first UTCI, for example, via MAC-CE, for preset beam management purposes, including measurement and reporting. The WTRU currently maintaining the first UTCI may receive the second UTCI, for example, via DCI, for beam measurement purposes.

In one example, the WTRU may perform estimation, prediction, and decision making of (UTCI) beams for one or more future transmissions based on an event-based beam reporting configuration.

The WTRU may determine beam quality based on the difference between the signal quality metrics (such as RSRP, SINR, rank, or EVM) and/or performance quality metrics (such as throughput or BLER) of the current UTCI beam and the predicted UTCI beam. These quality metrics may be derived and compared based on instantaneous values or statistical values (e.g., using historical data). The WTRU may perform beam prediction in the spatial domain, the time domain, or both.

The WTRU may identify the predicted (UTCI) beam as a possible replacement for the current UTCI, for example, by comparing the current beam(s) with the predicted beam(s) in the spatial domain, the time domain, or both. The WTRU report may include an explicit or implicit indication of the better predicted (UTCI) beam. The report may also include additional beam prediction information, such as the beam index, beam prediction accuracy/confidence level, etc. In one example, the WTRU may report the relative beam index or spatial relationship based on the maintained UTCI (anchor beam).

In one example, the WTRU may receive confirmation from the network (e.g., by receiving DCI, such as a UL grant) regarding whether to switch to the best WTRU predicted (UTCI) beam. In one example, the gNB may simply send a confirmation denying the switch to the WTRU predicted UTCI. In another example, the WTRU may be configured for a WTRU-triggered UTCI update, e.g., switching to the WTRU predicted UTCI beam without network confirmation.

As beam prediction events are triggered and activated, the network can send a second configuration to modify the beam reporting based on the event. In one example, under beam prediction, the network can reduce the number of RS transmissions depending on multi-user conditions.

Event-based reporting based on WTRU beam prediction in the spatial domain and/or time domain may result in improved beam selection accuracy, reduced latency from beam scanning, reduced signaling, or a combination thereof.

Examples of other events:

An event (eg, event n) among the one or more events may include at least one of the following (eg, in addition to event 1, event 2, and event 3 above).

An event (e.g., event 4) may be associated with beam failure recovery (BFR) and/or radio link failure (RRF) recovery. This event and its associated parameter(s) may be configurable in the WTRU. The event may occur when the WTRU predicts that the duration before a beam failure may occur is less than a threshold time value. The WTRU may then determine (e.g., declare) to report the corresponding report content, such as a notification of "near expiration" before failure, the number of time units remaining before failure, the new beam ID(s) in the case of recovery, the corresponding quality metric(s) associated with the new beam(s) and/or the current beam(s), and/or a flag indicating the event (e.g., event 4).

In one example, when the gNB receives the report (from the WTRU), the gNB may not select beams other than the reported beam(s), where the WTRU may expect/assume that the WTRU may use at least one of the reported beam(s) after the time offset of the reporting instance. For example, particularly for MTRP scenarios, the reported beam may be associated with a PDCCH monitoring beam (for one of multiple TRPs), e.g., associated with a CORESETpoolID, and these beams may also be reported together.

In one example, the WTRU may apply the reported beam immediately after the time offset (from the reported instance), e.g., without receiving an explicit confirmation from the gNB unless exception signaling is given from the gNB to cover the reported beam.

Another event (e.g., Event 5) may be associated with a situation where the WTRU may prioritize using different WTRU panels (e.g., for DL Rx and/or for UL Tx). This event and associated parameter(s) may be configured for the WTRU. This event may occur when the WTRU determines to change or switch one or more currently used WTRU panels to a different set of WTRU panels for, for example, DL Rx and/or UL Tx communications with a gNB. For example, the WTRU may currently use or activate WTRU Panel 1 and WTRU Panel 3 for communications with the gNB. The WTRU may determine to change from one set of activated WTRU panels (WTRU Panel 1 and WTRU Panel 3) to a second set of WTRU panels. The second set of WTRU panels may include new WTRU panels (e.g., WTRU Panel 2 and WTRU Panel 4) or portions of new WTRU panels (e.g., WTRU Panel 1 and WTRU Panel 4), where WTRU Panel 1 will continue to be used for communication and WTRU Panel 4 may be newly activated by instead deactivating WTRU Panel 3 (e.g., after configuring time offset parameters for activation). The WTRU may determine the report content corresponding to the report, for example, a determination to notify a change in a set of activated WTRU panels, timing-related information about when the new activation is completed, one or more WTRU panel IDs used for communication with the gNB as a new activation, corresponding quality metric(s) associated with the newly activated WTRU panel(s) and/or the current beam(s) (for example, representative beam ID(s), and/or a flag indicating this event (for example, event 5).

In response to the report, the WTRU may receive an acknowledgment signal or an indication message for the WTRU from the gNB, including information on which WTRU panel(s) to activate.

The WTRU may apply the reported set of WTRU panels to start after a time offset (from the reported instance), for example, without receiving an explicit confirmation from the gNB unless further update signaling from the gNB is given to cover the reported set of WTRU panels for communication with the gNB.

The above examples are non-limiting, and the definition of events with associated parameters (e.g., thresholds, etc.) can be configured by the gNB, for example, each with an event number or a flag to be used to identify one of one or more events between the gNB and the WTRU. The WTRU behavior described above for one example scenario of an event can also be applied to another example scenario of an event. For example, the "time to trigger" for the second set of measurement reports discussed under Event 2 can also be applied to Event 1. For example, based on the independent parameter "trigger time," as long as the measurement results of Event 1 meet the associated conditions (multiple) and the independent trigger time threshold, the corresponding report based on Event 1 will be sent to the network.

In one example, a method for aperiodic WTRU-driven reporting that is specific to an UL channel or signal and based on a maximum duration is provided.

In one example, if the next available UL transmission opportunity does not fall within the maximum duration, the WTRU may perform aperiodic (e.g., contention-based) transmission of event-based beam reports, for example, using contention-based PUCCH transmission or PRACH+PUSCH transmission.

In one example, a WTRU may receive configuration information for event-based beam reporting, indicating at least what to measure (e.g., a set of RSs and a set of TCI states), how to determine one or more events (e.g., based on (L1-)RSRP, (L1-)RSRQ, (L1-)SINR, CQI, etc.), what to report, and the method used to report the one or more events. The method may be event-specific.

The WTRU may receive configuration information indicating the maximum duration for which event-based beam reporting may be performed, for example, because such information needs to be reported quickly (e.g., before beam failure detection/recovery is initiated). The maximum duration may be an offset (e.g., number of slots, frames, etc.) from the time the trigger condition is met. The report may include at least beam information and/or beam quality information.

The WTRU may determine that an event has occurred based on measuring a set of beam quality metrics for a set of RSs and determining the event by comparing the set of beam quality metrics to one or more thresholds, for example, based on layer 1/2 event measurements.

The WTRU may determine one or more report contents based on an event, where the report contents may include the determined beam(s) (e.g., one or more RSs in a set of RSs), one or more corresponding beam quality metrics, and/or a flag representing the event.

When a triggering event is met, the WTRU may determine whether the next available UL transmission opportunity (e.g., PUSCH, PUCCH, etc.) falls within the (configured) maximum duration of the event-based beam reporting.

Based on this determination, the WTRU may selectively perform (1) WTRU-driven reporting based on scheduled UL channel transmissions (e.g., non-contention), or (2) WTRU-driven reporting based on contention-based transmissions.

In the case of WTRU-driven reporting based on a scheduled UL channel (e.g., non-contention), if the next available UL transmission opportunity is determined to fall within the configured maximum duration (from the time of the triggering event), the WTRU may perform event-based beam reporting using the next available (e.g., scheduled) UL transmission opportunity (e.g., non-contention).

For example, the WTRU may perform signaling via the (most recently available or scheduled) PUCCH resource (or PUSCH) for CSI reporting, such as by adding a new portion of the CSI or beam reporting content (e.g., Part 3 CSI). The WTRU may determine the CSI or beam reporting content by combining (e.g., merging, concatenating) the new portion with the NW-controlled reporting content (e.g., Part 1 and/or Part 2 CSI already scheduled for reporting via PUCCH resources).

In another example, the WTRU may or may be configured to swap CSI part(s) and reuse the bit width (e.g., allocated for Part 1 and/or Part 2 CSI) for WTRU-driven reporting, e.g., where zero padding bit(s) are inserted to match the bit width, which may include an N-bit flag (e.g., N=1) to indicate new report content based on WTRU-driven reporting.

In the event that the WTRU determines that the PUCCH resources used for CSI reporting include a HARQ-ACK transmission (e.g., when the HARQ-ACK transmission is piggybacked on the CSI report), the WTRU may or may be configured to discard the CSI portion and reuse the discarded portion for WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not discarded and is concatenated with the report content for WTRU-driven reporting.

The WTRU may be configured (or pre-defined) to prioritize PUSCH over PUCCH if more than one opportunity is found within the (configured) maximum duration. For example, in one case, the earlier resource may be used. In another example, such as when PUSCH and PUCCH collide in the same time slot or symbol(s), PUSCH may be used.

In the case of contention-based WTRU-driven reporting, if the next available (e.g., scheduled) UL transmission opportunity does not fall within the (configured) maximum duration, the WTRU may perform contention-based transmission (e.g., transmission using shared resources) for event-based beam reporting. For example, the WTRU may be (configured to) perform PUCCH transmissions on shared PUCCH resources, where one or more shared PUCCH resources are configured to the WTRU (e.g., via RRC) for use for such event-based beam reporting. A WTRU may (or may be configured to) transmit the report content and one or more identifiers (e.g., WTRU-ID, RNTI, jammer ID/parameters, etc.) via PUCCH transmission to identify the WTRU, for example, because one or more PUCCH resources may also be configured for other WTRU(s), such that conflicts may occur among WTRUs. This may provide benefits, particularly when it is desirable to maintain a current timing advance (TA), for example, as determined by the WTRU or signaled (e.g., configured) by the gNB.

In another example, a WTRU may (or may be configured to) perform a RACH transmission (and associated PUSCH transmission), where the RACH transmission may be contention-based. The WTRU may receive an indication or configuration for a two-step transmission procedure (e.g., a PRACH transmission and one or more associated PUSCH transmissions), where the PUSCH payload may carry the report content. This may provide benefits, particularly when a new timing advance (TA) is desired, such as may be determined by the WTRU or signaled (e.g., configured) by the gNB.

The WTRU may determine an event related to beam quality measurement (e.g., a critical level determination) based on one or more of the solutions described in the previous paragraphs. Upon detecting the event, the WTRU may generate and report information about the determined event. The WTRU may need to report this information quickly after detecting the event because the WTRU may require network action before entering a beam (and/or radio link) failure. However, when the event-based beam reporting is triggered, the WTRU may not have available UL resources.

In one example, the WTRU may perform aperiodic transmission of event-based beam reporting, such as contention-based PUCCH transmission or PRACH+PUSCH transmission (e.g., 2-step UL transmission, 2-step RACH msgA). The WTRU may decide to perform such a transmission if no UL resources (e.g., CG or DG PUSCH, PUCCH) are scheduled/available for transmission within a number of time slots from the time of the triggering event.

A WTRU may receive a configuration for event-based beam reporting, which may be associated with a resource setting, such as one or more of a reference signal (e.g., CSI-RS, SRS, SSB) or a TCI state. The WTRU may determine to perform measurements based on the configured resource setting, where the measurements may consist of one or more of L1-RSRP, L1-SINR, CQI, CRI, SSBRI. The WTRU may be configured with measurement thresholds, where the WTRU may determine which event to trigger based on one or more measurements exceeding the threshold. Event-based beam reporting may include a configuration that indicates to the WTRU what to include in the beam report. The WTRU may include a flag to indicate that one of the measurements exceeded the threshold. The WTRU may additionally include a value (eg, explicitly or quantitatively) representing the difference between the measurement and the threshold. The WTRU may include multiple flags, where each flag identifies a measurement that exceeds a threshold (eg, its corresponding threshold of one or more thresholds).

As part of the event-based beam reporting configuration, the WTRU may receive a maximum duration over which event-based beam reporting may be performed, for example, because this information needs to be reported quickly (e.g., before beam failure detection/recovery is initiated). The maximum duration may be defined from the time when one of the above triggering conditions is met. The maximum duration may be configured as one of the following: an offset (e.g., number of time slots, frames, etc.) from the time the triggering condition is met; or a (maximum) timer configured to start when the triggering condition is met. The WTRU may transmit WTRU-driven event-based reporting (e.g., beam information and/or beam quality information) before the time period expires. When the time period expires, the WTRU may reset the timer and decide to find another best beam(s), regardless of the currently identified reporting beam (e.g., by resetting the current WTRU-driven beam reporting procedure). In another example, when the time period expires, the WTRU may fall back to a default beam (e.g., associated with the lowest CORESET, having a CORESET index (e.g., 0), or coresetPoolIndex).

The WTRU may determine that an event has occurred based on measuring a set of beam quality metrics on a set of RSs configured with event-based beam reporting and a function that determines an event by comparing the set of beam quality metrics to one or more thresholds, for example, based on layer 1/2 event measurements.

The WTRU may determine one or more report contents based on the event, where the report contents may include one or more RSs in a set of RSs and corresponding one or more beam quality metrics.

Multiple events can be configured with different threshold levels and an associated maximum duration for each threshold. For example, if the first threshold is exceeded, a longer maximum duration can be configured, and if the second threshold is exceeded, a shorter maximum duration can be configured.

When a triggering event is met, the WTRU may determine whether the next available UL transmission opportunity (e.g., PUSCH, PUCCH, etc.) falls within the maximum duration (e.g., based on a maximum timer) of event-based beam reporting. Based on this determination, the WTRU may selectively perform (1) WTRU-driven reporting based on scheduled UL channels or (2) WTRU-driven reporting based on aperiodic transmissions.

WTRU-driven reporting of scheduled (e.g., contention-based) UL channels may be used. For example, if the WTRU determines that the next available UL transmission opportunity (PUCCH, PUSCH, CG, or DG) is within the maximum duration, the WTRU may use the next available UL transmission opportunity to perform event-based beam reporting.

In one example, the WTRU may multiplex event-based beam reporting in the PUSCH. A MAC-CE for event-based beam reporting may be defined. The WTRU may receive an UL grant (CG or DG) scheduling a PUSCH transmission at time T2.

If the triggering condition for event-based beam reporting occurs at time T1 and before receiving a grant (T1 < T2), the WTRU may multiplex the MAC-CE in the PUSCH. If the criteria for the event are not met (satisfied), the WTRU may transmit PUSCH and not transmit the event-based beam reporting based on the PUSCH buffer status. The WTRU may multiplex the PUSCH on the next available grant after T2 within the previously defined maximum duration.

The WTRU may use an offset T_offset (where T_offset is configured or indicated) so that the WTRU may determine timing based on T1 + T_offset < T2.

The WTRU may include one or more report contents in a MAC CE multiplexed in the PUSCH (e.g., similar to a PHR). The WTRU may generate a MAC-CE that includes the type of event triggered and the associated measurements. The WTRU may include an SRS Resource Set Index or SRI to identify the panel or antenna group that triggered the measurement.

Event-based beam reporting may be performed as a form of cross-CC beam reporting, e.g., for CA, dual connectivity, etc. A WTRU may report an event-based beam report via CC1 (e.g., FR1) to report a new or updated beam to be used in CC2 (e.g., FR2). The WTRU may include the index of the carrier in the event-based beam report.

In another example, the WTRU may include event-based beam reporting via the (most recently available) PUCCH resource used for CSI reporting, for example, by adding a new part of the CSI or beam reporting content (e.g., Part 3 CSI).

Part 1 of the CSI may include a new bit that the WTRU may use to indicate whether to send part 3. If the WTRU indicates a 1 in the new bit, then the WTRU may include event-based beam reporting content in part 3. Otherwise, the WTRU may only send part 1 and part 2.

The WTRU may determine the CSI or beam reporting content by combining (e.g., merging, concatenating) the new part into the NW-controlled reporting content (e.g., Part 1 and/or Part 2 CSI already scheduled for reporting via PUCCH resources). The WTRU may be configured with a priority index associated with Part 3 content, and the WTRU may determine which Part 3 content to include by comparing the priority with the Part 2 content. For example, event-based beam reporting content may have a higher priority than PMI content.

In another example, the WTRU may be configured to swap CSI part(s) and reuse the bit width (e.g., allocated for part 1 and/or part 2 CSI) for WTRU-driven reporting, e.g., by inserting zero padding bits to match the bit width, which may include an N-bit flag (e.g., N=1) to indicate new report content based on WTRU-driven reporting. For example, if N=1, the WTRU reports part 3 of the CSI instead of part 2. If N=0, the WTRU reports part 2 of the CSI.

In the event that the WTRU determines that the PUCCH resources used for CSI reporting include a HARQ-ACK transmission (e.g., when the HARQ-ACK transmission is piggybacked on the CSI report), the WTRU may (be configured to) discard the CSI portion and reuse the discarded portion for WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not discarded and is concatenated with the report content for WTRU-driven reporting. Example priority rules may include the following examples:

(i) If the WTRU decides to report HARQ-ACK in PUCCH, the WTRU MUST NOT discard the HARQ-ACK to be reused for event-based beam reporting;

(ii) If the WTRU decides to report HARQ-ACK+CSI PUCCH, the WTRU discards the CSI portion and reuses the resources for event-based beam reporting;

(iii) if the WTRU decides to report CSI PUCCH, the WTRU replaces the CSI portion and reuses the resources for event-based beam reporting, where the WTRU indicates a (e.g., 1 bit) flag to signal that the content is for event-based beam reporting; and/or

(iv) If CSI reporting is configured for legacy beam reporting (e.g., CRI/SSBRI+RSRP/SINR for beam management or group-based beam management), event-based beam reporting may have a higher priority. A new bit may be configured in the beam report, and the WTRU may toggle this bit to 1 to identify that the content is for event-based beam reporting.

WTRU-driven reporting based on aperiodic (e.g., contention-based) transmissions may be used. If the next available UL transmission opportunity does not fall within the maximum duration, the WTRU may perform an aperiodic transmission method of event-based beam reporting on the UL resources.

In one example, a WTRU may be or may be configured to perform (contention-based) PUCCH transmissions, where one or more PUCCH resources are pre-configured to the WTRU for use with such event-based beam reporting. The PUCCH resources may be configured to be periodic, such that the WTRU may use these PUCCH resources whenever event-based beam reporting is triggered. The resources may be WTRU-specifically configured. Alternatively, to avoid excessive overhead, PUCCH resources can be shared by multiple users (e.g., a procedure similar to non-orthogonal-multiple-access (NOMA) where each user has a signature/identity and the receiver performs MMSE-SIC type decoding), and each WTRU can scramble its PUCCH transmissions using a WTRU-specific identifier (e.g., WTRU-ID, RNTI, scramble ID/parameter, etc.) to identify the WTRU. This can be beneficial, particularly when it is desirable to maintain the current timing advance (TA), which may be determined by the WTRU or signaled by the gNB (e.g., configuration).

In another example, the WTRU may be (configured to) perform RACH transmissions (and associated PUSCH transmissions), where the RACH transmissions may be contention-based (e.g., 2-step RACH with msgA+msgB, where event-based beam reporting is sent in msgB). For example, the WTRU may receive an indication or configuration for a new 2-step transmission procedure (e.g., a 2-step RACH-like procedure consisting of an msgA (PRACH) transmission linked to an msgB (PUSCH) transmission), which may provide benefits in terms of latency reduction.

The WTRU may receive a configuration of RACH opportunities that determine the location of preambles in terms of time and frequency, and a configuration of PUSCH resource opportunities in which a set of RBs is associated with each preamble. The RBs provide resources for carrying the PUSCH payload. The WTRU may reuse PUSCH opportunities configured for the legacy two-step RACH procedure, or alternatively be configured with specific PUSCH opportunities reserved for event-based beam reporting. Preamble opportunities may also be reused from the legacy or separated into a separate set of preambles reserved for event-based beam reporting. This may be beneficial, particularly when a new timing advance (TA) is desired, for example, which may be determined by the WTRU or signaled by the gNB (e.g., configured).

In another example, a WTRU may be configured with an SRS transmission timing, where the WTRU may autonomously trigger SRS with implicit flags (e.g., via a predefined signature/parameter based on a sequence). The SRS transmission timing may be configured with an associated PUSCH resource timing, where procedures derived from SRS and PUSCH may be defined or configured (e.g., similar to SR). For example, the WTRU may transmit an SRS and the network may determine that the WTRU is requesting resources for event-based beam reporting. The network may schedule PUSCH resources within a configured maximum duration calculated based on the SRS transmission timing.

Opportunistic WTRU-driven beam reporting based on an acknowledgment mechanism may be used. In one example, the WTRU may receive configuration(s) of available timings and/or resources for WTRU-driven (e.g., DL) beam reporting and, based on a function of the event declared for reporting, determine to transmit a report at one or more timings (e.g., before a BFR). After reporting (e.g., a single sample or multiple samples), the WTRU may monitor for an acknowledgment (CF) signal (e.g., a CF field) from the gNB within a time window for stopping retransmissions. If not, the WTRU may retransmit the report. The acknowledgment signal may also include and/or indicate updated configuration(s) for the next available timing and/or resources.

The WTRU may receive configuration information for opportunistic WTRU-driven beam reporting.

Configuration information may include time-domain parameter(s) regarding when the WTRU may transmit if an event occurs, such as a periodic or irregular pattern of slots/symbols within a time window (e.g., within 10 ms), which may be interpreted as "available opportunities" for opportunistic WTRU-driven reporting. These available opportunities may conflict among WTRUs (or may not conflict based on gNB configuration, e.g., different PUSCH scrambling IDs among different WTRUs, scrambling by Cell ID and/or WTRU-ID, etc.).

Configuration information may include the number (M) of multi-sample transmissions reported by the WTRU-driven beam: If M = 1, a single Tx is reported. If M > 1, the multi-sample Tx reported is repeated in columns across available time instances (e.g., between slots, within slots as symbol-based alignment) based on time-domain parameter(s). This allows for increased chances of successful Rx at the gNB. Associated parameters across the multi-sample Tx (e.g., configuration(s) of spatial domain cycling, sequence domain jammer/pattern, resource domain hopping, etc.) can provide increased diversity in these transmissions.

The configuration information may include frequency domain parameter(s) that the WTRU may transmit on the frequency resources (RB(s)) at a given time, for example, semi-static fixed frequency resources, or based on a frequency hopping pattern, or an irregular pattern in the frequency domain generated as a function of other parameter(s) such as WTRU-ID, C-RNTI, slot/symbol index, etc.

The configuration information may include a parameter related to the ACK expiration time offset (e.g., set to 7 ms, 7 slots, or the number of symbols). For example, the WTRU may monitor for an ACK signal during this time window after transmitting a WTRU-driven beam report. If no ACK signal is received, the WTRU may retransmit the WTRU-driven beam report.

The configuration information may include parameters related to the confirmation (CF) signal format, such as a dedicated RNTI (CF-RNTI) for DCI including a CF field with a bit width (e.g., 2 bits), whether/which other DCI formats have a CF field, group common DCI (e.g., DCI format 2_0 or other), and/or whether the MAC-CE of the PDSCH has a CF field (e.g., the same or different bit width).

The configuration information may include parameters related to measurement-related parameter(s): what to measure (e.g., a set of RSs, a set of TCI states, etc.), how to determine one or more events, e.g., based on L1-RSRP, L1-SINR, CQI, and/or CRI, etc.

The WTRU may determine (e.g., at time T1) that an event occurred based on measuring a set of beam quality metrics for a set of RSs and a function that determines an event by comparing the set of beam quality metrics to one or more thresholds, for example, based on layer 1/2 event measurements.

The WTRU may determine one or more report contents based on the event, where the report contents may include one or more RSs in a set of RSs and corresponding one or more beam quality metrics.

The WTRU may determine the earliest possible time opportunity(s) after T1 based on M for transmitting a WTRU-driven beam report via an UL channel (e.g., PUSCH, PUCCH, etc.), where the UL channel may include a value of the CF field used as a token for acknowledgment (e.g., if an explicit acknowledgment method is configured). For example, the WTRU may be configured to determine the value based on a function (e.g., after transmitting a WTRU-driven beam report and applying modulo 4, the CF field value is 0, 1, 2, or 3). If M > 1, the WTRU may transmit M times in a row using PUSCH.

The WTRU may also use implicit ACKs. For example, the WTRU may determine that a transmission over an UL channel was successfully received at the gNB if the WTRU receives at least one of the following DL signals or channels within a time window determined based on the UL channel transmission timing and the (configured) ACK expiration time offset.

In one example, the WTRU may determine whether the WTRU receives a DL signal or channel (e.g., DCI and/or PDSCH) indicating a beam change (UTCI) within a time window.

In another example, if the transmission via the UL channel contains reporting content determined based on Event 1, the WTRU may determine that a (UTCI) beam change is indicated in the activated UTCI.

In another example, the WTRU may determine whether the WTRU received a DCI and/or MAC-CE indicating a new TCI activation command within the time window (which updates a new set of activated UTCIs mapped to the TCI field of the DL-DCI). When the WTRU-driven reporting is based on event 2 (reporting inactive UTCI(s)), the WTRU may determine whether the received DCI and/or MAC-CE is an acknowledgment from the gNB.

In another example, the WTRU may determine an acknowledgment by whether the WTRU receives an UL grant indicating a new UL (e.g., PUSCH) transmission within a time window (e.g., without a retransmission, based on a new-data-indicator (NDI) field indicating a switch). For example, when the WTRU-driven report is based on event 3 (beam prediction-based reporting), the WTRU may determine that this is an acknowledgment from the gNB.

If the WTRU does not receive the implicit acknowledgment signal within the time window, the WTRU may determine that no acknowledgment was given. Based on this determination, the WTRU may search for a new (UTCI) beam based on resetting the WTRU-driven reporting procedure and based on determining the earliest possible time opportunity(s) after the determination to transmit a second WTRU-driven report via the UL channel.

The WTRU may also or alternatively receive an explicit acknowledgment. For example, the WTRU may monitor for the receipt of the CF field during a time window based on the acknowledgment expiration time offset as an acknowledgment of the WTRU-driven beam report.

Upon receiving a CF field with the same value as the one transmitted by the WTRU via PUSCH, the WTRU may decide not to retransmit the report (and increment the CF field value by 1 and apply a modulo of 4). For example, just after the time window (and the addition of the offset parameter) has elapsed, the WTRU may update the reported beam unless otherwise received from the gNB. The offset parameter may be associated with (e.g., dependent on) the time of receipt of the acknowledgment signal (e.g., the CF field).

Figure 3 illustrates an example of a successful reception of an acknowledgment signal. In this example, an event is detected by the WTRU 301, triggering a WTRU-driven beam report 302. The acknowledgment signal 303 is then received within the WTRU monitoring window 304.

In the event that no CF field is received and/or a CF field is received with a value different from the value transmitted by the WTRU via PUSCH until the ACK expiration time offset expires (T2), the WTRU may retransmit the report based on M for the second earliest possible opportunity(s) after T2.

FIG4 shows an example in which no acknowledgment signal is received within the WTRU monitoring time window. In this example, a retransmission 401 of the WTRU-driven beam report is triggered.

The WTRU may receive another feedback from the gNB. In one example, the WTRU may receive an acknowledgment signal (e.g., CF field) that also updates at least one of the time domain parameter(s), frequency domain parameter(s), acknowledgment expiration time offset, CF signal format, and measurement-related parameter(s).

In an example, the updated configuration (content) may be received via MAC-CE of the PDSCH.

In one example, the updated configuration (content) may be received via DCI encoded with the CF-RNTI. (For example, the DCI may be specific to a TRP, such as via CORESETpoolID.)

In an example, the updated configuration (content) may be received via a PDSCH scheduled by DCI coded with the CF-RNTI.

In response to receiving the updated configuration, the WTRU may apply the updated configuration to the next WTRU-driven beam reporting procedure.

In one example, a WTRU may be configured for beam reporting and switching.

For example, a WTRU may be configured with one or more sets of candidate beams, which may be indicated as an indexed list related to reference signals, TCI status, etc. In this case, a first set of candidate beams may be used for measurement and reporting, and a second set of candidate beams may be used for measurement, reporting, and beam switching. Alternatively, or in addition to these, the WTRU may be configured with other measurement configurations, including at least measurement time/frequency opportunities, number of measurements, etc.

The WTRU may be configured with one or more sets of thresholds and trigger conditions for measuring, reporting, and beam switching, including at least one of: signal quality metrics, such as RSRP, SINR, rank, Error Vector Magnitude (EVM), etc.; performance quality metrics associated with transmission, such as BLER, etc.; and consistency metrics, such as statistical (reliability) metrics, temporal consistency of failures, etc.

The WTRU may be configured with one or more sets of uplink resources for reporting at least one of measurements or beam status.

The WTRU may be configured with values for time windows, counters, etc.

The WTRU may also be configured with an indication as to whether the WTRU is allowed to switch beams without confirmation from the gNB.

Figure 5 shows an example of a beam configuration for WTRU-based beam switching.

In this example, the WTRU may be configured with a first set of downlink beams 501 for measurement and reporting, e.g., downlink reference signals. When reporting, the WTRU may be instructed or configured with a second set of beams 502, which may be a subset of the first configured beams. The second set of beams may represent a set of beams that the WTRU may switch to without any or significant interaction with the gNB.

A WTRU may be configured or instructed to have a beam as either an originally configured or active beam. Additionally, a WTRU may be configured to have one or more additional beams for measurement. Using the configured resources and opportunities, the WTRU may be configured to perform periodic measurements or dynamically instructed to perform aperiodic or other non-periodic measurements. In one example, when the WTRU determines that the configured measurements on the originally configured beam do not meet the configured limit, the WTRU may identify a new beam as a possible replacement for the originally configured beam.

Figure 6 shows an example where the WTRU can autonomously switch to a newly identified beam.

Once the WTRU identifies 601 a new beam as a possible replacement for the originally configured beam, the WTRU may report at least the new beam and its quality, and the WTRU may transition 602 to the newly identified beam by updating the associated reference signal and TCI state.

In one example, using the configured uplink resources, the WTRU may also report its transition to the new beam(s) by explicit or implicit indication 603. The report may also include measurements related to the original and newly identified beam(s). In one example, after reporting the transition, the WTRU may monitor the PDCCH during a configured time window 604 to receive an acknowledgment 605 from the gNB. If the WTRU receives an acknowledgment 605 within the configured window 604, it may decide to stay on the newly identified beam; otherwise, it may perform a transition back to the original beam. Alternatively, if the WTRU does not receive a reject or negative command to revert to the originally configured beam within the configuration window measured relative to the time reference (e.g., its UL report), it can (determine) stay on the newly identified beam.

Figure 7 shows an example where a WTRU may switch to a newly identified beam upon receiving an indication from the network.

In this example, the WTRU may identify 701 a new beam as a possible replacement for the originally configured beam. The WTRU may report at least the new beam and its quality. The WTRU may transition to the newly identified beam(s) by updating the associated reference signals and TCI state only after receiving a specific indication from the network (e.g., gNB). The indication may be a signal such as a DCI or UL grant 702. Receipt of the indication 702 may be interpreted as a verification of the quality of the newly identified beam(s).

The WTRU may transition to the newly identified beam(s) after a configured window of measurements relative to a time reference (e.g., UL grant) 703. The WTRU may include a report 704 with the UL grant indicating its transition to the newly identified beam. In one example, the report may also include measurements related to the original and newly identified beams. The WTRU receives confirmation to stay on the newly identified beam 705.

Figure 8 shows an example in which a WTRU may report to the network its intention to switch to a newly identified beam.

The WTRU may identify a new beam 801 as a possible replacement for the originally configured beam. The WTRU may first report the new beam 802 and indicate its intention to transition to the new beam. The report may include measurements related to the original beam and the newly identified beam. Once the WTRU receives an acknowledgment 803, the WTRU may transition to the newly identified beam within a configured time window 804. The time window may be defined based on a given time reference (e.g., receipt of an acknowledgment message).

As described in the previous paragraph, a WTRU may receive a configuration for periodic beam reporting. To reduce resource usage, reporting opportunities may be configured to be sparse (i.e., configured with a high periodicity). If these reporting opportunities are shared between different WTRUs, this may result in conflicts, which may further delay the time required to successfully report beam measurements.

Because this information needs to be reported quickly (e.g., before beam failure detection/recovery begins), the WTRU may be configured with a maximum time interval within which it must transmit. In some cases, the maximum time interval may be an offset (e.g., number of slots, frames, etc.) from the time the trigger condition is met. The maximum time interval may be represented by a timer value, where the WTRU must transmit beam information before the timer expires.

When a triggering event is met, the WTRU may determine whether the next periodic transmission opportunity (or the next X periodic opportunities to support retransmissions, for example, in case of a conflict) falls within the maximum time interval for transmission.

If the next transmission duration (or the next X durations) exceeds the maximum interval requirement, the WTRU may perform aperiodic transmission methods such as one or more of the following: the WTRU may perform RACH; the WTRU may trigger a scheduling-request (SR); the WTRU may include the report in one or more scheduled transmissions allocated for other types of data (e.g., not related to the transmission of beam reports). The WTRU may trigger a Layer 3 (L3) measurement report and include the beam report.

In one example, a WTRU may be configured with multiple configurations of available resources, such as a dense configuration and a sparse configuration. The WTRU may decide which configuration to use. This decision may depend on various conditions and/or criteria, such as having multiple thresholds.

For example, a WTRU in poor channel conditions may need to report beam measurements quickly and/or frequently, in which case a dense configuration would be appropriate.

For example, a WTRU in good conditions will likely rarely trigger beam reporting, in which case the WTRU may be configured with a sparse beam reporting configuration (e.g., to avoid interrupting other transmissions/receptions that the WTRU may be performing).

Configuring multiple (e.g., all) WTRUs in a dense configuration would be less suitable because it would require sizing a large number of resources to avoid frequent collisions, such as in cells. However, distributing WTRUs between sparse and dense configurations (e.g., based on reporting likelihood/need) can optimize transmission opportunities and reduce the risk of collisions.

In another example, the WTRU may be configured with multiple periodic beam reporting configurations having different characteristics, such as different periodicity (i.e., dense or sparse), more or less resources during transmission opportunities.

In another example, the WTRU may switch between configurations based on at least one of: a network indication or an event. A network indication may include, for example, the receipt of DCI/RRC communication or the (de)activation of a configuration. An event may include the WTRU having multiple reporting thresholds. One may trigger a report, while another may trigger switching to a different (e.g., denser) configuration. If an L3 event is triggered, the WTRU may switch between beam-based reporting conditions.

If the WTRU switches to a denser configuration, it may do so only for a certain period of time to avoid unnecessary resource usage (e.g., after channel conditions have improved or the network has taken action to resolve the issue). The WTRU may revert back to the sparse configuration. For example, upon successful transmission of a beam measurement report, the WTRU may revert back to the sparse configuration. Or, the WTRU may revert back upon expiration of a time period (this duration may be configurable and begins when the dense configuration is resumed. Upon expiration of a timer, the WTRU may revert back to the sparse configuration).

Figure 9 shows an example of a WTRU initiated beam reporting procedure.

A WTRU may receive an indication from the network to activate one or more transmission configuration indication (TCI) states from a plurality of TCI states 901. The WTRU may also receive configuration information for WTRU-initiated beam reporting, wherein the configuration information includes parameters M and a threshold T 901. The WTRU may determine a candidate TCI state from the plurality of TCI states and the quality of the candidate TCI state 902. If the quality of the candidate TCI state is higher than the quality of at least M active TCI states by a threshold T, the WTRU may send a WTRU-initiated beam report 903.

Figure 10 shows an example of a WTRU-initiated beam reporting procedure based on a maximum time interval requirement.

The WTRU may receive configuration information for a WTRU-initiated beam reporting event from the network, wherein the configuration information includes a maximum time interval for transmitting WTRU-initiated beam reports 1001. The WTRU may detect that a WTRU-initiated beam reporting event has occurred 1002. The WTRU may determine a time value for a next available uplink transmission opportunity 1003. The WTRU may perform aperiodic transmission of WTRU-initiated beam reports based on a determination that the time value for the next available uplink transmission opportunity is later than the maximum time interval for transmitting WTRU-initiated beam reports 1004.

Although features and components are described above using specific combinations, those skilled in the art will appreciate that each feature or component can be used alone or in combination with other features and components. Furthermore, the methods described herein can be incorporated into computer-readable media for implementation as a computer program, software, or firmware executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), temporary storage, cache memory, semiconductor memory devices, magnetic media (such as internal hard drives and removable disks), magneto-optical media, and optical media (such as CD-ROMs and digital versatile disks (DVDs)). The processor in association with the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

100: Communication System 102: WTRU 102a, 102b, 102c, 102d: Wireless Transmitter/Receiver Unit (WTRU) 104: Radio Access Network (RAN) 106: Core Network (CN) 108: Public Switched Telephone Network (PSTN) 110: Internet 112: Other Networks 114a, 114b: Base Station 116: Air Interface 118: Processor 120: Transceiver 122: Transmitter/Receiver 124: Speaker/Microphone 126: Keypad 128: Display/Touchpad 130: Non-removable Memory 132: Removable Memory 134: Power Supply 136: Global Positioning System (GPS) Chipset 138: Peripheral Equipment 160a, 160b, 160c: eNodeB 162: Mobility Management Entity (MME) 164: Serving Gateway 166: Packet Data Network (PDN) Gateway; PGW 180a, 180b, 180c: gNB 182a, 182b: Access and Mobility Management Function (AMF) 183a, 183b: Session Management Function (SMF) 184a, 184b: User Plane Function (UPF) 185a, 185b: Data Network (DN) 201: UTCI 202: Codepoint 203: Diagram 204: Codepoint 2 205: UTCI 3 206: UTCI 7 207: UTCI Instance #1 208: UTCI Instance #2 209: Associated with UTCI Instance #1 210: Associated with UTCI Instance #2 301: WTRU detects event 302: WTRU-driven beam reporting 303: Acknowledgement signal 304: WTRU monitoring window 401: WTRU-driven beam reporting retransmission 501: First set of downlink beams 502: Second set of beams 601: WTRU identifies new beam 602: WTRU transitions to new beam 603: WTRU reports its transition to new beam 604: Configured time window 605: WTRU receives confirmation to stay on the newly identified beam 701: WTRU identifies new beam 702: WTRU receives uplink authorization; indication 703: Configuration window 704: WTRU reports new beam 705: WTRU receives confirmation to stay on the newly identified beam 801: WTRU identifies new beam 802: WTRU reports identification of new beam 803: WTRU receives confirmation to transition to the newly identified beam 804: Configuration window 901, 902, 903: Steps 1001, 1002, 1003, 1004: Steps N2, N3, N4, N6, N11: Interfaces S1: Interface X2: Interface Xn: Interface

A more detailed understanding may be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which: Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented; Figure 1B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communication system illustrated in Figure 1A according to an embodiment; Figure 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in Figure 1A according to an embodiment; FIG1D is a system diagram illustrating a further example RAN and a further example CN that may be used in the communication system illustrated in FIG1A according to one embodiment. FIG2 illustrates an example of a DCI for unified TCI status indication. FIG3 illustrates an example of successfully receiving an acknowledgment signal. FIG4 illustrates an example of not receiving an acknowledgment signal within a WTRU monitoring time window. FIG5 illustrates an example of a beam configuration for WTRU-based beam switching. FIG6 illustrates an example of a WTRU autonomously switching to a newly identified beam. FIG7 illustrates an example of a WTRU switching to a newly identified beam upon receiving an indication from the network. FIG8 illustrates an example of a WTRU reporting its intention to switch to a newly identified beam to the network. Figure 9 illustrates an example of a WTRU-initiated beam reporting procedure; and Figure 10 illustrates an example of a WTRU-initiated beam reporting procedure based on a maximum interval requirement.

901, 902, 903: Steps

Claims (16)

A method performed by a wireless transmit and receive unit (WTRU), the method comprising: receiving from a network an indication to activate one or more transmission configuration indication (TCI) states from a plurality of TCI states and configuration information for WTRU-initiated beam reporting, wherein the configuration information for WTRU-initiated beam reporting comprises a parameter M and a threshold T; determining a candidate TCI state and a quality of the candidate TCI state from the plurality of TCI states; and sending a WTRU-initiated beam report if the quality of the candidate TCI state is higher than a quality of at least M active TCI states by the threshold T. The method of claim 1, wherein the quality of a TCI state is based at least on a measured reference signal received power (RSRP) of a set of reference signals (RS) using the TCI state. The method of claim 1 or 2, wherein the candidate TCI state is configured in the WTRU by the network using downlink control information (DCI). The method of claim 1 or 2, wherein the candidate TCI state is configured in the WTRU by the network using a medium access control (MAC) control element (CE). The method of claim 1 or 2, wherein the candidate TCI state is configured in the WTRU by the network using a radio resource control (RRC) message. A method as in any of claims 1 to 5, wherein the WTRU initiated beam report includes information about the candidate TCI status. The method of any of claims 1 to 6, further comprising: Receiving an indication from the network to activate the candidate TCI state. The method of any one of claims 1 to 6, further comprising: autonomously activating the candidate TCI state. A wireless transmit and receive unit (WTRU) comprising at least one processor and a transceiver, wherein: The at least one processor and the transceiver are configured to receive from a network an indication for activating one or more transmission configuration indication (TCI) states from a plurality of TCI states and configuration information for WTRU-initiated beam reporting, wherein the configuration information for WTRU-initiated beam reporting comprises a parameter M and a threshold T; The at least one processor and the transceiver are configured to determine a candidate TCI state from the plurality of TCI states and a quality of the candidate TCI state; and The at least one processor and the transceiver are configured to send a WTRU-initiated beam report if the quality of the candidate TCI state is higher than a quality of at least M active TCI states by the threshold T. The WTRU of claim 9, wherein the quality of a TCI state is based at least on a measured reference signal received power (RSRP) of a set of reference signals (RS) using the TCI state. The WTRU of claim 9 or 10, wherein the candidate TCI state is configured in the WTRU by the network using downstream link control information (DCI). The WTRU of claim 9 or 10, wherein the candidate TCI state is configured in the WTRU by the network using a medium access control (MAC) control element (CE). The method of claim 9 or 10, wherein the candidate TCI state is configured in the WTRU by the network using a radio resource control (RRC) message. A WTRU as claimed in any one of claims 9 to 13, wherein the beam report initiated by the WTRU includes information about the candidate TCI status. The WTRU of any of claims 9 to 14, wherein: The at least one processor and the transceiver are further configured to receive an indication from the network to activate the candidate TCI state. The WTRU of any of claims 9 to 15, wherein: The at least one processor and the transceiver are further configured to autonomously activate the candidate TCI state.