Method for robust link performance management of xr

Abstract

A WTRU may receive, from a base station, configuration information related to handling a beam failure. The WTRU may receive one or more PDUs in a set of PDUs. The WTRU may receive a reference signal over the same beam, and may perform a first RSRP measurement. If the measured RSRP on the beam is below an RSRP threshold, the WTRU may increments a counter and may determine a remaining delay Dr for the set of PDUs based on the received PDUs. If the remaining delay Dr is less than a certain value, the WTRU may select a second maximum count threshold based on the remaining delay Dr and associated information. If the RSRP is less than the threshold, the WTRU may perform a second RSRP measurement and incrementing the counter. When the counter reaches the second maximum count threshold, the WTRU may transmit a beam failure indication to a gNB.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 335,406 filed on April 27, 2022, U.S. Provisional Patent Application No. 63 / 395,536 filed on August 5, 2022, U.S. Provisional Patent Application No. 63 / 421,805 filed on November 2, 2022, and U.S. Provisional Patent Application No. 63 / 454,133 filed on March 23, 2023, the entire contents of which are incorporated herein by reference. Background Art

[0003] The term "extended reality" (XR) is an umbrella term for different types of immersive experiences, including virtual reality (VR), augmented reality (AR), and mixed reality (MR) and realities interpolated therein. Virtual reality (VR) is a rendered version of a delivered visual and audio scene. The rendering can be designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimulation of the real world to the observer or user as naturally as possible as they move within the limits defined by the application. Augmented reality (AR) is the provision of additional information or artificially generated objects or content superimposed on the user's current environment. Mixed reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene with the intention of providing the illusion that these elements are part of the real scene. XR can include all real and virtual combined environments, as well as human-computer interactions generated by computer technology and / or wearable devices.

[0004] The concept of immersion in the context of XR services refers to the feeling of being surrounded by a virtual environment, as well as providing a sense of being physically and spatially located in the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in a virtual reality that is virtually indistinguishable from actual reality.

[0005] XR devices may be associated with the ability to provide various degrees of spatial tracking. XR devices may be equipped with various sensors to enable spatial tracking, such as monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, etc. Spatial tracking may be performed at different levels, such as 3 degrees of freedom (DoF) (e.g., rotational motion along the X, Y, and Z axes), 6DoF (e.g., rotational motion and / or translational motion along the X, Y, and Z axes), etc. Spatial tracking may generate interactions to experience some form of virtual content. Users may perform actions in and / or interact with components within the extended reality. For example, actions and / or interactions may involve movement, gestures, eye tracking, etc. Spatial tracking is an important contributing factor for immersive XR experiences. For example, some form of head and / or motion tracking may ensure that the visual and audio components of the simulation from the user's perspective are updated to be consistent with the user's movements. Inaccurate and / or delayed spatial tracking may cause the user to feel uncomfortable and / or motion sickness.

[0006] A wireless transmit / receive unit (WTRU) may correspond to any XR device / node that may appear in a variety of form factors. A WTRU (e.g., an XR WTRU) may include, but is not limited to, a head-mounted display (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearable devices, and the like. In addition, several different types of XR WTRUs may be envisioned based on the XR device functionality (e.g., display, camera, sensor, sensor processing, wireless connectivity, XR / media processing, power supply, and the like) to be provided by one or more devices, wearable devices, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs may be grouped into collaborative XR groups for supporting XR applications / services. Summary of the invention

[0007] Methods, systems, and tools for robust link maintenance for XR services may be disclosed herein. For example, a WTRU may receive service information from an application layer / higher layer and information about associations between WTRUs in a collaborative group. The WTRU may transmit information to a network / anchor WTRU to handle link performance management (e.g., for radio link failure (RLF) / beam failure and beam management) across a group of collaborative WTRUs. The WTRU may receive configuration information associated with link / beam management from the network. The WTRU may assist in triggering link failure indications in advance to prevent link failures and / or enable fast link failure recovery procedures. The WTRU may assist in fast beam failure detection and recovery. The WTRU may coordinate fast beam switching and may provide optimal beam tracking on a collaborative set of WTRUs. When reference signals for RSRP reporting and / or beam refinement are configured and / or scheduled, the WTRU may determine a scheduling instance. Based on the services that the WTRU expects to receive and current information about channel quality, the WTRU may transmit information to the network to indicate when it is appropriate to schedule CSI-RS in the DL for RSRP reporting. The WTRU may transmit information about XR services to the network. The WTRU may receive configuration information including parameters related to two or more measurement gap periods. The WTRU may transmit an indication to the network to indicate the measurement period to be used. The WTRU may receive configuration information related to default and / or additional beam failure recovery (BFR) procedures. The WTRU may encounter a beam failure instance (BFI) and may determine a remaining delay for a set of PDUs. The WTRU may select a configuration for indicating the beam failure to the gNB.

[0008] An anchor WTRU may assist in preventing link failures in a cooperating WTRU group. The anchor WTRU may determine / predict link failure instances (e.g., RLF and / or beam failure) in the cooperating group of WTRUs and may assist the network in preventing link failures by dynamically providing service information and transmitting link failure indications in advance. The anchor WTRU may receive higher layer / application layer information about the XR experience, such as association information across cooperating WTRUs, WTRU-related quality of service (QoS) requirements (e.g., QoS requirements corresponding to each WTRU in the cooperating group), and / or joint QoS requirements for the cooperating group. The anchor WTRU may receive (e.g., in RRC) a configuration including one or more thresholds related to QoS requirements (e.g., PDB) or joint QoS requirements for each WTRU and the duration of link failure (e.g., RLF and / or beam failure) instances. The anchor WTRU may predict an impending link failure and its duration on one or more Uu links corresponding to a WTRU or a subset of WTRUs in the cooperating group. If the predicted duration of the link failure instance is greater than or equal to a predetermined fractional portion of the PDB, the anchor WTRU may transmit an early link failure indication if the predicted link failure corresponds to a single WTRU or a joint link failure indication if the link failure corresponds to multiple WTRUs, and the network may respond by performing one or more actions (e.g., increasing transmit power or scheduling on different RBs) to prevent the link failure. If the predicted duration of the link failure instance is less than the predetermined fractional portion of the PDB, the anchor WTRU may assume that the link failure may be recovered before QoS degradation may occur and may not perform any action.

[0009] Fast beam failure detection and recovery from the perspective of a cooperating WTRU may be supported. The cooperating WTRU may perform fast beam recovery based on traffic information (e.g., PDB) and time thresholds for deciding whether to use the anchor WTRU to select an alternative beam or to use a default beam failure recovery procedure. The WTRU may receive data traffic information about a data type-related packet delay budget (PDB) from a higher layer / application layer. The WTRU may receive configuration information from the anchor WTRU (e.g., via the SL), which may include an anchor-assisted time threshold for transmitting a beam failure indication to the anchor WTRU. The WTRU may receive configuration information from the network (e.g., in the RRC), which may include a default time threshold for transmitting a beam failure indication to the network and a beam assignment (e.g., beam ID). The WTRU may detect a beam failure instance (e.g., RSRP measurement below a threshold) on its assigned beam. The WTRU may determine whether to request assistance from the anchor WTRU or use a default procedure for beam failure recovery based on traffic information (e.g., PDB), the anchor assistance time threshold, and / or the default time threshold. If the PDB is less than the anchor assistance time threshold, the WTRU may initiate a conventional beam failure recovery procedure. If the PDB is greater than or equal to the anchor assistance time threshold, the WTRU may transmit assistance information (e.g., relative position / orientation and current beam assignment) and request the anchor WTRU to assist in selecting an alternative beam, and receive an indication to start using the alternative beam. If the measured beam quality in the alternative beam is insufficient (e.g., RSRP measurement is below a threshold), the WTRU may initiate a default beam failure recovery procedure.

[0010] Coordinated beam maintenance from the perspective of the anchor WTRU may be supported. The anchor WTRU may determine the optimal beam to which the member WTRU is to switch based on assistance information from the application, (e.g., each) member WTRU, and the network. The anchor WTRU may receive application configuration information, which may include data arrival rate and / or initial special information (e.g., relative position, orientation) of (e.g., each) cooperating WTRU and the range of possible spatial variation of (e.g., each) cooperating WTRU. The anchor WTRU may receive configuration information from the network, which may include an initial beam assigned to (e.g., each) WTRU in the cooperating group, beam orientation information (e.g., direction, width) of one or more (e.g., all) candidate beams available for (e.g., each) WTRU in the cooperating group, and / or beam association information indicating a mapping between beam IDs and beam orientation information (e.g., direction, width). The anchor WTRU may calculate a beam validity interval for (e.g., each) cooperating WTRU based on the network configuration information and the application information. The WTRU may receive application data via the corresponding initial beam. The WTRU may determine an expected change in spatial information (e.g., new position, new orientation) of the cooperating WTRU based on application data and / or application configuration information. The WTRU may determine a beam switching rate for the cooperating WTRU based on the expected change in spatial information received from the member WTRU and the network configuration information. If the beam switching rate of the member WTRU is greater than the beam validity interval, the WTRU may determine the optimal beam for the member WTRU based on the expected spatial information and beam association information of the member WTRU, transmit an indication to the network on the optimal beam determined for the cooperating WTRU, and / or transmit an indication to the cooperating WTRU on the optimal beam to be used.

[0011] Dynamic adjustment of the maximum count number of BFIs used to transmit a beam failure indication to the gNB may be supported. The WTRU may receive configuration information related to handling beam failure from the base station, the configuration information may include one or more of the following: one or more maximum count values ​​(e.g., a default value C ) related to the maximum number of BFIs to be counted before indicating a beam failure to the gNB; max_1 and the second value C max_2 ); Beam failure detection duration T BFI ; A delay threshold D associated with the residual delay of the PDU set T ;D Tan association (e.g., a mapping relationship) with the maximum count value; and / or an RSRP threshold. The WTRU may receive one or more PDUs in the PDU set via a beam. The WTRU may receive a reference signal (e.g., a CSI-RS) via the same beam (e.g., periodically) and may perform a first RSRP measurement. If the RSRP measured on the beam is lower than the RSRP threshold, the WTRU may increase the BFI_count (e.g., CSI_RS). n ) incremented by 1 (for example, C n+1 ), and the remaining delay D of the PDU set can be determined based on the received PDU r For example, C n It can be a variable related to the current value of BFI_count. If the remaining delay D r Less than a certain value (for example, (C max_1 –1)*T BFI , which may be referred to as a comparison value), the WTRU may calculate the residual delay D based on the residual delay D r and the associated information to select a second maximum count threshold (e.g., less than C max_1 C max_2, ). The WTRU may perform a second RSRP measurement (e.g., on the CSI-RS) and may increment the BFI_count value if the RSRP is less than the threshold. When BFI_count reaches the second maximum count threshold (e.g., C max_2 ), the WTRU may transmit a beam failure indication to the gNB. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0013] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0014] Figure 1C is an example of an embodiment in which Figure 1A a system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0015] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0016] Figure 2A group of cooperating XR devices supporting the same XR application is illustrated.

[0017] Figure 3 An example beam pattern / grid mapping is illustrated.

[0018] Figure 4 A representation of the (initial) Tx / Rx beam pattern around a cooperating WTRU is illustrated.

[0019] Figure 5 An example of a cooperating group of WTRUs receiving CSI-RS is illustrated.

[0020] Figure 6 The RRM-related measurement periodicity configuration is illustrated.

[0021] Figure 7 An example of adaptive setting of the maximum count value of the BFI used to transmit a beam failure recovery request to the gNB is illustrated. DETAILED DESCRIPTION

[0022] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0023] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0025] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

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

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

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

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

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

[0032] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), roads, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0033] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 / 115 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0037] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0044] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0045] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for 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 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0049] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0052] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0053] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0054] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communication interface with a communication network.

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

[0056] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Direct link establishment (DLS) may be utilized to transmit point-to-point traffic between the source STA and the destination STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0057] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send a beacon on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be a working channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0058] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0059] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0060] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0061] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operation mode) is sending to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

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

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

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

[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0066] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0068] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0070] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure the traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0072] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0073] Given that Figures 1A to 1D as well as Figures 1A to 1D , one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0075] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0076] Link performance management may be performed. The time-varying nature of the radio propagation environment and imperfections in the physical hardware may introduce fading and severe impairments to the signal reaching the receiver. In order to maintain acceptable link performance to provide guaranteed QoS and capacity, various physical layer techniques may be employed, such as multi-antenna deployment with beamforming capabilities. Instantaneous link performance fluctuations may still occur due to poor channel conditions, WTRU mobility, etc., which may result in a significant degradation in received signal power conditions, resulting in poor QoS provision or even service interruption. L1 / L2 configurations may be provided for performance management, enabling the link to resume nominal operation in the event of performance degradation or connection loss.

