Method for service-based bfr enhancement in ai / ml systems

Abstract

A wireless transmit / receive unit (WTRU) can determine an occlusion of a first beam and / or a duration associated with the occlusion of the first beam. The WTRU can defer beam failure detection (BFD) or beam failure recovery (BFR) when an amount of data is less than a first threshold, a priority of the data is less than a second threshold, and / or the duration associated with the determined occlusion of the first beam is shorter than a third threshold. The WTRU can transmit a report including the determined occlusion, the duration associated with the determined occlusion, the amount of data associated with the first beam, the priority of the data associated with the first beam, an indication that the BFD or BFR is deferred, and / or an indication that a second beam has been selected.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 566,436, filed March 18, 2024, the entire contents of which are incorporated herein by reference. Background Technology

[0002] In Radio Access Network (RAN) #102, an agreement was reached on RAN work projects concerning Artificial Intelligence (AI) / Machine Learning (ML) for the New Radio (NR) air interface. Beam management was selected as one of the target use cases for AI / ML in the air interface. This technology may be fundamental to improving performance and / or complexity in conventional beam management. These aspects may include beam prediction in the time and / or spatial domains for reduced overhead and / or latency, and / or improved beam selection accuracy, etc. Summary of the Invention

[0003] The Wireless Transmit / Receive Unit (WTRU) can determine the congestion of a first beam and / or the duration associated with the congestion of the first beam. When the amount of data associated with the first beam is less than a first threshold, the priority of the data associated with the first beam is less than a second threshold, and / or the duration associated with the determined congestion of the first beam is less than a third threshold, the WTRU can determine to delay beam failure detection (BFD) or beam failure recovery (BFR). The WTRU can send a first report to the network, which includes one or more of the following: an indication of the determined congestion, an indication of the duration associated with the determined congestion of the first beam, an indication of the amount of data associated with the first beam, the priority of the data associated with the first beam, an indication that BFD or BFR has been delayed, and / or an indication that a second beam has been selected.

[0004] The WTRU can determine the congestion of the first beam using artificial intelligence or machine learning (AI / ML) models. The WTRU can then use AI / ML models to determine if the congestion persists after the duration expires. Based on this determination, the WTRU can execute a BFR (Blocking Freefall).

[0005] The WTRU can determine that the blockage does not exist after the duration expires. Based on this determination, the WTRU can send a second report to the network. This second report may include an indication that the blockage does not exist. The WTRU can select a second beam based on the determination that the second beam has beam measurements and / or predicted values ​​greater than those of the first beam.

[0006] The first report may include one or more of the start time or end time of the duration. The WTRU can determine the amount of data associated with the first beam prior to the start time of the blockade. The WTRU can receive instructions from the network. These instructions may include confirmation or rejection of delaying BFD and / or BFR. The WTRU can receive instructions from the network for the delay period. The delay period instructions may be based on instructions including confirmation of delaying BFD and / or BFR. The delay period may indicate how long to delay BFD and / or BFR. The WTRU can perform BFR based on instructions from the network including rejection of delaying BFD and / or BFR. Attached Figure Description

[0007] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0008] Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0009] Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown.

[0010] Figure 1D It is shown that, according to the embodiment, it is possible to Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0011] Figure 2 This is a diagram illustrating an example of a user equipment (UE) in a mobile state experiencing congestion.

[0012] Figure 3 An example of a transmission that skips a subset of the SSB is described.

[0013] Figure 4 The scenario described is that beam #1 is temporarily blocked and the WTRU is moving toward the center of beam #1.

[0014] Figure 5 The scenario described is that beam #1 is temporarily blocked and the UE is moving toward the center of beam #2. Detailed Implementation

[0015] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access this content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0016] like Figure 1A As shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs. Furthermore, any descriptions herein that refer to UEs may equally apply to WTRUs (and vice versa). For example, the WTRU can be configured to execute any procedure or process described herein that is performed by the UE (and vice versa).

[0017] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, eNodeBs, home node Bs, home eNodeBs, gNBs, NRNodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each described as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0018] Base station 114a may be part of RAN 104 / 113, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, 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 a desired spatial direction.

[0019] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0021] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

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

[0024] In other embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0025] For example, Figure 1A Base station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, it is not required that base station 114b access Internet 110 via CN 106 / 115.

[0026] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0029] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0030] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While processor 118 and transceiver 120 are described as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0032] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0033] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

[0036] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0037] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

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

[0039] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0040] RAN 104 may include eNode-B 160a, 160b, 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-B 160a, 160b, 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-B 160a, 160b, 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

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

[0043] The MME 162 can connect to each eNode-B 162a, 162b, 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0044] The SGW 164 can connect to each eNode B 160a, 160b, or 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, or 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover; triggering paging when DL data is available for WTRUs 102a, 102b, or 102c; and managing and storing the context of WTRUs 102a, 102b, or 102c.

[0045] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0046] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0047] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0049] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or peer into a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP via it. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peering traffic. Peering traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0050] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of a fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0051] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0052] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration described above can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0053] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain very long battery life).

[0054] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one of the STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example due to STAs (only supporting the 1MHz operating mode) sending to the AP, the entire available band can be considered busy, even if most of the band remains idle and may be available.

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

[0056] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0057] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0058] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0059] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0060] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0061] Figure 1DThe CN 115 shown 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. Although each of the foregoing elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0062] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases (e.g., services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc.). AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi.

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

[0064] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0065] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0066] Given Figure 1A-1D as well as Figure 1A-1D As described in the corresponding descriptions herein, one or all of the functions described for one or more of the 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, SMF183a-b, DN 185a-b, and / or any other device described herein (one or more) may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0067] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing and / or testing purposes that can be performed using over-the-air wireless communication.

[0068] One or more emulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios outside of deployment (e.g., testing) wired and / or wireless communication networks and / or test laboratories to implement testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0069] In this document, "one" and "a" and similar phrases are interpreted as "one or more" and "at least one". Similarly, any term ending with the suffix "(s)" will be interpreted as "one or more" and "at least one". The term "may" should be interpreted as "for example, may". The symbol " / " (e.g., a forward slash) may be used in this document to mean "and / or", where, for example, "A / B" may imply "A and / or B". In this document, the terms prediction and estimation are used interchangeably, but remain consistent with the present invention. In this document, the terms candidate cell, neighboring cell, and target cell are used interchangeably, but remain consistent with the present invention. In this document, the terms source cell, current cell, and serving cell are used interchangeably, but remain consistent with the present invention. In this document, the terms LTM command, LTM cell handover, LTM cell handover command, and cell handover command are used interchangeably, but remain consistent with the present invention.

[0070] Artificial intelligence (AI) can be broadly defined as the behavior exhibited by machines. This behavior can, for example, mimic cognitive functions to sense, reason, adapt, and / or act.

[0071] Machine learning (ML) can refer to a type of algorithm that solves problems based on learning from experience (e.g., data) without explicit programming (e.g., configuring a set of rules). ML can be considered a subset of AI. Different ML paradigms can be envisioned based on the nature of the data or feedback available for learning the algorithm. For example, supervised learning methods may involve learning a function that maps inputs to outputs based on labeled training examples. Each training example can be a pair consisting of an input and / or a corresponding output. Unsupervised learning methods, for example, may involve detecting patterns in data without pre-existing labels. Reinforcement learning methods may involve performing sequences of actions in an environment to maximize cumulative rewards.

[0072] Combinations and / or interpolation of the above methods can be applied to machine learning algorithms. Semi-supervised learning methods can use a combination of a small amount of labeled data and a large amount of unlabeled data during training. Semi-supervised learning can be considered between unsupervised learning (training data without labels) and supervised learning (training data with only labels).

[0073] Deep learning refers to a class of machine learning algorithms that employ loosely inspired artificial neural networks derived from biological systems. Deep neural networks (DNNs) are a special type of machine learning model inspired by the functions of the human brain. In a DNN, the input can be linearly transformed and / or passed multiple times through a non-linear activation function. DNNs typically consist of multiple layers, each composed of linear transformations and / or a given non-linear activation function. DNNs can be trained using training data via the backpropagation algorithm. Recently, DNNs have demonstrated state-of-the-art performance in various fields, such as speech, vision, natural language processing, and / or various supervised, unsupervised, and / or semi-supervised machine learning settings. The term AI / ML-based methods and / or processes can refer to achieving behaviors and / or conformities through data-driven learning without requiring an explicit configuration of the sequence of action steps. These methods enable the learning of complex behaviors that might be difficult to specify and / or achieve using conventional methods.

[0074] In this paper, an AI / ML model can be referred to as an implementation of an AI / ML-based method consisting of model parameters and / or model structure. For example, a DNN-based AI / ML model may include model parameters (e.g., weights and / or biases) and / or model structure, such as the type and / or size of each layer of the DNN (e.g., dense layers and / or convolutional layers, etc.).

[0075] User equipment (UE), also known as a radio transceiver unit (WTRU), can transmit and / or receive physical channels and / or reference signals (RS) based on at least one spatial domain filter. The term "beam" can refer to a spatial domain filter. The WTRU can transmit physical channels and / or signals using the same spatial domain filter used for receiving reference signals (RS) (e.g., Channel State Information RS (CSI-RS)) or synchronization signal (SSB) blocks. The WTRU transmission can be referred to as the "target," and / or the received RS and / or SSB can be referred to as the "reference" and / or "source." In this context, it can be said that the WTRU transmits the target physical channel and / or signal based on the spatial relationship of such RS and / or SSB.

[0076] The WTRU can transmit the first physical channel and / or signal using the same spatial domain filter as the spatial domain filter used to transmit the second physical channel and / or signal. The first and second transmissions can be referred to as the "target" and the "reference" (or "source"), respectively. In this case, it can be said that the WTRU transmits the first (target) physical channel and / or signal based on the spatial relationship of the reference second (reference) physical channel and / or signal.

[0077] Spatial relationships can be implicit, configured by Radio Resource Control (RRC) and / or signaled by Media Access Control (MAC) Control Elements (CE) or Downlink Control Information (DCI). For example, a WTRU can implicitly transmit the Physical Uplink Shared Channel (PUSCH) and / or the DM-RS of the PUSCH based on the same spatial domain filter as the SRS indicated by the SRI configured by RRC and / or indicated in the DCI. RRC can configure spatial relationships for the SRS Resource Indicator (SRI) or signaled by the MAC CE for the Physical Uplink Control Channel (PUCCH). This spatial relationship can also be referred to as "beam indication".

[0078] The WTRU can receive the first downlink channel and / or signal (e.g., target) based on the same spatial domain filters or spatial reception parameters as the second downlink channel and / or signal (e.g., reference). For example, this association can exist between physical channels such as the Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH) and / or their corresponding DM-RS. This association may exist at least when the first and second signals are reference signals, and when the WTRU is configured with Quasi-Cooperative Positioning (QCL) assumption type D between the corresponding antenna ports. This association can be configured as a Transmission Configuration Indicator (TCI) state. The WTRU can indicate the association between the CSI-RS or SSB and the DM-RS by an index of a set of TCI states configured by RRC and / or by MAC CE signaling. This indication can also be referred to as "beam indication".

[0079] In this document, beam resources may include TCI status, CSI-RS, DL RS, SSB for DL, SRS resources, UL RS, and / or TCI status for UL. Beam resources can be identified by beam indication.

[0080] A WTRU may use, receive, and / or configure one or more sets of reference signals with per-bandwidth portions (BWP) for monitoring and / or detecting beam failures. For example, the term q0 may be used for a beam failure detection set. In another example, terms q0,0 and / or q0,1 may be used as a beam failure detection set. A beam failure detection set (e.g., sets q0, q0,0, and / or q0,1) may include one or more RSs, where RSs may be CSI-RS resource configuration indices and / or SSB and / or Physical Broadcast Channel (PBCH) block indices. The RSs included in the beam failure detection RS set may be the same as those configured, used, and / or received for Radio Link Monitoring (RLM).

[0081] If no beam failure detection RS set (e.g., set q0, q0,0, or q0,1) is provided and / or configured for the WTRU, the WTRU can determine the appropriate RS set. For example, the WTRU can determine the RS signals to be included in the beam failure detection RS set for the BWP based on a periodic CSI-RS resource configuration index. The WTRU can use these indices to monitor the PDCCH in the corresponding CORESET indicated by the TCI status.

[0082] The WTRU can measure reference signals included in the beam failure detection RS set and / or accordingly estimate radio link quality. The WTRU can use one or more thresholds and / or ranges to monitor and / or estimate radio link quality. For example, a desynchronization threshold (e.g., Q_out) and / or a synchronization threshold (e.g., Q_in) can be used to estimate the quality of the radio link and / or the corresponding beam. The terms Q_out and Q_in can be used to represent one or more attributes and parameters and their corresponding values.

[0083] The threshold Q_out can be used to determine the quality of radio links and / or beams where signal transmission may not be reliably received, corresponding to the out-of-synchronization block error rate (BLER_out). Alternatively, the threshold Q_in can be used to determine the quality of radio links and / or beams where signal transmission can be reliably received, corresponding to the synchronization block error rate (BLER_in). BLER_out and / or BLER_in can be explicitly determined by the gNB.

[0084] If the gNB does not explicitly determine BLER_out and / or BLER_in, they can be estimated based on one or more parameters. For example, the WTRU can use, receive, and / or configure PDCCH transmission parameters to perform asynchronous and / or synchronous assessments. Controlling the number of Orthogonal Frequency Division Multiplexing (OFDM) symbols, aggregation level, the ratio of assumed PDCCH resource element (RE) energy to average secondary synchronization signal (SSS) RE energy, the ratio of assumed PDCCH DMRS energy to average SSS RE energy, the number of physical resource blocks (PRBs) with BWPs, subcarrier spacing, etc., can be used to determine the BLER_out and / or BLER_in thresholds.

[0085] The PDCCH transmission parameters that may be included when evaluating the Q_out and Q_in thresholds are shown in Tables 1 and 2, respectively. These tables are non-limiting examples of parameters that may be included when evaluating the asynchronous and synchronous thresholds. One or more of these parameters may be included, such as values, the number of PRBs, and / or the selection of each parameter. Other values, the number of PRBs, and / or selections may be included.

[0086] Table 1: PDCCH transmission parameters used for asynchronous evaluation Table 1 property The value used for BLER configuration #0 DCI format 1-0 Control the number of OFDM symbols 2 Convergence Level (CCE) 8 The assumed ratio of PDCCH RE energy to the average SSS RE energy 4dB The assumed ratio of PDCCH DMRS energy to average SSS RE energy 4dB Bandwidth (PRB) 24 Subcarrier spacing (kHz) SCS of effective DL BWP DMRS pre-encoder granularity REG bundle size REG bundle size 6 CP length conventional Mapping from REG to CCE Distribution

[0087] Table 2: PDCCH transmission parameters used for synchronization evaluation Table 2 property The value used for BLER configuration #0 DCI payload size 1-0 Control the number of OFDM symbols 2 Convergence Level (CCE) 4 The assumed ratio of PDCCH RE energy to the average SSS RE energy 0dB The assumed ratio of PDCCH DMRS energy to average SSS RE energy 0dB Bandwidth (PRB) 24 Subcarrier spacing (kHz) SCS of effective DL BWP DMRS pre-encoder granularity REG bundle size REG bundle size 6 CP length conventional Mapping from REG to CCE Distribution

[0088] The WTRU can monitor the beam failure detection RS set within a valid BWP. The WTRU can further estimate beam and / or radio link quality and report desynchronization and / or synchronization states. The WTRU can measure the radio link quality (L1-RSRP) of the SSB and / or CSI-RS within the corresponding beam failure detection RS set. The WTRU can then compare the measurements to corresponding thresholds to determine, indicate, and / or detect whether a BFI has occurred.

[0089] The WTRU can indicate, determine, and / or configure one or more Beam Failure Detection (BFD) counters. Thus, the WTRU can detect beam failures by counting BFI indications. The WTRU can indicate, determine, and / or configure one or more of the following: BFI_Counter: A counter used to count the number of BFIs, initially set to 0 and incremented with each BFI detection; BFI_Max_Count: The maximum value of BFI_Counter that triggers beam failure detection; BFD_Timer: A timer that can start from the first BFI detection. If the timer expires before BFI_Counter reaches BFI_Max_Count, the beam failure detection process stops.

