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

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 SWITCHINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 617,950, filed January 5, 2024, the contents of which are incorporated herein by reference.BACKGROUND

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

[0003] Conventional beam selection is controlled by the base station (e.g., g N B) based on WTRU reporting, such as channel state information (CSI) reporting. The WTRU may be configured with measurement resources, e.g., reference signals (RSs) and these resources are linked to a CSI reporting configuration. Based on the CSI reporting configuration (for example, periodic, semi-persistent, or aperiodic reporting), the WTRU may measure the resources and report the measurement results via the CSI reporting configuration. For the case of aperiodic reporting, the gNB may trigger a measurement reporting using a downlink control information (DCI). This conventional beam or channel state information (CSI) reporting from a WTRU may be susceptible to latency and overhead issues, which may result in lower efficiency.SUMMARY

[0004] Various aspects are disclosed for efficient beam management with reduced latency and overhead by performing WTRU initiated beam measurement reporting (WTRUIBR).

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

[0006] Based on these and other aspects described herein, methods to enable WTRU initiated beam reporting (WTRUIBR) are disclosed.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0011] FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0012] FIG. 2 shows an example of a DCI for unified TCI state indications;

[0013] FIG. 3 illustrates an example of successful reception of the confirmation signal;

[0014] FIG. 4 illustrates an example where the confirmation signal is not received within the WTRU monitoring time window;

[0015] FIG. 5 illustrates an example of a configuration of beams for WTRU-based beam switching;

[0016] FIG. 6 illustrates an example where the WTRU may autonomously switch to a newly identified beam;

[0017] FIG. 7 illustrates an example where the WTRU may switch to a newly identified beam upon receiving an indication from the network;

[0018] FIG. 8 illustrates an example where the WTRU may report, to the network, its intention to switch to a newly identified beam;

[0019] FIG. 9 illustrates an example of a WTRU initiated beam reporting procedure; and

[0020] FIG. 10 illustrates an example of a WTRU initiated beam reporting procedure based on maximum time interval requirement.DETAILED DESCRIPTION

[0021] The following acronyms may be used herein:

[0022] CG Configured grant

[0023] DG Dynamic grant

[0024] MAC CE MAC control element

[0025] ACK Acknowledgement

[0026] BLER Block Error Rate

[0027] BWP Bandwidth Part

[0028] C-JT Coherent Joint Transmission

[0029] CP Cyclic Prefix

[0030] CP-OFDM Conventional OFDM (relying on cyclic prefix)

[0031] CQI Channel Quality Indicator

[0032] CRC Cyclic Redundancy Check

[0033] CSI Channel State Information

[0034] DAI Downlink Assignment Index

[0035] DCI Downlink Control Information

[0036] DL Downlink

[0037] DM-RS Demodulation Reference Signal

[0038] DRB Data Radio Bearer

[0039] HARQ Hybrid Automatic Repeat Request

[0040] LTE Long Term Evolution for example from 3GPP LTE R8 and up

[0041] NACK Negative ACK

[0042] mTRP Multiple TRP

[0043] MCS Modulation and Coding Scheme

[0044] MIMO Multiple Input Multiple Output

[0045] NC-JT Non-Coherent Joint T ransmission

[0046] NR New Radio

[0047] OFDM Orthogonal Frequency-Division Multiplexing

[0048] PHY Physical Layer

[0049] PMI Precoding Matrix Indicator

[0050] PRACH Physical Random Access Channel

[0051] PSS Primary Synchronization Signal

[0052] RACH Random Access Channel (or procedure)

[0053] RAR Random Access Response

[0054] RF Radio Front end

[0055] RLF Radio Link Failure

[0056] RLM Radio Link Monitoring

[0057] RNTI Radio Network Identifier

[0058] RRC Radio Resource Control

[0059] RRM Radio Resource Management

[0060] RS Reference Signal

[0061] RSRP Reference Signal Received Power

[0062] RSSI Received Signal Strength Indicator

[0063] SDU Service Data Unit

[0064] SRS Sounding Reference Signal

[0065] SS Synchronization Signal

[0066] SSS Secondary Synchronization Signal

[0067] SPS Semi-persistent scheduling

[0068] SUL Supplemental Uplink

[0069] TB Transport Block

[0070] TBS Transport Block Size

[0071] TCI Transmission Configuration Indicator

[0072] TRP Transmission / Reception Point

[0073] UL Uplink

[0074] URLLC Ultra-Reliable and Low Latency Communications

[0075] WLAN Wireless Local Area Networks and related technologies (IEEE 8O2.xx domain)

[0076] WTRU Wireless Receive and Transmit Unit

[0077] As used herein, “a” and “an” and similar terms are to be interpreted as “one or more” and “at least one.” Similarly, any term which ends 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.”

[0078] As used herein, a symbol 7” (forward slash) may be used herein to represent “and,” “or” or “and / or,” where for example, “A / B” may imply “A and / or B.”

[0079] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

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

[0081] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0082] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the 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 a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum A cell may provide coverage for a wireless service to a specific geographical areathat may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0083] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (for example, 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).

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

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

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

[0087] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (for example, an eNB and a gNB)

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

[0089] The base station 114b in FIG 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localizedarea, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (for example, for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (for example, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0090] The RAN 104 may be in communication 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 may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error 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, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0091] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0092] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (for example, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0093] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0094] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), 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. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0098] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, 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).

[0099] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (for example, nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium- ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0100] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (for example, longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (for example, base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0101] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a handsfree headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0102] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (for example, associated with particular subframes for both the U L (for example, for transmission) and DL (for example, for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (for example, a choke) or signal processing via a processor (for example, a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmissionand reception of some or all of the signals (for example, associated with particular subframes for either the UL (for example, for transmission) or the DL (for example, for reception)).

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

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

[0105] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0106] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0107] 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 serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA

[0108] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0109] 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.

[0110] The CN 106 may facilitate communications with other networks For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communicationsdevices. For example, the CN 106 may include, or may communicate with, an IP gateway (for example, an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0111] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (for example, temporarily or permanently) wired communication interfaces with the communication network.

[0112] In representative embodiments, the other network 112 may be a WLAN.

[0113] 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 or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (for example, directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (I BSS) mode may not have an AP, and the STAs (for example, all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0114] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (for example, 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the 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 802.11 systems. For CSMA / CA, the STAs (for example, every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (for example, only one station) may transmit at any given time in a given BSS

[0115] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0116] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0117] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (for example, only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (for example, to maintain a very long battery life).

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

[0119] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In 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. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

[0122] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (for example, containing a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0123] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (for example, such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, 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 the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0124] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0125] The CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0126] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (for example, handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized 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 AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0127] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