[0077] Radio link failure and RRC re-establishment may occur. While in RRC_CONNECTED, the WTRU may perform radio link monitoring (RLM) in the active BWP based on reference signals (e.g., SSB / CSI-RS) and signal quality thresholds configured by the network. SSB-based RLM is based on the SSB associated with the initial DL BWP and may be configured (e.g., only) for the initial DL BWP and for DL ​​BWPs containing the SSB associated with the initial DL BWP. For other DL BWPs, RLM may be performed (e.g., only) based on CSI-RS.

[0078] The WTRU may declare a radio link failure (RLF) when one or more of the following criteria are met: expiration of a timer that is started after an indication of a radio problem from the physical layer (e.g., if the radio problem is recovered before the timer expires, the WTRU may stop the timer); a random access procedure failure; and / or an RLC failure.

[0079] After declaring RLF, the WTRU may remain in RRC_CONNECTED, select a suitable cell and initiate RRC re-establishment, and / or enter RRC_IDLE (eg, if no suitable cell is found within a certain period of time after declaring RLF).

[0080] Beam management may be performed. For example, beam management may be defined as a set of L1 / L2 procedures to acquire and maintain transmit receive points (TRxPs) and / or WTRU beam sets that may be used for DL ​​and UL transmission / reception, which may include one or more of the following aspects: beam determination (e.g., for the TRxP or WTRU to select its own Tx / Rx beam), beam measurement (e.g., for the TRxP or WTRU to measure characteristics of received beamformed signals), beam reporting (e.g., for the WTRU to report information of beamformed signals based on beam measurements), and / or beam scanning (e.g., the operation of covering a spatial area with beams transmitted and / or received during time intervals in a predetermined manner).

[0081] The correspondence between TRxP and Tx / Rx beams at WTRU may be defined as follows. The correspondence between Tx / Rx beams at TRxP may be established if one or more of the following conditions are met: TRxP is capable of determining the TRxP Rx beam for uplink reception based on the WTRU's downlink measurements on one or more Tx beams of TRxP, and / or TRxP is capable of determining the TRxP Tx beam for downlink transmission based on the TRxP's uplink measurements on one or more Rx beams of TRxP.

[0082] The Tx / Rx beam correspondence at the WTRU may be established if one or more of the following conditions are met: the WTRU is capable of determining the WTRU Tx beam for uplink transmission based on the WTRU's downlink measurements on one or more Rx beams of the WTRU; the WTRU is capable of determining the WTRU Rx beam for downlink reception based on an indication of TRxP based on uplink measurements on one or more Tx beams of the WTRU; and / or supports an indication of the ability to provide TRxP with information related to the WTRU beam correspondence.

[0083] DL L1 / L2 beam management procedures can be supported within one or more TRxPs. A first procedure (e.g., P-1) can be used to enable WTRU measurements on different TRxP Tx beams to support the selection of TRxP Tx beams / WTRU Rx beams. For beamforming at the TRxP, P-1 can include intra / inter-TRxP Tx beam scanning from a set of different beams. For beamforming at the WTRU, P-1 can include WTRU Rx beam scanning from a set of different beams. A second procedure (e.g., P-2) can be used to enable WTRU measurements on different TRxP Tx beams to possibly change the inter / intra-TRxP Tx beams, e.g., for beam refinement from a set of beams smaller than the set of beams in P-1. P-2 can be a special case of P-1. A third procedure (e.g., P-3) can be used to enable WTRU measurements on the same TRxP Tx beam to change the WTRU Rx beam (if the WTRU uses beamforming).

[0084] Network-triggered aperiodic beam reporting can be supported under P-1, P-2, and P-3 related operations.

[0085] WTRU measurements based on RSs for beam management (e.g., at least CSI-RS) can consist of K beams, where K can be equal to the total number of configured beams. The WTRU can report the measurement results of N selected Tx beams, where N can be or can not be a fixed number. Procedures based on RSs for mobility purposes can not be excluded. If N < K, the reported information can include the measurement quantities for the N beams and information indicating the N DL Tx beams. Specifically, when the WTRU is configured with K'> 1 non-zero power (NZP) CSI-RS resources, the WTRU can report N' CRIs (CSI-RS resource indicators). For example, K' can refer to the number of CSI-RS resources, while K can refer to the number of configured beams. N' can refer to the number of CSI-RS resource indicators to be reported, and N can refer to the number of beams for which the WTRU will report measurements.

[0086] The WTRU can be configured with one or more of the following higher layer parameters for beam management: N ≥ 1 reporting settings and M ≥ 1 resource settings; reporting settings; and / or resource settings.

[0087] The WTRU can be configured with N ≥ 1 reporting settings and M ≥ 1 resource settings. The link between the reporting settings and the resource settings can be configured in the agreed CSI measurement settings. The resource settings and the reporting settings can be used to support CSI-RS based procedures (e.g., P-1 and / or P-2). Procedures (e.g., P-3) can be supported with or without reporting settings.

[0088] The WTRU may be configured with reporting settings that may include information indicating one or more of the following: selected beam, L1 measurement report, time domain behavior (e.g., aperiodic, periodic, semi-persistent), and / or frequency granularity (e.g., if multiple frequency granularities are supported).

[0089] The WTRU may be configured with a resource setting. The resource setting may include one or more of a time domain behavior (e.g., aperiodic, periodic, semi-persistent), an RS type (e.g., at least NZP CSI-RS), and / or one or more CSI-RS resource sets, where (e.g., each) CSI-RS resource set has K ≥ 1 CSI-RS resources. Some parameters of the K CSI-RS resources may be the same (e.g., port number, time domain behavior, density, and periodicity, if any).

[0090] One or more alternatives for beam reporting may be supported. In a first alternative, the WTRU may report information about TRxP Tx beams that may be received using a selected WTRU Rx beam set, where an Rx beam set may refer to a WTRU Rx beam set used to receive DL signals. WTRU specific implementation issues regarding how to construct an Rx beam set may be disclosed. (e.g., each) Rx beam in a WTRU Rx beam set may correspond to a selected Rx beam in (e.g., each) panel. For a WTRU with more than one WTRU Rx beam set, the WTRU may report the TRxP Tx beam and an identifier of the associated WTRU Rx beam set for each reported TX beam. Different TRxP TX beams reported for the same Rx beam set may be received simultaneously at the WTRU. Different TRxP TX beams reported for different WTRU Rx beam sets may not be received simultaneously at the WTRU.

[0091] In a second alternative, the WTRU may report information about the TRxP Tx beams on a per WTRU antenna group basis, where a WTRU antenna group may refer to a receiving WTRU antenna panel or subarray. For a WTRU with more than one WTRU antenna group, the WTRU may report the TRxP Tx beams along with the identifier of the associated WTRU antenna group for each reported TX beam. Different TX beams reported for different antenna groups may be received simultaneously at the WTRU. Different TX beams reported for the same WTRU antenna group may not be received simultaneously at the WTRU.

[0092] Beam failure detection and recovery may be performed. For beam failure detection, the gNB may configure a beam failure detection reference signal (e.g., SSB or CSI-RS) for the WTRU, and when the number of beam failure instance indications from the physical layer reaches a configured threshold before the configured timer expires, the WTRU may declare a beam failure.

[0093] SSB-based beam failure detection may be based on the SSB associated with the initial DL BWP and may be configured (e.g., only) for the initial DL BWP and / or for a DL BWP including the SSB associated with the initial DL BWP. For other DL BWPs, beam failure detection may be performed (e.g., only) based on CSI-RS.

[0094] The MAC entity may be configured by RRC for each serving cell with a beam failure recovery procedure that may be used to indicate a new SSB or CSI-RS to the serving gNB when a beam failure is detected on the serving SSB / CSI-RS. Beam failure may be detected by counting beam failure instance indications from lower layers to the MAC entity. If beamFailureRecoveryConfig is reconfigured by upper layers during an ongoing random access procedure for beam failure recovery of the SpCell, the MAC entity may stop the ongoing random access procedure and initiate the random access procedure using the new configuration.

[0095] RRC may configure one or more of the following parameters in BeamFailureRecoveryConfig, BeamFailureRecoverySCellConfig, and RadioLinkMonitoringConfig for beam failure detection and recovery procedures: beamFailureInstanceMaxCount (e.g., for beam failure detection); beamFailureDetectionTimer (e.g., for beam failure detection); beamFailureRecoveryTimer (e.g., for beam failure recovery procedures); rsrp-ThresholdSSB (e.g., for RSRP threshold for SpCell beam failure recovery); rsrp-ThresholdBFR (e.g., for RSRP threshold for SCell beam failure recovery); powerRampingStep (e.g., for SpCell beam failure recovery); powerRampingStepHighPriority (e.g., for SpCell beam failure recovery); preambleReceivedTargetPower (e.g., for SpCell beam failure recovery); preambleTransMax (e.g., for SpCell beam failure recovery); scalingFactorB (e.g., for SpCell beam failure recovery); ssb-perRACH-Occasion (e.g., for SpCell beam failure recovery using contention-free random access resources); ra-ResponseWindow (e.g., a time window for monitoring responses for SpCell beam failure recovery using contention-free random access resources); prach-ConfigurationIndex (e.g., for using contention-free random access resources); ra-ssb-OccasionMaskIndex (e.g., for SpCell beam failure recovery using contention-free random access resources); ra-OccasionList (e.g., for SpCell beam failure recovery using contention-free random access resources); candidateBeamRSList (e.g., a list of candidate beams for SpCell beam failure recovery); and / or candidateBeamRSSCellList (e.g., a list of candidate beams for SCell beam failure recovery).

[0096] A WTRU variable (e.g., BFI_COUNTER), which may be initially set to 0, may be used to count beam failure instances and may be used to count beam failure instances when the WTRU variable reaches a threshold (e.g., beamFailureInstanceMaxCount, which may also be referred to as C max and / or "max count"), a beam failure is declared.

[0097] After detecting a beam failure, the WTRU may trigger beam failure recovery by initiating a random access procedure on the PCell, and / or select an appropriate beam to perform beam failure recovery (for example, if the gNB has provided dedicated random access resources for certain beams, these beams may be prioritized by the WTRU).

[0098] After completing the random access procedure, beam failure recovery can be considered complete.

[0099] A business model for XR applications / use cases may be provided. One or more services / business flows for different XR applications / use cases may be disclosed herein.

[0100] One or more Virtual Reality 1 (VR1) applications / use cases may be used. VR1 applications (e.g., immersive 6 degrees of freedom (6DoF) streaming) may be modeled using service flows suitable for a viewport-dependent streaming architecture. Similar to adaptive streaming (e.g., DASH), viewport-dependent streaming allows the quality of the media / video to be dynamically updated based on the available bitrate in the network and wireless interfaces. Based on the service / business flow, tracking and pose information (e.g., small packet size: <100B) of the XR device viewport is periodically transmitted to the XR server in the uplink (UL) at a relatively low data rate (e.g., 0.5Mbps to 2Mbps, 60Hz to 500Hz). In response, the XR server adaptively transmits viewport-optimized media (e.g., H.264 / 265 video) in the downlink (DL) at high data rates (e.g., 6MBps to 18MBps for 4k omnidirectional and FoV regional streaming) and quasi-periodically (e.g., 40fps / 60fps / 120fps), and then renders the media in the XR device display.

[0101] The service characteristics of VR1 may be as follows. UL services may include pose / viewport information (e.g., including information about 6DoF), and may have a small packet size (e.g., a constant size <100B), a low data rate (e.g., 0.5Mbps to 2Mbps), and may be a single stream. UL services may be periodic (e.g., with a periodicity range of 60Hz to 500Hz). DL services may include media / video containing viewport-optimized scenes (e.g., high quality) and / or media video for non-viewport scenes (e.g., lower quality), and may have a large packet size (e.g., a variable size with a Gaussian distribution or a fixed size of 1500B), a high data rate (e.g., 6Mbps to 18Mbps), and end-to-end (E2E) latency (e.g., 50ms), and may be multi-stream (e.g., may include video streams with different bit rates, 3D media, and / or metadata). DL services may be quasi-periodic (e.g., periodicity as a function of frame rates of 40 / 60 / 120fps).

[0102] Virtual Reality 2 (VR2) applications may be used. VR2 applications (e.g., immersive gaming spectator mode) may be modeled using service flows suitable for a split rendering architecture. The XR server may perform pre-rendering and encoding of 2D media / video frames based on pose information periodically transmitted by the XR device at a low data rate (e.g., 0.5Mbps to 2Mbps, 60Hz to 500Hz). Rendering is primarily performed in the XR server and transmitted in the DL at a high data rate and low latency (e.g., 30Mbps to 45Mbps, 10ms to 20ms). The XR device decompresses the received media / video and performs asynchronous time warping (ATW) to correct the viewport based on the latest pose information. Although the RTT latency for sending pose information in the UL and receiving pre-rendered media in the DL may be as long as 50ms, ATW enables motion-to-photon latency requirements (<20ms) to be met based on in-device processing.