[0090] The parameters described above are non-limiting examples of parameters that can be included in beam failure detection. One or more of these parameters may be included, and / or other parameters may be included.

[0091] If a BFI count has occurred, the WTRU can start and / or restart the BFD_Timer and / or increment the BFI_Counter by 1. If the BFI_Counter reaches the BFI_Max_Count, the WTRU can initiate the Beam Failure Recovery (BFR) procedure. Optionally, if the BFD_Timer has expired and / or the BFI_Counter has not yet reached the BFI_Max_Count, the beam failure detection procedure can be considered to have completed successfully.

[0092] The WTRU can determine, indicate, and / or trigger beam failure recovery based on the beam failure detection process. The WTRU can indicate, determine, and / or configure one or more of the following: BFR_Timer: a timer that can be started with the BFR process; RSRP_Threshold: the RSRP threshold used in the BFR; candidateBeamRSList: a list of candidate beam reference signal indices to be monitored, measured, and / or selected during beam failure recovery; power ramp: parameters including the power ramp step size and / or the received preamble target power, etc.; and / or random access. PRACH parameters may include the preamble index, SSB for each RACH timing, random access response window, PRACH configuration index, random access timing, and / or SSB association mask index, etc.

[0093] The parameters described above are non-limiting examples of parameters that can be included in beam failure detection. One or more of these parameters may be included, and / or other parameters may be included.

[0094] The WTRU can use / receive / or configure one or more sets of reference signals for each BWP to monitor, measure, and select resources for beam failure recovery. For example, the term q1 can be used for a beam failure recovery set. In another example, the item q1,0 or q1,1 can be used as a beam failure recovery set. A beam failure recovery set (e.g., set q1, q1,0, or q1,1) can include one or more reference signals. Reference signals can be CSI-RS resource configuration indices and / or SS / PBCH block (SSB) indices. RSs included in the BFR-RS set can be based on a candidateBeamRSList configured as a part of the BFR process.

[0095] The WTRU can initiate a BFR based on a random access procedure. The WTRU can configure random access parameters, start the BFR_Timer, and apply power ramp parameters. The WTRU can monitor and / or measure one or more reference signals from the candidateBeamRSList. The WTRU can determine whether there is at least one SSB with an SS-RSRP above the corresponding RSRP_Threshold of the SSBs in the candidateBeamRSList, or whether there is at least one CSI-RS with a CSI-RSRP above the corresponding RSRP_Threshold of the CSI-RSs in the candidateBeamRSList. The WTRU can then select the appropriate reference signal as a candidate new beam and / or random access resource for the BFR procedure. For example, the term q_new can be used to denote a newly selected beam / random access resource. The WTRU can perform PRACH transmissions in the appropriate random access resource and / or according to the spatial relationship of the SS / PBCH blocks configured with or associated with the periodic CSI-RS resource and / or QCL-ified.

[0096] Alternatively, if uplink channel resources (e.g., uplink shared channel (UL-SCH)) are available, the WTRU can initiate a MAC-CE beam failure recovery procedure. Therefore, the WTRU can generate a BFR MAC-CE. The WTRU can then transmit on the appropriate UL channel resources.

[0097] The WTRU can identify, recognize, and / or configure one or more CORESETs corresponding to the random access procedure of the corresponding BFR. The WTRU can monitor the PDCCH in the search space set to detect DCI formats with corresponding Cyclic Redundancy Check (CRC) scrambled with Radio Network Identifiers (RNTIs), e.g., Cell (C)-RNTI and / or Modulation and Coding Scheme (MCS)-C-RNTI. The WTRU can determine antenna port quasi-co-location parameters that are identical to the antenna port quasi-co-location parameters associated with the index q_new for monitoring the PDCCH in the search space set and / or receiving the corresponding PDSCH.

[0098] If the BFR_Timer has expired and / or the beam failure recovery process has not been successfully completed, the WTRU can trigger link failure detection and follow the link failure recovery (LFR) process.

[0099] In this document, a TRP (e.g., a transmitting and receiving point) may be used interchangeably with one or more of a transmitting point (TP), a receiving point (RP), a radio remote head (RRH), a distributed antenna (DA), a base station (BS), a sector (e.g., a sector of a BS), and / or a cell (e.g., the geographic cell area served by a BS). In this document, multiple TRPs may be used interchangeably with one or more of multiple (M) TRPs, M-TRPs, and multiple TRPs.

[0100] The WTRU can report a subset of Channel State Information (CSI) components, which may correspond at least to the CSI-RS Resource Indicator (CRI), SSB Resource Indicator (SSBRI), indications of the panel received by the WTRU (e.g., panel identity or group identity), measurements such as L1-RSRP and L1-Signal-Noise Ratio (SINR) obtained from the SSB and / or CSI-RS (e.g., cri-RSRP, cri-SINR, ssb-Index-RSRP, ssb-Index-SINR), and other channel state information such as at least rank indicator (RI), channel quality indicator (CQI), precoding matrix indicator (PMI), and / or layer index (LI).

[0101] The WTRU can receive synchronization signal / physical broadcast channel (SS / PBCH) blocks. An SS / PBCH block (SSB) can include the primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH). The WTRU can monitor, receive, or attempt to decode SSBs during initial access, initial synchronization, radio link surveillance (RLM), cell search, and cell handover.

[0102] The WTRU can measure and report Channel State Information (CSI), wherein the CSI for each connection mode may include and / or be configured with one or more of the following: CSI reporting configuration. The CSI reporting configuration may include one or more of the following: CSI reporting quantity (e.g., Channel Quality Indicator (CQI), Rank Indicator (RI), Precoding Matrix Indicator (PMI), CSI-RS Resource Indicator (CRI), and / or Layer Indicator (LI), etc.); CSI reporting type (e.g., aperiodic, semi-persistent, and / or periodic); CSI reporting codebook configuration (e.g., Type I, Type II, and / or Type II port selection, etc.); and / or CSI reporting frequency.

[0103] Each connection mode's CSI may include and / or be configured with one or more of the following: CSI-RS resources, including one or more of the following CSI resource settings: Non-zero power (NZP)-CSI-RS resources for channel measurements; NZP-CSI-RS resources for interference measurements; and / or CSI-IM resources for interference measurements.

[0104] Each connection mode's CSI may include and / or be configured with one or more of the following: NZP CSI-RS resources, including one or more of the following: NZP CSI-RS resource ID; periodicity and / or offset; QCL information and / or TCI status; and / or resource mapping (e.g., number of ports, density, and / or CDM type, etc.).

[0105] The WTRU may indicate, identify, and / or configure one or more reference signals. The WTRU may monitor, receive, and / or measure one or more parameters based on the corresponding reference signals. The following parameters are non-limiting examples of parameters that may be included in the measurement of the reference signals. One or more of these parameters may be included, and / or other parameters may be included.

[0106] Parameters may include SS-RSRP. SS reference signal received power (SS-RSRP) can be measured based on a synchronization signal (e.g., DM-RS in SSS or PBCH). SS reference signal received power can be defined as a linear average of the power contribution of the RE carrying the corresponding synchronization signal. Power scaling of the reference signal may be necessary when measuring RSRP. In the case of SS-RSRP used for L1-RSRP, the measurement can also be performed based on a CSI reference signal in addition to the synchronization signal.

[0107] Parameters may include CSI-RSRP. CSI-RSRP can be measured based on a linear average of the power contribution of the RE carrying the corresponding CSI-RS. CSI-RSRP measurement can be configured within the measurement resources used for the configured CSI-RS timing.

[0108] Parameters may include SS-SINR. SS signal-to-interference-plus-noise ratio (SS-SINR) can be measured based on the synchronization signal (e.g., DMRS in SSS and / or PBCH). SS-SINR can be defined as the linear average of the power contribution of the RE carrying the corresponding synchronization signal divided by the linear average of the noise and interference power contributions. In the case of SS-SINR being used for L1-SINR, noise and interference power measurements can be performed based on resources configured by a higher layer.

[0109] Parameters may include CSI-SINR. CSI-SINR can be measured based on the linear average of the power contribution of the RE carrying the corresponding CSI-RS divided by the linear average of the noise and interference power contributions. When CSI-SINR is used for L1-SINR, noise and interference power measurements can be performed based on resources configured at a higher level. Otherwise, noise and interference power can be measured based on the resources carrying the corresponding CSI-RS.

[0110] Parameters may include RSSI. Received Signal Strength Indicator (RSSI) can be measured based on the average of the total power contribution in the configured OFDM symbols and / or bandwidth. Power contributions can be received from different resources (e.g., co-channel serving and / or non-serving cells, adjacent channel interference and / or thermal noise, etc.).

[0111] Parameters may include CLI-RSSI. The Cross-Layer Interference Received Signal Strength Indicator (CLI-RSSI) can be measured based on the average of the total power contribution in the configured OFDM symbols for the configured time and / or frequency resources. Power contributions can be received from different resources (e.g., cross-layer interference, co-channel serving and / or non-serving cells, adjacent channel interference and / or thermal noise, etc.).

[0112] Parameters may include SRS-RSRP. The probe reference signal RSRP (e.g., SRS-RSRP) can be measured based on a linear average of the power contribution of the RE carrying the corresponding SRS.

[0113] Parameters may include SS-RSRQ. The secondary synchronization reference signal reception quality (SS-RSRQ) can be measured based on measurements of the received reference signal power (SS-RSRP) and received signal strength (RSSI). SS-RSRQ can be calculated as the ratio of N × SS-RSRP / NR carrier RSSI, where N can be determined based on the number of resource blocks in the corresponding NR carrier RSSI measurement bandwidth. Thus, the measurements used in the numerator and / or denominator can be on the same set of resource blocks.

[0114] Parameters may include CSI-RSRQ. CSI Reference Signal Received Quality (CSI-RSRQ) can be measured based on measurements of the Reference Signal Received Power (CSI-RSRP) and / or Received Signal Strength (RSSI). SS-RSRQ can be calculated as the ratio of N × CSI-RSRP / CSIRSSI, where N can be determined based on the number of resource blocks in the corresponding CSI-RSSI measurement bandwidth. Thus, the measurements used in the numerator and / or denominator can be over the same set of resource blocks.

[0115] CSI report configurations (e.g., CSI-ReportConfigs) can be associated with a single BWP (e.g., indicated by BWP-Id) which configures one or more of the following parameters: CSI-RS resources and / or sets of CSI-RS resources for channel and interference measurements; CSI-RS report configuration type, including periodic, semi-persistent, and / or aperiodic; CSI-RS transmission periodicity for periodic and semi-persistent CSI reports; CSI-RS transmission slot offset for periodic, semi-persistent, and / or aperiodic CSI reports; a list of CSI-RS transmission slot offsets for semi-persistent and / or aperiodic CSI reports; and time constraints for channel and / or interference measurement report band configurations (e.g., wideband and / or subband CQI, and / or precoding matrix indicator (PMI), etc.). Thresholds and / or calculation modes for reporting quantities (CQI, RSRP, SINR, LI and / or rank indicator (RI) etc.); codebook configuration; group-based beam reporting; CQI table; subband size; non-PMI port indication; and / or port index, etc.

[0116] A CSI-RS (e.g., NZP-CSI-RS-ResourceSet) may include one or more CSI-RS resources (e.g., NZP-CSI-RS-Resource and / or CSI-ResourceConfig), wherein the WTRU may be configured in the CSI-RS resource with one or more of the following: CSI-RS periodicity and / or slot offsets for periodic and / or semi-persistent CSI-RS resources; CSI-RS resource mappings for defining the number, density, CDM type, OFDM symbols and / or subcarrier occupancy of CSI-RS ports; the bandwidth portion to which the configured CSI-RS is allocated; and / or a reference to the TCI state including QCL source RS and / or the corresponding QCL type.

[0117] A WTRU can be configured with one or more RS resource sets. The RS resource set configuration can include one or more of the following: RS resource set ID, one or more RS resources for the RS resource set, repetition (e.g., on or off), non-periodic trigger offset (e.g., one of 0-6 slots), and / or TRS information (e.g., true or false).

[0118] A WTRU can be configured with one or more RS resources. The RS resource configuration may include one or more of the following: RS resource ID; resource mapping (e.g., resources in a PRB); power control offset (e.g., a value of -8, ..., 15); power control offset using SS (e.g., -3dB, 0dB, 3dB, 6dB); scrambling ID; periodicity and / or offset; and / or QCL information (e.g., based on TCI state).

[0119] The attributes of granting and / or allocation may include at least one of the following: frequency allocation; an aspect of time allocation, such as duration; priority; modulation and / or coding scheme; transport block size; multiple spatial layers; multiple transport blocks; TCI status, CRI and / or SRI; number of repetitions; whether the repetition scheme is type A or type B; whether the grant is a configured grant type 1, type 2 and / or dynamic grant; whether the allocation is a dynamic allocation and / or semi-persistent scheduling (e.g., configured) allocation; configured grant index and / or semi-persistent allocation index; periodicity of configured granting and / or allocation; channel access priority level (CAPC); and / or any parameters provided in the DCI by MAC and / or RRC for scheduling granting and / or allocation.

[0120] The indication of a DCI may include at least one of the following: explicit indication of the DCI field or RNTI, CRC for masking and / or scrambling the DCI; implicit indication by attributes such as DCI format, DCI size, CORESET and / or search space, aggregation level, and / or the first resource element of the received DCI (e.g., the index of the first control channel element). The mapping between attributes and / or values ​​may be provided by RRC and / or MAC signaling.

[0121] Receiving and / or monitoring a DCI that has or uses RNTI may mean that the CRC of the DCI is masked and / or scrambled with RNTI.

[0122] A WTRU can use a Scheduling Request (SR) to request UL-SCH resources for a new transmission. A WTRU can use SRs to send one or more requests, indications, and / or reports to, for example, a gNB. A WTRU can be configured with zero or one or more SR configurations. SR configurations can include a set of PUCCH resources for SRs across different BWPs and / or cells. A WTRU can be configured with at most one PUCCH resource for each BWP's SR, for example, for logical channels or for secondary cell (SCell) beam failure recovery and / or for consistent LBT failure recovery. A WTRU can be configured with, for example, up to two PUCCH resources for each BWP's SR, for example, for beam failure recovery of the serving cell's BFD-RS set.

[0123] Each SR configuration can correspond to one or more logical channels, SCell beam failure recovery, consistent LBT failure recovery, BFD-RS set beam failure recovery, etc. In the example, each logical channel, SCell beam failure recovery, BFD-RS set beam failure recovery, and consistent LBT failure recovery can be mapped to zero or one SR configuration, which can be configured via RRC.

[0124] In this document, signals can be used interchangeably with one or more of the following: SRS, CSI-RS, DM-RS, SSB, and / or Phase Tracking Reference Signal (PT-RS). Channels can be used interchangeably with one or more of the following: PDCCH, PDSCH, PUCCH, PUSCH, PUCCH, PUSCH, and / or PRACH. Signals, channels, and / or messages (e.g., as in DL or UL signals, channels, and / or messages) can be used interchangeably, but remain consistent with this invention. RS can be used interchangeably with one or more of RS resources, RS resource sets, RS ports, and / or RS port groups. RS can be used interchangeably with one or more of SSB, CSI-RS, SRS, and / or DM-RS, TRS, PRS, and PTRS. The terms time instance, time slot, symbol, and / or subframe can be used interchangeably. The terms SSB, SS / PBCH block, PSS, SSS, PBCH, and / or Master Information Block (MIB) can be used interchangeably. The terms SSB, SSB beam, and / or SSB index can be used interchangeably. The proposed solution estimates and / or predictions can be used for transmission and / or reception belonging to a single and / or multiple cells and a single and / or multiple TRPs. CSI reports are interchangeable with CSI measurements, beam reports, and / or beam measurements. RS resource sets are interchangeable with beam groups. The terms prediction, estimation, calculation, evaluation, and / or determination are interchangeable. RSRP is interchangeable with SS-RSRP, CSI-RSRP, SRS-RSRP, RSRP based on DMRS measurements in PBCH, RSRP based on DMRS measurements in PDCCH, RSRP based on DMRS measurements in PDSCH, RSRP based on DMRS measurements in PUCCH, and / or RSRP based on DMRS measurements in PUSCH. The terms service, user plane (UP) service, and control plane (CP) service are interchangeable.