[0129] The CN 106 may facilitate communications with other networks For example, the CN 106 may include, or may communicate with, an IP gateway (for example, an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0130] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0132] The one or more emulation devices may perform the 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 may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (for example, testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (for example, which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0133] Artificial Intelligence (Al) may be broadly defined as the behavior exhibited by machines. Such behavior may for example include mimic cognitive functions to sense, reason, adapt and act. An Al system may learn and exploit the physical world (such as existing data sets, entity behavior, sensory information, etc.) to train Al models based on various learning schemes such as deep learning, federated learning, reinforcement learning, and / or a combination of them. The trained model may automatically discover useful knowledge, make decisions or have application-specific skills.

[0134] Machine learning (ML) may refer to a type of algorithm that solves a problem based on learning through experience or data, without explicitly being programmed or configured with a set of rules. Machine learning can be considered as a subset of Al. Different machine learning paradigms may be envisioned based on the nature of data or feedback available to the learning algorithm. For example, a supervised learning approach may involve learning a function that maps an input to an output based on labeled training examples, wherein each training example may be a pair including an input and a corresponding output. For example, an unsupervised learning approach may involve detecting patterns in the data with no pre-existing labels. For example, a reinforcement learning approach may involve performing a sequence of actions in an environmentto maximize the cumulative reward. In some solutions, it is possible to apply machine learning algorithms using a combination or an interpolation of the above-mentioned approaches. For example, a semi-supervised learning approach may use a combination of a small amount of labeled data with a large amount of unlabeled data during training. In this regard, semi-supervised learning falls between unsupervised learning (with no labeled training data) and supervised learning (with only labeled training data).

[0135] Deep Learning (DL) may refer to a class of machine learning algorithms that employ artificial neural networks, specifically deep neural networks (DNNs). The DNNs are a special class of machine learning models wherein the input is linearly transformed and pass-through non-linear activation function multiple times DNNs typically include multiple layers where each layer includes a linear transformation and non-linear activation functions The DNNs can be trained using training data via back-propagation algorithms. DNNs have useful in a variety of domains, for example, speech, vision, natural language, and for various machine learning settings such as supervised, un-supervised, and semi-supervised.

[0136] The term AIM L (Artificial Intelligence Machine Learning) based processing may refer to realization of behaviors and / or conformance to requirements by learning based on data, without any explicit configuration of sequence of steps of actions. Such methods may enable learning complex behaviors which might be difficult to specify and / or implement when using legacy methods.

[0137] An AIML model may refer to an implementation of an AIML based method which is made up of (1) model parameters and (2) a model structure. For example, a DNN-based AIML model may include a model parameters (i.e., weights and biases) and a model structure (i.e., the types and sizes of each layer of the deep neural network such as dense layers, convolutional layers, etc.).

[0138] Spatial domain filters, also referred to as “beams,” are discussed herein. WTRU may transmit a physical channel or signal using the same spatial domain filter as the spatial domain filter used for receiving a reference signal (RS), such as a channel state indicator reference signal (CSI-RS) or a synchronization signal block (SSB). The WTRU transmission may be referred to as “target”, and the received RS or SS block may be referred to as “reference” or “source”. In such case, the WTRU may be said to transmit the target physical channel or signal according to a spatial relation with a reference to such RS or SSB.

[0139] The WTRU may perform a first transmission using a first physical channel or signal according to the same spatial domain filter as the spatial domain filter used for performing a second transmission in a second physical channel or signal. The first and second transmissions may be referred to as “target” and “reference” (or “source”), respectively. In such case, the WTRU may be said to transmit the first (target) physical channel or signal according to a spatial relation with a reference to the second (reference) physical channel or signal.

[0140] A spatial relation may be implicit, configured by RRC or signaled by MAC control element (CE) or downlink control information (DCI). For example, a WTRU may implicitly transmit physical uplink shared channel (PUSCH) and demodulation reference signal (DM-RS) of PUSCH according to the same spatial domain filter as a sounding reference signal (SRS) indicated by an SRS resource indicator (SRI) indicated in DCI or configured by RRC. In another example, a spatial relation may be configured by RRC for an SRI orsignaled by MAC CE for a physical uplink control channel (PUCCH). Such spatial relation may also be referred to as a “beam indication.”

[0141] The WTRU may receive a first (target) downlink channel or signal according to the same spatial domain filter or spatial reception parameter as a second (reference) downlink channel or signal. For example, such association may exist between a physical channel such as physical downlink control channel (PDCCH) or physical downlink shared channel (PDSCH) and its respective DM-RS. At least when the first and second signals are reference signals, such association may exist when the WTRU is configured with a quasi-colocation (QCL) assumption type D between corresponding antenna ports. Such association may be configured as a transmission configuration indicator (TCI) state. A WTRU may be indicated an association between a CSI-RS or SS block and a DM-RS by an index to a set of TCI states configured by RRC and / or signaled by MAC CE. Such indication may also be referred to as a “beam indication.”

[0142] Unified TCI (UTCI) may refer to a beam / RS to be (simultaneously) used for multiple physical channels / signals and may comprise, for example, a common TCI, a common beam, or a common RS. The term “TCI” may comprise a TCI state that includes at least one source RS to provide a reference

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

[0144] The WTRU may be configured with a first mode for unified TCI (for example, SeparateDLULTCI mode) where an indicated unified TCI (for example, the first unified TCI or the second unified TCI) may be applicable for either downlink (for example, based on the first unified TCI) or uplink (for example, based on the second unified TCI).

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

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

[0147] The WTRU may determine a TCI state applicable to a transmission or reception by first determining a Unified TCI state instance applicable to this transmission or reception, then determining a 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 a PDCCH, a PDSCH, and / or CSI-RS. A Unified TCI state instance may also be referred to as a TCI state group, TCI state process, unified TCI pool, a group of TCI states, a set of timedomain instances / stamps / slots / symbols, and / or a set of frequency-domain instances / RBs / sub-bands, etc. A Unified TCI state instance may be equivalent or identified to a Coreset Pool identity (for example, CORESETPoollndex, a TRP indicator, and / or the like).

[0148] As used herein, unified TCI may be interchangeably used with one or more of unified TCI states, unified TCI instance, TCI, and TCI state, but still consistent with the invention.

[0149] Transmission Reception Point (TRP), Multi-TRP (MTRP) may be interchangeably used with one or more of TP (transmission point), RP (reception point), RRH (radio remote head), DA (distributed antenna), BS (base station), a sector (of a BS), and a cell (for example, a geographical cell area served by a BS), but still consistent with the invention. As used herein, Multi-TRP may be interchangeably used with one or more of MTRP, M-TRP, and multiple TRPs, but still consistent with the invention.

[0150] Configuration of TRPs, SRIs, PL reference RS(s): a WTRU may be configured with (or may receive configuration of) one or more TRPs to which the WTRU may transmit and / or from which the WTRU may receive. The WTRU may be configured with one or more TRPs for one or more cells. A cell may be a serving cell, secondary cell.

[0151] A 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 comprise a CSI-RS, SSB, or another downlink RS transmitted from the TRP to a WTRU. A CMR may be configured or associated with a TCI state. A WTRU may be configured with a CMR group where CMRs transmitted from the same TRP may be configured. Each group may be identified by a CMR group index (for example group 1). A WTRU may be configured with one CMR group per TRP, and the WTRU may receive a linkage between one CMR group index and another CMR group index, or between one RS index from one CMR group and another RS index from another group.

[0152] A WTRU may be configured with (or receive configuration of) one or more pathloss (PL) reference groups (for example, sets) and / or one or more SRS groups, SRS resource indicator (SRI) or SRS resource sets.

[0153] A PL reference group may correspond to or may 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 (for example CSI-RS set, SRI sets), CORESET index, and or reference signals (for example CSI-RS, SSB)

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

[0155] In the examples and embodiments described herein, TRP, PL reference group, SRI group, and SRI set may be used interchangeably. The terms set and group may be used interchangeably herein.

[0156] CSI components, a WTRU may report a subset of channel state information (CSI) components, where CSI components may correspond to at least a CSI-RS resource indicator (CRI), a SSB resource indicator (SSBRI), an indication of a panel used for reception at the WTRU (such as a panel identity or group identity), measurements such as L1-RSRP, L1-SINR taken from SSB or CSI-RS (for example cri-RSRP, cri-SINR, ssb- Index-RSRP, ssb-lndex-SINR), and other channel state information such as at least rank indicator (Rl), channel quality indicator (CQI), precoding matrix indicator (PMI), Layer Index (LI), and / or the like.

[0157] Property of a grant or assignment may comprise at least one of the following:

[0158] - a frequency allocation;

[0159] - an aspect of time allocation, such as a duration;

[0160] - a priority;

[0161] - a modulation and coding scheme;

[0162] - a transport block size;

[0163] - a number of spatial layers;

[0164] - a number of transport blocks;

[0165] - a TCI state, CRI or SRI;

[0166] - a number of repetitions;

[0167] - whether the repetition scheme is Type A or Type B;

[0168] - whether the grant is a configured grant type 1 , type 2 or a dynamic grant;

[0169] - whether the assignment is a dynamic assignment or a semi-persistent scheduling (configured) assignment;

[0170] - a configured grant index or a semi-persistent assignment index;

[0171] - a periodicity of a configured grant or assignment;

[0172] - a channel access priority class (CAPC); or

[0173] - any parameter provided in a DCI, by MAC or by RRC for the scheduling the grant or assignment.

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

[0175] As used herein, the terms “prediction” and “estimation” may be used interchangeably, but still consistent with the invention.

[0176] As used herein, the terms “source cell,” “current cell,” and “serving cell” may be used interchangeably, but still consistent with the invention.

[0177] As used herein, the terms “candidate cell,” “neighbor cell,” and “target cell” may be used interchangeably, but still consistent with the invention.

[0178] As used herein, the term “beam” and “TCI state” may be used interchangeably.

[0179] As used herein, a signal may be interchangeably used with one or more of 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).

[0180] As used herein, a channel may be interchangeably used with one or more of 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.

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

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

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

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

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

[0186] As used herein, UTCI may be interchangeably used with TCI, UTCI state, TCI state.

[0187] In one example, UL channel or signal specific and a max-duration based aperiodic WTRU-driven reporting is provided. In one example, if a next available UL transmission occasion does not fall within a maximum duration, the WTRU may perform an aperiodic (e.g., contention-based) transmission method of the event-based beam reporting, e.g., a contention-based PUCCH transmission, a PRACH+PUSCH transmission. It should be noted that in some cases the maximum duration may be configured.

[0188] In one example, a WTRU may receive 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 -)SI NR, CQI, etc., and what / how to report based on an event.

[0189] In one example, the WTRU may receive configuration information indicating a maximum duration in which the event-based beam reporting can be performed, e.g , due to the need to report this information quickly (e g., prior to beam failure detection / recovery initiation). The maximum duration may be an offset (e.g., number of slots, frames etc.) from a triggering condition being satisfied. The reporting may comprise at least the beam information and / or beam quality information.

[0190] The WTRU may determine that an event occurs, based on measuring a set of beam quality metrics of a set of RSs and a function to determine the event by comparing the set of beam quality metrics with one or more thresholds, e.g., based on Layer-1 / 2 event measurement

[0191] The WTRU may determine one or more reporting contents based on the event, where the reporting contents may comprise the determined beam(s) (e.g., one or more RSs of the set of RSs), corresponding one or more beam quality metrics, and / or a flag representing the event.

[0192] Upon satisfaction of a triggering event, the WTRU may determine whether the next available UL transmission occasion (e.g., PUSCH, PUCCH, etc.) falls within a maximum duration for an event-based beam reporting. In some cases the maximum duration may be configured.

[0193] Based on the determination, the WTRU may selectively perform either (1) scheduled UL channel based (e.g., contention free) WTRU-driven reporting, or (2) contention-based transmission based WTRU-driven reporting.

[0194] Scheduled UL channel transmissions (e.g., contention free) may be WTRU-driven reporting. If the next available UL transmission occasion is determined to fall within the maximum duration from the triggering event, the WTRU may perform an event-based beam reporting using the next available scheduled UL transmission occasion.