[0103] The service characteristics of VR2 may be as follows. UL services may include pose / viewport information and may have a small packet size (e.g., a constant size <100B), a low data rate (e.g., 0.5Mbps to 2Mbps), and may be a single stream. UL services may be periodic (e.g., a periodicity ranging from 60Hz to 500Hz). DL services may include 3D scenes in a frame buffer and may have a large packet size (e.g., a variable size with a Gaussian distribution or a fixed size of 1500B or higher), a high data rate (e.g., 30Mbps to 45Mbps), a latency round trip time of 30ms or 50ms, and may be multi-stream (e.g., may include 3D video / media and / or metadata). DL services may be quasi-periodic (e.g., periodicity as a function of a frame rate of 60 / 90fps).

[0104] Augmented Reality 1 (AR1) applications may be used. AR1 applications (e.g., real-time communication with a store assistant) may be characterized using service flows suitable for a distributed computing architecture. Depending on the service / business flow, the XR device transmits pose information (e.g., 0.5Mbps to 2Mbps, 60Hz to 500Hz) and / or video (e.g., 10Mbps, 10Hz frame update rate) to the XR server in the UL. The XR server uses the received information to generate a scene, which is then converted into a 2D (video) or 3D media (3D object) format along with metadata (e.g., scene description). Compressed media and metadata (e.g., characterized by a Pareto distribution) are delivered quasi-periodically in the DL at a relatively high data rate (e.g., 30Mbps to 45Mbps, 40fps / 60fps / 120fps). The XR device then generates an AR scene locally by overlaying 3D objects on the 2D video, and renders the scene in the device display.

[0105] The service characteristics of AR1 may be as follows. UL services may include posture information and / or 2D video stream information. The posture information may have a small packet size (e.g., a constant size <100B), a low data rate (e.g., 0.5Mbps to 2Mbps), and may have a periodicity in the range of 60Hz to 500Hz. The video information may have a relatively large packet size, a data rate of 10Mbps, may be periodic (update periodicity of 10Hz) and may be multi-stream video. DL services may include 2D / 3D pre-rendered media and XR metadata, and may have a large packet size (e.g., Pareto distribution) and a high data rate (e.g., 30Mbps to 45Mbps), and may be multi-stream (e.g., may include 2D / 3D media and / or metadata). DL services may be quasi-periodic (e.g., periodicity as a function of a frame rate of 60 / 90fps).

[0106] Augmented Reality 2 (AR2) applications may be used. AR2 applications (e.g., XR conferencing, AR avatar calls) may use services / business flows applicable to the XR conversation architecture, where two or more XR clients / devices may perform peer-to-peer communication with intermediate media processing in the network. Based on the type of user representation, different types of media that may be supported for AR2 applications may include 2D+ / RGBD (e.g., 2.7Mbps), 3D mesh (e.g., 30Mbps), and / or 3D video point cloud coding (VPCC) / geometry-based point cloud compression (GPCC) (e.g., 5Mbps to 50Mbps). The XR client in the device may initiate a call establishment procedure, based on which the session control function triggers network-based media processing. The session control function also forwards the call establishment to the second XR client / device, followed by real-time media processing and streaming to both clients with low latency (e.g., E2E<100ms). During the XR call, 2D / 3D media and possible user pose information are sent quasi-periodically in the UL and DL between the XR clients / devices.

[0107] The service characteristics of AR2 may be as follows. UL services may include 2D / 3D media and the user's posture and / or video. UL services may have a relatively large packet size, a data rate of 2.7Mbps to 50Mbps, a packet delay budget (PDB) <150ms, and may be multi-stream (2D / 3D media). UL services may be quasi-periodic (e.g., 60Hz to 500Hz). DL services may include 2D / 3D media and the user's posture and / or video. DL services may have a large packet size (e.g., truncated Gaussian distribution), a data rate of 2.7Mbps to 50Mbps, and an E2E PDB <100ms, and may be multi-stream (e.g., may include 2D / 3D media). DL services may be quasi-periodic (e.g., 60Hz to 500Hz).

[0108] XR conference applications can be used. XR conference applications can provide an immersive conference experience between geographically remote users by representing users in a 3D volume representation (e.g., a point cloud or mesh). One or more cameras (e.g., with depth perception capabilities) can be placed at the location of (e.g., each) user to allow interaction (e.g., viewing, listening, rotating, zooming in, resizing, etc.) with each other's full 3D volume representation on their respective devices (e.g., headphones / glasses). XR conference applications can support simultaneous UL and DL media services, where the media consists of audio, video, and / or 3D objects. Media formats that can be used to capture users in 3D volume formats may include 2D+ / RGBD (for 1 camera>2.7Mbps, for 2 cameras>5.4Mbps), 3D mesh (about 30Mbps), and / or 3D VPCC / GPCC (5Mbps to 50Mbps). The media processor may be located in the center or distributed on the edge. Additionally, the service / business flow between XR clients / users via the media processor within the network may be similar to the AR2 and XR session use cases. Joining an XR conferencing session may result in a download spike at the beginning to download the virtual environment and associated media objects within the XR application. Throughout the remainder of the session, the data rate may vary depending on the number of users, the users' upload format, and the refresh rate of the virtual 2D / 3D objects / environment.

[0109] The service characteristics of an XR conference may be as follows. UL services may include 2D / 3D media, as well as the user's posture and / or real-time video. UL services may have a relatively large packet size, a data rate of 2.7Mbps to 50Mbps, and may be multi-stream (2D / 3D media). UL services may be quasi-periodic (e.g., 60Hz to 500Hz). UL services may have a low encoder packet error rate (PER) of <1e-3. DL services may include 2D / 3D media, the user's posture and / or real-time video, and 2D / 3D objects / environments (e.g., which may come from a third party). DL services may have a large packet size, a data rate of 2.7Mbps to 50Mbps, and an E2E PDB<100ms, and may be multi-stream (e.g., may include 2D / 3D media). DL services may be quasi-periodic (e.g., 60Hz to 500Hz) and may have a low encoder PER of <1e-3.

[0110] Cloud gaming (CG) applications can be used. CG applications (e.g., 5G online games) can rely mainly on an adaptive streaming architecture, in which the video / media rendered in the network is streamed to a thin client in a device (e.g., a smartphone, tablet). In a typical service / business flow for CG, the XR device transmits viewport-related pose information (e.g., 100B to 250B) to the XR server periodically in the UL (e.g., 0.1Mbps to 1Mbps, 60Hz to 500Hz). The generated viewport-related video / media (e.g., 1500B) is encoded / compressed (e.g., H.264 / 265 video) and transmitted quasi-periodically in the DL by the XR server (e.g., 30Mbps to 45Mbps, 30fps / 50fps / 60fps / 90fps / 120fps, PER: 10e-3). The received video / media is then rendered in the XR device during decoding and processing. The RTT delay for supporting certain high-end CG applications (e.g., Class D: photo-realistic or natural video games) can be determined by the round-trip interaction delay (e.g., 50ms). For other CG applications (e.g., Class A, Class B, and Class C defined in TR26.955), the uplink PDB is 10ms, and the downlink streaming PDB can range from 50ms to 200ms.

[0111] The service characteristics of the CG may be as follows. The UL service may include pose / viewport information. The UL service may have a relatively small packet size (e.g., 100B to 250B), a low data rate of 0.1Mbps to 1Mbps, a PDB of 10ms, and may be a single stream. The UL service may be periodic (e.g., 60Hz to 500Hz). The DL service may include 2D / 3D media and / or video of the user. The DL service may have a large packet size (e.g., a maximum of 1500B), a high data rate of 30Mbps to 45Mbps, and a PDB of 20ms, and may be multi-stream (e.g., may include 2D / 3D media and / or video). The DL service may be quasi-periodic (e.g., periodicity as a function of frame rate of 30fps / 50fps / 60fps / 90fps / 120fps) and may have a low encoder PER of <10e-3.

[0112] Current processing of link performance management and link maintenance in the RAN for XR services may be challenging for one or more of the following reasons. In the RAN, momentary interruptions and / or degradations in link performance may occur due to momentary fluctuations in the propagation channel or handovers, which may result in beam switching or radio link and / or beam failures. XR services (e.g., where information units may be carried in PDU sets) may impose strict end-to-end QoS requirements (e.g., across all PDUs in a PDU set), and during the transmission of PDUs in the PDU set, nominal link performance may need to be maintained in the RAN (e.g., with minimal interruptions and fast link / beam recovery), with interruptions or performance degradation being minimal, to meet the strict QoS requirements. In the event of momentary degradation of link performance due to radio link and / or beam failures or beam switching, the recovery time, defined as the duration taken before nominal link performance is restored, may need to be small enough to maintain the QoS requirements. For example, if Figure 2 As shown, an XR application / experience may consist of multi-stream traffic generated / received by a single WTRU (e.g., HMD: video and pose data) or a group of WTRUs (e.g., HMD, haptic gloves). Figure 2 A group of collaborative XR devices supporting the same XR application is illustrated. Multi-stream traffic may be in a single device (e.g., HMD: video and pose data), and / or across multiple devices (e.g., HMD, haptic gloves). For a single XR application / experience with multi-stream traffic across multiple devices (e.g., a collaborative group of WTRUs), recovery time in one WTRU may impact the overall XR experience. Link / beam management may be performed without considering interdependencies and associations of PDUs in a PDU set. For XR, traffic associations and interdependencies between PDUs in a PDU set may need to be considered when initiating and executing beam / link management procedures. Thus, adaptive beam / link management may be supported for a WTRU (e.g., or a group of WTRUs) running an XR application.

[0113] Since the current handling of link performance management is on a per-device basis, in a scenario where a user runs an XR application on a cooperative group of devices, the traffic associations and interdependencies in the QoS across the cooperative group of WTRUs may not be considered when initiating a (link) recovery procedure. For example, consideration may be given to how to coordinate link management procedures across a cooperative WTRU group and utilize information such as traffic information and measurements collected from each member WTRU to prevent RLC, and / or how to utilize existing group information to coordinate and implement faster link failure recovery procedures in the event of an RLC failure being prevented for one WTRU or a subset of WTRUs in the cooperative group.

[0114] Collaborative WTRU groups may be used. As used herein, a network may include, for example, any of a base station (e.g., a gNB, a TRP, a RAN node), a core network function, and / or an application function (e.g., an edge server function, a remote server function). As used herein, a flow may correspond to any of the following: a QoS flow or a data flow (e.g., a data flow consisting of one or more PDUs or PDU sets, which may be associated with one or more QoS requirements such as latency, data rate, reliability, etc.). A PDU set (e.g., a media unit, a video frame) may include one or more PDUs. A PDU set may be associated with a PDU set level QoS requirement (e.g., data rate, latency, error rate, and / or reliability), which may apply to one or more (e.g., all) PDUs associated with the PDU set. Different PDUs in a PDU set may be associated with respective PDU level QoS requirements. Such associations and interdependencies may be visible to an AS layer (e.g., having an association ID) and / or processed by an AS layer having association awareness during data transmission in the UL and / or data reception in the DL.

[0115] In one example, a WTRU may be enabled to dynamically adjust a maximum count (max count) threshold based on association information (e.g., mapping) between a residual delay in a PSDB and a set of maximum count thresholds for indicating a BFI, which may be used to determine when to transmit an indication of a beam failure (BF) to a gNB. A WTRU may receive configuration information related to default and additional beam failure recovery (BFR) procedures. The WTRU may encounter a beam failure instance (BFI) and may determine a residual delay for a set of PDUs. The WTRU may select a configuration for indicating the beam failure to the gNB.

[0116] As used herein, the term "collaborative XR" or "collaborative WTRU group" may refer to, but is not limited to, supporting XR applications / services whereby one or more WTRUs may perform at least one XR-related action to provide an XR experience to a user, which may include enabling sensory capabilities whereby a user may perceive full or partial immersion in different real / virtual environments and / or the ability to interact with real and / or virtual objects (including avatars).

[0117] As used herein, the term "WTRU" may include one or more of the following: a standalone / independent WTRU / device / node (e.g., XR device, XR glasses, smartwatch); a non-independent device / node (e.g., a device associated with a WTRU, a sensor, a wearable device, a haptic glove); a device / node controlled by a network (e.g., a network operator); a device / node that may not be directly associated with and / or connected to a gNB, but may be a candidate option given certain parameters (e.g., FoV metadata (e.g., size, dimensions, quality, etc. of the FoV), pose information); and / or a fixed / static or mobile / mobile device / node / WTRU. As used herein, the terms "WTRU," "node," and / or "device" may be used interchangeably and may refer to any of the WTRU types described herein.