[0125] Beam Failure Recovery (BFR) and / or beam switching methods can increase signaling overhead, increase latency (due to handover intervals), and / or increase power consumption at both the Network Wireless (NW) and / or the WTRU. BFR and / or beam switching can be avoided because the WTRU does not expect urgent traffic. This paper discusses efficient methods for beam management using AI / ML in mobile scenarios.

[0126] One solution could include delaying beam failure detection based on service status. For example, a WTRU that has already predicted congestion can identify and / or predict potential User Plane Function (UPF) or Control Plane (CP) services (using AI / ML). If the uplink (UL) and / or downlink (DL) are not urgent, WTRU1 can postpone entering BFD and / or BFR modes.

[0127] WTRU can have the ability to predict congestion (e.g., when beam quality and / or RSRP drop below a threshold for a finite duration that can be predicted), service status, and / or the optimal beam after the congestion duration ends.

[0128] The WTRU can predict blocking on the first beam (or RS) and / or the corresponding blocking duration. The prediction can be based on at least one of an AI / ML model and / or measurements of one or more configurations of the first BFD-RS set (e.g., via a trained model based on fingerprint recognition at gNB).

[0129] The WTRU can predict a second beam (or RS), which can be the optimal beam (or RS) after blocking is complete (e.g., the second beam in each BFD-RS set). The second predicted beam (or RS) may or may not be included in the configured first BFD-RS set. Blocking completion can be determined based on at least one of the following: the predicted blocking duration has elapsed, the predicted and / or actual beam quality, and / or the RSRP may be higher than a threshold.

[0130] The WTRU can determine and / or predict potential traffic states (e.g., within a predicted congestion duration). States can include traffic volume and / or traffic type and / or priority. The WTRU can postpone beam failure detection and / or associated BFRs if the determined and / or predicted traffic is low priority (not urgent), the determined and / or predicted volume is less than a threshold, and / or the congestion duration is shorter than a time threshold.

[0131] The WTRU can perform a handshake and can indicate at least one of the following: predicted congestion and / or congestion timing (e.g., start, end, and / or duration), determined and / or predicted gNB service status (e.g., before the start time of the congestion), whether the WTRU has determined to postpone beam failure detection and associated BFR, and / or predicted second beam (or RS). This can be done as part of a CSI report or via a separate SR. The WTRU can indicate that it has predicted congestion. Due to low service, the WTRU may postpone the BFR. The WTRU can indicate the set of BFD-RS predicted for congestion. This indication may include the second predicted beam, the duration of the BFR to be postponed (TPP_BFR), the location of the WTRU, RSRP measurements of the set of BFD-RS predicted for congestion, etc.

[0132] The WTRU can receive acknowledgment and / or rejection and / or enable and / or disable instructions from the gNB. If acknowledged, the WTRU can receive instructions regarding the duration (e.g., delay period) of delaying BFD and / or associated BFR, corresponding parameters, etc. The WTRU may delay BFD and / or associated BFR. If rejected, the WTRU may execute BFR; the WTRU may report beam failure; and / or the US may send RACH, etc.

[0133] After one or more of the following has elapsed: the end of the BFD and / or associated BFR delay process and / or the duration of the blocking or delay of the BFD and / or associated BFR, the WTRU may determine whether the BFD conditions still apply (e.g., based on measurements of the configured BFD-RS set). The WTRU may attempt to detect the CORESET and / or receive the PDCCH to measure beam quality (e.g., based on the PDCCH DMRS).

[0134] If the conditions still apply, the WTRU can perform a beam failure (e.g., the WTRU reports a beam failure; and / or sends a RACH, etc.). If the conditions no longer apply, the WTRU can send a report to the gNB. The WTRU can send a UL transmission (e.g., via SR, UCI, and / or MAC-CE, etc.) indicating that beam failure was avoided. The WTRU can report measurements taken before and / or during the blocking (if any), for example, for gNB training purposes.

[0135] Currently in NR version 18 (R18), if the WTRU detects a (pre-)configured number of beam failure instances (BFI), the WTRU can trigger a beam failure detachment (BFD) and / or execute a beam failure detachment (BFR). Figure 2 As shown, WTRU1 210 is served by beam #2 240 and / or detects BFD and / or initiates BFR by switching to beam #1 230. This switching may result in excessive traffic in beam #1 230. Based on the current specification, even after the blocking ends, WTRU1 210 may not switch back to beam #2 240, resulting in more traffic in beam #1 230.

[0136] Based on prior technology, WTRU1 210, served by beam #2 240, can predict that beam #1 230 or beam #3 250 is the best candidate beam (based on the movement and / or orientation of WTRU1 210). WTRU1 210 can initiate a BFR and / or request a switchover to beam #1 230 and / or beam #3 250 in advance or before BFD. This switchover may result in heavier traffic on the gNB side in beam #1 230 or beam #3 250, as WTRU1 210 may not switch back to beam #2 240 until another event (BFD and / or PDCCH command) is detected.

[0137] Generally, in the context of AI / ML systems, two types of blocking can be considered: predictable blocking and unpredictable blocking. Predictable blocking occurs when the WTRU uses an AI / ML model (e.g., mapping and / or fingerprinting) in the corresponding beam (e.g., beam #2 240) received by WTRU1 210 (e.g., offline and / or from a gNB, e.g., based on a model trained on the gNB). Therefore, if blocking 260 is stationary, WTRU1 210 may already know it. WTRU1 210 can then predict the time required to traverse blocking 260. Unpredictable blocking refers to blocking that occurs suddenly and / or may be due to dynamic changes in the environment. Therefore, the WTRU may not be able to predict this type of blocking.

[0138] The WTRU can determine and / or predict traffic and / or congestion levels. The WTRU can perform one or more of the following operations: The WTRU can receive indications about its traffic level (e.g., data volume, throughput, latency, and / or jitter). UL and DL can be indicated separately, or there can be a common indication for both. Indications can be at different Data Radio Bearer (DRB) granularities. DRB granularity can be total UP, CP, level, DRB level, DRB group level, and / or groups can be based on a QoS profile of the DRB (e.g., whether they are guaranteed bit rate bearers, etc.). Indications can be associated with one or more time ranges and / or durations (e.g., X megabytes expected in 1 second, Y megabytes expected in 2 seconds, etc.). Indications can refer to already available data that may be awaiting transmission (e.g., DL data awaiting transmission at network nodes). Indications can refer to data that is expected to become available soon (e.g., within a certain duration). There can be separate indications for awaiting and / or predicted data, or there can be a common indication for both.

[0139] The WTRU can receive indications about congestion status from the network. There can be separate indications for UL and / or DL, or a common indication for both. Indications can be at the cell group level (e.g., primary cell group (MCG) and / or secondary cell group (SCG) in a dual-connectivity scenario, for the primary cell (PCell) and / or all secondary cells (SCell), for a subset of SCells, etc.), cell level, beam level, and / or a set of beams. Indications can be simple flag indications (e.g., congested or not congested). Indications can also have greater granularity (e.g., no congestion, slight congestion, and / or high congestion, etc.). Indications can include duration information (e.g., how long the congestion level is expected to last).

[0140] Alternatively, the WTRU can identify and / or predict potential traffic (e.g., capacity and / or throughput). Based on buffer status monitoring at the WTRU, the WTRU can identify high traffic if it encounters buffer overflow. The WTRU can monitor the time packets spend in any L2 buffer (e.g., Packet Data Convergence Protocol (PDCP) buffer, RLC buffer, MAC buffer, etc.). Time can be an absolute value or relative to the packet delay budget (PDB) associated with the Protocol Data Unit (PDU) (e.g., the PDB configured for the bearer to which the PDU belongs, and / or the PDCP drop time configured for the bearer to which the PDU belongs, etc.). Based on traffic and / or congestion state prediction, the input parameters to the AI / ML model will be, for example, the time spent in different L2 buffers and the additional aspects of the applicable prediction time window.

[0141] The WTRU can determine the duration. During this duration, based on received indications and / or forecasts regarding the service status, there may be no urgent UL and / or DL ​​services.

[0142] The WTRU can receive indications about traffic volume and / or congestion levels in several ways, including via dedicated messages (e.g., RRC signaling, PDCP control DU, RLC control PDU, MAC CE, and / or DCI); and / or via broadcast messages (e.g., via RRC messages, SIB signaling, and / or group DCI).

[0143] There can be separate traffic volume and / or congestion level indicators, and / or a common indicator for both. The indicator may include explicit information (e.g., details such as buffer level, duration, and / or congestion level). The indicator may simply be an index, where the network has pre-configured the WTRU with associations to detailed traffic volume and / or congestion-related information. A combination of both is conceivable, where the indicator includes some explicit information and / or some pre-configured indexes. For example, the buffer level could be an index of a pre-configured buffer level table for the WTRU, such as a regular buffer status report. The congestion level and / or duration can be explicitly included in the indicator.

[0144] Even if there is no waiting traffic, a certain level of waiting traffic, and / or no certain duration has elapsed since the last DL data arrived or the last UL data was transmitted, some bearers can be configured as "undeferrable".

[0145] The WTRU can receive indications about the congestion state at the network. The network can determine the congestion state based on the number of WTRUs currently served by the corresponding gNB, the number of WTRUs expected to be served in the near future (e.g., WTRUs in an INACTIVE state), and the scheduling requirements of the traffic for the corresponding WTRUs. The granularity and / or number of indications received by the WTRU from the network can include any one or more of the following: the WTRU can receive indications from the network only when the congestion state is bad and / or critical; the WTRU can receive periodic indications about the congestion state from the network; the WTRU can receive one congestion state indication from the network for all types of traffic; the WTRU can receive a congestion state indication for UL traffic and / or another congestion state indication for DL ​​traffic.

[0146] The WTRU can receive congestion status indications for the services and / or service types currently used in the WTRU (e.g., Ultra Reliable and Low Latency (URLLC) services, Extended Reality (XR) services, Enhanced Massive Mobile Broadband (eMBB) services, etc.). For example, for UL services, the WTRU can send an indication of the service type to the gNB during UL PDU session establishment. This indication, in addition to allowing the scheduler at the network to allocate and / or provide resources to the WTRU accordingly, can also identify the WTRUs primarily affected by congestion. For example, URLLC services can take precedence over eMBB services, and / or the congestion status can differ for each type of service. The congestion status of URLLC services can be set to "moderate," while the congestion status of eMBB services (e.g., less important) can be set to "critical" to prioritize URLLC services in the UL. In other words, the NW can determine future services, service priorities, and / or Quality of Service (QoS) priorities based on one or more indications received from the WTRU based on UL data.

[0147] The gNB can perform RRC reconfiguration when it detects congestion and / or congestion deemed "critical." In this case, the gNB can send an RRC reconfiguration message to the WTRU. The reconfiguration message can include information about the congestion status, such as the affected DRBs, the expected congestion length, and / or any resulting reconfiguration (e.g., activating a new DRB set, activating another configuration permission (CG) configuration, etc.). In response, the WTRU can send an RRC reconfiguration complete message to acknowledge the reconfiguration process (including information about congestion).

[0148] Congestion indications from the network may include additional information, such as information about the beams affected by congestion. This may include the affected SSB (e.g., in terms of SSB ID), the affected CSI-RS beam (e.g., in terms of CSI-RS beam ID), any relevant information between UL and DL beams (e.g., the DL transmit (Tx) beam IDX corresponding to the UL receive (Rx) beam ID Y), information about the new beam to be used as a result of congestion (e.g., using SSB 2), and / or any relevant information between different beams or their types (e.g., using SSB 2 if SSB 1 is affected by congestion). Furthermore, this may include the expected duration for which a beam may be affected and / or when an alternative beam will be used.

[0149] Congestion signaling can occur in different ways. For example, the WTRU can receive an indication of congestion status, such as in the MAC CE and / or scheduling DCI. The network can detect congestion on a per-data radio bearer (DRB) basis. In this case, the gNB can send a congestion indication from the PDCP and / or RLC entity in the gNB to the corresponding PDCP / RLC entity in the WTRU for the relevant bearer in the PDCP and / or Radio Link Control (RLC) control PDU.

[0150] The gNB can send congestion indications in the MAC CE, which has a bitmap introduced for congestion indication on a per-DRB basis to efficiently control multiple DRBs separately and simultaneously, for example, an 8-bit bitmap corresponding to the DRBs configured in the WTRU. When congestion indication is available for each type of service signaling, the 8-bit bitmap can correspond to the DRB configured for the type of service indicating congestion, for example, a DRB configured to serve eMBB services. When the WTRU can be configured with a large number of DRBs, more than one format of MAC-CE can be configured to indicate congestion based on each DRB, for example, a 16-bit bitmap in addition to the 8-bit bitmap can be used to indicate a larger number of DRBs.

[0151] Any one or more solutions may include the WTRU receiving configuration information about congestion status indications from the network, for example, during RRC (re)configuration. This configuration may include: periodicity of the periodic congestion indication, granularity of the congestion indication, one configuration for all services, and / or one configuration for UL services and / or another configuration for DL ​​services, and / or one configuration for all service types and / or one configuration for each service type (e.g., URLLC, eMBB, XR, and / or services, etc.).

[0152] The WTRU can send requests to the network regarding current and / or upcoming congestion states. Requests can be made at any granularity as described above, such as a general indication and / or an indication for each service type (e.g., UL to DL, and / or eMBB to URLLC to XR, etc.). In response to a request sent from the WTRU, the WTRU can receive a congestion indication from the network. The WTRU can send such requests to the network periodically. The WTRU can be configured with a set of SRs, where the WTRU can determine to send the first SR to implicitly indicate one or more indications (e.g., to the gNB).

[0153] The WTRU may send the aforementioned indication in any one or more of the following situations: when the WTRU has sent one or more scheduling requests and has not received any response from the network and / or UL permission in response. In this case, the WTRU may determine that congestion exists and send a request to the network for acknowledgment; when the WTRU has sent multiple scheduling requests and has reached the maximum counter sr_TransMax, preventing the WTRU from sending any more SRs and / or the WTRU has not received any UL permission in response from the network; when the WTRU has sent an SR to the network and the SR disable timer is still running, preventing the WTRU from sending another SR to the network and / or the WTRU has not received any UL permission in response to the SR; and / or when the WTRU has sent a Buffer Status Report (BSR) to the network and has not received any UL permission in response to the BSR.

[0154] For example, receiving an indication from the network within a pre-configured time window could indicate that there is no congestion. In another solution, not receiving an indication from the network might indicate that the congestion situation is so bad that the WTRU cannot receive any indication.

[0155] A WTRU's request for network congestion information can be triggered based on the current state of the beam failure monitoring process. For example, if the current counter value of the BFI reaches a certain threshold (e.g., below the threshold for the maximum value of the BIF used to detect BF and / or trigger BFR), the WTRU can send a request to the network. Indications from the WTRU requesting congestion levels from the network can be UCI, MAC CE, RLC control PDU, PDCP control PDU, and / or RRC messages. These indications can include detailed information such as relevant services (e.g., radio bearers and / or QoS profiles) and / or network information (e.g., cell identity and / or beaming).

[0156] The scheduler at the network has information about multiple WTRUs and / or m that it serves, in order to allocate resources to these multiple WTRUs. Therefore, the scheduler can know the current congestion state and the upcoming congestion state for future time windows. The length of the congestion window and / or the severity of congestion may depend on the scheduling requirements of the currently served WTRUs. Such scheduling requests may include any one or more of the following: the UL and / or DL ​​service modes of the servicing WTRU, CG configuration details of the servicing WTRU (e.g., the allowed size and / or periodicity, and / or offsets to the CG configuration, etc.), semi-persistent scheduling (SPS) configuration details of the servicing WTRU (e.g., the allowed size and / or periodicity of the DL), scheduling requests received by the gNB to date, the number of BSR requests received by the gNB (e.g., regular BSR, preemptive BSR, and / or periodic BSR), details included in the BSR requests (e.g., the allowed size requested by the WTRU in the BSR, the periodicity of the periodic BSR, etc.), and DSR (Delay Status Report) indications received by the network, which include information about the remaining delay of data in the corresponding WTRU buffer (e.g., the remaining time before the PDB expires, etc.).

[0157] The WTRU can determine and / or predict traffic conditions based on one or more of the following: buffer status and / or buffer level monitoring at the WTRU. If the WTRU experiences a buffer overflow, it can determine that heavy traffic exists and / or traffic exceeds a determined and / or (pre-)configured threshold. If the buffer level at the WTRU is continuously filled >X% (e.g., X=80) (e.g., for a pre-configured time window), the WTRU can determine that heavy traffic exists. The WTRU can monitor the time spent by traffic in any L2 buffer (e.g., PDCP buffer and / or MAC buffer, etc.). If determined at the PDCP sublayer, the time spent in buffer calculations can be based on existing PDCP drop timers, and / or, if determined at the MAC sublayer, on a new timer at the MAC. The WTRU can determine the remaining time of data in any of its L2 buffers. For example, the remaining time can be related to the PDB associated with a PDU or the PDU set delay budget (PSDB) associated with a PDU set. If determined at the PDCP sublayer, the remaining time calculation can be based on existing PDCP drop timers, or, if determined at the MAC sublayer, on a new timer at the MAC.

[0158] The WTRU can determine and / or predict business conditions based on unanswered and / or unfulfilled SR and / or BSR requests. If the WTRU does not receive UL permission in response to one or more SR and / or BSR requests, the WTRU can determine that congestion exists.

[0159] The WTRU can determine and / or predict service conditions based on partially satisfied BSR requests. If the WTRU sends a request for a UL grant of size X, but receives a grant of size Y smaller than what it reports in the BSR table, the WTRU can determine that the NW cannot grant the requested resource due to congestion. Alternatively, if the WTRU receives a UL grant insufficient to meet the service volume level indicated in the BSR, the WTRU can determine that the NW cannot grant the requested resource due to congestion.

[0160] The WTRU can determine and / or predict service conditions based on indications from the application. In the UL, the WTRU can receive indications about upcoming services from the application at the application layer. For example, a WTRU transmitting XR services in the UL can receive indications about XR services from the XR application within the WTRU. These indications may include information about UL jitter (since jitter is generated in the application) and / or the periodicity of UL services and / or upcoming service surges. Based on this indication and / or other information (e.g., its CG configuration at the WTRU and / or ongoing and / or unfulfilled SR / BSR requests), the WTRU can determine that it is experiencing congestion in the current and / or upcoming time window.

[0161] The WTRU can determine and / or predict operational conditions based on AI / ML operations at the WTRU. The WTRU can have an AI / ML model to determine and / or predict congestion and / or impending congestion and / or any one or more of the aforementioned parameters associated with congestion (e.g., congestion duration, affected DRBs and / or affected SSBs, etc.). Input parameters to the AI / ML model can be, for example, the time spent in different L2 buffers, as well as additional aspects such as applicable prediction time windows and any of the aforementioned parameters related to congestion. Other input parameters to the AI / ML model (e.g., when determining network congestion levels) can be, for example, the time of day, the WTRU location (e.g., current cell or geographic location, etc.).

[0162] The WTRU can report determined and / or predicted service levels and / or latency status to the NW. Once the current and / or predicted service levels are determined, the WTRU can report them periodically, and when it receives a request from the NW requesting a report on the determined and predicted service levels and / or latency status at the WTRU, it will also report the latency status at the WTRU.

[0163] The WTRU can determine the duration during which there will be no urgent UL and / or DL ​​services based on received instructions, the determination and / or prediction of the service status at the WTRU.

[0164] The WTRU can be configured with and / or determined one or more service levels based on received indications, determined and / or predicted data traffic, data congestion, etc., as described herein. The WTRU can determine the service level based on a first service level (e.g., high service), a second service level (e.g., medium service), a third service level (e.g., low service), etc.

[0165] After receiving one or more congestion detections and / or indications of reception from the network, the WTRU can perform different operations at different L1 / L2 levels. For example, based on the WTRU's determination of potential traffic and / or non-urgent needs for UL / DL data transmission and / or reception (e.g., traffic currently buffered at the WTRU or valid traffic in the DL belongs to a bearer with very lenient latency and / or throughput requirements), the WTRU can modify the BF detection and / or recovery process. The WTRU can modify BF detection by extending the maximum BFI counter value, resetting and / or pausing the BFI counter, and / or resetting and / or pausing the BFD timer, etc.

[0166] Based on the determination of severe congestion in the network (e.g., determined by the WTRU itself or based on indications received from the network), the WTRU can modify the BF detection and / or recovery process. The WTRU can modify the BF detection and / or recovery process by extending the maximum BFI counter value, resetting and / or pausing the BFI counter, and / or resetting and / or pausing the BFD timer, etc.

[0167] The WTRU can improve the prediction of one or more beams based on the detection and / or prediction of service status. The WTRU can expand the number of candidate beams and / or improve the identity of candidate beams for beam failure recovery after service status detection and / or prediction. The WTRU may not monitor one or more beams affected by congestion (e.g., affected SSBs).

[0168] Other L2 operations, such as discarding and multiplexing, may involve the WTRU discarding low-priority and / or low-importance PDUs that it would normally attempt to transmit under normal (no congestion) conditions at the PDCP sublayer when congestion is present. Alternatively, in order to multiplex PDUs at the MAC sublayer, the WTRU may not multiplex low-priority and / or low-importance PDUs into MAC PDUs and / or prioritize higher-priority / higher-importance PDUs when congestion is present.

[0169] The WTRU can be configured with one or more QoS profiles, including one or more QoS flows, each QoS flow being identified by a QoS Flow Identifier (QFI). The WTRU can receive one or more QFIs of one or more QoS flows to be mapped to one or more Data Radio Bearers (DRBs) PDU sessions. QoS flows can be mapped via higher-layer parameters (e.g., mappedQoS-FlowsToAdd) as part of the Serving Data Adaptation Protocol (SDAP) configuration. The WTRU can receive the configured QoS profiles, QoS flows, and / or QFIs as part of RRC configuration and / or RRC reconfiguration messages.

[0170] In the application layer, data packets originate from the application. The Non-Access Stratum (NAS) layer can assign QoS requirements and / or mapping rules. The NAS can map data and / or IP flows carrying data packets to QoS flows and / or configure QFIs for each QoS flow. Therefore, all data packets within the same QoS flow have the same QFI. The Access Stratum (AS) layer maps QoS flows to radio layer resources, whereby the SDAP entity within the WTRU maps QoS flows to DRBs. Therefore, all data packets mapped to the same DRB have the same transmission processing in the AS (e.g., from the perspective of the radio interface). SDAP QoS flow to DRB mapping rules can be configured semi-statically in the RRC. Therefore, WTRU-SDAP can map SDUs to DRBs based on the configured rules, and / or map to the default DRB if no rules are configured. The RRC can configure each DRB with one or more Logical Channels (LCHs). Finally, the Link Control Protocol (LCP) function in the WTRU-MAC can allocate UL radio resources between LCHs with buffered data in the WTRU. Allocation can be based on configured QoS-related LCP parameters (e.g., LCH priority, LCH priority bit rate (PBR), bucket size duration (BSD), and / or LCH LCP mapping limits configured per LCH).

[0171] WTRU can determine one or more priority levels for a configured QoS flow based on one or more configured QoS requirements. For example, WTRU can determine priority levels based on a first priority level (e.g., high priority), a second priority level (e.g., medium priority), a third priority level (e.g., low priority), and so on.

[0172] The WTRU can be configured with one or more QoS requirements for received, determined, and / or configured QoS flows. One or more of the following QoS requirements may be applicable: error rate. The WTRU can be configured with one or more types of QoS based on one or more levels of expected error rate (e.g., PDU set error rate (PSER)). For example, a first type of QoS flow may include a guaranteed bit rate (GBR), where the WTRU receives configurations regarding one or more of the guaranteed bit rate (e.g., in Kbit / s), maximum bit rate (e.g., in Kbit / s), etc. A second type of QoS flow may be non-GBR. If the configured GBR is higher than a corresponding threshold, the WTRU can determine that the first type of QoS flow has a first priority level. If the configured GBR is lower than the corresponding threshold, the WTRU can determine that the first type of QoS flow has a second priority level. The WTRU can determine that the second type of QoS flow has a third priority level, and so on.

[0173] Another potentially applicable QoS requirement is a latency threshold. The WTRU can receive and / or transmit one or more Service Data Streams (SDFs) as part of one or more PDUs. SDFs can be applied to different applications, where each SDF can have different service QoS requirements. The WTRU can be configured with one or more levels of PDU set latency thresholds (PSDBs). As part of analyzing packets corresponding to the UPF (e.g., using Packet Detection Rules (PDR)), the WTRU can determine one or more priority levels for the SDFs. The WTRU can determine the priority level based on QoS Enforcement Rules (QERs), the configured PSDB, and / or the corresponding QFI associated with the PDR. If the configured PSDB is configured for low latency and / or below a first latency threshold, the WTRU can determine that the QFI has a first priority level. If the configured PSDB is above the first latency threshold and / or below a second latency threshold, the WTRU can determine that the QFI has a second priority level. If the configured PSDB is above the second latency threshold, the WTRU can determine that the QFI has a third priority level, and so on.

[0174] The WTRU determines or receives information about the operating mode and the duration of the BFR delay (T) on its effective first (e.g., original) beam. PP_BFR The configuration of ) can include one or more of the following modes.