[0195] In an example, a WTRU may signal by a (most-recent available or scheduled) PUCCH resource (or PUSCH) for CSI reporting, e.g , via adding a new part (e g., Part 3 CSI) of CSI or beam reporting contents The WTRU may determine the CSI or beam reporting contents by combining (e.g , merging, concatenating) the new part into the NW-controlled reporting contents, e.g., Part 1 and / or Part 2 CSI, already scheduled to be reported via the PUCCH resource. The WTRU may also, or alternatively, be configured to replace the CSI part(s) and reuse the bit width (e.g., allocated for Part 1 and / or Part 2 CSI) for the WTRU-driven reporting, e.g., with zero-padding bit(s) inserted to match the bit width, where a N-bit flag (e.g., N=1) may be included for indicating the new reporting contents based on the WTRU-driven reporting.

[0196] On a condition that the WTRU determines that the PUCCH resource for CSI reporting includes HARQ-ACK transmission (e.g , when the HARQ-ACK transmission is piggybacked on the CSI reporting), the WTRU may be configured to drop the CSI part and reuse the dropped part for the WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not dropped and concatenated with the reporting contents for the WTRU-driven reporting.

[0197] In the case where more than one occasion is found within the maximum duration, the WTRU may be configured, or defined, with a priority between the above PUSCH and PUCCH. For example, in one case the earlier occasion may be used. In another case, the PUSCH may be used, e.g , when both PUSCH and PUCCH are collided in a same slot or symbols

[0198] Contention-based WTRU-driven reporting may be used. For example, if the next available UL transmission occasion does not fall within the maximum duration, the WTRU may perform a contention-based transmission (e.g., a transmission using a shared resource) of the event-based beam reporting.

[0199] For example, the WTRU may be configured to perform a PUCCH transmission over a shared one or more PUCCH resources, where the one or more shared PUCCH resources are configured (e.g., via RRC) to the WTRU for such event-based beam reporting. The WTRU may, or may be configured to, transmit, via the PUCCH transmission, the reporting contents and one or more identifiers (e g., WTRU-ID, an RNTI, a scrambling ID / parameter, etc.) to identify the WTRU. This may occur, for example, because the one or more PUCCH resources may also be configured to other WTRU(s) so that a collision may happen among WTRUs. This may provide benefits especially when a current timing advance (TA) is desired to be maintained, e.g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

[0200] In another example, the 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 2-step transmission procedure (e.g., PRACH transmission and associated one or more PUSCH transmissions), where the PUSCH payload may deliver the reporting contents. This may provide benefits especially when a new TA is desired to be acquired, e.g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

[0201] In some 5G systems NR-MIMO operation, beam or CSI reporting from a WTRU is performed by a procedure controlled by a gNB. Specifically, the WTRU may be configured with measurement resources (NZP- CSI-RS resources and / or SSB indexes) including CSI-IM resources and these are linked to a CSI reporting configuration. Based on the CSI reporting configuration, for example, periodic, semi-persistent, or aperiodic reporting, the WTRU measures the measurement resources and reports the measurement results via the CSI reporting configuration. For the case of aperiodic reporting, the gNB triggers (by sending a DCI) the measurement and reporting behavior for the WTRU to conduct. There is a need to reduce the latency and overhead associated with existing gN B-control led beam management methods.

[0202] According to various embodiments, WTRU-driven beam reporting methods may be provided to reduce the latency and overhead for beam management.

[0203] In one example, a WTRU may be configured with a plurality of transmission configuration indicator (TCI) states, for example, unified TCI (UTCI) states, each applicable for multiple channel(s) / signal(s). The multiple channel(s) / signal(s) may be configured to the WTRU (or pre-determined or defined), for example, in a form of a list, by a higher-layer signaling (for example, RRC and / or MAC-CE) which may comprise at least one of following:

[0204] - one or more CORESETs;

[0205] - one or more PDCCH candidates;

[0206] - one or more search spaces;

[0207] - one or more PDSCHs (for example, PDSCH occasions / configurations / instances, etc.);

[0208] - one or more RSs (for example, CSI-RSs, DMRSs, SSB indexes, PRSs, PTRSs, and / or SRSs);

[0209] - one or more PUSCHs (for example, PUSCH occasions / configurations / instances, etc.);

[0210] - one or more PUCCH resources (for example, PUCCH resource sets / groups); or

[0211] - one or more PRACH occasions / resources / RSs.

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

[0213] FIG. 2 shows an example of a DCI for unified TCI state indications.

[0214] In this example, a codepoint 202 is received in the TCI field located in the DCI and is mapped to a UTCI 201. Specifically, in this example, the codepoint 202 comprises 3-bits to represent TCI states 0 to 7. This example is non-limiting, e.g., more or less TCI states may be defined. The WTRU may receive the mapping between the codepoint 202 and the UTCI 201 in the DCI. The WTRU may receive one or more TCI states, as illustrated in the figure 203, via e.g., a MAC-CE signaling.

[0215] 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 UTCI7206 to the multiple channel(s) / signal(s). This may be based on a list of the multiple channel(s) / signal(s) configurable by a higher-layer signaling from a gNB. For example, the list of the multiple channel(s) / signal(s) may be given per UTCI instance, where a UTCI instance may correspond to a column in the mapping table, illustrated in the figure: 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. .

[0216] In one example, the threshold level may be based on a type of candidate beam for WTRU-initiated beam reporting is provided. A WTRU may determine that a quality of a current beam is below a first threshold. Based on that determination, the WTRU may determine that a quality of other candidate beam(s) is / are higher than a threshold, where the threshold is determined based on a type of the other beam(s) and / or a status of UTCI (as either activated or non-activated).

[0217] In one example, A WTRU may receive configurations for one or more of: a plurality of beam indexes (for example, TCI states, unified TCI states (UTCI), RS resources, etc.), where each beam index may be associated with a beam (for example, a RS that may be used to determine a beam for transmission or reception); beam reporting related parameter(s) (for example, periodicity, UL resource(s) forthe reporting, etc.); one or more thresholds for determining one or more events that may trigger a reporting; and / or one or more priority parameters or priority information associated with the one or more triggering events or the reports associated with the events, for example, a priority for each event or report or a priority order for the events or reports.

[0218] The WTRU may receive an indication of one or more activated beam indexes (for example, activated UTCI states).

[0219] The WTRU may receive, for example, from a gNB, an indication of a first and / or a second beam index of the plurality of beam indexes (for example, of the activated beam indexes), for DL and / or UL communications with the gNB, where the first beam index (for example, UTCI3) may be used to determine a first current beam for communications with TRP1 of the gNB, and the second beam index (for example, UTCI7) may be used to determine a second current beam for communications with TRP2 of the gNB.

[0220] The WTRU may perform, based on the configurations, one or more beam measurements, for determining whether a reporting event occurs, where a reporting event may occur according to at least one of Eventl, Event 2, or Event s, and where a beam quality may, for example, be at least of (L1-)RSRP, (L1-)SINR, (L1-) RSRQ, CQI, etc.

[0221] Eventl may be used to improve or aid a gNB to perform dynamic selection among activated UTCIs. Eventl may occur when: a first beam quality of the first current beam (or a second beam quality of the second current beam) is below a first threshold; and a beam quality difference between the first current beam (or the second current beam) and a third beam exceeds a second threshold, where the third beam is associated with another activated beam index (for example, UTCI state). For example, when “L1-RSRP of UTCI23(new)” minus “L1-RSRP of UTCI3(current)” is higher than the second threshold.

[0222] Event2 may be used to improve or aid a gNB in determining a new activated set of UTCIs. Event2 may occur when: a first beam quality of the first current beam (or a second beam quality of the second current beam) is below a first threshold; and a beam quality difference between a (for example, any) beam associated with an activated beam index and a candidate beam exceeds a threshold, where the WTRU may receive configuration of one or more candidate beams (for example, by RRC) and the configuration may indicate a pool of TCI or UTCI states.

[0223] Event3 may be used, for example, for finding a new beam based on beam prediction” Event3 may occur when: a first beam quality of the first current beam (or a second beam quality of the second current beam) is below a first threshold, and a beam quality difference between a beam associated with an activated beam index (for example, the current, or any other) and a beam determined based on a beam prediction exceeds a threshold.

[0224] When the WTRU determines (for example, declares) an event (for example, Eventl , Event2, or Event3) occurs, the WTRU may transmit (for example, report) at least one of following: the beam index of the beam with the higher beam quality that triggered the event, for example, the beam index of the third beam for Eventl , beam index of the candidate beam for Event2, or the beam index of the predicted beam for Event3.; beam quality metric(s), for example, one or more of (L1-)RSRP, (L1-)SINR, (L1-)RSRQ, CQI, etc , for the beam associated with the reported beam index; and a flag indicating the event (of the one or more events)

[0225] When multiple events are triggered and the reports for two or more events collide (for example, in the same symbol or slot) the WTRU may send the report for one of the events where the event for which to send the report is determined by the WTRU based on the configured priority parameter(s) or information.

[0226] The WTRU may, or may be configured to, determine, based on the configured priority parameter(s) or information, a priority order (for example, ranking) among the one or more events or among the reports associated with the events, for example, the priority order may be determined such that Event2 is the highest priority, Eventl is the second-highest priority, and Events is the lowest priority.

[0227] The WTRU may send the 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, for example, be associated with the event that triggered the report.

[0228] In one example, a WTRU may receive configurations of a plurality of beam indexes (for example, TCI states, beam IDs, RSs, RS resources, unified TCIs (UTCIs) or unified TCI states (UTCI states), etc.), where one or more events may be defined or configured, which trigger reporting at least one beam index of the plurality of beam indexes, where one or more thresholds are associated with the one or more events. For example, the configurations may further comprise beam reporting related parameter(s) (for example, periodicity, UL resource(s) for the reporting, etc.), one or more thresholds for determining one or more events that may trigger a reporting, and / or one or more priority parameters or priority information associated with the one or more triggering events or the reports associated with the events, for example, a priority for each event or report or a priority order for the events or reports.