[0118] A cooperating group may be composed of one or more WTRUs, where a first WTRU may be designated as an anchor WTRU and a second WTRU may be designated as a cooperating WTRU or member WTRU.

[0119] In the context of collaborative XR, an anchor WTRU may refer to a WTRU that participates in performing one or more of the following: hosting an application function (e.g., an XR application) from which a request for any XR action may be received; receiving a request for an XR action from an application function located in the network (e.g., an edge server, a remote server); initiating a discovery procedure for determining other WTRUs / devices / nodes in the vicinity to perform any XR action in the collaborative group; and / or establishing connectivity and / or sessions (e.g., XR sessions, PDU sessions, application sessions) by transmitting / receiving requests for session establishment, and operating as a primary anchor point for communicating with a RAN function / node (e.g., a gNB), a CN function, and / or an application function, including transmitting and / or receiving any of the session-related messages (e.g., capability transfer, assistance information transfer, configuration transfer, measurement information, XR action status information, session activation / deactivation, session release). When supporting connectivity to a network, the interface between the anchor WTRU and the network (e.g., a gNB) may be referred to as a primary Uu link.

[0120] The terms "collaborative WTRU" and "member WTRU" are used interchangeably and in the context of collaborative XR may refer to any WTRU that participates in performing one or more of the following: initiating a discovery procedure and / or receiving a request to enable the WTRU to be discovered (e.g., via a sidelink or via a network) to perform any of the XR actions described herein; transmitting information related to the XR action (e.g., pose information, FoV parameters including orientation, FoV width and other FoV metadata, UL data containing captured / mapped FoV content and / or media / video frames, assistance information, status information) directly to the network (e.g., gNB, CN function, application function) and / or indirectly to the anchor WTRU; receiving information (e.g., RRC configuration information, application configuration information) that may be used to determine any of the XR actions in conjunction with the anchor WTRU; and / or transmitting XR action-related messages / reports, including pose and / or FoV measurements and estimates, to the anchor WTRU and / or the network via a sidelink interface (e.g., NR sidelink, Bluetooth, WiFi Direct, etc.). When supporting connectivity to a network, the interface between a cooperating WTRU and a network (e.g., a gNB) may be referred to as a secondary Uu link. A cooperating WTRU may be associated with different cooperating groups and anchor WTRUs.

[0121] The XR experience may refer to the overall experience for the end user that results from the coordinated sending and / or receipt of the correct data to the correct end device in a reliable and timely manner.

[0122] As used herein, terminology related to "multimodality" may refer to multiple flows and / or any association between multiple WTRUs, such as may be in a cooperative WTRU group, which may be associated with supporting an application / service common to one or more WTRUs.

[0123] The terms used herein in connection with "anchor WTRU" and "cooperating WTRU" are non-limiting examples. Other terms that may be used when referring to an anchor WTRU may include "center WTRU", "master WTRU", "primary WTRU", "initiator WTRU", etc. Other terms that may be used when referring to a cooperating WTRU may include "member WTRU", "assistant WTRU", "supporting WTRU", "secondary WTRU", etc.

[0124] The different attributes described herein, including a cooperation group, an anchor WTRU, a cooperation WTRU, and / or an XR action, may be associated with different identifiers / IDs (e.g., a cooperation group ID, an anchor WTRU ID per group, a cooperation WTRU ID per group, an XR action ID, etc.). The different identifiers / IDs associated with a cooperation XR may be assigned / configured, for example, by any of the following: a WTRU, a network, an application function, etc.

[0125] Similar to the secondary WTRU, the tertiary WTRU may be a WTRU type associated with a role and functional capabilities in a collaboration group. This WTRU may participate in XR actions for a shorter duration and / or a smaller portion of the task, and therefore may require partial configuration (e.g., may take less time to complete or perform the XR action, and / or incur less overhead).

[0126] Methods, systems, and tools for robust link maintenance for XR services may be described herein.

[0127] A WTRU (e.g., anchor WTRU) in a cooperative WTRU group associated with an application / experience may assist in indicating instances of link failures (e.g., RLF and / or beam failure) for one or more WTRUs in advance and assist in preventing link failures (e.g., RLF and / or beam failure). For example, such assistance in preventing link failures may be performed as part of a link management procedure and / or a link maintenance procedure. The anchor WTRU may also assist the network by providing information common to the group to enable link failure prevention and / or coordinate faster link failure recovery procedures for affected WTRUs in the cooperative group, and maintaining service (group QoS) synchronization between WTRUs in the application.

[0128] In one example, the anchor WTRU may use information / indications received from the application layer / higher layers (e.g., camera FoV, pose information) and information collected from the cooperating WTRUs regarding channel measurements (e.g., BLER, RSRP, RSRQ, RSSI measurements) to predict an impending link failure (e.g., RLF and / or beam failure) and / or link failure duration in one or more links corresponding to the cooperating WTRU. In addition, a single link failure prediction corresponding to (e.g., one) WTRU in the cooperating group may also be used as a prediction of a possible simultaneous link failure for another WTRU in the group. Based on the predicted duration of the link failure (e.g., RLF and / or beam failure) and the QoS associated with each service (e.g., PDB) corresponding to the WTRU, the anchor WTRU may then be triggered to transmit an early link failure (e.g., RLF and / or beam failure) indication to the network. The network may then take one or more steps (e.g., scheduling on a different RB, transmitting on another carrier, duplicating packets, increasing signal power, switching to a different beam, etc.) to avoid link failure and maintain QoS requirements for services to (e.g., each) WTRU as well as joint QoS requirements (e.g., time difference for receiving PDUs in different data services is below a threshold).

[0129] For beam failure detection, the cooperating WTRU may provide application layer / higher layer information (e.g., spatial orientation and / or location information) and beam related (e.g., the current beam it is using) information to the anchor WTRU and the network, which in turn may provide assistance / configuration information to the (e.g., cooperating) WTRU regarding when / how it may request the anchor WTRU's assistance for fast beam failure recovery or follow the default (e.g., legacy) procedure. When providing the cooperating WTRU with configuration information regarding when / how it may request the anchor WTRU's assistance for fast beam failure recovery, the anchor WTRU may use information regarding the QoS requirements (e.g., PDB) corresponding to the cooperating WTRU. When providing the configuration information, the anchor WTRU may also use the joint QoS requirements corresponding to the cooperating group, which may be used when more than one cooperating WTRU requires assistance for fast beam failure recovery at the same time.

[0130] For beam switching for optimal beam tracking, the anchor WTRU may use changes in spatial information (e.g., changes in WTRU angular orientation or relative position) received from the application layer / higher layers and information about some aspects of traffic characteristics (e.g., data arrival rate) and / or information obtained from the cooperating WTRUs. For example, the anchor WTRU may use changes in spatial information (e.g., including traffic information) to determine the optimal beam it can switch to. The anchor WTRU may be configured to provide assistance to the network and cooperating WTRUs to track and switch to the optimal beam as the XR experience progresses and the WTRU moves around. In coordinating and providing faster optimal beam switching capabilities, the anchor WTRU may ensure that the joint QoS requirements for the cooperating group are maintained.

[0131] When receiving / sending data / PDUs in multiple flows, the joint QoS requirements may apply to any of the QoS metrics, including but not limited to latency, data rate, and reliability. In the case of a joint QoS requirement corresponding to data rate, the PDUs in one or more associated flows may be considered to satisfy the joint QoS when the PDUs are sent and / or received by one or more WTRUs in the collaboration group at a data rate value associated with each flow and at least a joint minimum data rate value or a joint maximum data rate value associated with one or more flows associated with the application. Similarly, in the case of a joint QoS bound corresponding to latency, the PDUs in one or more associated flows may be considered to satisfy the joint QoS when the PDUs are sent and / or received by the WTRU within a latency bound (e.g., PDB) associated with each flow and at least a joint minimum latency bound or a joint maximum latency bound associated with one or more flows belonging to the application.

[0132] PDUs in different service flows corresponding to (e.g., each) WTRU in a cooperative group may be required to meet a joint QoS requirement (e.g., to avoid a drift condition where PDUs in different associated data flows may drift from each other). Thus, in addition to the individual QoS requirements, the association and / or dependency of services between WTRUs in a cooperative group may need to be considered, for example, when determining a condition or set of conditions that may be used by an anchor WTRU to indicate an early link failure (e.g., RLF and / or beam failure). However, link failure (e.g., RLF and / or beam failure) indication and recovery or prevention procedures (which do not consider the association between PDUs in different services to / from (e.g., each) WTRU in a cooperative group) may result in a timing difference in the reception of PDUs in different data services that exceeds a required limit (e.g., does not meet the joint QoS requirement).

[0133] The WTRU may receive traffic information from the application layer / higher layers and information about associations between the WTRUs in the cooperation group.

[0134] The anchor WTRU and / or more cooperating WTRUs may receive explicit and / or implicit information indicating service characteristics from the application layer / higher layers / network. The service information obtained by (e.g., each) WTRU in the cooperating group from the application layer / higher layers / network may include, for example, one or more of the following: PDB; data arrival rate; information related to the range of spatial changes (e.g., changes in angular orientation of the WTRU, changes in relative position of the WTRU) that the user is allowed to experience or can make; and / or information related to the initial spatial settings (e.g., initial angular orientation, initial relative position) of each WTRU in the cooperating group.

[0135] The traffic information may be used by the anchor WTRU / network to determine traffic associations between different WTRUs in a cooperative WTRU group, and to assist one or more network / anchor WTRU related actions to achieve link management. For example, such information may be received periodically or aperiodically / dynamically in RRC signaling, MACCE, DCI, NAS layer signaling, SL, or application layer signaling.

[0136] The information received by the WTRU (e.g., the anchor WTRU) and / or the network identifying the association between the WTRU and the data flow may include an identifier / ID associated with the collaborative group (e.g., a group ID that associates the WTRU with a common XR experience) and / or an identifier / ID associated with the anchor WTRU (e.g., a WTRU in a collaborative WTRU group may receive information / ID about the anchor WTRU). The different identifiers / IDs associated with the collaborative XR may be assigned / configured by one or more of the following (e.g., via RRC, MAC CE, control PDU, DCI, application / NAS layer signaling, etc.): the anchor WTRU, the network, and / or an application function.

[0137] The WTRU may communicate information to the network / anchor WTRU to handle link performance management across a set of cooperating WTRUs (eg, for RLF / beam failure and beam management).

[0138] A WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may transmit information to the network and / or the anchor WTRU associated with data communication across a cooperating WTRU group, handling of joint QoS requirements and link performance management (e.g., RLF and / or beam failure, beam management) for one or a subset of WTRUs in the cooperating WTRU group. Such information may be transmitted periodically or aperiodically / dynamically (e.g., based on detection of an event as described herein) as assistance information and / or status indications. The anchor WTRU may transmit information to the network via AS layer signaling (e.g., RRC signaling and / or messages, MAC CE, control PDU, or UCI) and / or non-AS (NAS) layer signaling (e.g., PDU session related messages).

[0139] The information transmitted by the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) to the network and / or the anchor WTRU may include the ID of the anchor WTRU, the ID of the cooperating WTRU and the cooperating group ID (e.g., transmitted to the network) and / or traffic characteristics and / or parameters of the data / traffic associated with (e.g., each) cooperating WTRU in the cooperating group. The WTRU may also transmit QoS requirements (e.g., for each WTRU), including data rate, latency, reliability, absolute / relative priority values, etc. The WTRU may also transmit joint QoS requirements associated with the cooperating group.

[0140] The anchor WTRU may transmit any of the information described herein to the network upon one or more of the following events: during connectivity / session establishment and / or (re)configuration; upon changing / updating data / traffic flows in the collaborative group; upon receiving higher layer / application information; upon detecting measurement and / or mobility changes in one of the WTRUs or a subset of WTRUs in the collaborative group; and / or upon completing RLF recovery and re-establishing the RRC connection.

[0141] The anchor WTRU may transmit any of the information described herein to the network during connectivity / session establishment and / or (re)configuration. For example, the anchor WTRU may transmit the information during RRC connection, PDU session, application session establishment and / or (re)configuration and / or when changing the RRC state in any of the WTRUs in the cooperating WTRU group.

[0142] The anchor WTRU may transmit any of the information described herein to the network when changing / updating the data / traffic flows in the cooperative group. For example, the anchor WTRU may transmit the information when adding a new WTRU to the cooperative WTRU group and / or when releasing a WTRU from the cooperative group.

[0143] The anchor WTRU may transmit any of the information described herein to the network upon receiving higher layer / application information. For example, the anchor WTRU may transmit the information upon receiving an indication (e.g., from any of the WTRUs in the cooperating group or an application function hosted in the network) indicating a change in supported data types, service characteristics, QoS requirements, etc.