[0175] First mode: Maintaining Rx / Tx. For example, performing semi-persistent / aperiodic discontinuous reception (DRX) and / or discontinuous transmission (DTX) towards the WTRU. The WTRU may be able to predict the optimal (second) beam in the time domain. The WTRU may not monitor or receive any SSB and / or RS. The WTRU does not monitor SPS PDSCH timing and / or dynamically authorized / assigned PDCCH for new transmissions. The WTRU may not transmit CG PUSCH timing and / or SR timing. The WTRU may determine a short DRX duration to avoid entering Radio Link Failure (RLF) or desynchronization. During DRX active mode, the WTRU may monitor paging to maintain synchronization. After the duration has elapsed, the WTRU may connect to the first original beam. The WTRU and / or the network may be synchronized relative to when the WTRU is connected and / or reachable.

[0176] The process may succeed if the WTRU monitors, receives, and / or measures the PDCCH DMRS RSRP on the original first beam and / or the measured RSRP is above a threshold. Based on the first original beam, the process may fail if the WTRU cannot receive the PDCCH or if the measured RSRP is below a threshold. In addition to the accuracy of beam prediction, the predicted second beam, etc., the WTRU uses a third or fourth operating mode based on one or more (pre-)configured pieces of information. The WTRU can use the third operating mode if "prediction accuracy is acceptable" and "the second beam is different from the first beam." The WTRU uses the fourth operating mode if "prediction accuracy is acceptable" and "the second beam is the same as the first beam." The WTRU can use the fourth operating mode if "prediction accuracy is general or unacceptable."

[0177] Second mode: Modify the BFI counter, BFI maximum count, and / or BFD timer and / or candidate beam set. The WTRU can monitor the corresponding SSB and / or RS and increment the BFI counter until it reaches a (pre-)configured first (normal) MAX (e.g., maximum) value. When the first maximum counter is reached, the WTRU can continue monitoring and / or attempt to detect the corresponding CORESET, PDCCH, SSB, RS, etc., until the BFI counter reaches a second maximum value (e.g., during an extended period). The WTRU can monitor the first set of BFR candidate beams and / or the second set of BFR candidate beams during the extended period to select one or more optimal candidate beams. After the extended period has passed, the WTRU can attempt to connect to the original first beam.

[0178] The procedure may succeed if the WTRU monitors, receives, and / or measures the PDCCH DMRS RSRP on the original first beam and / or the measured RSRP is above a threshold. The WTRU may send a report to the gNB. The procedure will fail if either of the following conditions applies: based on the first original beam, the WTRU cannot receive the PDCCH and / or the measured RSRP is below a threshold. If the delay duration (T) is within the specified timeframe... PP_BFR If the second maximum value is reached within a certain range, the process may fail. In the event of a failed process, the WTRU uses the fourth operating mode (conventional BFR) to connect to the best-selected candidate beam.

[0179] Third mode: Skip BFR and / or perform beam switching to the second (predicted) beam. The WTRU may be able to predict the optimal (second) beam in the time domain. The WTRU may not measure the candidate beam and / or, after time has elapsed, directly connect based on the determined and / or predicted second beam (e.g., perform RACH). If a connection to the second predicted beam is not possible and / or if the beam quality of the second predicted beam is unacceptable, the WTRU may use a fourth operating mode based on the original first beam.

[0180] Fourth mode: Revert to conventional BFR based on the original first beam. In the fourth operating mode, if the beam quality is unacceptable after the RLF timer expires and no candidate beam is available, the WTRU can initiate an RLF recovery. The WTRU can send an indication (e.g., via a flag in the BFR MAC-CE) to indicate the reason for using revert to conventional BFR.

[0181] This document describes how one or more thresholds and / or maximum values ​​for timers and / or counters can be indicated and / or configured (e.g., via gNB) via one or more of RRC, MAC-CE, and / or DCI. For practical operation, the WTRU can be configured with one value (e.g., via one of RRC, MAC-CE, and / or DCI). The gNB can configure the WTRU with two or more candidate values ​​(e.g., via RRC and / or MAC-CE), and / or indicate one value for practical operation (e.g., via MAC-CE and / or DCI).

[0182] The WTRU can support BFR delay. The WTRU can determine the BFR delay operating mode based on a first beam (e.g., a beam activated and / or indicated by the gNB, for example, for transmitting and / or receiving one or more channels and / or signals). The WTRU can receive an indication of the BFR delay operating mode based on the first beam (e.g., via one or more of RRC, MAC-CE, and / or DCI). In another solution, the WTRU can determine and / or receive configuration information (e.g., TPP_BFR) regarding the duration of performing and / or delaying the BFR. The determination and / or indication of the operating mode and / or duration can be based on one or more of the following modes.

[0183] First mode: Perform semi-persistent and / or aperiodic DRX / DTX for the WTRU (e.g., Rx / Tx hold for the WTRU). The WTRU can hold, stop, and / or disable Rx / Tx. The WTRU can perform semi-persistent and / or aperiodic DRX / DTX for the WTRU in the first operating mode. In this mode, the WTRU can stop monitoring, receiving, measuring, and / or transmitting one or more signals and / or channels. The WTRU may not monitor and / or receive one or more of the following, such as SSB, RS, SPS PDSCH timing, dynamic granting for new transmissions, and / or allocated PDCCH, for example, during the configured and / or determined DRX / DTX duration. The WTRU may not transmit uplink signals and / or channels, such as PUSCH during CG PUSCH timing, SR timing, etc., for example, during DRX / DTX.

[0184] The WTRU can determine the maintenance of Rx / Tx related parameters. These parameters can be associated with semi-persistent and / or aperiodic DRX / DTX for the WTRU. If the WTRU determines a set of DRX / DTX parameters for semi-persistent DRX / DTX, aperiodic DRX / DTX, and / or delayed BFR, the WTRU can determine whether to use a first or second set of DRX / DTX related parameters. The WTRU can use a short DRX / DTX duration as the first set of DRX / DTX parameters, for example, to avoid entering RLF and / or desynchronization mode. That is, the WTRU can determine that the determined and / or configured BFR delay duration (e.g., TPP_BFR) may be longer than a corresponding threshold after which the WTRU attempting to connect via the first original beam may experience RLF and / or become desynchronized. Thus, the WTRU can determine to use a short DRX / DTX duration to avoid loss of synchronization and / or entering RLF. The WTRU can predict and / or determine that the probability of the WTRU entering desynchronization and / or RLF is low. The WTRU can predict that it may be located in the center of a cell with high received power (e.g., RSRP). Therefore, the WTRU can determine the use of a second set of DRX / DTX parameters (e.g., with a long DRX / DTX duration).

[0185] The WTRU can apply a defined set of DRX / DTX related parameters (e.g., based on DRT / DTX type) to DRX / DTX operations. The WTRU can monitor paging signaling (e.g., to maintain synchronization) by monitoring the associated CORESET and / or paging PDCCH in the search space.

[0186] In the first mode, after the BFR delay duration (e.g., TPP_BFR) expires, the WTRU can use the first beam to apply, use, transmit, and / or receive one or more channels and / or signals. The WTRU can determine whether the performance of reception and / or transmission is acceptable based on the first beam, and the WTRU can determine the operating mode accordingly.