[0229] As noted above, Eventl may be used for improving or aiding an gNB in performing dynamic selection among activated UTCIs.

[0230] A WTRU may receive a configuration of a plurality of unified TCI states (UTCI) (for example, the plurality of beam indexes), one or more types of candidate (UTCI) beams, one or more events defined based the one or more types of candidate (UTCI) beams, one or more thresholds each associated with an event, and / or at least one WTRU-driven reporting configuration.

[0231] A WTRU may currently use, or maintain, a first UTCI (for example, UTCI3) and a second UTCI (for example, UTCI7). This can be based on receiving an indication, such as via a DCI, of the first and second UTCI provided earlier in time. The indication must satisfy a defined beam application timeline, as illustrated in Figure 1. For example, this may involve receiving Codepoint 2 of the TCI field of a DL-DCI. This reception must occur sufficiently in advance, meaning the required time to apply the UTCI, including beam application time (BAT), has already elapsed. .In one example, the WTRU may be configured to determine a beam quality (for example, (L1-)RSRP, (L1-JSINR, (L1-)RSRQ, CQI, etc.) difference between a current (one or more) (UTCI) beam(s) and other candidate (UTCI) beam(s), which may correspond to an event (for example, Eventl) of the one or more events being configured, defined, or indicated. The other candidate (UTCI) beam(s) may be other UTCI(s) being activated / mapped in (the same column of) the TCI field. This may provide benefits in terms of assistinga gNB (for example, a serving-gNB, a serving-cell, a TRP, a serving-TRP) for aiding the gNB to do better dynamic selection among activated UTCIs.

[0232] For example, the current UTCI3 is to be compared with UTCI2, UTCI23, UTCI26, UTCI4, UTCI15, and / or UTCI5 (which are all in the first column of the TCI field, which may be a first indicated TCI). The WTRU may determine (for example, select) UTCI23 to be reported based on comparing the beam quality between UTCI3 and UTCI23, where reporting contents may comprise a first index or value associated with the UTCI23, a corresponding first beam quality metric, and / or a flag representing the Event! .

[0233] For example, the current UTCI7 is to be compared with UTCI9, UTCI4, UTCI11, UTCI19, and / or UTCI8 (which are all in the second column of the TCI field, which may be a second indicated TCI). The WTRU may determine (for example, select) UTCI11 to be reported based on comparing the beam quality between UTCI7 and UTCI11 , where reporting contents may comprise a second index or value associated with the UTCI11 and / or a corresponding second beam quality metric, and / or a flag representing the Eventl .

[0234] The WTRU may (be configured to) report the reporting contents based on the one or more events (for example, the Eventl) occurring via a UL channel or signal.

[0235] As described above, Event2 may be used to improve or aid a gNB in determining a new activated set of UTCIs.

[0236] In Event 2, the WTRU may be RRC configured with a pool of UTCIs. The RRC configured UTCI pool may be large, up to 256 states. Out of this initial pool of UTCIs, the WTRU may get a first set of UTCIs activated by MAC CE, meaning that the UTCIs may be actively measured and maintained for the beam management purposes using the associated RS. As the active measurements for activated UTCI have 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 measurements purposes.

[0237] The second set of UTCIs may be added to the measurement process as an addition to the already first activated UTCI set. The maximum size of the second set of UTCI may be based on a WTRU reported capability that may be described as the maximum number of UTCIs that can be simultaneously tracked overall, or number of UTCIs that can be simultaneously tracked beyond the maximum activate UTCIs (for example beyond 8 UTCIs codepoints).

[0238] The second UTCI set may be configured by MAC CE as well (or configured by RRC, and / or indicated by a DCI). The second set of UTCIs may be part of the RRC configured pool. The second set of UTCI measurement command may contain any combination of the following parameters: the second set of codepoints for the UTCIs; and / or an indicator or a pointer to the Event2 configuration as there may be multiple Event2 configurations (for example: permanent measurements, semi-statically activated by a threshold, or activation by DCI command).

[0239] The WTRU may be configured with an Event2 measurement report that may include any combination of the following parameters: second set measurement granularity (for example this may be less often measured than the first set UTCI measurements granularity); a threshold or thresholds formeasurements activation, as this process may kick in only when the quality of a certain number of UTCI states from the first set go below a certain quality; a reporting threshold for the second UTCI set; and or a time to trigger for the second set measurement report, meaning that only if the measurements of a second UTCI set member is above the configured quality measurement for the configured time to trigger, the report will be sent to the network.

[0240] Thus, the second UTCI set measurement may be activated by the WTRU only under the configured conditions and may not be permanently executed.

[0241] Alternatively, the second UTCI set may be measured continuously at the ordered granularity and Event2 reported under the configured quality and / or time conditions.

[0242] Alternatively, the second UTCI set measurements and reporting may be activated by network using a DCI command. This may be a one-shot measurement for the entire second set of UTCIs or seen as an aperiodic measurement setup that may be ended by the WTRU report of by a network deactivation command.

[0243] When the conditions for the second UTCI set measurements are met or activated, the WTRU measures the related / associated RSs for the configured quantities (for example, RSRP, RSRQ, SINR) and it may report for example the UTCIs that are above a certain quality threshold as defined by Event2 configuration. The report may contain any combination of the following parameters: the index(es) of UTCI states fulfilling the Event2 configuration conditions; pointer to the UTCI state from the second set; the associated UTCI measurement quantity; a differential value of the measurement quality for a specific UTCI from the second set; and / or the index(es) of active UTCI states or pointers to the UTCI states from the first set that are any more reliable (below a quality threshold) and the indexes of the UTCI states or pointers to the UTCI states from the second set that fulfil the quality threshold, for example, described by Event2.

[0244] In one example, using a combination of above conditions, the WTRU may order the active beam from lower to higher quality and the WTRU may determine if the beam quality of one or more (e.g., M) active beams is below a threshold If so, Event2 measurements are triggered, as described above. Then the WTRU may determine if the beam quality of a candidate beam is better than the beam quality of one or more (e.g. N) active beams. In one example, M=N.

[0245] In one example, the second set UTCI Event2 reporting may be sent by UCI over PUSCH, PUCCH, MAC CE or ever RRC reporting.

[0246] Network driven active UTCI update: Upon sending the Event2 report, the WTRU may receive a MAC CE UTCI activation command that contains a new first set of UTCI codepoints that may contain UTCI codepoints for the previously reported TCIs from the second set. Additionally, the WTRU may receive a new second set of UTCIs for further measurements reporting for Event2.

[0247] WTRU driven active UTCI update: Alternatively, the WTRU may report to the network as part of Event2 the UTCIs for the second set that fulfill the Event2 along with UTCIs from the first set that will be replaced. Upon receiving an ACK (as acknowledgement) for the Event2 report from the network, the WTRU may autonomously activate / update the new first set.

[0248] After updating the first set of active UTCI states, the WTRU may place the deactivated UTC I states in the second set autonomously.

[0249] Alternatively, the WTRU may completely drop the declared unreliable states after updating the UTCI active set.

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

[0251] The WTRU may receive one or more configuration parameters for WTRU-initiated beam reporting (WTRUIBR). The configuration parameters may include a set of reference signals (RSs) for WTRUIBR, a threshold value associated with an event, and / or information on an UL channel (e.g., PUSCH) to be used by the WTRU delivering the WTRU initiated beam report upon the event being triggered. The one or more configuration parameters for WTRUIBR may be received in an RRC message.

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

[0253] The WTRU may determine a set of candidate TCI states. Candidate TCI states are TCI states to be measured by the WTRU. The set of candidate TCI states may be configured by the network or may be determined by the WTRU, independently. A candidate TCI state may be a TCI state that is available, but not activated

[0254] The WTRU may measure RSRP of a first RS using (e.g., associated with) a candidate TCI state. The WTRU may compare the measurement performed using a candidate TCI state with a measurement performed using an active TCI state. Upon identifying a candidate TCI state that results in a measured RSRP value of a first RS which is higher than an RSRP of 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 measured RSRP value using that TCI state.

[0255] As noted above, Events may be used, for example, for finding a new beam based on beam prediction. In Events a WTRU may receive a network request to provide capability information. The request to WTRU may be based on RRC signaling following the random access procedure. The WTRU may prepare a WTRU capability information message including support for event-based beam reporting with beam prediction.

[0256] The WTRU capability information related to beam prediction event-based beam reporting may include information or parameters related to the beam prediction mechanism. In one example with WTRU utilizing Artificial-lntelligence(AI) / Machine-Learning(ML) for beam prediction, information may include one or more AI / ML model IDs, processing / training capabilities, datasets, storage, etc.

[0257] The WTRU may send the WTRU capability information message through RRC signaling, for example, over the PUSCH.

[0258] The WTRU may receive a configuration of a plurality of beams (for example, unified TCI states (UTCI)), each representing a set of transmission configurations such as specific beam indices applicable to multiple channels or signals. WTRU configuration may be pre-determined or defined by higher-layer signaling (RRC, MAC-CE, etc.).

[0259] The WTRU configuration may also include one or more events related to (UTCI) beam measurement and reporting defined based on one or more types of candidate (UTCI) beam, one or more thresholds (for example, triggers for activation), WTRU reporting settings (for example, granularity, timers, and filters for sending a report), etc. WTRU configuration may also include prioritization between two or multiple event-based beam reporting event types.

[0260] A possible WTRU event type (for example, Event3) is beam prediction event-based beam reporting. The configuration for this type of event may further include one or more parameters related to beam prediction measurements and reporting such as prediction metrics, domain (spatial, time, or both), accuracy / confidence levels, fallback mechanism, resources, opportunities, etc.

[0261] In one example, the WTRU may be configured to perform beam prediction for a given number of beams, for example, Xcbeams (out of a possible X beams). In one example, WTRU may be configured to perform beam prediction for one or multiple time-units from a reference point in time, for example, predicting beams at a time slot n + kt, n + k2, etc., where kLmay be a positive integer. These time-units relating to one or more future transmissions (fct) may be fixed, or semi-statistically or dynamically configured by the network.

[0262] The beam prediction mechanism may be based on AI / ML, grid-based or non-grid-based, heuristic, or other methods. In the case of AI / ML, the configuration may include information about the AI / ML model, training procedures (for example, online or offline), inputs / outputs, hyperparameter tuning, triggers for reversion to legacy procedure, etc.

[0263] In one example, WTRU receives configuration for the AI / ML model offline training including training reference signals and training time windows. WTRU may assess the accuracy of the AI / ML model for beam prediction at any given point during the training phase and send an indication to the gNB if certain beam prediction accuracy is achieved. In one example, the WTRU may request for an additional training phase if beam prediction accuracy is below a certain threshold.

[0264] In one example, a WTRU with an offline trained AI / ML in an inference stage, or / and WTRU with online AI / ML model training, can send a retraining request to the network if certain accuracy thresholds such as beam prediction accuracy falls below a certain threshold.

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

[0266] The WTRU may receive, for example, through a MAC-CE, afirst UTCI for default beam management purposes including measurements and reporting. The WTRU, currently maintaining a first UTCI, may receive, for example, through DCI, a second UTCI for beam measurement purposes.

[0267] In one example, the WTRU may perform estimation, prediction, and determination for (UTCI) beams for one or more of future transmissions according to the event-based beam reporting configuration.

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

[0269] The WTRU may identify a predicted (UTCI) beam as a potential replacement of the current UTCI, for example, with comparing current beam(s) with predicted beam(s), in spatial domain, time domain, or both. WTRU reporting can include an explicit or implicit indication of a preferred predicted (UTCI) beam The reporting may also include additional beam prediction information such as beam indices, beam prediction accuracy / confidence levels, etc. In one example, the WTRU may report the relative beam indices or spatial relation based on the maintained UTCI (anchor beams).

[0270] In one example, the WTRU may receive an acknowledgement from the network (for example, through reception of a DCI, for example, UL grant) whether or not to switch to the preferred WTRU predicted (UTCI) beam. In one example, the gNB may only send an acknowledgement for rejecting the switching to the WTRU predicted UTCI. In another example, WTRU may be configured for WTRU-triggered UTCI updating, for example, switching to a WTRU predicted UTCI beam without network confirmation.

[0271] With a beam prediction event triggered and activated, the network may send a second configuration to modify the event-based beam reporting. In one example, under beam prediction, the network may reduce the number of RS transmissions, depending on the multi-user conditions.

[0272] Event based reporting based on WTRU beam prediction in spatial or / and time domain may result in improved beam selection accuracy, reduced latency from beam sweeping, reduced signaling, or a combination of these.

[0273] Examples of other events:

[0274] An event (for example, Event n) of the one or more events may comprise at least one of following (for example, other than the above Eventl , Event2, Event3).

[0275] An event (e.g., Event4) may be associated with beam failure recovery (BFR) and / or radio link failure (RLF) recovery. This event and its related parameter(s) may be configured in the WTRU. The event may occur when the WTRU predicts that the time duration before a beam failure may occur is less than a threshold time value. Then, the WTRU may determine (for example, declare) to report corresponding report contents, for example, notifying the “nearing expiry” before falling into the failure, how many time units are remaining before the failure, new beam ID(s) if found for the recovery, corresponding quality metric(s) associated with the new beam(s) and / or the current beam(s), and / or a flag representing this event (for example, Event4)

[0276] In one example, when a gNB receives the reporting (from the WTRU), the gNB may not select other beams than the reported beam(s), where the WTRU may expect / assume that the WTRU may use at least oneof the reported beam(s) after a time offset of the reporting instance. For example, especially for a MTRP scenario, the reported beam may be associated with a PDCCH monitoring beam (for a TRP among multiple TRPs), for example, associated with a CORESETpoollD, that may also be reported together.

[0277] In one example, the WTRU may apply the reported beam right after the time offset (from the instance of the reporting), for example, without receiving an explicit confirmation from the gNB, unless an exceptional signaling from gNB to override the reported beam is given.

[0278] Another event (e g., Event5) may be associated with the case where the WTRU may prefer to use a different WTRU-panel, for example, for DL Rx and / or for UL Tx). This event and related parameter(s) may be configured to the WTRU. The event may occur when the WTRU determines to change or switch one or more currently used WTRU-panels into a different set of WTRU-panels for communication, for example, with a gNB for DL Rx and / or UL Tx. For example, the WTRU may currently use or active WTRU-panel1 and WTRU-panel3 for communications with the gNB. The WTRU may determine to change the set of activated WTRU-panels (WTRU-panel1 and WTRU-panel3) to a second set of WTRU-panels The second set of WTRU-panels may comprise new WTRU-panels (for example, WTRU-panel2 and WTRU-panel4) or partially new WTRU-panels (for example, WTRU-panel1 and WTRU-panel4) where the WTRU-panel1 is to be continuously used for communications and the WTRU-panel4 may be newly activated (for example, after a configured time offset parameter for the activation) by instead deactivating the WTRU-panel3. The WTRU may determine to report corresponding report contents, for example, notifying the determination for changing an activated set of WTRU- panels, timing-related information on when the new activation is completed, etc., one or more WTRU-panel ID(s) as being newly activated for communications with the gNB, corresponding quality metric(s) associated with (for example, representative beam ID(s) of) the newly activated WTRU-panel(s) and / or the current beam(s), and / or a flag representing this event (for example, Event5).