[0144] The anchor WTRU may transmit any of the information described herein to the network upon detecting a measurement and / or mobility change in one of the WTRUs or a subset of the WTRUs in the cooperation group. For example, the anchor WTRU may transmit the information when RSRP, RSRQ, RSSI measurements of a signal, channel, radio link, carrier, etc. are above / below a threshold and / or when a pose / positioning measurement (e.g., position information, pose in 6DoF) is above / below a pose threshold.

[0145] The anchor WTRU may transmit any of the information described herein to the network upon completion of RLF recovery and reestablishment of the RRC connection. For example, the anchor WTRU may transmit the information upon completion of a successful RRC reestablishment during RLF recovery in one of the WTRUs or a subset of the WTRUs in the cooperating group.

[0146] The WTRU may receive configuration information associated with link / beam management from the network.

[0147] A WTRU in a collaborative group (e.g., an anchor WTRU and / or a collaborative WTRU) may receive configuration information from the network and / or the anchor WTRU, which is used by the WTRU (e.g., the anchor WTRU and / or the collaborative WTRU) to determine when it can trigger an early link failure (e.g., RLF and / or beam failure) indication or switch to an optimal beam for a WTRU or a subset of WTRUs in the collaborative group of the WTRU, so that the network can (e.g., in beam management) maintain link performance, prevent link failures (e.g., RLF and / or beam failure), and / or assist in fast link failure (e.g., RLF and / or beam failure) recovery procedures.

[0148] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a collaborative WTRU) may include one or more of: thresholds associated with the individual QoS of each WTRU; thresholds associated with a joint QoS (e.g., a joint PDB); thresholds associated with beam validity intervals; thresholds associated with instances in which the WTRU may transmit a beam failure indication; information for associating a remaining delay for a set of PDUs with a maximum count value (e.g., a value of the number of consecutive BFIs); and / or information about available beam sets.

[0149] The configuration information received by the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) may include thresholds associated with the individual QoS of each WTRU. For example, the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) may receive thresholds for (e.g., each) WTRU in a cooperating WTRU group, the thresholds being associated with the corresponding PDB and the expected duration of a predicted link failure (e.g., RLF and / or beam failure) instance.

[0150] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include thresholds associated with a joint QoS (e.g., a joint PDU). For example, a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may receive a threshold associated with a joint QoS requirement for a cooperating WTRU group. The joint QoS requirement for a PDU in two or more WTRUs in the cooperating group may be associated with, for example, a joint delay bound associated with a time difference between reception times of the PDUs in (e.g., each) WTRU.

[0151] Configuration information received by a WTRU (eg, an anchor WTRU and / or a cooperating WTRU) may include a threshold associated with a beam validity interval. For example, a WTRU (eg, an anchor WTRU and / or a cooperating WTRU) may receive a threshold associated with a beam switching rate.

[0152] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include thresholds associated with instances at which the WTRU may transmit a beam failure indication. For example, a WTRU (e.g., an anchor UE and / or a cooperating UE) may receive a threshold associated with measured RSRP for detecting beam failure instances (BFIs). The WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may receive a threshold associated with a maximum number of BFIs to count before indicating a beam failure to the gNB. count The relevant maximum count threshold (for example, the default C max_default Value and / or auxiliary C max Value) collection. Except for the maximum count C max In addition to the threshold, the WTRU may also receive a beam failure detection duration timer T for beam failure detection. BFI .

[0153] The configuration information received by the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) may include information for associating the residual delay of the PDU set with the maximum count value. For example, the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) may receive association information (e.g., a mapping relationship) to determine the maximum count value based on the residual delay D. r To select the maximum count C to use max value to receive one or more (eg, all) PDUs in a PDU set.

[0154] The configuration information received by the WTRU (e.g., the anchor WTRU and / or the cooperating WTRU) may include information about the available beam sets. For example, the network may provide the anchor WTRU with information about the available beam sets that cover the area where the cooperating group of WTRUs is located. The provided information may also include the corresponding beam direction, orientation, and / or width, thereby allowing the anchor WTRU to have, for example, Figure 3 Some mapping of beam patterns / grids across cooperating groups of WTRUs is shown. Figure 3 An example beam pattern / grid mapping is illustrated. Beams covering the area may be assigned corresponding beam IDs (e.g., Figure 3 B-1, B-2...B-20) shown.

[0155] For example, the WTRU may receive configuration information via AS layer signaling (eg, RRC signaling / messages, MAC CE, or DCI) or non-AS (NAS) layer signaling (eg, PDU session related messages).

[0156] The WTRU may assist in triggering a link failure indication in advance to prevent link failure and / or enable fast link failure recovery procedures.

[0157] After receiving the configuration information, one or more WTRUs in the cooperation group may start receiving PDUs from the sending entity (e.g., base station) via their corresponding Uu link. For example, the WTRUs in the group may also perform measurements in the channel (e.g., RSRP, RSRQ, RSSI measurements) to determine the link quality. For example, the WTRU may be configured to perform measurements periodically, or may be triggered to perform measurements upon receiving a command from the network or anchor WTRU.

[0158] The anchor WTRU may be configured to receive reported channel measurements (e.g., RSRP, RSRQ, RSSI, etc.) from one or more WTRUs in the cooperating group. The anchor WTRU may use the received measurements to determine / predict an impending link failure (e.g., RLF and / or beam failure) of one or more Uu links corresponding to one or more WTRUs in the cooperating group. The anchor WTRU may also be able to determine / predict a link failure (e.g., RLF and / or beam failure) of the WTRU based on its prediction of a link failure of another WTRU in the same cooperating group that shares similar channel characteristics. The link failure prediction (e.g., each time) may be accompanied by a predicted link failure duration, based on which the anchor WTRU may trigger an early link failure indication for the WTRU or an early joint link failure indication for a subset of WTRUs in the cooperating group.

[0159] The anchor WTRU may predict an impending link failure (e.g., RLF and / or beam failure) in one of the Uu links in the cooperating group. The anchor WTRU may obtain the prediction of the impending link failure (e.g., RLF and / or beam failure) based on collected traffic information (e.g., FoV, pose information from the camera) and / or link quality measurements (e.g., RSRP, RSRQ, RSSI measurements) performed by one or more WTRUs in the group.

[0160] If the anchor WTRU also predicts that the duration of the link failure in the cooperating WTRU will be longer than half (e.g., or some other fractional portion) of the PDB associated with its corresponding traffic, the anchor WTRU may transmit an early indication to the network that a link failure may occur at a certain point in time. The anchor WTRU may also include information (e.g., WTRU ID) indicating the WTRU to which the early RLF indication corresponds.

[0161] The anchor WTRU may predict an impending link failure in two or more Uu links in a cooperative group. The anchor WTRU may be able to predict a link failure in two or more Uu links based on collected traffic information (e.g., FoV, pose information from a camera) and / or link quality measurements (e.g., RSRP, RSRQ, RSSI measurements) from cooperative WTRUs corresponding to (e.g., each) link. The anchor WTRU may also be able to predict a link failure in two or more Uu links based on a prediction of a link failure for a single link (e.g., two Uu links may experience similar channel conditions, and therefore, a link failure (e.g., RLF and / or beam failure) predicted for one link may also be used as an indication that a link failure (e.g., RLF and / or beam failure) is also impending in another link). The link failure prediction (e.g., each time) may also be accompanied by a prediction of the duration of the link failure (e.g., RLF and / or beam failure).

[0162] For example, if the anchor WTRU determines that the predicted link failure durations for all its Uu links (except one Uu link) for which link failure is predicted are shorter than half (e.g., or some other fractional portion) of the PDB assigned to the corresponding links, the anchor WTRU may transmit to the network (e.g., only) early link failure indications for WTRUs for which link failure durations in their Uu links are predicted to be longer than half (e.g., or some other fractional portion) of the PDB. The anchor WTRU may also include information (e.g., a WTRU ID) indicating the WTRU to which the early link failure indication corresponds.

[0163] For example, if the anchor WTRU determines that the predicted link failure duration for two or more Uu links will be longer than half (e.g., or some other fractional portion) of the PDB assigned to those links, the anchor WTRU may transmit an early joint link failure (e.g., RLF and / or beam failure) indication for the group of WTRUs that predict the link failure to the network. The anchor WTRU may also include information (e.g., WTRU ID) indicating the (e.g., each) WTRU to which the early link failure indication corresponds and the joint QoS requirement for the group of WTRUs. The anchor WTRU may include the joint QoS requirement information for the group of WTRUs when transmitting the early indication of joint link failure for the group of WTRUs as assistance information for the network when it takes steps to allocate additional resources to prevent link failures (e.g., RLF and / or beam failure).

[0164] After transmitting an early link failure (e.g., RLF and / or beam failure) indication, the network may perform one or more actions to prevent link failures on the corresponding link / links. The actions performed by the network may include, for example, one or more of the following: increasing the power of the link indicating the early RLF; switching the beam indicating the early beam failure; transmitting on a different frequency band / carrier; duplicating packets; and / or using multiple TRPs.

[0165] The network may respond to the anchor WTRU to indicate that a link failure (e.g., RLF and / or beam failure) is unavoidable and imminent (e.g., due to resource shortage, adverse channel conditions, etc.) for one or more WTRUs in the cooperating group. The anchor WTRU may then instruct the WTRU or subset of WTRUs for which the link failure is declared unavoidable to initiate link recovery procedures (e.g., RRC re-establishment and / or beam reselection) without waiting for a timer (e.g., T301 timer for triggering RLF) to expire or without counting a maximum number of beam failure instances (e.g., beamFailureInstanceMaxCount) configured by the WTRU for triggering a beam failure indication before reporting a link failure (e.g., RLF and / or beam failure). The anchor WTRU may also share information (e.g., cell ID, beam ID) with the network that may be shared among the group of WTRUs and may be used to achieve faster link failure (e.g., RLF and / or beam failure) recovery.

[0166] The WTRU may assist in fast beam failure detection and recovery.

[0167] For beam failure detection and recovery, after receiving configuration information from the network and / or anchor WTRU, one or more WTRUs in the cooperative group may start receiving PDUs from the transmitting entity (e.g., base station) in their corresponding Uu link and assigned Tx / Rx beam. The WTRUs in the cooperative group may also start performing periodic beam measurements (e.g., CSI-RSRP, RSRQ, RSSI measurements) to monitor beam quality.

[0168] A beam failure instance may be detected when a cooperating WTRU or a subset of cooperating WTRUs in a cooperating group measures a beam quality below a preconfigured threshold (e.g., an RSRP threshold). Based on a received configuration (e.g., received from the network and / or anchor WTRU), a cooperating WTRU or a subset of cooperating WTRUs that detects a beam failure instance on an assigned beam may decide to request assistance from the anchor WTRU for fast beam failure recovery or may perform a default beam failure recovery procedure according to the network. A cooperating WTRU or a subset of WTRUs may decide to employ an anchor WTRU-assisted beam failure recovery procedure or a network-configured beam failure recovery procedure based on one or more of the following conditions. If one or more cooperating WTRUs detect a beam failure instance and the PDB value or joint PDB value of the traffic corresponding to the WTRU (e.g., in the case of a beam failure instance for more than one WTRU) is less than an anchor assistance time threshold, the WTRU or the group of WTRUs may employ a network-configured (e.g., default) procedure for beam failure detection and recovery. If one or more collaborating WTRUs detect a beam failure instance and the PDB value or joint PDB value of the service corresponding to the WTRU (for example, in the case of a beam failure instance of more than one WTRU) is greater than the anchor point assistance time threshold, the WTRU or the group of WTRUs may transmit an indication to the anchor WTRU to request assistance for fast beam failure recovery.

[0169] The cooperating WTRUs and the network may provide the anchor WTRU with current information about the Tx / Rx beam assignments (e.g., beam orientation, beam width, AoD and AoA of boresight, etc.) so that the anchor WTRU can have a close representation of the Tx / Rx beam patterns around the cooperating WTRU group, such as Figure 4 shown. Figure 4 A representation of the (initial) Tx / Rx beam pattern around a cooperating WTRU is illustrated. Figure 4 The representation shown can be obtained from Figure 3 The beam pattern / grid map export shown.

[0170] When transmitting an indication to the anchor WTRU to request assistance for fast beam failure recovery, the cooperating WTRU or subset of WTRUs may include application layer / higher layer spatial information (e.g., current relative position and / or angular orientation) and / or lower layer information (e.g., current beam assignments). The anchor WTRU may assist the cooperating WTRU by transmitting an indication that notifies the network of the most suitable beam set to switch to, and assigning the beam set to the WTRU or set of WTRUs requesting assistance for fast beam failure recovery.