[0187] In the first mode of the WTRU, a successful BFR delay may occur. The WTRU may attempt to receive and decode the associated CORESET and / or paging PDCCH in the search space and / or determine the received signal power (e.g., RSRP). The WTRU may attempt to receive, detect, and / or measure the RSRP of one or more configured PDCCH DMRS based on the original first beam. If the measured RSRP is above the corresponding threshold, the WTRU may determine that the performance of the first beam is acceptable. Thus, the WTRU can determine that the BFR delay is successful, and therefore the WTRU can continue to receive and / or transmit signals and channels based on the first beam.

[0188] Unsuccessful BFR delay. For example, if the WTRU fails to receive, detect, and / or decode the paging PDCCH, and / or if the measured RSRP of the received PDCCH DMRS is below a threshold, the WTRU can determine that the BFR delay was unsuccessful and use another operating mode.

[0189] The WTRU can predict the second beam (e.g., the optimal beam) in the time domain. The WTRU can predict the second optimal beam from the current time, for example, X ms. The WTRU may also be able to predict the second optimal beam (e.g., TPP_BFR) after a duration of delay configured for the BFR.

[0190] Unsuccessful BFR delays may occur. One or more of the following examples may be applied: If the WTRU is able to perform beam prediction and / or the prediction accuracy used to predict the second beam is higher than a prediction accuracy threshold, and the predicted second beam is different from the original first beam, then the WTRU may determine to use a third operating mode. If the WTRU is able to perform beam prediction and / or if the prediction accuracy used to predict the second beam is higher than a prediction accuracy threshold, and the predicted second beam is the same as the original first beam, then the WTRU may determine to use a fourth operating mode, as described herein. The WTRU may send an indication, for example as part of a report, such as via a flag in the BFR MAC-CE, where the indication may indicate that the first operating mode has been selected. Due to unsuccess, the WTRU performs a fallback to the fourth operating mode. For example, if the WTRU cannot perform beam prediction and / or if the prediction accuracy used to predict the second beam is lower than or equal to a prediction accuracy threshold, then the WTRU may determine to use the fourth operating mode.

[0191] Second Mode: Extended Beam Failure Detection Process. The WTRU can extend the BFD process by applying different BFI counters, timers, a set of monitoring beams for beam failure detection, and / or a set of candidate beams for new beam selection, thereby delaying the BFR. The WTRU can use the second operating mode if it determines and / or indicates its capability regarding the extended BFI counters, timers, and / or a set of candidate beams.

[0192] The WTRU can be configured with two or more sets of BFR configurations. For example, if the WTRU supports normal and / or conventional BFR modes (excluding support for a second operating mode and / or extended BFI counters, timers, and / or a set of candidate beams, etc.), then the first set of BFR configurations can be used. In other words, normal and / or conventional BFR can include operation based on the initially configured first set of configurations. If the WTRU supports extended BFR modes (e.g., a second mode), then the second set of BFR configurations can be used. BFR configurations can include one or more of the following: threshold, counter maximum value, and / or timer maximum value, etc.

[0193] A WTRU can be configured with two or more sets of BFD-RS. For example, if the WTRU supports normal and / or conventional BFR modes, the first set of BFD-RS can be used. If the WTRU supports extended BFR modes (e.g., a second mode), the second set of BFD-RS can be used.

[0194] The WTRU can be configured with two or more new candidate beam (NCB) RSs. If the WTRU supports normal or conventional BFR mode, the first set of NCB RSs can be used. If the WTRU supports extended BFR mode (e.g., mode 2), the second set of NCB RSs can be used.

[0195] The WTRU can monitor, detect, and / or measure the BFD-RS (e.g., one or more of q0, SSB, and / or RS). Based on monitoring, detection, and / or measurement, the WTRU can detect beam failure. If the measurement quality of the BFD-RS is below a beam failure threshold, the WTRU can increment the BFI counter (e.g., until a (pre-)configured first maximum value is reached). If the WTRU determines a normal or regular BFR mode and / or the beam failure counter reaches the first maximum value (e.g., configured in the first set of BFR configurations and / or before the first BFR timer expires), the WTRU can trigger BFR operation. If the WTRU determines a second mode (e.g., upon reaching the first maximum value within the beam failure counter), the WTRU can continue monitoring, measuring, and / or attempting to detect beam failure (e.g., based on associated CORESET, search space, PDCCH, SSB, and / or RS, etc.) until the BFI counter reaches a second maximum value (e.g., configured in the second set of BFR configurations and / or before the second BFR timer expires, e.g., an extended period).

[0196] The WTRU can apply different groups of BFD-RS (e.g., based on the first group configuration). The WTRU can monitor the first group of BFD-RS before the first timer expires and / or the first maximum value of the first counter is reached. After the first timer expires and / or the first maximum value of the first counter is reached, the WTRU can monitor the second group of BFD-RS.

[0197] The WTRU can apply different groups of NCB RS (e.g., based on the first group configuration). The WTRU can measure the first group of NCB RS before the first timer expires and / or before the first maximum value of the first counter is reached. After the first timer expires and / or the first maximum value of the first counter is reached, the WTRU can measure the second group of NCB RS. The WTRU can apply the first beam (e.g., based on the second mode) after the second BFR timer expires.

[0198] The second mode considers successful BFR delay. The WTRU can determine the operating mode after extending the BFR-related configuration. For example, the WTRU can detect, receive, and / or decode PDCCHs (e.g., WTRU and / or group-specific PDCCHs in the associated CORESET and / or search space). The WTRU can measure the corresponding PDCCH DMRS RSRP on the original first beam. If the measured RSRP is higher than the corresponding threshold, the WTRU can determine that the performance of the first beam is acceptable. Therefore, the WTRU can determine that the BFR delay is successful. Thus, the WTRU can continue to receive and / or transmit signals and / or channels based on the first beam.

[0199] The second mode considers unsuccessful BFR delays. If the WTRU fails to receive, detect, and / or decode the PDCCH and / or if the measured RSRP (e.g., the RSRP of the measured PDCCH DMRS) is below the corresponding threshold, the WTRU may determine to use the fourth operating mode, as described herein. The WTRU may send an indication, for example as part of a report, via a flag in the BFR MAC-CE, which may indicate that the second operating mode was selected and / or, due to its unsuccessfulness, the WTRU may perform a fallback to the fourth operating mode.

[0200] Third mode: Recovering beam failures and / or performing beam switching based on beam prediction. If the WTRU can predict a second beam (e.g., the optimal beam) in the time domain (e.g., X ms from the current time), the WTRU can use the third operating mode.

[0201] The WTRU can detect one or more BFIs and / or trigger BFR operation after the maximum number of BFIs is reached (e.g., within a timer), where the BFR operation can be based on a second predicted beam. The WTRU can determine that a BFR delay based on a configured and / or determined duration (e.g., TPP_BFR) is unsuccessful, where the WTRU can trigger BFR operation based on the second predicted beam. The WTRU can determine one or more optimal beams based on the prediction quality (e.g., predicted RSRP) of the NCB RS corresponding to the second predicted beam. Based on the determined one or more optimal beams, the WTRU can (e.g., to the gNB) indicate one or more optimal beams. The WTRU can send one or more PRACHs (e.g., in PRACH resources associated with one or more optimal beams). The WTRU can indicate one or more optimal beams (e.g., indicating RS indexes and / or beam indices, etc.). The indication can be one or more of RRC, MAC CE, UCI, special SR, as part of enhanced HARQ-ACK, as part of CSI-RS, etc.

[0202] The third mode considers the successful process. The WTRU can attempt to receive, detect, and / or decode the PDCCH (e.g., the associated CORESET and / or the WTRU and / or group-specific PDCCH in the search space). The WTRU can measure the corresponding PDCCH DMRS RSRP on the predicted second beam. If the measured RSRP is higher than the corresponding threshold, the WTRU can continue receiving and transmitting based on the second (predicted) beam.

[0203] The third mode considers unsuccessful processes. The WTRU may attempt to receive, detect, and / or decode the PDCCH (e.g., the associated CORESET and / or WTRU and / or group-specific PDCCH in the search space). The WTRU may measure the corresponding PDCCH DMRS RSRP on the predicted second beam. If the measured RSRP is below the corresponding threshold, the WTRU may determine to use the fourth operating mode, as described herein. The WTRU may send an indication, for example as part of a report, via a flag in the BFR MAC-CE, indicating that the third operating mode has been selected, and that due to its unsuccessfulness, the WTRU performs a fallback to the fourth operating mode.

[0204] Fourth Mode: Fallback to Regular BFR Based on the Original First Beam. The WTRU can detect one or more BFIs and / or trigger BFR operation after reaching a maximum value (e.g., within a timer). After triggering BFR operation, the WTRU can support BFR operation based on a set of NCB RSs. The WTRU can determine one or more optimal beams based on the measurement quality of the NCB RSs (e.g., the measured RSRP). Based on the determined one or more optimal beams, the WTRU can (e.g., to the gNB) indicate one or more optimal beams. The WTRU can send one or more PRACHs (e.g., in PRACH resources associated with one or more optimal beams). The WTRU can indicate one or more optimal beams (e.g., indicating RS index, beam index, etc.). The indication can be one or more of RRC, MAC CE, and / or UCI.

[0205] If the WTRU fails to identify a new beam, or fails to receive a PDCCH in the associated CORESET and / or search space (e.g., within a timer), or if the measured RSRP based on the PDCCH DMRS is below the corresponding threshold, the WTRU can determine that the BFR procedure was unsuccessful. In this case, the WTRU can trigger one or more contention-based RACH procedures and / or RLF recovery, etc.

[0206] A WTRU can be configured with one or more sets of reference signal (RS) resources, beams, and / or beam pairs. Each RS resource, beam, and / or beam pair can be associated with the transmission of a beam from a specific beam parameter (e.g., beam direction and beamwidth). A WTRU can be configured with associated beams and / or RS resources and / or beam parameters.

[0207] The WTRU can be configured with a first set of RS resources, beams, and / or beam pairs that can cover the entire RS resource space, beam space, and / or beam pair space. The WTRU can determine or select sets A and B such that the union of sets A and B covers the entire RS resource space, beam space, and / or beam pair space. Sets A and B can be mutually exclusive. Set B may include RS resources on which the WTRU can perform measurements to obtain direct measurements of the first set of beams or beam pairs (e.g., a one-to-one mapping between RS resources and beams or beam pairs) and / or estimated measurements of the second set of beams or beam pairs (e.g., a many-to-one mapping between RS resources and beams or beam pairs and / or possibly using AI / ML estimation models).

[0208] The WTRU can be configured with requirements for set A and / or set B. The WTRU can be configured with one or more sets of RS resources associated with each beam. For example, the WTRU can be configured with a first beam associated with two sets of RS: the first set includes a single RS resource, and the second set includes multiple RS resources. The WTRU can determine the measurements associated with the beam via direct measurement of the RS resources in the first set and / or via estimates obtained from measurements of the RS resources in the second set.

[0209] The WTRU can determine a set of measurements for RS resources (e.g., set B) such that for each beam for which the WTRU must obtain measurements (e.g., directly or via estimation), set B includes at least one of two sets of RS resources associated with that beam. This document allows set B to be used interchangeably with a set of RS resource sets, beams, beam pairs, beam RS resources, RS resources, and / or beam patterns. This document also allows set A to be used interchangeably with a set of RS resource sets, beams, beam pairs, beam RS resources, RS resources, and / or beam patterns.

[0210] The WTRU can be (pre-)configured with the maximum number of RSs and / or SSBs in the cell (e.g., within an SSB burst). The maximum number of SSBs and / or RSs can be explicitly configured for the WTRU (e.g., via MIB, SIB, RRC, MAC-CE, and / or DCI, etc.). Alternatively, the maximum number of SSBs and / or RSs can be implicitly indicated to the WTRU based on the frequency range used. If the WTRU operates in a first frequency range (e.g., FR1), the WTRU can determine the maximum number of SSBs and / or RSs as a first value (e.g., up to eight SSBs and / or RSs). If the WTRU operates in a second frequency range (e.g., FR2), the WTRU can determine the maximum number of SSBs and / or RSs (e.g., within an SSB burst) as a second value (e.g., up to 64 SSBs and / or RSs), and so on.

[0211] For example, during initial access, cell (re)selection, beam measurement, beam management, etc., the WTRU can detect one or more SSBs and / or RSs (e.g., in an SSB burst). Considering the maximum number of SSBs and / or RSs, only a subset of SSBs and / or RSs can be planned, configured, required, desired, and / or designed for use (e.g., within a cell). The planned set of SSBs and / or RSs can be a collection of SSBs and / or RSs. The collection can cover the entire SSB and / or RS resource space and / or beam space. The number of planned SSBs and / or RSs can be less than or equal to the maximum number of SSBs and / or RSs determined at the network based on the coverage space of SSBs and / or RSs, beam correlation, etc. The number of planned SSBs, RSs, and / or corresponding SSB and / or RS beam indices can be provided to and / or configured to the WTRU.

[0212] The WTRU can receive, be provided with, or be configured with information about the actually transmitted RS and / or SSB (e.g., within an SSB burst). This information may include the number of actually transmitted SSB and / or RS beams, the SSB and / or RS indices corresponding to the actually transmitted SSB beams, etc. The WTRU can consider the set of actually transmitted SSBs and / or RSs as set B, where set B may be a subset of the configured set A. Alternatively, the WTRU can identify, be provided with, or be configured with a set of skipped SSBs and / or RSs. This set of skipped SSBs and / or RSs may not actually be transmitted within the corresponding SSB burst and / or RS transmission time window. The WTRU can use this set of transmitted beams (set B) to estimate and / or predict untransmitted beams. The WTRU can consider the set of estimated SSBs and / or RSs as set A.

[0213] The WTRU can be (pre-)configured with one or more first configuration information regarding transmissions on one or more set B beams. The first configuration information may include time and / or frequency resources, time periods, frequency hopping, etc., for transmissions of the corresponding SSB / RS in set B. The WTRU can also be configured with a second set of configuration information regarding transmissions on set A beams. That is, the WTRU can receive configurations regarding all transmissions and / or estimated instances of SSBs and / or RSs that can be transmitted in connection with set A and / or set B. The second configuration information may include time and / or frequency resources, time periods, frequency hopping, etc., for transmissions of the corresponding SSB / RS in set A. The second time period corresponding to transmissions on set A beams may be longer than the first time period corresponding to transmissions on set B beams. The WTRU can receive the first and / or second configuration information, for example, via MIB, SIB, RRC, MAC-CE, and / or DCI.

[0214] Figure 3An example of a system 300 with skipped SSBs is shown. Solid line beam 310 indicates set B or the transmitted beam. Dashed line beam 320 indicates set A or the estimated beam.

[0215] Delayed beam failure detection can be based on traffic conditions. The WTRU can have the ability to predict the optimal beam after a blockage (e.g., when beam quality and / or RSRP drop below a threshold for a finite duration that can be predicted), traffic conditions, and / or the end of the blockage duration.

[0216] WTRU can predict blocking on the first beam (or RS) and / or the corresponding blocking duration. The prediction can be based on at least one of the following: an AI / ML model, and / or measurements of the first BFD-RS set for one or more configurations (e.g., via a trained model based on fingerprint recognition at gNB).

[0217] The WTRU can predict a second beam (or RS), which can be the optimal beam (or RS) after blocking is complete (e.g., the second beam in each BFD-RS set). The second predicted beam (or RS) may or may not be included in the configured first BFD-RS set. Blocking completion can be determined based on at least one of the following: the predicted blocking duration has passed, the predicted and / or actual beam quality and / or RSRP may be above a threshold.

[0218] The WTRU can determine and / or predict potential traffic states (e.g., within a predicted congestion duration). States can include traffic volume and / or traffic type and / or priority. The WTRU can postpone beam failure detection and / or associated BFRs if the determined and / or predicted traffic is low priority (not urgent), the determined and / or predicted volume is less than a threshold, and / or the congestion duration is shorter than a time threshold.

[0219] Regarding the WTRU and network handshake, the WTRU may indicate at least one of the following: predicted congestion and / or congestion timing (e.g., start, end, and / or duration), the determined and / or predicted service status of the gNB (e.g., before the start time of the congestion), whether the WTRU has determined to postpone beam failure detection and associated BFR, and / or predicted second beam (or RS). This can be as part of a CSI report or via a separate SR. The WTRU may indicate that it has predicted congestion. Due to low service, the WTRU may postpone the BFR. The WTRU may indicate the BFD-RS set for predicted congestion. This indication may include the second predicted beam, the duration of the BFR to be postponed (TPP_BFR), the location of the WTRU, RSRP measurements of the BFD-RS set for predicted congestion, etc.