[0279] In response to the reporting, the WTRU may receive a confirmation signal from the gNB or an indication message for the WTRU including information on which WTRU-panel(s) to activate.

[0280] The WTRU may apply the reported set of WTRU-panels to be activated after a time offset (from the instance of the reporting), for example, without receiving an explicit confirmation from the gNB, unless a further update signaling from the gNB is given to override the reported set of WTRU-panels to be used for communications with the gNB.

[0281] The above embodiments are non-limiting examples and a definition of an event with related parameter(s), for example, threshold, etc. are configurable from the gNB, for example, each with an event number or flag to be used for identifying an event of the one or more events between the gNB and the WTRU. A proposed WTRU behavior under one example scenario of the event described above may be applicable for another example scenario of an Event For example, the “time to trigger” for the second set measurement report discussed under Event2 may also be applicable under Eventl, for example, based on an independent parameter for “time to trigger”, only if the measurement result for Eventl satisfies the related condition(s) witha threshold for the independent time to trigger, the corresponding report based on Eventl will be sent to the network.

[0282] In one example, a method for UL channel or signal specific and a max-duration based aperiodic WTRU-driven reporting is provided.

[0283] In one example, if a next available UL transmission occasion does not fall within a maximum duration, the WTRU may perform an aperiodic (e.g., contention-based) transmission of the event-based beam reporting, e g., using a contention-based PUCCH transmission or a PRACH+PUSCH transmission.

[0284] 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., and what to report and the method to be used to report the one or more events. The method may be event specific.

[0285] The WTRU may receive configuration information indicating a maximum duration in which the eventbased beam reporting may be performed, e.g., due to the need to report this information quickly (e.g., prior to beam failure detection / recovery initiation). The maximum duration may be an offset (e.g., number of slots, frames etc.) from a triggering condition being satisfied. The reporting may comprise at least the beam information and / or beam quality information.

[0286] The WTRU may determine that an event occurs based on measuring a set of beam quality metrics of a set of RSs and determine the event by comparing the set of beam quality metrics with one or more thresholds, e.g., based on Layer-1 / 2 event measurement.

[0287] The WTRU may determine one or more reporting contents based on the event, where the reporting contents may comprise the determined beam(s) (e.g., one or more RSs of the set of RSs), corresponding one or more beam quality metrics, and / or a flag representing the event .

[0288] Upon satisfaction of a triggering event, the WTRU may determine whether the next available UL transmission occasion (e.g., PUSCH, PUCCH, etc.) falls within the (configured) maximum duration for the event-based beam reporting.

[0289] Based on the determination, the WTRU may selectively perform either (1) Scheduled UL channel transmission based (e.g., contention free) for WTRU-driven reporting, or (2) Contention-based transmission based for WTRU-driven reporting.

[0290] In the case of scheduled UL channel based (e.g., contention free) WTRU-driven reporting, if the next available UL transmission occasion is determined to fall within the configured maximum duration (from the time when the event was triggered), the WTRU may perform the event-based beam reporting using the next available (e.g., scheduled) UL transmission occasion (e.g., contention free) .

[0291] For example, the WTRU may perform signaling by a (most-recent available or scheduled) PUCCH resource (or PUSCH) for CSI reporting, e.g., via adding a new part (e.g., Part 3 CSI) of CSI or beam reporting contents. The WTRU may determine the CSI or beam reporting contents by combining (e.g., merging,concatenating) the new part into the NW-controlled reporting contents, e.g., Part 1 and / or Part 2 CSI, already scheduled to be reported via the PUCCH resource.