[0171] The anchor WTRU can determine the location of the anchor WTRU based on the current spatial information it is provided with and the representation of the Tx / Rx beam patterns available to it (e.g., Figure 4 As shown in Figure 2, the most appropriate beam to be switched to and assigned to the WTRU or set of WTRUs is determined. Figure 4 4, beams B-2, B-3, and B-4 may be grouped into beam pattern 402, beams B-5, B-6, and B-7 may be grouped into beam pattern 404, beams B-13, B-14, and B-15 may be grouped into beam pattern 406, and beams B-19, B-20, and B-1 may be grouped into beam pattern 408. For example, if a WTRU (e.g., a base station) is assigned a first beam (e.g., beam “B-3”) for communicating with a transmitting entity (e.g., a base station), Figure 4 WTRU-2 in the example) to the anchor WTRU (e.g., Figure 4 If an anchor WTRU (e.g., WTRU-1 in FIG. 1 ) requests assistance for fast beam failure recovery, the anchor WTRU, which knows the WTRU's currently assigned beam (e.g., the beam on which the beam failure instance was detected) and spatial information (e.g., angular orientation and / or position), is able to determine that the WTRU can recover the WTRU's beam if the network assigns the WTRU to a different beam (e.g., beam B-4).

[0172] The network may then switch to the beam indicated by the anchor WTRU when communicating with the cooperating WTRU or WTRU subset that detected the beam failure instance. The network may also instruct the WTRU or WTRU subset to start measuring the beam to which it switched (e.g., RSRP, RSRQ measurements). If the WTRU or WTRU subset still detects a beam failure instance based on measurements performed in the newly selected beam or beams, the WTRU or WTRU subset may fall back to a default (e.g., network configured) procedure to initiate a beam failure recovery procedure. If the WTRU or WTRU subset does not detect a beam failure instance when performing measurements on the newly selected beam or beams, the WTRU or WTRU subset may maintain transmission and reception on the one or more beams.

[0173] The WTRUs may coordinate fast beam switching and may provide optimal beam tracking across a cooperating set of WTRUs.

[0174] In one example, after receiving the configuration information and / or application-related information, the anchor WTRU may determine a beam validity interval for a beam assigned to (e.g., each) WTRU in the set of cooperative groups. The beam validity interval may be related to a range of spatial changes (e.g., angular orientation, relative position change) that a WTRU may experience before the beam assigned to the WTRU is no longer an optimal beam. The WTRUs in the cooperative group may start receiving PDUs from a transmitting entity (e.g., a base station) in their assigned Tx / Rx beams.

[0175] The anchor WTRU may use a set of PDUs and / or application / configuration information (e.g., a range of possible spatial variations of the WTRU) received from a sending entity (e.g., a base station, an application layer) to determine / predict expected variations in some aspects of spatial information corresponding to a cooperating WTRU or a subset of WTRUs. Various aspects of spatial information that the anchor WTRU may be able to determine / predict may include the angular orientation of the WTRU along a given axis and / or the position of the WTRU relative to the anchor WTRU and / or the sending entity (e.g., a base station).

[0176] The anchor WTRU may determine the beam switching rate for the cooperating WTRU or WTRU subset based on various aspects of the changes in spatial information that the cooperating WTRU or WTRU subset is expected to experience and / or configuration information provided by the network. The configuration information provided by the network to the anchor WTRU / cooperating WTRU may include a beam pattern / grid mapping corresponding to the cooperating group (e.g., Figure 3 ) and the current beam assignment to (e.g., each) WTRU in the cooperation group (e.g., as Figure 4 shown).

[0177] If the beam switching rate of the cooperating WTRU or WTRU subset is greater than the validity interval of the corresponding beam or beam subset, the anchor WTRU may determine the optimal beam or optimal beam set to which the WTRU or WTRU subset may switch. The anchor WTRU may determine the optimal beam or optimal beam set to which the WTRU or WTRU subset may switch based on the expected change in spatial information and the beam pattern / grid mapping available to the anchor WTRU (e.g., Figure 3 as shown) to determine a new optimal beam for the WTRU or an optimal set of beams for a subset of WTRUs.

[0178] Upon receiving an indication from the anchor WTRU, the network may switch the beam or set of beams when communicating with the corresponding WTRU or set of WTRUs.

[0179] The WTRU may determine an instance suitable for scheduling CSI-RS / SRS based on expected DL / UL traffic and channel conditions. In addition to determining the characteristics of the expected traffic in the DL and / or UL, the WTRU may also obtain information about the propagation channel quality and / or received signal strength for a given future duration based on received DL and / or UL traffic and / or measurements made through beamforming DMRS. Based on the information obtained by the WTRU and the expected changes in the channel and / or received DL / UL signal strength, the WTRU may determine whether to transmit an indication to the network to indicate the next DL and / or UL transmission instance / timing suitable for sending CSI-RS to the WTRU and / or for the WTRU to send SRS to the network, so that some measure of channel quality (e.g., RSRP) can be reported for link adaptation, beam management, and / or RLM.

[0180] The WTRU may also be an anchor WTRU that determines appropriate DL / UL transmission times to schedule CSI-RS / SRS transmissions to a member WTRU or set of member WTRUs in a cooperative group of WTRUs. By scheduling the transmission of CSI-RS and / or SRS (e.g., only) when necessary and based on the characteristics of the expected DL and / or UL traffic, the network is able to save resources and improve the capacity of the WTRU. Additionally, for a cooperative group of WTRUs located close to each other, where the link qualities of the member WTRUs may be similar or identical, (e.g., only) the anchor WTRU may be configured with a CSI-RS and / or SRS and / or may be configured to report channel quality measurements (e.g., RSRP) of itself and / or the member WTRUs, thereby saving resources and improving the capacity of the group of cooperative WTRUs.

[0181] The CSI-RS and SRS resource configuration may be periodic, aperiodic or semi-persistent CSI-RS transmission. In periodic transmission, the WTRU may expect to receive / send CSI-RS / SRS in a set of resources reserved at periodic intervals. In aperiodic transmission, the WTRU may receive explicit signaling from the network (e.g., in the DCI) indicating the CSI-RS / SRS transmission instance. For XR services, periodic transmission of CSI-RS / SRS may incur additional overhead, which may potentially reduce capacity. Aperiodic transmission of CSI-RS / SRS after data / control / periodic CSI-RS transmission may be sufficient to meet strict latency requirements. Semi-persistent CSI-RS / SRS transmission may reduce resource overhead because even if the WTRU is configured with a periodic resource set, the CSI-RS / SRS may be sent (e.g., only) after explicit activation via the MAC CE, and / or may also be deactivated after a period of time. However, for beam management or RLM in services with faster response time, semi-persistent CSI-RS / SRS transmission may not be suitable. For XR services, solutions based on dynamic / adaptive CSI-RS / SRS configuration may be useful, which provide robust link management to balance the trade-off between capacity and latency.

[0182] The WTRU may obtain measurements of link and / or channel quality and received DL and / or UL signal strength using reference signals (e.g., DMRS), which may be scheduled using PDSCH / PUSCH. The WTRU may receive CSI-RS (e.g., only) when it is expected to report to the network an expected change in channel quality and / or DL / UL received signal strength. The WTRU (e.g., anchor WTRU) may transmit information associated with an application to the network as auxiliary information and / or status information / indication. In one example, the information associated with an application that may be transmitted by the WTRU to the network may include service characteristics and / or parameters of the application. The WTRU may transmit QoS requirements (e.g., for each WTRU in the case of a cooperative group of WTRUs), including data rate, latency, reliability, absolute / relative priority values, etc. In the case of a cooperative group of WTRUs, the WTRU may transmit the location (e.g., position and / or orientation) of the WTRUs in the cooperative group relative to the anchor WTRU.

[0183] The WTRU (e.g., the anchor WTRU) may transmit this information to the network at one or more of the following points in time: during connectivity / session establishment and / or (re)configuration; when changing / updating data / traffic flows in the collaborative group; when receiving higher layer / application information; and / or when measurement and mobility changes are detected in one of the WTRUs or a subset of WTRUs in the collaborative group.

[0184] The WTRU (e.g., anchor WTRU) may transmit this information to the network during connectivity / session establishment and / or (re)configuration. For example, the WTRU may transmit this information to the network in the following situations: during RRC connection, PDU session, application session establishment and / or (re)configuration; when changing the RRC state in any of the WTRUs in the cooperating WTRU group; and / or when a successful RRC re-establishment is completed during RLF recovery in one of the WTRUs or a subset of WTRUs in the cooperating group.

[0185] A WTRU (e.g., anchor WTRU) may transmit this information to the network when changing / updating data / traffic flows in a cooperative group. For example, a WTRU may transmit this information to the network when adding a new WTRU to a cooperative WTRU group and / or when releasing a WTRU from the cooperative group.

[0186] A WTRU (e.g., an anchor WTRU) may transmit higher layer / application information to the network upon receiving the information. For example, a WTRU may transmit the information to the network upon receiving an indication (e.g., from the application layer) indicating a change in service characteristics, QoS requirements, etc.

[0187] A WTRU (e.g., an anchor WTRU) may transmit this information to the network upon detecting a measurement and / or mobility change in one or a subset of the WTRUs in the cooperative group. For example, the WTRU may transmit this information to the network upon detecting a measurement and / or mobility change in one or a subset of the WTRUs in the cooperative group. For example, the WTRU may transmit this information to the network upon detecting a measurement and / or mobility change in one or more of the WTRUs in the cooperative group moving a certain distance beyond a threshold at which the link / channel qualities may no longer be the same and / or correlated.

[0188] A WTRU (e.g., an anchor WTRU) may determine instances and / or time periods suitable for sending a CSI-RS to the WTRU and / or for the WTRU to transmit an SRS to the network (e.g., in terms of a trade-off between resource overhead, reliability, and / or latency) based on configuration information transmitted by the network, which may consist of one or more parameters, thresholds, and / or trigger conditions. The configuration information received by the WTRU may include one or more of: thresholds related to measured channel quality and / or received signal strength; thresholds related to spatial and / or angular orientation; thresholds related to QoS; and / or information about a set of WTRUs in a cooperating group of WTRUs covered by the same CSI-RS / SRS transmission.

[0189] The configuration information received by the WTRU may include thresholds related to the measured channel quality and / or received signal strength. For example, a WTRU (e.g., an anchor WTRU) may receive a set of thresholds (e.g., threshold 1 and threshold 2, which may be thresholds related to channel quality measurement or signal strength measurement, such that threshold 1 < threshold 2) related to the channel quality (e.g., CQI) of its Uu link and / or received signal strength (e.g., RSRP, SNR, etc.) in the DL and / or UL.

[0190] The configuration information received by the WTRU may include thresholds related to spatial and / or angular orientation. For example, a WTRU (e.g., an anchor WTRU) may receive thresholds associated with changes in its spatial and / or angular orientation and / or changes in the spatial and / or angular orientation of member WTRUs in a cooperative group of WTRUs.

[0191] The configuration information received by the WTRU may include thresholds related to QoS. For example, a WTRU (e.g., an anchor WTRU) may receive thresholds associated with a PDB and a required PER / BLER. A cooperating group of WTRUs (e.g., an anchor WTRU) may receive thresholds associated with a joint QoS (e.g., a joint PDB).

[0192] The configuration information received by the WTRU may include information about a set of WTRUs in a cooperative group of WTRUs that are covered by the same CSI-RS / SRS transmission. For example, in the case of a cooperative group of WTRUs, a WTRU (e.g., an anchor WTRU) may receive a set of WTRUs covered by channel quality measurement reports (e.g., SNR / SINR, RSRP, CQI, etc.) obtained by the WTRU based on its configured CSI-RS and / or SRS. For example, (e.g., only) one WTRU (e.g., an anchor WTRU) may be configured with a CSI-RS and / or SRS without configuring the remaining WTRUs, and / or measurements obtained from and / or by the WTRU may also be applicable to one or more (e.g., all) other WTRUs in the group. The group of cooperative WTRUs may also be grouped based on their relative proximity to each other. One or more representative WTRUs in a subgroup within the group may be configured with a CSI-RS and / or SRS. In this case, the channel quality report transmitted by and / or obtained from the representative WTRU may be considered to cover one or more (e.g., all) WTRUs in the subgroup.

[0193] Figure 5 An example of a cooperating group of WTRUs receiving CSI-RS is illustrated. Figure 5 As shown, one or more (eg, all) WTRUs in the cooperation group may receive CSI-RS (eg, Figure 5 Alternatively, one WTRU (eg, the anchor WTRU) may receive a CSI-RS (eg, Figure 5 ), or one WTRU in each subgroup may receive the CSI-RS (e.g., Figure 5 on the right side of the ).

[0194] For example, Figure 5 As shown, the gNB 502 may send CSI-RS to a cooperating group 508 of WTRUs, which may include WTRUs 510, 512, 514, 516, and 518. Figure 5514, all of the WTRUs 510, 512, 514, 516, and 518 may receive CSI-RS and / or may send RSRP reports to the gNB 502. Alternatively, the WTRUs may be grouped into subgroups 520, and one WTRU (e.g., WTRU 514) may receive CSI-RS and / or send RSRP reports. Alternatively, the WTRUs may be divided into two or more subgroups, such as a first subgroup 522 and a second subgroup 524. The first subgroup 522 may include WTRUs 510, 512, and 514, and the second subgroup 524 may include WTRUs 516 and 518. One WTRU in each subgroup (e.g., WTRU 512 and WTRU 516) may receive CSI-RS and / or send RSRP reports to the gNB 502.

[0195] After receiving the configuration information, and possibly after obtaining suitable / optimal transmit and receive beams and other radio link parameters, the WTRU may begin receiving and sending PDUs in the DL and UL. The WTRU may determine and / or predict a measure of channel quality and / or received signal strength on the Uu link for a given duration in the future based on its past acquired information and current channel and / or DL / UL signal measurements. For a cooperative group of WTRUs, the anchor WTRU may determine and / or predict the expected channel quality and / or received signal strength of a member WTRU based on channel measurement information provided to the anchor WTRU by the member WTRU (e.g., via the SL). The channel quality and / or DL ​​signal strength measurements may include, for example, expected SNR / SINR, expected RSRP measurements, and / or expected CQI.

[0196] After preparing and sending the UL PDU, the WTRU (e.g., anchor WTRU) is able to determine and / or predict aspects of the expected traffic in the DL and / or UL for a given duration in the future. For a cooperating group of WTRUs, the WTRU may also determine and / or predict characteristics of the DL traffic that the member WTRUs may expect to receive in the DL and / or send in the UL for a period of time in the future. The characteristics and / or aspects of the DL and / or UL traffic that the WTRU is able to determine and / or predict may include, for example, expected changes in QoS (e.g., PDB / PER), expected changes in joint QoS (e.g., joint PDB), and / or expected arrival times of DL / UL PDUs.

[0197] In an example applicable to DL transmission, a WTRU (e.g., an anchor WTRU) may determine and / or predict a change in measured channel quality and / or received signal strength, a change in expected QoS, and / or a change in expected joint QoS (e.g., PDB, required PER) between a cooperating group of WTRUs. If the WTRU determines and / or predicts a change in expected channel quality measurements (e.g., SNR / SINR, RSRP, CQI, etc.) above a first threshold of configured thresholds related to channel quality measurements and / or below a second threshold of these configured thresholds, the WTRU may further determine and / or predict a change in QoS of expected traffic in the DL. If the WTRU further determines that a change in QoS of its expected traffic in the DL and / or UL is above a configured threshold related to QoS and / or joint QoS, the WTRU may transmit an indication to the network to send CSI-RS in the next PDSCH transmission instance. This may be done to report expected changes in channel quality and / or received signal strength (e.g., SNR, RSRP) for link adaptation, radio link management, beam management, and / or to manage expected radio link or beam failures.

[0198] If the WTRU determines and / or predicts a change in an expected channel quality measurement (e.g., SNR / SINR, RSRP, CQI, etc.) that is above a second threshold (e.g., suggesting a significant expected change in the channel quality measurement), the WTRU may transmit an indication to the network to send a CSI-RS in the next PDSCH transmission instance, regardless of the expected change in QoS and / or combined QoS, thereby reporting the expected change in the channel quality measurement and / or received signal strength (e.g., SNR, RSRP).

[0199] After a WTRU (e.g., an anchor WTRU) determines that it is expected to transmit an indication to the network to transmit CSI-RS, the WTRU may also determine that the next transmission time instance at which the network may transmit CSI-RS may be too early and / or may result in a longer delay than the PDB required to maintain good quality of experience (QoE) before the WTRU receives CSI-RS and reports back measurements of changes in channel quality and / or received signal strength and the network may take appropriate action (e.g., switch beams, increase power, etc.). In this case, the WTRU may instruct the network to transmit CSI-RS in the next DRX on cycle, rather than instructing to transmit CSI-RS in the next DL transmission time instance, even if no DL traffic is scheduled, for urgent reporting of channel quality measurements.

[0200] In an example applicable to UL transmissions, based on PDUs received in the DL and / or PDUs sent in the UL, a WTRU (e.g., an anchor WTRU) may determine and / or predict a change in its spatial and / or angular orientation, which in turn may affect the channel / radio link / beam quality and received signal strength in the UL. Based on the magnitude of the change in spatial and / or angular orientation, the WTRU may determine when to transmit an indication to the network including a request to transmit an SRS so that the network may immediately measure the change in channel quality and / or received signal (e.g., beam) strength corresponding to the change in spatial and / or angular orientation of the WTRU and / or take appropriate action (e.g., switch beams).

[0201] If a WTRU (eg, an anchor WTRU) determines and / or predicts that the spatial and / or angular orientation change of the WTRU is above a configured threshold, the WTRU may transmit a request to the network to obtain a resource grant to transmit SRS in the next available transmission instance.

[0202] After receiving the indication, the WTRU (eg, anchor WTRU) may receive an acknowledgement to expect CSI-RS in the next PDSCH transmission instance or the next DRX On cycle and / or transmit SRS to the network in the next PUSCH transmission instance.

[0203] The WTRU may be configured to determine a measurement periodicity for radio resource management (RRM) related measurements. For example, the WTRU may determine an appropriate measurement periodicity for a WTRU measurement configuration for performing RRM related measurements.

[0204] The WTRU may receive configuration information from the network, the configuration information including two or more parameters related to a periodicity value for performing RRM-related measurements. The WTRU may select a measurement periodicity (e.g., in a configured periodicity) for RRM-related measurements. For example, the RRM-related measurements may be measurements of one or more of SSB, CSI-RS, etc. The WTRU may select a measurement periodicity (e.g., in a configured periodicity) for RRM-related measurements based on information obtained related to one or more of the rate of change of the propagation channel and / or service information. The WTRU may assist in maintaining link performance (e.g., acceptable link performance) under changing channel conditions and mobility, for example, by dynamically or semi-statically changing the measurement periodicity for RRM-related measurements to accommodate XR service requirements.

[0205] In one example, the WTRU may periodically perform RRM-related measurements on a configured set of resources. For example, the WTRU may reserve or utilize one or more configured sets of resources at periodic intervals. RRM-related measurements may be measurements performed to select one or more cells, to support radio access technology (RAT) handover, to support BWP switching, and the like. For example, the configured set of resources may include one or more of SSB or CSI-RS. Measurement instances occurring at short intervals (e.g., relatively short measurement periodicity) may result in more frequent interruptions to DL / UL reception / transmission of services for the WTRU within a given duration, which may result in reduced throughput. Measurement instances occurring at short intervals may introduce longer latency, resulting in poor QOE for XR applications. Measurement instances occurring at long intervals (e.g., relatively long periodicity) may not allow the gNB and WTRU to adapt quickly to changes, resulting in the network being unable to update the RRM configuration quickly enough relative to the PDB in the XR service. For example, the WTRU may perform measurements to adapt to changes in one or more of channel conditions, WTRU location, and / or WTRU speed. Based on changes in these channel conditions and / or measurement reports transmitted by the WTRU, the WTRU may be configured to use a modified RRM configuration, which may include updating one or more BWP configurations / switches, cell (e.g., RLM) configurations, or beam configurations / handovers, etc. Measurement instances occurring in long intervals may result in radio link failures. For XR services, implementations based on dynamically / adaptively configured RRM-related measurement periodicity may provide robust link performance while providing a balanced balance of capacity and latency.

[0206] Figure 6 The following example illustrates the configuration of RRM related measurement periodicity. Figure 6 As shown, the WTRU may receive from the gNB at least one (e.g., default) configuration for an RRM-related measurement periodicity T1 and an additional configuration related to a second measurement periodicity T2, wherein the first (e.g., default) measurement periodicity T1 may be greater than the second measurement periodicity T2 (i.e., T1>T2), as shown in FIG. Figure 6 For example, RRM-related measurements may include SSB or CSI-RS measurements. Figure 6 As shown, T1 may include SSBs 602, 604, 606, and 608, and / or SSBs 610, 612, 614, 616, and 618. T2 may include SSBs 620, 622, and / or 624.

[0207] The WTRU may start DL / UL reception / transmission and perform RRM-related measurements at each period (e.g., each T1 period) with a configured measurement duration (e.g., measurement gap), during which the DL / UL reception / transmission may be interrupted. The WTRU may also measure changes in link quality and / or propagation channels, for example, when receiving DL traffic using reference signals (e.g., demodulation reference signals (DMRS)). The WTRU may determine whether a change (e.g., a periodic change) in RRM-related procedures should occur based on the observed rate of change of link and / or channel quality. For example, the observed rate of change of link and / or channel quality may include a rate of change of reference signal received power (RSRP) based on DMRS. For example, the RRM-related procedures may include one or more of handover, cell reselection, radio link monitoring, BWP switching, etc. The WTRU may receive configuration information from the gNB, which consists of thresholds related to the rate of change of measured link and / or channel quality (e.g., the rate of change of measured RSRP values) and / or packet arrival rate in XR traffic. When these thresholds are exceeded, the WTRU may be configured to adjust one or more RRM configuration parameters (eg, measurement periodicity).

[0208] The WTRU may use reference signals to obtain measurements of link and / or channel quality and received DL strength (e.g., RSRP). For example, DMRS that may be scheduled using a physical downlink shared channel (PDSCH) transmission may be used for measurement. The WTRU may also determine the rate of change R of the link and / or channel quality measurements between measurement instances. m The rate of change of the measured link and / or channel quality between measurement instances R m The WTRU may indicate that one or more of the following events are expected to occur: increased WTRU mobility, congestion, and / or link / beam failure. The WTRU may also determine that RRM-related procedures corresponding to these events (e.g., congestion, increased mobility, link / beam failure) are expected to occur. For example, the RRM-related procedures may include, but are not limited to, handover, cell selection, cell reselection, BWP switching, beam selection, and / or beam reselection.

[0209] Based on the observed rate of change R of the link and / or channel quality measurements between measurement instances m, the WTRU may determine whether to switch an RRM-related (e.g., SSB, CSI-RS) measurement interval (e.g., periodicity) from a first value to a second value (e.g., from T1 to T2) and transmit an indication to the gNB. The indication may indicate that the WTRU has changed its RRM measurement periodicity and / or has adjusted one or more RRM-related configuration parameters. The indication may indicate the changed periodicity / RRM configuration parameter value. If the WTRU determines that the link and / or channel quality measurement (e.g., measured RSRP, RSRQ, etc.) has changed between measurement instances at a rate R m If the WTRU determines that the link and / or channel quality measurements (e.g., measured RSRP, RSRQ, etc.) are changing at a rate R between measurement instances, the WTRU may switch the RRM-related measurement interval (e.g., periodicity) from a first value to a second value (e.g., from T1 to T2) such that the WTRU may perform RRM-related measurements at shorter intervals. However, if the WTRU determines that the link and / or channel quality measurements (e.g., measured RSRP, RSRQ, etc.) are changing at a rate R between measurement instances, the WTRU may switch the RRM-related measurement interval (e.g., periodicity) from a first value to a second value (e.g., from T1 to T2) such that the WTRU may perform RRM-related measurements at shorter intervals. m is less than the packet arrival rate, the WTRU may maintain the RRM-related measurement interval (periodicity) at a first value (eg, T1).

[0210] The WTRU may dynamically adjust the maximum number of BFI counts it needs to perform before declaring a beam failure and / or transmitting a beam failure indication to the gNB. In one example, the WTRU may receive configuration information from the network consisting of two or more maximum count values ​​related to the number of BFIs that the WTRU must count before declaring a beam failure and transmitting a beam failure indication to the network. During reception of PDUs in a PDU set, the WTRU may need to maintain nominal link performance and may dynamically adapt to channel conditions to meet the PDU set level delay budget and maintain dependencies between PDUs in the PDU set. For beam / link failure instances, the WTRU may switch to an alternative beam and / or perform a beam failure recovery procedure to recover the optimal beam and maintain an acceptable packet error rate during reception. During a beam failure instance, the WTRU may also recover the optimal beam for continued reception of PDUs before the PDU set level delay expires. In a scenario (e.g., a legacy scenario), the WTRU may be statically configured to count the maximum number of beam failure instances (C ) before it may indicate to the network that a beam failure has occurred and initiate a beam failure recovery procedure. max ). Such a configuration may enable the WTRU to wait for a predetermined duration for favorable channel conditions to allow the beam to recover by itself. Therefore, this configuration may prevent the WTRU from declaring a beam failure prematurely and prevent the beam failure recovery procedure from being triggered unnecessarily. However, such a static configuration may not be sufficient to meet the PDU set level delay requirements during beam failure occasions when receiving PDUs in a PDU set in delay sensitive applications.

[0211] In an example solution, the WTRU may be configured with a number of maximum counts (C ) for counting BFIs before transmitting a BF indication. max ) value, and can be based on the remaining delay D r To dynamically select the appropriate C to use max value to receive one or more (e.g., all) PDUs in the PDU set after a beam failure occurs.