[0220] The WTRU can receive acknowledgment and / or rejection and / or enable and / or disable instructions from the gNB. If acknowledged, the WTRU can receive instructions regarding the duration (e.g., delay period) of delaying BFD and / or associated BFR, corresponding parameters, etc. The WTRU may delay BFD and / or associated BFR. If rejected, the WTRU may execute BFR; the WTRU may report beam failure; and / or the US may send RACH, etc.

[0221] After one or more of the following has elapsed: the end of the BFD and / or associated BFR delay process and / or the duration of the blocking or delay of the BFD and / or associated BFR, the WTRU may determine whether the BFD conditions still apply (e.g., based on measurements of the configured BFD-RS set). The WTRU may attempt to detect the CORESET and / or receive the PDCCH to measure beam quality (e.g., based on the PDCCH DMRS).

[0222] If the conditions still apply, the WTRU may perform a beam failure (e.g., the WTRU reports a beam failure; and / or sends a RACH, etc.). If the conditions no longer apply, the WTRU may send a report to the gNB. The WTRU may send a UL transmission (e.g., via SR, UCI, and / or MAC-CE, etc.) indicating that beam failure was avoided. The WTRU may report measurements taken before and / or during the blocking (if any), for example, for gNB training purposes.

[0223] The WTRU can determine and / or predict the occurrence of a congestion event. Prediction can be based on one or more of the following: measurements. The WTRU can perform measurements on one or more RSs configured for congestion prediction and / or configured for other purposes; WTRU location, based on current and / or predicted future location; WTRU trajectory, where the WTRU can predict congestion based on current mobility, speed and / or direction and / or predicted future speed and / or direction; historical congestion identification, where the WTRU can store previous congestion determinations; the WTRU can be configured with congestion information (e.g., by gNB); AI / ML models, where the WTRU can use AI / ML models whose inputs include any elements in this list, and / or their outputs to predict congestion and / or their parameters.

[0224] The blocking can be predicted to be temporary or of fixed duration. A predicted blocking event and / or a predicted blocking event can be defined as at least one of the following: one or more beam failure events. Predicted blocking can be defined as a prediction that one or more beam failure events will occur consecutively. Predicted blocking can be defined as a prediction that one or more beam failure events will occur within a fixed time period. Predicted blocking can be defined as a prediction that one or more beam failure events will occur on one or more beams and / or RS (e.g., BFD-RS). Predicted blocking can be defined as a prediction that all beam measurements will be identified as beam failure events. Predicted blocking can be defined as a prediction that no beam measurement may be identified as a beam failure for a period of time.

[0225] If the RSRP is below a threshold, congestion can be predicted. Predicted congestion can be defined as a prediction that one or more RSRP measurements on one or more RSs (e.g., BFD-RS) will be below the corresponding threshold. Predicted congestion can also be defined as a prediction that one or more RSRP measurements on one or more RSs (e.g., BFD-RS) will be below the threshold for a period of time. Furthermore, predicted congestion can be defined as a prediction that no RSRP measurement will be above the threshold for a period of time. The threshold and / or the time period can be configurable (e.g., via RRC, MAC-CE, and / or DCI indication signaling).

[0226] Blocking can be predicted when one or more blocking conditions are met. Blocking conditions can include any elements disclosed herein. For example, a blocking condition can be defined as blocking determinism.

[0227] Blocking can be predicted by listening-before-speaking (LBT) failures. Predicting blocking can be defined as the prediction that one or more potentially consecutive LBT processes will fail. Predicting blocking can be defined as the prediction that one or more LBT processes will fail over a period of time. Predicting blocking can be defined as the prediction that no LBT process will succeed over a period of time.

[0228] The WTRU can predict and / or report parameters for predicting blocking events. Parameters for predicting blocking events may include at least one of the following: beam and / or RS set. The WTRU can predict blocking of one or more beams and / or one or more RS sets (e.g., BFD-RS set).

[0229] Duration can be a parameter of a blocking event. WTRU can predict the duration of a predicted blockage. Duration can be defined as the time at which a blockage is predicted to occur, the number of time slots, the number of symbols, and / or the number of subframes.

[0230] Start and / or end times can be parameters of a blocking event. The WTRU can predict the start time, symbol, time slot, subframe, and / or end time, symbol, time slot, and / or subframe for blocking. The start time can be defined as when the WTRU predicts a blocking event will be declared. The end time can be defined as when the WTRU predicts the blocking condition will no longer exist. If measurements are determined not to indicate beam failure and / or are above a threshold, the WTRU can determine that the blocking condition no longer exists.

[0231] Measured or predicted measurements can be parameters of a blocking event. WTRU can determine the measured values ​​at the time of blocking prediction. WTRU can determine the predicted measured values ​​during the predicted blocking duration. Predicted measurements can be measurements used to determine beam failure events. Measured values ​​can be defined as a range of maximum and minimum values ​​during the predicted blocking duration. Predicted measurements can be used to determine if the predicted blocking has ended. Predicted measurements can be associated with beams or RSs for which blocking events have been predicted. Predicted values ​​can be associated with beams and / or RSs different from those for which blocking events have been predicted. WTRU can predict the optimal beam or optimal set of RSs (e.g., BFD-RS set and / or candidate RS set). The predicted optimal beam and / or optimal set of RSs can be determined based on predicted and / or actual measurements.

[0232] The optimal beam and / or optimal RS set can be determined for different times: the optimal beam and / or optimal RS set at the time of blocking prediction, the optimal beam or optimal RS set at the beginning of the predicted blocking, the optimal beam or optimal RS set at some point during the predicted blocking duration, and / or the optimal beam or optimal RS set at the end of the predicted blocking.

[0233] Prediction quality can be a parameter of the blocking event. WTRU can determine the quality of a prediction that foreshadows blocking. Quality can indicate the determinism of whether a blocking event and / or its parameters have occurred.

[0234] The WTRU position can be a parameter of a blocking event. The WTRU position can include at least one of the following: the WTRU position at the time of blocking prediction, the WTRU position at the time of blocking prediction start, and / or the WTRU position at the time of blocking end.

[0235] When determining predicted congestion, the WTRU may exhibit specific behaviors. The WTRU can predict congestion events or their parameters. The WTRU may be configured with transmission parameters and / or may determine or predict transmission parameters. Transmission parameters may include at least one of the following: UL and / or DL ​​data volumes. The WTRU may predict, determine, and / or configure UL and / or DL ​​data volumes. UL and / or DL ​​data volumes may be applicable during congestion prediction or at the start time of the congestion prediction prediction.

[0236] UL and / or DL ​​data parameters. WTRU can predict, determine, and / or configure parameters associated with current or upcoming UL and / or DL ​​data. These parameters may include at least one of the following: user plane and / or control plane, SRB and / or DRB, LCH, priority (e.g., LCH priority and / or L1 priority), QoS, delay budget, required reliability, and / or Hybrid Automatic Request (HARQ) operating point.

[0237] When the WTRU predicts congestion, it can determine the action to take. The action to take may include at least one of the following: delaying or postponing beam failure detection (BFD). The WTRU may delay or postpone BFD for a period of time. The WTRU may stop or pause BFD measurements for a period of time. The WTRU may skip beam failure measurements during the predicted congestion duration without incrementing the BFI counter. During the predicted congestion duration, the WTRU may pause and / or skip the BFI count. In another example, the WTRU may increment the value of a beam failure counter or timer.

[0238] The WTRU may employ behavior to delay and / or postpone beam failure recovery (BFR). The WTRU may delay or postpone BFR for a period of time.

[0239] The WTRU may preemptively announce beam failure (BFD) and / or initiate beam retrieval (BFR). When blocking is predicted, the WTRU can announce a beam failure before the blocking itself occurs. The WTRU can adjust BFD parameters (e.g., counters and / or timers) to allow it to confirm the predicted blocking. This allows the WTRU to confirm predicted blocking faster than conventional beam failure detection.

[0240] The WTRU can perform beam switching behavior. The WTRU can be configured, instructed, and / or determined to switch to a selected beam different from the original first beam predicted to be blocked. The WTRU can optionally switch to a second predicted beam, a third configured beam, and / or a fourth candidate beam. Beam switching may include transmitting a PRACH on the selected beam. Beam switching can be RACH-free. The WTRU can transmit configured UL transmissions (e.g., PUCCH, PUSCH, etc.) based on the selected beam. The WTRU can transmit SRs based on a spatial filter corresponding to the selected beam.

[0241] The WTRU can perform a handover to another cell. The WTRU can be configured, instructed, and / or determined to perform a handover to a configured and / or determined second cell, which is different from the first cell predicted to be congested.

[0242] The WTRU can perform normal behavior (e.g., announcing BFD and / or initiating BFR when a blocking event occurs). For example, the WTRU can be configured, instructed, and / or determined to fall back to a beam failure recovery procedure received via, for example, RRC, MAC-CE, and / or DCI.

[0243] The WTRU can employ behavior that indicates predicted congestion. The WTRU can send a report (e.g., to the gNB) to indicate a predicted congestion event. The WTRU can send this report as part of the CSI, a separate SR, or an enhanced HARQ-ACK via, for example, RRC, MAC-CE, and / or UCI.

[0244] The WTRU can determine its behavior when congestion is predicted based on at least one of the following: one or more transmission parameters. If UL and / or DL ​​traffic volume is below a threshold, the WTRU can determine to delay or postpone BFD and / or BFR. If UL and / or DL ​​traffic volume is above a threshold, the WTRU can determine to declare BFD and / or execute BFR. If it is determined that the priority of UL and / or DL ​​traffic is greater than a possible configurable value, the WTRU can preemptively declare BFD and / or trigger BFR.

[0245] The WTRU can determine its behavior based on predicted and / or determined blocking event parameters. If the predicted duration of the blocking event is less than a threshold, the WTRU can delay and / or postpone BFD and / or BFR. If the predicted duration is greater than the threshold, the WTRU can declare BFD and / or execute BFR.

[0246] WTRU can determine its behavior based on predicted and / or actual measurements. For example, WTRU can determine the behavior to be adopted based on actual measurements (e.g., at or before the predicted blockage) and / or predicted measurements (e.g., at any time during the blockage duration and / or after the blockage duration).

[0247] WTRU can determine its behavior based on prediction quality. If the prediction quality and / or expected accuracy is greater than a threshold, WTRU can choose a first behavior (e.g., delayed BFD and / or BFR). If the prediction quality and / or expected accuracy is less than a threshold, WTRU can choose a second behavior (e.g., regular BFD and / or BFR behavior).

[0248] The WTRU can use a combination of the listed methods to determine the action to take when congestion is predicted. If the predicted congestion duration is less than a first threshold and the predicted UL and / or DL ​​traffic is less than a second threshold, the WTRU may delay and / or postpone and / or adjust the parameters of BFD and / or BFR. If the predicted congestion duration is less than the first threshold and / or the predicted UL and / or DL ​​traffic is greater than the second threshold, the WTRU may switch beams. If the predicted congestion duration is greater than the first threshold and / or the predicted UL and / or DL ​​traffic is less than the second threshold, the WTRU may perform a regular BFD and / or BFR. If the predicted congestion duration is greater than the first threshold and / or the predicted UL and / or DL ​​traffic is greater than the second threshold, the WTRU may preemptively declare BFD and / or trigger BFR.

[0249] A WTRU can provide an indication of a predicted blocking event. A WTRU can instruct (e.g., to a gNB and / or another WTRU) to predict a blocking event or one or more blocking parameters. The WTRU can determine the indication to predict a blocking event based on the timing of the predicted blocking event (e.g., the timing relative to the prediction of the blocking event). If the time difference between the predicted time of the blocking event and the predicted time of the blocking event is greater than a possible configurable value, the WTRU can instruct blocking and / or one or more blocking parameters.

[0250] WTRU can indicate the WTRU-determined and / or WTRU-preferred behavior used to predict congestion events. WTRU can explicitly indicate the behavior determined by WTRU. WTRU can indicate the measurement and / or trigger and / or prediction values ​​used to determine the WTRU-preferred behavior (e.g., indicating the predicted duration and / or predicted traffic volume above and / or below a threshold).

[0251] When the WTRU performs a BFR (either preemptively and / or using regular behavior or after a delayed and / or postponed period of time), the WTRU may indicate a cause (e.g., a predicted blocking event) and / or one or more predicted blocking parameters.

[0252] The WTRU can indicate the preferred beam to be used during or after a predicted blocking event. The WTRU can report the duration to be delayed (e.g., TPP_BFR), the location of the WTRU, and / or measurements of quality parameters (e.g., RSRP) of one or more BFD-RS sets predicted to be blocked.

[0253] Instructions can be transmitted in pre-configured resources (e.g., CG resources) and / or can be multiplexed onto DG or CG permissions. WTRU can send instructions in at least one of the following: UCI, CSI report, SR, MAC CE, PRACH, and / or RRC.

[0254] The WTRU can receive acknowledgments of predicted blocking events. After sending an indication of a predicted blocking event, the WTRU can monitor the reception of the indication to determine whether it has received acknowledgment or rejection of the action determined by the WTRU (e.g., from the gNB and / or other WTRUs). The WTRU can indicate that it is delaying and / or postponing BFD and / or BFR. The WTRU can monitor (e.g., from the gNB) for acknowledgment of this. If the WTRU does not receive acknowledgment (e.g., from the gNB), the WTRU can assume a NACK and / or proceed using normal methods (e.g., waiting until a beam failure event is actually detected and / or then triggering BFR).

[0255] The WTRU can determine its behavior or parameters based on received instructions (e.g., from the gNB). For example, the WTRU can instruct on predicted blocking and predicted blocking parameters, and can determine BFD or BFR delay parameters (e.g., delay duration, delay timing, and behavior after the delay period) based on received instructions (e.g., from the gNB).

[0256] The WTRU can receive rejections and / or unacknowledgements (e.g., from the gNB), therefore, the WTRU can not delay, postpone, or preempt BFD or BFR. The WTRU can ignore predicted blocking and / or predicted blocking parameters, but can continue to predict future blocking. The WTRU can receive commands to deactivate blocking prediction.

[0257] The WTRU can be monitored and confirmed, for example, in the DCI (e.g., from the gNB), possibly in a specific CORESET or search space or DCI format. The CORESET, search space, and / or DCI format can be determined based on one or more predictive blocking parameters, or one or more currently configured beams, and / or TCI status or QCL indication.

[0258] The WTRU can define and / or configure a time period during which it can delay and / or postpone BFD and / or BFR. The time period can be measured in symbols, time slots, subframes, and / or time units (e.g., ms, microseconds, etc.). After the delay and / or postponement period has elapsed, the WTRU can define or configure WTRU behavior. After the delay and / or postponement period has elapsed, the WTRU can perform at least one of the following: determining whether the BFD conditions apply (or still apply) to the original beam or original RS set. The WTRU can have a second set of BFD parameters (e.g., counters and / or timers) for measurements of the original beam or RS. The second set of BFD parameters can be the same as the regular parameter set.

[0259] After the delay and / or postponement time has elapsed, the WTRU can determine whether the BFD conditions apply to the predicted second beam and / or RS set. The WTRU can use a standard set of BFD parameters and / or a second set of BFD parameters. After the delay and / or postponement time has elapsed, the WTRU can attempt to detect the PDCCH on the CORESET to measure beam quality (e.g., on the PDCCH DMRS).

[0260] If the WTRU determines that no failure has occurred in the original beam or RS set or the second beam or RS set (e.g., the measurement is above a threshold), the WTRU may report (e.g., to the gNB) that beam failure may no longer be applicable after the blocking duration. The WTRU may determine and / or indicate the accuracy of the prediction (e.g., by comparing the predicted measurement with the actual measurement).

[0261] If the WTRU determines a BFD on the original beam and / or RS set or one or more second beams or RS sets, the UE may declare a beam failure and / or trigger a BFR. The WTRU may determine and / or report the prediction accuracy of the predicted blocking and / or measurements after the predicted blocking ends. Reporting of post-blocking event beam failure and / or prediction accuracy performance may be accomplished by at least one of the following: SR, UCI, MAC CE, PUCCH, PUSCH, and / or RRC.