[0292] In another example, the WTRU may, or may be configured to, replace the CSI part(s) and reuse the bit width (e.g., allocated for Part 1 and / or Part 2 CSI) for the WTRU-driven reporting, e.g., with zero-padding bit(s) inserted to match the bit width, where a N-bit flag (e.g., N=1 ) may be included for indicating the new reporting contents based on the WTRU-driven reporting

[0293] On a condition that the WTRU determines that the PUCCH resource for CSI reporting includes a HARQ-ACK transmission (e.g , when the HARQ-ACK transmission is piggybacked on the CSI reporting), the WTRU may, or may be configured to, drop the CSI part and reuse the dropped part for the WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not dropped and concatenated with the reporting contents for the WTRU-driven reporting.

[0294] In the case where more than one occasions are found within the (configured) maximum duration, the WTRU may be configured (or pre-provisioned) with a priority between the PUSCH and PUCCH. For example, in one case, the earlier resource may be used. In another example, the PUSCH may be used, e.g., when both PUSCH and PUCCH are collided in a same slot or symbol(s)

[0295] In the case of contention-based WTRU-driven reporting, if the next available (e.g , scheduled) UL transmission occasion does not fall within the (configured) maximum duration, the WTRU may perform a contention-based transmission (e.g., a transmission using a shared resource) of the event-based beam reporting. For example, the WTRU may (be configured to) perform a PUCCH transmission over a shared PUCCH resource, where the one or more shared PUCCH resources are configured (e.g., via RRC) to the WTRU for such event-based beam reporting. The WTRU may (or may be configured to) transmit, via the PUCCH transmission, the reporting contents and one or more identifiers (e g., WTRU-ID, an RNTI, a scrambling ID / parameter, etc.) to identify the WTRU, e.g., because the one or more PUCCH resources may also be configured to other WTRU(s) so that a collision may happen among WTRUs. This example may provide benefits especially when a current timing advance (TA) is desired to be maintained, e.g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

[0296] In another example, the 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 2-step transmission procedure (e.g., PRACH transmission and associated one or more PUSCH transmissions), where the PUSCH payload may deliver the reporting contents. This may provide benefits especially when a new timing advance (TA) is desired to be acquired, e g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

[0297] A WTRU may determine an event related to the beam quality measurement based on one or more of the solutions described in the previous paragraphs (e.g., threshold-level determination). Based on 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 requires a network action beforeentering beam (and / or radio link) failure. However, the WTRU may not have UL resources available when the event-based beam reporting is triggered.

[0298] In one example, the WTRU may perform an aperiodic transmission of the event-based beam reporting, e.g., a contention-based PUCCH transmission, or a PRACH+PUSCH transmission (e.g. 2-step UL transmission, 2-step RACH msgA). A WTRU may determine to perform this transmission if no UL resources (e g., CG or DG PUSCH, PUCCH) are scheduled / available for transmission within a number of slots from the time where the event was triggered.

[0299] A WTRU may receive a configuration for an 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 TCI states. The WTRU may determine to perform measurements based on the configured resource setting where the measurement may consist of one or more of L1-RSRP, L1-SINR, CQI, CRI, SSBRI. The WTRU may be configured with a measurement threshold where the WTRU may determine which event is triggered based on one or more of the measurements exceeding a threshold. The event-based beam reporting may include a configuration to indicate to the WTRU what to include in the beam report. The WTRU may include a flag to indicate that one of the measurements exceeded a threshold The WTRU may additionally include a value representing the difference between the measurement and the threshold (e.g., explicitly or quantized). The WTRU may include multiple flags where each flag identifies the measurement that exceeded the threshold (e g., its corresponding threshold of the one or more thresholds).

[0300] The WTRU may receive, as part of the event-based beam reporting configuration, a maximum duration in which the event-based beam reporting can be performed, e g., due to the need to report this information quickly (e.g., prior to beam failure detection / recovery initiation). The maximum duration may be defined starting from the time when one of the above triggering conditions is satisfied. The maximum duration may be configured as one of the following: an offset (e.g., number of slots, frames etc.) from a triggering condition being satisfied; or a (max-)timer configured to start when the triggering condition is satisfied. The WTRU may transmit the WTRU-driven event-based report (e.g., the beam information and / or beam quality information) prior to time period expiration expiry. When the time period expires, the WTRU may reset the timer and determines to find another best beam(s), regardless of the currently identified reported 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 a lowest CORESET, with a CORESET index (e.g., 0), or coresetPool Index).

[0301] The WTRU may determine that an event occurs, based on measuring a set of beam quality metrics on a set of RSs configured with the event-based beam reporting, and a function to determine the event by comparing the set of beam quality metrics with one or more thresholds, e.g., based on Layer-1 / 2 event measurement.

[0302] The WTRU may determine one or more reporting contents based on the event, where the reporting contents may comprise one or more RSs of the set of RSs and corresponding one or more beam quality metrics.

[0303] Multiple events may be configured with different threshold levels, and associated maximum duration per threshold. For example, a longer maximum duration may be configured if a first threshold is exceeded, and a shorter maximum duration may be configured if a second threshold is exceeded.

[0304] Upon satisfaction of a triggering event, the WTRU may determine whether the next available UL transmission occasion (e.g., PUSCH, PUCCH, etc.) falls within the maximum duration (e.g., based on the maxtimer) for the event-based beam reporting. Based on the determination, the WTRU may selectively perform either (1) scheduled UL channel based WTRU-driven reporting or (2) aperiodic transmission based WTRU- driven reporting.

[0305] Scheduled (e.g., contention-based) UL channel based WTRU-driven reporting may be used. For example, if the WTRU determines that the next available UL transmission occasion (PUCCH, PUSCH, CG or DG) is within the maximum duration, the WTRU may perform the event-based beam reporting using the next available UL transmission occasion.

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

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

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

[0309] The WTRU may include the one or more reporting contents into a MAC CE multiplexed in the PUSCH (e.g., PHR-like). The WTRU may generate the MAC-CE which includes the type of event triggered and associated measurement The WTRU may include the SRS resource set index or SRI to identify the panel or antenna group where the measurement was triggered.

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

[0311] In another example, the WTRU may include the event-based beam report by a (most-recent available) PUCCH resource for CSI reporting, e g., via adding a new part (e.g., Part 3 CSI) of CSI or beam reporting contents.

[0312] The Part 1 of the CSI may include a new bit that the WTRU may use to indicate if a Part 3 is sent. If the WTRU indicates a 1 in the new bit, the WTRU may include the event-based beam reporting content in a Part 3. Otherwise, the WTRU only sends Part 1 and Part 2.

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

[0314] In another example, the WTRU may be configured to replace the CSI part(s) and reuse the bit width (e g., allocated for Part 1 and / or Part 2 CSI) for the WTRU-driven reporting, e g., with zero-padding bit(s) inserted to match the bit width, where a N-bit flag (e.g., N=1 ) may be included for indicating the new reporting contents based on the 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.

[0315] On a condition that the WTRU determines that the PUCCH resource for CSI reporting includes HARQ-ACK transmission (e.g , when the HARQ-ACK transmission is piggybacked on the CSI reporting), the WTRU may (be configured to) drop the CSI part and reuse the dropped part for the WTRU-driven reporting, where the (piggybacked) HARQ-ACK transmission is not dropped and concatenated with the reporting contents for the WTRU-driven reporting. Example priority rules may include the following examples:

[0316] (i) If the WTRU determines to report a HARQ-ACK in a PUCCH, then the WTRU cannot drop it to reuse for the event-based beam reporting;

[0317] (ii) If the WTRU determines to report a HARQ-ACK + CSI PUCCH, then the WTRU drop the CSI part and reuses the resources for the event-based beam reporting;

[0318] (iii) If the WTRU determines to report a CSI PUCCH, then the WTRU replaces the CSI part and reuses the resource for the event-based beam reporting, where the WTRU indicates a (e.g., 1 -bit) flag to signal that the contents are for event-based beam reporting; and / or

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

[0320] Aperiodic (e g, contention-based) transmission based WTRU-driven reporting may be used. If the next available UL transmission occasion does not fall within the maximum duration, the WTRU may perform an aperiodic transmission method of the event-based beam reporting on an UL resource

[0321] In one example, the WTRU may, or may be configured to, perform a (contention-based) PUCCH transmission, where the one or more PUCCH resources are pre-configured to the WTRU for such event-based beam reporting. PUCCH resources may be configured with a periodicity such that the WTRU may use them whenever the event-based beam report is triggered. The resource may be WTRU-specifically configured. Alternatively, to avoid excessive overhead, the PUCCH resources may be shared by multiple users (e.g, non- orthogonal-multiple-access (NOMA)-like procedure where each user has a signature code / identity and thereceiver performs an MMSE-SIC type decoding), and each WTRU may scramble the PUCCH transmission with a WTRU-specific identifier (e.g., WTRU-ID, an RNTI, a scrambling ID / parameter, etc ) to identify the WTRU This may provide benefits especially when a current timing advance (TA) is desired to be maintaining, e.g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

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