[0212] The WTRU can receive and beam failure detection duration T BFI and additional configuration information related to RSRP thresholds for detecting beam failure instances. In a scenario (e.g., a legacy scenario), the WTRU may be configured to measure RSRP during a CSI-RS and / or SRS measurement instance, and if the measured RSRP is below a threshold, the physical (PHY) layer may detect a beam failure. Upon detecting a beam failure, the PHY layer in the WTRU may transmit an indication to the MAC layer, which in turn may start a BFI count C1 and start a BFI timer. The timer in the MAC layer may continue to run until the MAC layer receives a second indication of a beam failure from the PHY layer, in which instance the MAC layer may update the BFI count to C2 and may reset the BFI timer. The MAC layer may continue to increment the BFI count by 1 to C n+1 , and resets the timer whenever the MAC layer receives an indication of beam failure from the PHY layer. n+1 =C max , the MAC layer may send an indication to the network requesting the initiation of a beam failure recovery procedure. However, if the BFI timer expires (e.g., reaches T BFI ), the MAC layer may assume that the beam RSRP has recovered and may reset its BFI count to 0 (e.g., C0).

[0213] In order to dynamically adjust the maximum count (C max ) value, the WTRU may also calculate the remaining delay D of the PDU set after the first beam failure instance based on r with the maximum count value (e.g., C max_default , C max_1 , C max_2 ...etc.) sets to receive the mapping relationship, the maximum count value set may also include a default C that the WTRU can select. max_default The maximum count value can also be configured in descending order, so that C max_default >C max_1 >C max_2 > ... etc. In one example, the WTRU may calculate the remaining delay D of the PDU set based on ther To adopt the mapping, so that if D r <(C max_default –1)*T BFI , then the WTRU can use C max_1 ; or if D r <(C max_1 –1)*T BFI , then the WTRU can use C max_2 etc.