[0262] In the case of more than one BFD-RS set, the WTRU can perform a handshake when delaying the BFR. In this case, the WTRU can perform and / or be configured with one or more of the following: The WTRU can be configured with more than one BFD-RS set. The WTRU can detect a (pre-configured) number of BFIs. Therefore, the WTRU can even determine a BFD on the first BFD-RS set. The WTRU can determine that a second BFD-RS set has not experienced a BFD. The WTRU can determine and / or predict potential service states based on the first BFD-RS set. If the determined service is low (non-urgent), the WTRU can determine to delay beam failure detection and / or further BFR for the first BFD-RS set. The WTRU can be (pre-configured) with a first duration (T). PP_BFR ), to postpone BFR for the first BFD-RS set.

[0263] WTRU can predict the duration of delay (T) PP_BFR The second predicted beam may be the optimal beam after that. The second predicted beam may be the same as or different from the beam in the configured first BFD-RS set.

[0264] Regarding the handshake, the WTRU can indicate the detected BFD and / or predicted traffic to the gNB via the second BFD-RS set beam. The WTRU can send the indication as part of a CSI report or via a separate SR. The WTRU can indicate that it has detected a BFD on the first BFD-RS set. The WTRU can indicate that it will postpone the BFR due to low traffic. The WTRU can indicate the BFD-RS set where the BFD was detected. The indication may include the second prediction beam, the duration to be postponed (T... PP_BFR ), the location of WTRU, RSRP measurement of the BFD-RS set detected by BFD, etc.

[0265] The WTRU can receive acknowledgment and / or rejection and / or enable and / or disable indications from the gNB. If acknowledged, the WTRU can receive indications regarding duration, operating mode, and / or corresponding parameters, etc. The WTRU can accordingly defer BFR for the first BFD-RS set. If rejected, the WTRU can receive indications regarding the operating mode. The WTRU may fall back to normal BFR. In other words, the WTRU can report beam failure (e.g., transmitting RACH, etc.).

[0266] After the BFR delay process ends and the configured and / or determined time has elapsed, the WTRU can determine whether the BFD conditions still apply to the first BFD-RS set. The WTRU may attempt to detect the CORESET and / or receive the PDCCH to measure beam quality (e.g., based on PDCCH DMRS). If the conditions still apply, the WTRU may fall back to normal BFR. In other words, the WTRU may report a beam failure (e.g., transmitting RACH, etc.). If the conditions no longer apply, the WTRU may send a report to the gNB. The WTRU may send a UL (e.g., via SR, UCI, and / or MAC-CE, etc.) indicating that a beam failure has occurred. The WTRU may report measurements taken before and / or during the blocking (e.g., for gNB training purposes).

[0267] In the case of more than one BFD-RS set, the WTRU can be configured with one or more of the following for delaying BFR: configuration on more than one BFD-RS set; threshold regarding the number of BFIs; threshold regarding the service status; duration of delaying BFR (TPP_BFR); and indication of the predicted duration of delaying BFR (TPP_BFR).

[0268] For each configured BFD-RS set, the WTRU can be configured with individual configuration information. The WTRU can be configured with a first service level, a first duration for delaying BFR, a first indication for enabling and / or disabling BFR delay, a first maximum value and / or threshold for the number of BFIs, etc., which can correspond to beams in the first BFD-RS set. The WTRU can be configured with a second service level, a second duration for delaying BFR, a second indication for enabling and / or disabling BFR delay, a second maximum value and / or threshold for the number of BFIs, etc., which can correspond to beams in the second BFD-RS set, and so on.

[0269] The WTRU may trigger a BFR deferral process based on one or more of the following conditions: The WTRU may detect BFIs on the first BFD-RS set. If the number of detected BFIs exceeds a configured threshold, the WTRU may trigger a BFR deferral process. The WTRU may have detected a (pre-configured) number of BFIs and may predict service status based on the first BFD set RS. If the WTRU determines that the predicted service status is below the configured threshold, the WTRU may trigger a BFR deferral process. The WTRU may have detected a (pre-configured) number of BFIs and may configure, indicate, and / or determine the priority level of the service status, such as QoS priority, based on the first BFD set RS. If the WTRU determines that the predicted priority level of user plane and / or control plane functions is low (e.g., not urgent), the WTRU may trigger a BFR deferral process.

[0270] [Procedure for Deferring BFR] After triggering a deferral of BFR for the first BFD-RS set, the WTRU may follow this procedure: The WTRU may determine that the second BFD-RS set has not experienced BFD, e.g., no BFI occurred, and / or the number of BFIs in the second BFD-RS set is below a configured second threshold. The WTRU may predict that the second beam is likely to be the optimal beam after the configured deferral duration (TPP_BFR) has elapsed. The WTRU may use a pre-trained AI / ML model to predict the optimal beam after the configured deferral time has elapsed. The second predicted beam may be the same as or different from the beams in the configured first BFD-RS set; for example, the WTRU may predict a new beam from set A as the second predicted beam. The WTRU may also predict the optimal deferral duration (e.g., TPP_BFR) to be reported to the NW, if configured by the NW.

[0271] The WTRU can initiate a handshake process to receive a BFR decision from the NW. The WTRU can initiate a handshake upon detecting a beam failure on the first BFD-RS set. The WTRU can initiate a handshake via at least one beam from the second BFD-RS set. The WTRU can transmit the indication as part of a CSI report via a separate SR, or as part of an enhanced HARQ-ACK codebook, for example via UCI, MAC-CE, RRC, etc.

[0272] The WTRU can indicate one or more of the following to the NW in the handshake feedback: detection of BFD; identifier on the BFD-RS set where BFD was detected; approval request to postpone BFR due to detected beam failure and low traffic (or low priority (e.g., low QoS) traffic); if configured, the WTRU can also indicate the predicted optimal postponement duration T. PP_BFR ; the predicted second beam and / or predicted metrics used after the delay time has elapsed, such as predicted RSRP and / or predicted traffic; the speed and / or location of the WTRU; and / or the RSRP measurement of the BFD-RS set detected by the BFD.

[0273] The WTRU can receive acknowledgment, rejection, enable, and / or disable instructions (e.g., from the gNB) to perform the BFR deferral determined by the WTRU. The WTRU can receive instructions via DCI, MAC-CE, and / or RRC, etc.

[0274] If the BFR delay is confirmed, the WTRU can receive information regarding the duration (T). PP_BFR One or more instructions from the WTRU. The indicated delay duration may differ from the duration requested by the WTRU. If the BFR delay is confirmed, the WTRU may receive one or more operating modes and / or corresponding parameters. The WTRU may delay the BFR accordingly for the first BFD-RS set. The WTRU may increment the default T. PP_BFR Then, the BFR is delayed. If the BFD still applies to the first BFD-RS set after the delay time has elapsed, the WTRU can switch to the predicted second beam. If the BFD still applies to the first BFD-RS set after the delay time has elapsed, the WTRU can switch to the indicated third beam corresponding to the second BFD-RS set. If the BFD still applies to the first BFD-RS set after the delay time has elapsed, the WTRU can revert to the regular BFR.

[0275] If the BFR delay is rejected, the WTRU can be instructed to do one of the following: the WTRU can switch to another beam associated with the second BFD-RS set; the WTRU can fall back to the regular BFR; and / or can report a beam failure, for example, by sending a RACH.

[0276] If BFR deferral is permitted and / or if the WTRU defers BFR, the WTRU can determine whether the BFD conditions still apply to the first BFD-RS set after the BFR deferral process is completed and / or the configured and / or determined deferral time has elapsed. The WTRU may attempt to detect CORESET and / or receive PDCCH to measure beam quality (e.g., based on PDCCH DMRS).

[0277] If the BFR conditions still apply to the first BFR-RS set, the WTRU may follow one of the following procedures: The WTRU may fall back to the normal BFR and may report a beam failure (e.g., by sending a RACH). The WTRU may switch to the second predicted beam. The WTRU may send a PRACH on the second detection beam. The WTRU may detect the CORESET and receive a PDCCH to measure the beam quality of the second beam and send a UL via the second beam resources (e.g., via SR, UCI, and / or MAC-CE, etc.), indicating that the WTRU has switched to the second beam. The WTRU may switch to the third beam corresponding to the second BFD-RS. The WTRU may detect the CORESET and / or receive a PDCCH to measure the beam quality of the third beam. The WTRU may send a UL via the third beam resources (e.g., via SR, UCI, and / or MAC-CE, etc.), indicating that the WTRU has switched to the third beam.

[0278] If the BFR conditions on the first BFR-RS set no longer apply, the WTRU may send a report to the gNB including one or more of the following: The WTRU may send a UL (e.g., via SR, UCI, and / or MAC-CE, etc.) indicating that a beam failure has occurred. The WTRU may report measurements taken before and / or during the blocking (e.g., for gNB training purposes), including one or more of the following: RSRP measurements for the first and / or second BFD-RS sets; accumulated traffic at the UP and / or CP buffers; prediction accuracy of the traffic prediction model; prediction accuracy of the delay time prediction model; and / or the WTRU's speed, location, and / or trajectory.

[0279] The WTRU can perform the selection and / or reporting of preferred BFR delay methods. The WTRU can determine and / or report preferred parameters for delaying BFD and / or associated BFR based on the WTRU's position relative to the beam pattern, beam measurement quality, and / or prediction accuracy, etc.

[0280] The WTRU can be configured with a first set of BFR parameters, including a first BFI maximum counter (e.g., BFI-MAX-1) and / or a first set of BFD-RS, etc.

[0281] The WTRU can determine and / or receive indications for enabling, allowing, activating, and / or acknowledging the postponement of a first configuration and / or determined duration (e.g., T) of the BFD and / or associated BFR process on one or more first BFD-RS set beams (or RSs). PP_BFR1 ).

[0282] WTRU can predict the duration of determination / configuration (T) PP_BFR The second (optimal) beam (or RS) to be used after that. The WTRU can perform predictions (e.g., based on the WTRU's velocity, orientation, position, and / or AI / ML, etc.).

[0283] The WTRU can be configured with multiple parameters for delaying BFD and / or associated BFR (e.g., extending the number of BFI counters and / or timers). The WTRU can be configured with one or more second sets of BFD and / or BFR parameters, including one or more second BFI maximum counters, one or more second sets of BFD-RS sets, and / or one or more durations for delaying BFD and / or associated BFR.

[0284] The WTRU can select a second set of BFD and / or BFR parameters from one or more configured second set parameters for BFD and / or associated BFR postponement (e.g., before BFD occurs). Selection can be based on at least one of the following: the accuracy of beam prediction, the predicted second beam, and / or upcoming UL traffic.

[0285] The WTRU can determine the acceptable accuracy of beam prediction. If the WTRU can determine that the prediction accuracy of the second predicted beam is acceptable, i.e., the accuracy parameter is above a first threshold, then the original first BFD-RS ensemble beam and / or the predicted second beam are identical. If the WTRU can determine that the second predicted beam is identical to the first beam, then the WTRU can determine the first operating mode as the preferred mode. This may occur if the WTRU is centered on the first beam, and / or if the WTRU moves towards the center (e.g., based on increased differential RSRP measurements).

[0286] The original first BFD-RS ensemble beam and / or the predicted second beam can be different. If the WTRU determines that the second predicted beam is different from its first beam, the WTRU can determine the third operating mode as the preferred mode. This occurs if the WTRU is at the cell edge of the first beam, or if it is facing the cell edge (e.g., based on reduced differential RSRP measurements).

[0287] The WTRU can perform general accuracy checks on beam prediction. If the WTRU can determine that the prediction accuracy of the second predicted beam is general (i.e., the accuracy parameter is below a first threshold and / or above a second threshold), the original first BFD-RS set beam and / or the predicted second beam can be the same. This can also happen if the WTRU can determine that the second predicted beam is the same as the first beam. This is possible if the WTRU is centered on the first beam, or if the WTRU moves towards the center (e.g., based on increased differential RSRP measurements). The WTRU can use a first configured BFD-RS set. The WTRU can select a second BFI maximum counter (BFI-MAX-2) from one or more configured second BFI maximum counters. The WTRU can optionally delay a second time (T) of the BFD and / or associated BFR. PP_BFR2 During this period, WTRU can predict that the first and / or second beams are the same based on the accuracy level.

[0288] The original first BFD-RS set beam and / or predicted second beam can be different if the WTRU can determine that the second predicted beam is different from its first beam. This may occur if the WTRU is at the cell edge of the first beam, or if the WTRU moves toward the cell edge (e.g., based on reduced differential RSRP measurements). The WTRU can select a third BFI maximum counter (BFI-MAX-3) from one or more configured second BFI maximum counters. The WTRU can also choose to postpone a third time (T) of BFD and / or associated BFR. PP_BFR3 Then, the WTRU can predict that the second predicted beam becomes different from the first configured BFD-RS set based on the accuracy level. The WTRU can select a second set of BFD-RS from one or more configured second sets of BFD-RS sets, for example, based on an AI / ML model and / or the predicted second beam.

[0289] The WTRU can determine unacceptable accuracy for beam prediction. If the WTRU determines that the prediction accuracy of the second predicted beam is unacceptable, i.e., the accuracy parameter is below a second threshold, the WTRU can select a fourth BFI maximum counter (BFI-MAX-4) from one or more configured second BFI maximum counters (e.g., where BFI-MAX-4 can be lower than BFI-MAX-2 and / or BFI-MAX-3). The WTRU can also choose to delay the fourth duration (T) of the BFD and / or associated BFR. PP_BFR4 ).

[0290] The WTRU can identify upcoming UL services. If the WTRU identifies one or more UL services (e.g., SR and / or RACH, etc.), the WTRU can perform a BFR.

[0291] The WTRU can perform reporting. The WTRU can send an indication to the gNB that selects a second set of BFD and / or BFR parameters (e.g., if BFD is detected in a future time window). The WTRU can send the indication as part of a CSI report (e.g., periodically) or via a separate SR (e.g., semi-persistent and / or aperiodic transmission). The indication may include one or more parameters, such as a selected BFI maximum counter, the duration for which BFD and / or associated BFR are delayed, and / or the BFD-RS set, etc. The indication may include the effective duration of the selected second set of BFD and / or BFR parameters (e.g., after which the WTRU can fall back to the first set of BFD and / or BFR parameters). The WTRU can receive acknowledgments, value adjustments, and / or rejection indications from the gNB.

[0292] The WTRU can determine and / or receive one or more indications and / or configuration information that can allow, enable, acknowledge, and / or activate the postponement of the BFR on one or more first BFD-RS set beams for a configured, indicated, and / or determined duration (e.g., TPP_BFR). The WTRU may be able to predict a second (optimal) beam to be used after a certain duration. The WTRU can predict a second (optimal) beam after the BFR postponement duration (TPP_BFR). The WTRU can predict the second beam based on a training dataset (e.g., in AI / ML), the WTRU's velocity, orientation, position, and / or one or more beam quality measurements (e.g., RSRP).

[0293] When delaying BFR, the WTRU can be configured with one or more operating modes. The WTRU can use one or more of the following modes: First mode: Hold Tx / Rx. For example, the WTRU can hold any transmit, receive, BFR, etc., as in a semi-persistent and / or aperiodic DRX and / or DTX oriented towards the WTRU. Second mode: Extend BFD. For example, the WTRU can extend the BFI counter, timer, and / or candidate beam set, etc. Third mode: Beam switching. For example, the WTRU can skip the BFR on the first beam and / or perform a beam switch to the second beam. Fourth mode: The WTRU can fall back to normal BFR.

[0294] The WTRU can determine the operating mode for delaying BFR based on one or more conditions. The WTRU can determine the operating mode before detecting beam failure and / or triggering BFD. The WTRU can determine the operating mode based on one or more of the following example conditions: accuracy of beam prediction conditions. The WTRU can determine that the prediction accuracy of the optimal future beam is acceptable. That is, the WTRU can determine that the accuracy of one or more predicted beam resources and / or corresponding predicted quality parameters is higher than a specified, determined, and / or configured first threshold. The WTRU can determine the accuracy of the prediction parameters by comparing one or more predicted beam resources with one or more corresponding measurement parameters. If the difference is below the first threshold, the WTRU can determine that the accuracy is valid and / or acceptable. When the difference is above the first threshold and below a second threshold, the WTRU can determine that the accuracy is general. When the difference is above the second threshold, the WTRU can determine that the accuracy is unacceptable and / or invalid.