[0323] The WTRU may receive a configuration of a RACH occasion where the preamble locations are determined in time and frequency, and a configuration of a PUSCH resource occasion where a set of RBs is linked to each preamble. The RBs provide resources for loading the PUSCH payload. The WTRU may reuse PUSCH occasions configured for a legacy 2-step RACH procedure, or alternatively be configured with specific PUSCH occasions reserved for event-based beam report. The preamble occasion may also be reused from legacy, or partitioned into a separate set of preambles reserved for the event-based beam report. This may provide benefits especially when a new timing advance (TA) is desired to acquired, e g., which may be determined by the WTRU or informed (e.g., configured) by the gNB.

[0324] In another example, a WTRU may be configured with SRS transmission occasions where the WTRU may autonomously trigger an SRS with an implicit flag (e.g., via a sequence-based pre-defined signature / parameter). The SRS transmission occasions may be configured with an associated PUSCH resource occasion, where a procedure from the SRS and the PUSCH may be defined or configured (e.g., SR- like). For example, the WTRU may transmit the SRS and the network may determine that the WTRU is requesting a resource for an event-based beam report. The network may schedule a PUSCH resource within a configured maximum duration calculated based on the SRS transmission occasion.

[0325] Opportunistic WTRU-driven beam reporting based on confirmation mechanisms may be used. In one example, a WTRU may receive configuration(s) of available occasions and / or resources for WTRU-driven (e g., DL) beam reporting, and determine to transmit (e.g , before BFR) the reporting on one or more of the occasions based on a function to declare an event for the reporting. After the reporting (e.g., single- or multishot), the WTRU may monitor to receive a confirmation (CF) signal (e.g., CF-field) from a gNB within a time window for stopping retransmission. If not, the WTRU may retransmit the reporting. The confirmation signal may also comprise and / or indicate an updated configuration(s) for next available occasions and / or resources.

[0326] A WTRU may receive configuration information for opportunistic WTRU-driven beam reporting.

[0327] The configuration information may include time-domain parameter(s) on when the WTRU may transmit if an event occurs, e.g., periodicity, or irregular pattern in slot / symbol within a time window (e.g, within 10ms), which may be interpreted as “available occasions” for the opportunistic WTRU-driven reporting. Theseavailable occasions may be collided among WTRUs (or not collided based on gNB configuration, e.g., different scrambling ID for PUSCH among different WTRUs, scrambled by cell-1 D and / or WTRU-ID, etc.).

[0328] The configuration information may include a number (M) of multi-shot transmissions of a WTRU- driven beam reporting: If M= 1 , a single Tx of the reporting If M>1 , multi-shot Tx of the reporting repeatedly in a row across available time instances (e.g., inter-slot, intra-slot as symbol-set-level) based on the time-domain parameter(s). This case allows for increasing opportunities of successful Rx at gNB. Some associated parameters across the multi-shot Tx, e.g , configuration(s) of spatial-domain cycling, sequence-domain scrambling / pattern, resource-domain hopping, etc. may provide increased diversity of such transmission.

[0329] The configuration information may include frequency-domain parameter(s) on which frequency resource (RB(s)) the WTRU can transmit in a given time, e.g., a semi-statically fixed frequency resource, or based on a frequency hopping pattern, or an irregular pattern in frequency domain generated by a function with respect to other parameter(s) such as WTRU-ID, C-RNTI, slot / symbol index, etc.

[0330] The configuration information may include parameters related to confirmation expiry time offset (e.g., set to 7ms, / slots, or# of symbols). For example, the WTRU may monitor a confirmation signal during this time window after transmitting a WTRU-driven beam reporting. If a confirmation signal is not received, the WTRU may re-transmit the WTRU-driven beam reporting.

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

[0332] 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.

[0333] The WTRU may determine (e.g., at time T 1) that an event occurs, based on measuring a set of beam quality metrics of a set of RSs and a function to determine the event by comparing the set of beam quality metrics with one or more thresholds, , e.g., based on Layer-1 / 2 event measurement.

[0334] The WTRU may determine one or more reporting contents based on the event, where the reporting contents may comprise one or more RSs of the set of RSs and corresponding one or more beam quality metrics.

[0335] The WTRU may determine earliest possible time occasion(s) after T 1 , based on M, for transmitting the WTRU-driven beam reporting via a UL channel (e.g., PUSCH, PUCCH, etc.), where the UL channel may include a value of a CF-field to be used as a token for confirmation (e.g., if the explicit confirmation method is configured) For example, the WTRU may be configured to determine the value based on a function (e.g., increasing 1 after transmitting a WTRU-driven beam reporting and applying modular of 4, then a value of the CF-field is 0, 1 , 2, or 3) If M>1, the WTRU transmits using the PUSCH M-times in a row.

[0336] The WTRU may also use an implicit confirmation. For example, the WTRU may determine that the transmission via the UL channel is successfully received at the gNB on condition that the WTRU receives atleast one of the following DL signal or channel within a time window determined based on the UL channel transmission timing and the (configured) confirmation expiry time offset.

[0337] In one example, the WTRU may determine it is confirmed if the WTRU receives a DL signal or channel (e.g., a DCI and / or a PDSCH) indicating a (UTCI) beam change within the time window.

[0338] In another example, the WTRU may determine the (UTCI) beam change is indicated within activated UTCIs if the transmission via the UL channel contains the reporting contents determined based on Eventl .

[0339] In another example, the WTRU may determine it is confirmed if the WTRU receives a DCI and / or MAC-CE, indicating a new TCI activation command (that updates a new set of activated UTCIs mapped to a TCI field of a DL-DCI) within the time window. The WTRU may determine that the reception if the DCI and / or MAC-CE is a confirmation from the gNB when the WTRU-driven reporting was based on Event2 (reporting non-activated UTCI(s)).

[0340] In another example, the WTRU may determine it is confirmed if the WTRU receives a UL grant indicating a new UL (e.g., PUSCH) transmission (e.g., no re-transmission, based on indicating a new-data- indicator(NDI) field being toggled) within the time window. For example, the WTRU may determine this is the confirmation from the gNB when the WTRU-driven reporting was based on Event3 (reporting based on beam prediction).

[0341] If the WTRU did not receive the implicit confirmation signal within the time window, the WTRU may determine the confirmation is not given. Based on the determination, the WTRU may find a new (UTCI) beam, based on resetting the WTRU-driven reporting process, and transmit a second WTRU-driven reporting via a UL channel based on determining an earliest possible time occasion(s) after the determination.

[0342] A WTRU may also or alternatively receive an explicit confirmation. For example, the WTRU may monitor a reception of the CF-field as a confirmation of the WTRU-driven beam reporting during a time window based on the confirmation expiry time offset.

[0343] On a condition that the CF-field with the same value as what the WTRU transmitted via the PUSCH is received, the WTRU may determine not to retransmit the reporting (and increases 1 of the CF-field value and applies modular of 4) For example, right after the time window (and plus an Offset parameter) passed, the WTRU may update the reported beam, unless something else is received from the gNB. The Offset parameter may be associated with (e.g., depending on) the reception time of the confirmation signal (e.g., CF-field).

[0344] FIG. 3 illustrates an example of successful reception of the confirmation signal. In this example, an event is detected by the WTRU 301, triggering a WTRU-driven beam reporting 302. A confirmation signal 303 is then received within the WTRU monitoring time window 304.

[0345] On a condition that the CF-field is not received and / or the CF-field is received with a different value as what the WTRU transmitted via the PUSCH until the expiry (T2) of the confirmation expiry time offset, the WTRU may retransmit the reporting on second earliest possible occasion(s) after T2, based on M.

[0346] FIG. 4 illustrates an example where the confirmation signal is not received within the WTRU monitoring time window. In this example, a retransmission of the WTRU-driven beam report is triggered 401

[0347] The WTRU may receive another feedback from gNB. In an example, the WTRU may receive the confirmation signal (e.g., the CF-field) which (also) updates at least one parameter of the time-domain parameter(s), frequency-domain parameter(s), confirmation expiry time offset, OF signal format, and measurement related parameter(s).

[0348] In an example, the updated configuration (contents) may be received via the MAC-CE of a PDSCH.

[0349] In an example, the updated configuration (contents) may be received via a DCI scrambled by the CF-RNTI (e.g., the DCI may be dedicated to one TRP, e.g., via a CORESETpoollD, etc.)

[0350] In an example, the updated configuration (contents) may be received via a PDSCH scheduled by a DCI scrambled by the CF-RNTI.

[0351] In response to receiving the updated configuration, the WTRU may apply the updated configuration for next WTRU-driven beam reporting procedures.

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

[0353] For example, a WTRU may be configured with one or more set of candidate beams that may be indicated as a list of indices referring to a reference signals, TCI states, etc. In this case, a first set of candidate beams that may be used for measurement and reporting, and, a second set of candidate beams that may be used, for measurement, report and beam-switching. Alternatively, or in addition to these, a WTRU may be configured with other measurement configurations, including at least measurement time / frequency opportunities, measurement quantities, etc.

[0354] A WTRU may be configured with one or more sets of thresholds and triggering conditions for at least one of measurement, report and beam-switch, including at least one of: a signal quality metric, e.g., RSRP, SINR, rank, Error-Vector-Magnitude(EVM), etc.; a performance quality metric associated to a transmission, e.g., BLER, etc.; and a consistency metric, e.g., a statistical (reliability) measure, time-consistency of the failure, etc.

[0355] A WTRU may be configured with one or more set of uplink resources for at least one of reporting of a measurement or state of a beam.

[0356] A WTRU may be configured with a value for a time window, counter, etc.

[0357] A WTRU may also be configured with an indication whether the WTRU is allowed to switch beam without gNB confirmation.

[0358] FIG. 5 illustrates an example of a configuration of beams for WTRU-based beam switching.

[0359] In this example, the WTRU may be configured with a first set of downlink beams for measurement and reporting 501 , e.g., downlink reference signals Upon the reporting, the WTRU may be indicated or configured with a second set of the beams 502, wherein the second set of beams may be a subset of the firstconfigured beams. The second set of the beams may represent a set of beams that the WTRU may be allowed to switch to / from without any or much interaction with gNB

[0360] A WTRU may be configured or indicated with a beam as the originally configured or active beam. Further, a WTRU may be configured with one or more of additional set of beams for measurement. Using the configured resources and opportunities, a WTRU may be configured to perform a periodic, or dynamically indicated to perform an aperiodic or other non-periodic measurements. In one example, when the WTRU determines that a configured measurement on the originally configured beam does not meet the configured threshold, the WTRU may identify a new beam as a potential replacement of the originally configured beam.

[0361] FIG. 6 illustrates an example where the WTRU may autonomously switch to a newly identified beam.

[0362] Once the WTRU identifies a new beam 601 as a potential replacement of the originally configured beam, the WTRU may report at least the new beam and its quality, and the WTRU may transit 602 to the newly identified beam by updating the associated reference signals and TCI states.

[0363] Using configured uplink resources, in one example, a WTRU may also report its transition to the new beam(s) 603 through an explicit or an implicit indication. The report may also include the measurements related to the original and newly identified beam(s). In one example, after the reporting of the transition, the WTRU may monitor PDCCH during a configured time window 604 to receive a confirmation 605 from gNB. If the WTRU receives the confirmation 605 within the configured window 604, it may (determine to) stay with the newly identified beam, otherwise it may perform transition back to the original beam. Alternatively, if the WTRU does not receive a rejection or a denying command to reverse to the originally configured beam within a configured window measured with respect to a time reference, e.g., its UL report, it may (determine to) stay with the newly identified beam.

[0364] FIG. 7 illustrates an example where the WTRU may switch to a newly identified beam upon receiving an indication from the network.

[0365] In this example, the WTRU may identify a new beam 701 as a potential replacement of the originally configured beam, the WTRU may report at least the new beam and its quality, and the WTRU may transit to the newly identified beam(s) by updating of the associated reference signals and TCI states only after reception of a particular indication from the network, e g., gNB. The indication may be a signal, e.g., a DCI, an UL grant 702. The reception of the indication 702 may be interpreted as a validation of the quality of the newly identified beam(s).

[0366] The WTRU may transit to the newly identified beam(s) after a configured window 703 measured with respect to a time reference, e.g., an UL grant. The WTRU may use the UL grant to include the report indicating its transition to the newly identified beam 704. In one example, the reporting may also include the measurements related to the original and newly identified beam. The WTRU may receive a confirmation to stay in the new beam 705.

[0367] FIG. 8 illustrates an example where the WTRU may report, to the network, its intention to switch to a newly identified beam.

[0368] The WTRU may identify a new beam 801 as a potential replacement of the originally configured beam, the WTRU may first report the new beam 802 and indicate its intention to transit to the new beam. The report may include measurements related to the original beam and the newly identified beam. Once the WTRU receives a confirmation 803, the WTRU may transit to the newly identified beam within a configured time window 804. The time window may be defined from a given time reference, e.g., the reception of the confirmation message.

[0369] As described in previous paragraphs, a WTRU may receive a configuration for periodic beam reporting. In order to reduce resource usage, the reporting occasions may be (configured as being) sparse (i.e., configured with large periodicities). If these reporting occasions are shared between different WTRUs, this may result in collisions, which may further delay the time needed to successfully report the beam measurements.

[0370] Due to the need to report this information quickly (e g., prior to beam failure detection / recovery initiation), the WTRU may be configured with a maximum time interval in which the transmission must be performed. In some cases, the maximum time interval may be an offset (e.g., number of slots, frames etc.) from a triggering condition being satisfied. The maximum time interval may be represented by a timer value, where the WTRU must transmit the beam information prior to timer expiry.

[0371] Upon satisfaction of a triggering event, the WTRU may determine whether the next periodic transmission occasion (or next X period occasions to, e.g., support retransmissions in the case of collision) falls within the maximum time interval for transmission.

[0372] If the next transmission duration (or next X durations) exceeds the maximum time interval requirement, the WTRU may perform an aperiodic transmission method, such as one or more of the following: the WTRU may perform RACH; the WTRU may trigger 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 transmission of beam reporting). The WTRU may trigger an Layer3(L3) measurement report and include the beam reporting.