[0214] In one example, the WTRU may start receiving PDUs in a PDU set using an optimal beam. Upon starting to receive the PDU set, the WTRU may also receive an indication from the gNB (e.g., in a DCI) with information about a first PDU in the PDU set. For example, the indication may indicate that a given PDU (e.g., the first PDU) is the beginning of the PDU set (e.g., the first PDU is the first PDU in the PDU set). The indication about the first PDU may be transmitted as part of downlink control information (DCI) at the beginning of each PDU set.

[0215] In one example, after obtaining an indication of a first PDU in a PDU set, the WTRU may begin receiving the PDUs in the PDU set via a beam. Figure 7 An example of adaptive setting of the maximum count value of the BFI used to transmit a beam failure recovery request to the gNB is illustrated. Figure 7 As shown, the WTRU may also periodically receive CSI-RS and / or SRS to measure RSRP and determine the received power of the beam. If the WTRU measures an RSRP value below an RSRP threshold and / or receives at least one erroneous PDU, the PHY layer in the WTRU may transmit a first indication of a beam failure instance to the MAC layer, after which the MAC layer may start incrementing the BFI count C1 and enable the beam failure detection timer T BFI Based on the received PDUs, the MAC layer in the WTRU may determine the remaining delay D for the set of PDUs after experiencing the first BFI. r The WTRU may then use the remaining delay D r , the maximum count value available C max The mapping relationship between the set and the beam failure detection timer is used to determine the maximum number of BFIs to be counted before transmitting a beam failure indication to the network to initiate the beam recovery procedure and maintain the delay budget. In one example, the MAC layer in the WTRU may be configured to switch back to the default maximum count value C after receiving one or more (e.g., all) PDUs in the PDU set. max_default .

[0216] In one example, the WTRU may receive a configuration set including a maximum count (C max ) related to one or more thresholds, BF detection timer (T BFI ), one or more mapping relationships between the remaining delay value and the maximum count threshold and / or thresholds related to RSRP management (e.g., in Figure 7 702 in ). The WTRU may begin receiving PDUs in the PDU set (e.g., including an indication of a starting PDU in the PDU set) (e.g., at Figure 7 The WTRU may measure the RSRP on the beam and may determine that the RSRP on the beam is below the RSRP threshold (e.g., the WTRU is experiencing BFI) (e.g., at 704 in FIG. 1 ). Figure 7 704 in FIG. 1 ). The WTRU may determine the remaining delay D of the PSDB that satisfies the PDU set. r (For example, in Figure 7 The WTRU may use the mapping relationship to select an appropriate maximum count threshold C for the number of BFIs to be counted. max (For example, in Figure 7 706 in ). The WTRU may use C max_2 As a threshold for the maximum number of BFIs to be counted before transmitting a beam failure indication to the gNB (e.g. Figure 7 708 of them).

[0217] In one example, the WTRU may dynamically adjust the BFR maximum count threshold C max, which may be used to determine when to transmit an indication of a beam failure (BF) to the gNB. The variability may be based on association information (e.g., a mapping) between the remaining delay in the PSDB and a configured maximum count threshold for indicating a beam failure. For example, the WTRU may be configured to receive beam failure configuration information, the beam failure configuration information including a plurality of thresholds indicating a maximum number of beam failure instances (BfI) to be counted before indicating a beam failure, a beam failure detection duration, an indication of at least an association between a first threshold of the plurality of thresholds and a minimum delay parameter (e.g., a remaining delay value), and an RSRP threshold for beam failure detection. The WTRU may use the RSRP threshold to evaluate the beam failure. The WTRU may receive a first PDU in a PDU set and an indication that the first PDU is a first PDU in a plurality of PDUs in the PDU set. The WTRU may determine that at least one of the PDU sets has not been successfully received (e.g., and / or a beam failure has occurred). The WTRU may determine that the remaining delay bound of the PDU set is less than or equal to the minimum delay parameter. In response to determining that at least one of the PDU sets has not been successfully received and the remaining delay bound of the PDU set is less than or equal to the minimum delay parameter, the WTRU may use a first threshold to evaluate a beam failure. The WTRU may transmit an indication of a beam failure based on determining that the number of detected BFIs exceeds the first threshold.

[0218] For example, the WTRU may receive configuration information from a network indicating multiple associations between a reference signal received power (RSRP) threshold, a beam failure detection duration value, and / or a corresponding number of consecutive BFIs and a remaining delay value. The WTRU may receive a PDU associated with a PDU set on a beam. The WTRU may initialize a counter to a first counter value (e.g., 0). The WTRU may receive an indication that the PDU is the first PDU in the PDU set (e.g., and / or the PDU is the first PDU among multiple PDUs in the PDU set). The WTRU may perform a first RSRP measurement associated with the beam. The WTRU may determine that the first RSRP measurement is less than the received RSRP threshold. The WTRU may increment the counter based on determining that the first RSRP measurement is less than the received RSRP threshold. The WTRU may determine a remaining delay value associated with the PDU set based on the received PDU. The WTRU may determine a comparison value (e.g., (C )) based on a default value for the number of consecutive BFIs and the beam failure detection duration value. max_1 –1)*T BFI). The WTRU may compare the remaining delay value with a comparison value. The WTRU may select a value for the number of consecutive BFIs based on the remaining delay value associated with the PDU set and a plurality of associations. For example, if the remaining delay value is less than the comparison value, the WTRU may select a value for the number of consecutive BFIs. If the WTRU determines that the second RSRP measurement is less than the received RSRP threshold, the WTRU may perform a second RSRP measurement and may increment a counter. The WTRU may send an indication of a beam failure based on the selected value for the number of consecutive BFIs. For example, the WTRU may send an indication of a beam failure based on the number of consecutive BFIs reaching (e.g., being greater than or equal to) a selected value.

[0219] The processes and means described herein may be applied in any combination, may be applied to other wireless technologies, and may be used for other services.

[0220] The WTRU may refer to an identity of a physical device, or to an identity of a user, such as a subscription-related identity, for example, an MSISDN, a SIP URI, etc. The WTRU may refer to an application-based identity, such as a user name that may be used for each application.

[0221] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, and / or any host computer.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information from a network, the configuration information comprising a reference signal received power (RSRP) threshold and a plurality of associations between a corresponding number of consecutive beam failure instances (BFIs) and a residual delay value; receiving, via the beam, a packet data unit (PDU) associated with the set of PDUs; performing a first RSRP measurement associated with the beam; determining that the first RSRP measurement is less than a received RSRP threshold; determining a remaining delay value associated with the set of PDUs based on the received PDUs; selecting a value for the number of consecutive BFIs based on the remaining delay value associated with the set of PDUs and the plurality of associations; as well as An indication of a beam failure is sent to the network based on the selected value of the number of consecutive BFIs.

2. The method according to claim 1, further comprising: An indication is received that the PDU is a first PDU among a plurality of PDUs in the set of PDUs.

3. The method according to claim 1, further comprising: incrementing a counter based on determining that the first RSRP measurement is less than the received RSRP threshold; determining a comparison value based on a default value of the number of consecutive BFIs and a beam failure detection duration value; comparing the remaining delay value associated with the set of PDUs with the comparison value; as well as Under the condition that the remaining delay value is less than the comparison value, the value of the number of consecutive BFIs is selected based on the remaining delay value and the configuration information. The method according to claim 3 , wherein the configuration information further includes the beam failure detection duration value.

5. The method according to claim 3, further comprising: Make sure the timer has not expired; as well as The counter is incremented based on determining that the first RSRP measurement is less than the received RSRP threshold and determining that the timer has not expired.

6. The method according to claim 1, further comprising: Initializing a counter to a first counter value; as well as Upon determining that the first RSRP measurement is less than the received RSRP threshold, the counter is incremented to a second counter value.

7. The method according to claim 6, further comprising: performing a second RSRP measurement; determining that the second RSRP measurement is less than the received RSRP threshold; as well as Upon determining that the second RSRP measurement is less than the received RSRP threshold, the counter is incremented to a third counter value.

8. The method of claim 6, wherein sending the indication of the beam failure based on the selected value of the number of consecutive BFIs comprises: determining that the second counter value is equal to or greater than the value of the number of consecutive BFIs; as well as The indication of the beam failure is sent based on determining that the second counter value is equal to or greater than the value of the number of consecutive BFIs.

9. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor, the processor being configured to: receiving configuration information from a network, the configuration information comprising a reference signal received power (RSRP) threshold and a plurality of associations between a corresponding number of consecutive beam failure instances (BFIs) and a residual delay value; receiving, via the beam, a packet data unit (PDU) associated with the set of PDUs; performing a first RSRP measurement associated with the beam; determining that the first RSRP measurement is less than a received RSRP threshold; determining a remaining delay value associated with the set of PDUs based on the received PDUs; selecting a value for the number of consecutive BFIs based on the remaining delay value associated with the set of PDUs and the plurality of associations; as well as An indication of a beam failure is sent to the network based on the selected value of the number of consecutive BFIs.

10. The WTRU of claim 9, wherein the processor is further configured to receive an indication that the PDU is a first PDU among a plurality of PDUs in the set of PDUs.

11. The WTRU of claim 9, wherein the processor is further configured to: incrementing a counter based on determining that the first RSRP measurement is less than the received RSRP threshold; determining a comparison value based on a default value of the number of consecutive BFIs and a beam failure detection duration value; comparing the remaining delay value associated with the set of PDUs with the comparison value; as well as Under the condition that the remaining delay value is less than the comparison value, the value of the number of consecutive BFIs is selected based on the remaining delay value and the configuration information.

12. The WTRU of claim 11, wherein the configuration information further includes the beam failure detection duration value.

13. The WTRU of claim 11 , wherein the processor is further configured to: Determining that the timer has not expired; and The counter is incremented based on a determination that the first RSRP measurement is less than a received RSRP threshold and a determination that the timer has not expired.

14. The WTRU of claim 9 wherein the processor is further configured to: Initializing a counter to a first counter value; and Upon determining that the first RSRP measurement is less than the received RSRP threshold, the counter is incremented to a second counter value.

15. The WTRU of claim 14 wherein the processor is further configured to: performing a second RSRP measurement; determining that the second RSRP measurement is less than the received RSRP threshold; and Upon determining that the second RSRP measurement is less than the received RSRP threshold, the counter is incremented to a third counter value.

16. The WTRU of claim 14, wherein the processor being configured to send the indication of the beam failure based on the selected value of the number of consecutive BFIs comprises the processor being configured to: determining that the second counter value is equal to or greater than the value of the number of consecutive BFIs; and The indication of the beam failure is sent based on determining that the second counter value is equal to or greater than the value of the number of consecutive BFIs.

Images