[0295] The WTRU can determine the operating mode based on the predicted second beam conditions. The WTRU can determine whether the predicted second beam in the time domain is the same as or different from the beam resources in the first BFD-RS set.

[0296] The WTRU can determine the operating mode based on upcoming UL service conditions. The WTRU can identify UL services that are not scheduled and / or configured during the duration of the delayed BFR (e.g., TPP_BFR). The WTRU can identify one or more UL services that are scheduled and / or configured for the duration of the delayed BFR (e.g., TPP_BFR). UL services may include one or more of SR, RACH, PUCCH, and / or PUSCH.

[0297] If the accuracy of the future optimal beam prediction is acceptable, the WTRU can perform the procedure. The WTRU can determine that the accuracy of the beam prediction is acceptable and / or valid. Thus, the WTRU can determine the optimal second beam in the time domain, for example, after the BFR delay has passed (e.g., TPP_BFR).

[0298] If the WTRU determines that the predicted second beam in the first BFD-RS set is the same as the original first beam, the WTRU can use the first operating mode. That is, after the BFR delay duration has elapsed, the WTRU can use the first original beam.

[0299] For example, see Figure 4 WTRU 410, which is served via beam #1 420 (e.g., in a moving car), is temporarily blocked. Figure 4 The scenario described is that beam #1 420 is temporarily blocked and WTRU 410 is moving toward the center of beam #1 420. In this case, WTRU 410 can determine to postpone the BFR process for a certain duration. WTRU 410 can predict that after the duration has elapsed, WTRU 410 will still be near beam #1 420 and can be served by beam #1 420.

[0300] In this scenario, the WTRU 410 can determine to use a first operating mode, in which the WTRU 410 maintains any transmit, receive, BFR, etc., for a determined and / or (pre-)configured duration. The WTRU 410 can continue operating, transmitting, receiving, etc., based on the first beam after the time has elapsed.

[0301] In replacement scenarios, if the WTRU determines that the predicted second beam differs from the original first beam, the WTRU can determine to use a third operating mode. That is, after the BFR delay duration has elapsed, the WTRU can use the second predicted beam. For example, in... Figure 5 In this case, WTRU 510, which is being served via beam #1 520 (e.g., in a moving car), is temporarily blocked. Figure 5 The scenario described is that beam #1 520 is temporarily blocked and WTRU 510 is moving toward the center of beam #2 530.

[0302] In this scenario, WTRU 510 can determine to postpone the BFR procedure for a certain duration. WTRU 510 can predict that after the duration has elapsed, WTRU may not be near beam #1 520. WTRU 510 can predict that by the time the BFR postponement duration has elapsed, WTRU 510 may be near beam #2 530 and can be served by beam #2 530.

[0303] In this scenario, the WTRU can determine to use the third operating mode. The WTRU can perform beam switching after the BFR delay duration has elapsed. The WTRU can transmit PRACH based on the second beam, and / or the WTRU can transmit one or more UL signals and / or channels based on the second beam. The UL signals and / or channels can be one or more of SRS, SR, PUCCH, and / or PUSCH, etc.

[0304] The WTRU can perform the process if the accuracy of predicting the best future beam is "general". If the WTRU determines that the accuracy of predicting the second beam is generally good, the WTRU can determine to postpone the BFR using a second operating mode. That is, the WTRU can determine to postpone the BFR for a first determined and / or (pre-)configured duration (e.g., TPP_BFR1), during which time the WTRU continues to measure and / or monitor the configured BFD-RS set. The WTRU can extend the maximum number to a second maximum value for detecting the BFI based on the first BFD-RS set that detects blocking and / or beam failure. The WTRU can measure and / or monitor the second BFD-RS set. The WTRU can monitor and / or measure a second set of candidate beams.

[0305] If the accuracy of predicting the best future beam is unacceptable, the WTRU can execute the following procedure. If the WTRU determines that it cannot predict the second beam and / or if the WTRU determines that the accuracy of predicting the second beam is unacceptable and / or invalid, the WTRU can determine to postpone the BFR using a second operating mode. That is, the WTRU can determine to postpone the BFR for a second determined and / or (pre-)configured duration (e.g., TPP_BFR2), during which time the WTRU continues to measure and monitor the configured set of BFD-RS. The second duration may be shorter than the first duration. In the example, the WTRU may extend the maximum number to a third maximum value for detecting the BFI based on the first set of BFD-RS that detects blocking and / or beam failure, where the third maximum value may be lower than the second maximum value. The WTRU can measure and / or monitor the second set of BFD-RS. The WTRU can monitor and / or measure a second set of candidate beams.

[0306] When the WTRU identifies one or more UL service opportunities, the WTRU may use a shorter BFR postponement duration or stop and / or cancel the BFR postponement process. One or more of the following may apply: a shorter BFR postponement duration. For example, the WTRU may determine the duration for the BFR postponement based on the next UL service opportunity. The WTRU may determine the duration from when the number of detected BFIs reaches its maximum value until the next UL service opportunity (e.g., TUL). The WTRU may determine the duration of the processing time for a regular BFR operation (e.g., Tlegacy_BFR). The WTRU may subtract the regular BFR processing time from the time until the next UL opportunity. The WTRU may use the resulting duration as the BFR postponement time (e.g., TPP_BFR = TUL – Tlegacy_BFR).

[0307] The WTRU can further determine, apply, and / or perform beam switching. For example, the WTRU can determine that the accuracy of predicting future beams is valid. The WTRU can predict the second beam that will be used when scheduling and / or configuring the next UL service. In this way, the WTRU can switch to the second predicted beam to perform the scheduled and / or configured UL transmission.

[0308] The WTRU can further determine, apply, and / or perform a fallback to the regular BFR procedure. The WTRU may determine that the accuracy of the predicted future beam is invalid, or that the WTRU cannot predict a second beam. Therefore, the WTRU may fall back to performing the regular BFR procedure. That is, the WTRU can measure one or more candidate beams and transmit a PRACH on the selected candidate beam (e.g., one with the highest RSRP).

[0309] The WTRU can also perform reporting as a preferred BFR postponement method. The WTRU can perform one or more of the following: if BFD is detected in a future time window, the WTRU can send an indication to the gNB indicating the preferred operating mode for BFR postponement. The WTRU can send the indication as part of a CSI report (periodically) or via a separate SR (semi-persistent or aperiodic transmission). The indication can include a time window during which the indicated preferred operating mode is valid. The indication can include one or more parameters regarding the indicated preferred operating mode: if a first operating mode is preferred, it can indicate short and / or long DRX periods. If a second operating mode is preferred, it can indicate the number of BFI extensions and / or the set of monitored BFR candidate beam extensions. If a third operating mode is preferred, it can indicate a predicted second beam. The WTRU can receive acknowledgments, value adjustments, and / or rejection indications from the gNB.

[0310] The WTRU may send one or more reports and / or indications to indicate a determined operating mode for deferring the BFR. Reports may include one or more pieces of information about the determined operating mode. The WTRU may send reports to the gNB. The WTRU may send reports and / or indications via UCI, MAC-CE, and / or RRC signaling. Indications and / or reports may include one or more of the following: the determined operating mode. The WTRU may indicate the determined operating mode using flag indications, where a first value (e.g., zero) may indicate a first mode, a second flag value (e.g., one) may indicate a second mode, a third flag value (e.g., two) may indicate a third mode, and so on. The WTRU may report one or more indications based on the determined operating mode.

[0311] For example, if the WTRU determines to use the first operating mode, the WTRU can report the determined short and / or long period times of the DRX. For example, if the WTRU determines to use the second operating mode, the WTRU can report the number of BFI extensions, the extended set of BFD-RS, and / or the extended set of candidate beam resources, etc. If the WTRU determines to use the third operating mode, the WTRU can report the predicted second beam.

[0312] Indications and / or reports may include duration. For example, a WTRU may indicate the time span for which a defined operating mode can be applied. A WTRU may indicate a start time, duration, and / or end time. A WTRU may indicate duration based on time instances, number of symbols, time slots, frames, and / or subframes. A WTRU may indicate duration based on time units, such as milliseconds and / or microseconds.

[0313] Indications and / or reports may include periodicity: the WTRU may indicate whether the operating mode determined by the application occurs semi-continuously, periodically, or aperiodically. The WTRU may determine the periodicity of the mode determined by the application based on detected, triggered, and / or determined conditions, such as the accuracy of beam prediction, the timing of configured and / or scheduled UL and / or DL, etc., as described herein.

[0314] Indications and / or reports may include quality parameters of the measurement. The WTRU may report one or more quality parameters of the measurement before blocking, during blocking and / or beam failure, and / or after the end of blocking and / or beam failure. The WTRU may report SS-RSRP, CSI-RSRP and / or RSRP of measurements based on PDCCH DMRS, RSRP based on PDSCH DMRS, RSRP based on PBCH DMRS, etc.

[0315] Indications and / or reports may include speed, position, and / or trajectory. WTRUs may report their position, speed, and / or trajectory before, during, and after blocking and / or beam failure.

[0316] The WTRU can be configured, determined, and / or (pre-)configured with time and / or frequency resources to send reports and / or indications. The WTRU can be configured and / or determined to send reports before or after applying a determined operating mode. In this case, one or more of the following can be applied: an indication before applying the determined mode. As described herein, a WTRU predicting congestion can determine to postpone the BFR based on one or more conditions. The WTRU can be (pre-configured) and / or determined to send reports before being blocked and upon detecting one or more conditions and / or receiving a trigger for future congestion. If there is a sufficiently long time window between detecting the condition and / or receiving the trigger and the congestion and / or beam failure, the WTRU can determine to send a report before the congestion.

[0317] When a WTRU is configured with more than one BFD-RS set, a WTRU that detects a beam failure based on the first BFD-RS set and / or a WTRU that predicts a blockage based on the first BFD-RS set can use one or more beam resources from the configured second BFD-RS set to send reports and / or indications.

[0318] The WTRU can be (pre-)configured or determined to send reports as part of a (pre-)configured CSI report. The WTRU can, for example, send (special) scheduling requests (SRs) via (pre-)configured PUCCH resources. In this way, the WTRU can send the determined operating mode and / or corresponding information as part of the sent SR.

[0319] The WTRU can be configured and / or determined to send an indication after delaying the BFR based on a determined pattern. The WTRU can be (pre-)configured and / or determined to send a report after delaying the BFR and after applying the determined pattern. In this case, one or more of the following can be applied: Implicit indication: The WTRU can indicate the delay of the BFR by sending a configured and / or scheduled UL after the delay duration has elapsed. The WTRU can use (pre-)configured UL resources configured for a specific SR transmission. Therefore, the gNB is aware that the WTRU has maintained any transmission based on the BFR delay process due to blocking and / or beam failure detection. The gNB is aware that the WTRU no longer experiences blocking and / or beam failure detection.

[0320] After applying the determined pattern, the WTRU can send explicit instructions: The WTRU can send reports and / or instructions via one or more explicit instructions. One or more of the following can be applied to explicit instructions: via UCI and / or MAC-CE: For example, the WTRU can send a report as part of a UCI and / or MAC-CE associated with one or more configured and / or scheduled UL transmissions. A WTRU scheduled to send a PUCCH may include a report as part of the transmitted UCI. A WTRU scheduled to send a PUSCH may include a report as part of the transmitted MAC-CE.

[0321] HARQ-ACK can be an explicit indication: for example, after a blocking event ends, a beam failure ends, and / or the BFR delay duration has elapsed, the WTRU can send a report as part of a HARQ-ACK transmission at least associated with the received PDCCH. The WTRU can send an enhanced HARQ-ACK codebook, which may include (flag) indications to indicate whether the WTRU has delayed the BFR. A first value (e.g., zero) may indicate a BFR delay, and / or a second flag value (e.g., a) may indicate no BFR delay.

[0322] After sending the report, the WTRU may receive acknowledgments, one or more adjustment commands for one or more parameters used for BFR postponement. The WTRU may receive rejection indications (e.g., from the gNB), whereby the WTRU may not perform BFR postponement and / or may roll back to the regular BFR procedure.

Claims

1. A wireless transceiver unit (WTRU), comprising: The processor is configured as follows: Determine the blocking of the first beam and the duration associated with the blocking of the first beam; When the amount of data associated with the first beam is less than a first threshold, the priority of the data associated with the first beam is less than a second threshold, or the duration associated with the blocking of the determined first beam is less than a third threshold, delayed beam failure detection (BFD) or beam failure recovery (BFR) is determined; and Send a first report to the network, the first report including one or more of the following: an indication of a determined blockage, an indication of the duration of the blockage associated with the determined first beam, an indication of the amount of data associated with the first beam, the priority of the data associated with the first beam, an indication that BFD or BFR has been postponed, or an indication that a second beam has been selected.

2. The WTRU according to claim 1, wherein, The WTRU determines the blocking of the first beam using an artificial intelligence or machine learning (AI / ML) model.

3. The WTRU according to claim 1, wherein, The processor is also configured to: The system uses artificial intelligence or machine learning (AI / ML) models to determine if a blockage still exists after the duration has expired; and BFR is executed based on the determination that there is still a blockage after the duration expires.

4. The WTRU according to claim 1, wherein, The processor is also configured to: It is confirmed that there is no blockage after the duration expires; and Based on the determination that there is no congestion after the duration expires, a second report is sent to the network, wherein the second report includes an indication that there is no congestion.

5. The WTRU according to any one of claims 1 to 4, wherein, The processor is configured to: The second beam is selected based on the determination that the second beam has a beam measurement and / or prediction value greater than that of the first beam.

6. The WTRU according to any one of claims 1 to 5, wherein, The first report may also include one or more of the following: the start time of the duration or the end time of the duration.

7. The WTRU according to any one of claims 1 to 6, wherein, The processor is configured to: Determine the amount of data associated with the first beam prior to the start time of the blocking.

8. The WTRU according to any one of claims 1 to 7, wherein, The processor is configured to: Receive an instruction from the network, wherein the instruction includes confirmation or rejection of postponing BFD or BFR.

9. The WTRU according to claim 8, wherein, The processor is configured to: Receive an indication of a delay period from the network, wherein the indication of the delay period is based on an indication including confirmation of a delay of BFD or BFR, wherein the delay period indicates how long the BFD or BFR is delayed.

10. The WTRU according to claim 8, wherein, The processor is configured to: Based on instructions from the network, including rejection of postponement of BFD or BFR, execute BFR.

11. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Determine the blocking of the first beam and the duration associated with the blocking of the first beam; When the amount of data associated with the first beam is less than a first threshold, the priority of the data associated with the first beam is less than a second threshold, or the duration associated with the blocking of the determined first beam is less than a third threshold, delayed beam failure detection (BFD) or beam failure recovery (BFR) is determined; and Send a first report to the network, the first report including one or more of the following: an indication of a determined blockage, an indication of the duration of the blockage associated with the determined first beam, an indication of the amount of data associated with the first beam, the priority of the data associated with the first beam, an indication that BFD or BFR has been postponed, or an indication that a second beam has been selected.

12. The method according to claim 11, wherein, The WTRU determines the blocking of the first beam via an (AI / ML) model.

13. The method according to claim 11, wherein, The processor is also configured to: Artificial intelligence or machine learning (AI / ML) models determine that blocking still exists after the duration expires; and BFR is executed based on the determination that there is still a blockage after the duration expires.

14. The method of claim 11, further comprising: It was confirmed that there was no blockage after the duration expired; and Based on the determination that there is no congestion after the duration expires, a second report is sent to the network, wherein the second report includes an indication that there is no congestion.

15. The method according to any one of claims 11 to 14, further comprising: The second beam is selected based on the determination that the cell measurement value of the second beam is greater than that of the first beam.

16. The method according to any one of claims 11 to 15, wherein, The first report may also include one or more of the following: the start time of the duration or the end time of the duration.

17. The method according to any one of claims 11 to 16, further comprising: Determine the amount of data associated with the first beam prior to the start time of the blocking.

18. The method according to any one of claims 11 to 17, further comprising: Receive an instruction from the network, wherein the instruction includes confirmation or rejection of postponing BFD or BFR.

19. The method of claim 18, further comprising: Receive an indication of a delay period from the network, wherein the indication of the delay period is based on an indication including confirmation of a delay of BFD or BFR, wherein the delay period indicates how long the BFD or BFR is delayed.

20. The method of claim 18, further comprising: Based on instructions from the network, including rejection of postponement of BFD or BFR, execute BFR.

Images