[0373] In one example, a WTRU may be configured with multiple configurations of available resources, e.g., one dense configuration and one sparse configuration. The WTRU may determine which configuration to use. This determination may depend on different conditions and / or criteria, e.g., with multiple thresholds.

[0374] For example, a WTRU in a poor channel condition may need to quickly and / or frequently report the beam measurements, in which case a dense configuration would be suitable.

[0375] For example, a WTRU in a good condition will likely rarely trigger a beam report, in which case the WTRU may be configured with a sparse beam reporting configuration (e.g., to avoid interruption to other transmissions / receptions the WTRU may perform)

[0376] Configuring multiple (e.g., all) WTRUs with a dense configuration would be less suitable as it would require dimensioning large resources to avoid frequent collisions, e.g., in a cell. However, distributing WTRUs between sparse and dense configurations (e.g , based on likelihood / need of reporting) may optimize the transmission opportunities and reduce collision risk.

[0377] In another example a WTRU may be configured with multiple periodic beam reporting configurations, with different characteristics, such as different periodicities (i.e., dense or sparse), large or fewer resources during the transmission occasion.

[0378] 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, reception of a DCI / RRC signaling, or (de)activation of a configuration Event based may include a WTRU being provided with multiple reporting thresholds. One may trigger a report, and another may triggers a switch to a different (e g., denser) configuration. If an L3 event is triggered, the WTRU may switch beam based reporting conditions.

[0379] If a WTRU switches to a denser configuration, it may be only for a certain time to avoid using the resources unnecessarily (e.g., after channel conditions have improved or measures taken by the network to solve the issue) The WTRU may revert back to a sparse configuration. For example the WTRU may revert back to a sparse configuration upon successful transmission of the beam measurement report. Or the WTRU may revert back upon expiry of a time period (the duration may be configured, and started upon reverting the dense configuration. At expiry of the timer the WTRU may revert back to the sparse configuration).

[0380] FIG. 9 illustrates an example of a WTRU initiated beam reporting procedure.The WTRU may receive, from a network, an indication 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 comprises a parameter M and threshold T 901. The WTRU may determine a candidate TCI state from the plurality of TCI states and a quality of the candidate TCI state 902. On a condition that the quality of the candidate TCI state is greater than a quality of at least M active TCI states by the threshold T, the WTRU may send a WTRU initiated beam report 903.

[0381] FIG. 10 illustrates an example of a WTRU initiated beam reporting procedure based on maximum time interval requirement.

[0382] The WTRU may receive, from a network, configuration information for a WTRU initiated beam reporting event, wherein the configuration information comprises a maximum time interval for transmitting the WTRU initiated beam report 1001. The WTRU may detect that the WTRU initiated beam reporting event has occurred 1002. The WTRU may determine a time value for a next available uplink transmission occasion 1003. The WTRU may perform an aperiodic transmission of the WTRU initiated beam report based upon a determination that the time value for the next available uplink transmission occasion is later than the maximum time interval for transmitting the WTRU initiated beam report 1004.

[0383] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wirelessconnections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. 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 from the plurality of TCI states and a quality of the candidate TCI state; and on a condition that the quality of the candidate TCI state is greater than a quality of at least M active TCI states by the threshold T, sending a WTRU initiated beam report.

2. The method of claim 1 , wherein the quality of a TCI state is based on at least a measured reference signal received power (RSRP) of a set of reference signals (RSs) using the TCI state.

3. The method of claims 1 or 2, wherein the candidate TCI state is configured in the WTRU by the network using a downlink control information (DCI).

4. The method of claims 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).

5. The method of claims 1 or 2, wherein the candidate TCI state is configured in the WTRU by the network using a radio resource control (RRC) message.

6. The method of any one of claims 1 to 5, wherein the WTRU initiated beam report comprises information on the candidate TCI state.

7. The method of any one of claims 1 to 6, further comprising: receiving, from the network, an indication to activate the candidate TCI state.

8. The method of any one of claims 1 to 6, further comprising: autonomously activating the candidate TCI state.

9. A wireless transmit and receive unit (WTRU), the 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 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; 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, on a condition that the quality of the candidate TCI state is greater than a quality of at least M active TCI states by the threshold T, send a WTRU initiated beam report.

10. The WTRU of claim 9, wherein the quality of a TCI state is based on at least a measured reference signal received power (RSRP) of a set of reference signals (RSs) using the TCI state.

11. The WTRU of claims 9 or 10, wherein the candidate TCI state is configured in the WTRU by the network using a downlink control information (DCI).

12. The WTRU of claims 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).

13. The method of claims 9 or 10, wherein the candidate TCI state is configured in the WTRU by the network using a radio resource control (RRC) message.

14. The WTRU of any one of claims 9 to 13, wherein the WTRU initiated beam report comprises information on the candidate TCI state.

15. The WTRU of any one of claims 9 to 14, wherein: the at least one processor and the transceiver are further configured to receive, from the network, an indication to activate the candidate TCI state.

16. The WTRU of any one of claims 9 to 15, wherein: the at least one processor and the transceiver are further configured to autonomously activate the candidate TCI state

Images