Method for Robust Link Performance Management for XR

Abstract

The WTRU may receive configuration information regarding handling beam failure from a base station. The WTRU may receive one or more PDUs of a PDU set. The WTRU may receive a reference signal via 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 increment a counter and may determine a remaining delay D r of the PDU set based on the received PDU. If the remaining delay D r is less than a certain value, the WTRU may select a second maximum count threshold based on the remaining delay D r and associated information. The WTRU may perform a second RSRP measurement and may increment the counter if the RSRP is below the threshold. When the counter reaches the second maximum count threshold, the WTRU may send a beam failure indicator to the gNB.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) 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

[0002] 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), as well as realities interpolated between them. Virtual Reality (VR) is a rendered version of a delivered visual and auditory scene. The rendering is designed to mimic as naturally as possible real - world visual (e.g., stereoscopic 3D) and auditory stimuli for an observer or user as they move within the limits defined by the application. Augmented Reality (AR) is when a user is provided with additional information or artificially generated objects, or content overlaid on the current environment. Mixed Reality (MR) is an advanced form of AR where some virtual elements are intentionally inserted into the physical scene to provide the illusion that these elements are part of the real scene. XR can include all real and virtual combined environments and human - machine interactions generated by computer technology and / or wearables.

[0003] The concept of immersion in the context of XR services refers to providing the feeling of being surrounded by a virtual environment and the feeling of being physically and spatially located within the virtual environment. The level of virtualization can range from partial sensory input to fully immersive multi-sensory input that leads to a virtual reality that is practically indistinguishable from actual reality.

[0004] XR devices can be associated with the ability to provide various degrees of spatial tracking. XR devices can be equipped with various sensors that enable spatial tracking, such as, for example, a monocular camera / stereo camera / depth camera, wireless beacon, GPS, inertial sensors, etc. Spatial tracking can be performed at various levels, such as, for example, 3 degrees of freedom (DoF) (e.g., rotational movement along the X, Y, and Z axes) or 6 DoF (e.g., rotational movement and / or translational movement along the X, Y, and Z axes). Spatial tracking can result in an interaction to experience some form of virtual content. The user can act within and / or interact with components within the extended reality. For example, actions and / or interactions can include movement, gestures, gaze tracking, etc. Spatial tracking is an important enabler of immersive XR experiences. For example, a certain form of head and / or movement tracking can ensure that the simulated visual and auditory components from the user's perspective are updated to match the user's movement. Incorrect and / or delayed spatial tracking can result in discomfort and / or a feeling of motion sickness for the user.

[0005] A wireless transmit / receive unit (WTRU) can be compatible with any XR device / node that can be provided in various form factors. Examples of WTRUs (such as XR WTRUs) include, but are not limited to: Head Mounted Displays (HMDs), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearables, etc. Additionally, several different types of XR WTRUs can be envisioned based on XR device capabilities (such as displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, power, etc.) provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs can be grouped into a cooperative XR group to support XR applications / services. Summary of the Invention

[0006] Methods, systems, and means for robust link maintenance for XR services may be disclosed herein. For example, a WTRU may receive traffic information from an application / upper layer and information regarding associations between WTRUs within a coordination group. The WTRU may send information to a network / anchor WTRU to handle link performance management (e.g., radio link failure (RLF) / beam failure and beam management) across a group of coordinated WTRUs. The WTRU may receive configuration information from a network associated with link / beam management. The WTRU may assist in early triggering of link failure indicators 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 provide optimal beam tracking across a coordination set of WTRUs. The WTRU may determine a scheduling instance when a reference signal used for RSRP reporting and / or beam refinement is configured and / or scheduled. The WTRU may send information to the network indicating when it is suitable to schedule CSI-RS in the DL based on current information regarding the traffic and channel quality the WTRU expects to receive for RSRP reporting. The WTRU may send information regarding XR traffic to the network. The WTRU may receive configuration information including parameters related to two or more measurement gap periods. The WTRU may send an indicator to the network indicating 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 determine the remaining latency of a set of PDUs. The WTRU may select a configuration to use to indicate beam failure to the gNB.

[0007] The anchor WTRU may assist in preventing link failures in a coordinated WTRU group. The anchor WTRU may determine / predict link failure instances (e.g., RLF and / or beam failure) within the coordinated group of WTRUs, dynamically provide traffic information, and send early link failure indicators, thereby assisting the network in preventing link failures. The anchor WTRU may receive upper layer / application layer information related to the XR experience, such as association information across the coordinated WTRUs, WTRU-related quality of service (QoS) requirements (e.g., QoS requirements corresponding to each WTRU within the coordinated group), and / or joint QoS requirements for the coordinated group. The anchor WTRU may receive a configuration (e.g., in RRC) that includes one or more thresholds related to each WTRU or joint QoS requirements (e.g., PDB) and the duration of a link failure instance (e.g., RLF and / or beam failure). The anchor WTRU may predict the next link failure and its duration on one or more Uu links corresponding to one or a subset of the WTRUs within the coordinated group. If the predicted duration of the link failure instance is equal to or greater than a predetermined percentage of the PDB, the anchor WTRU may send an early link failure indicator if the predicted link failure corresponds to a single WTRU, or a joint link failure indicator 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 a different RB) to prevent the link failure. If the predicted duration of the link failure instance is less than a predetermined percentage of the PDB, the anchor WTRU may assume that the link failure may recover before QoS degradation occurs and may not perform any action.

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

[0009] Coordinated beam maintenance from the perspective of the anchor WTRU can be supported. The anchor WTRU can determine the optimal beam for (e.g., each) member WTRU to switch based on assistance information from the application, member WTRUs, and the network. The anchor WTRU can receive application configuration information, which can include the data arrival rate for (e.g., each) coordinated WTRU and / or initial special information (e.g., relative location, orientation) and the range of possible spatial changes for (e.g., each) coordinated WTRU. The anchor WTRU can receive configuration information from the network, which can include the initial beam assigned to (e.g., each) WTRU in the coordination group, beam orientation information (e.g., direction, width) of one or more (e.g., all) candidate beams available at (e.g., each) WTRU in the coordination group, and / or beam association information indicating the mapping between the beam ID and the beam orientation information (e.g., direction, width). The anchor WTRU can calculate the beam active interval for (e.g., each) coordinated WTRU based on the network configuration information and application information. The WTRU can receive application data via the corresponding initial beam. The WTRU can determine the expected change in spatial information (e.g., new location, new orientation) for the coordinated WTRU based on the application data and / or application configuration information. The WTRU can determine the beam switching rate for the coordinated WTRU based on the expected change in the 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 active interval, the WTRU can determine the optimal beam for the member WTRU based on the expected spatial information of the member WTRU and the beam association information, send an indication to the network on the optimal beam determined for the coordinated WTRU, and / or send an indication to the coordinated WTRU on the optimal beam to be used.

[0010] Dynamic adaptation of the maximum count number of BFIs for sending beam failure indicators to the gNB may be supported. The WTRU may receive configuration information related to handling beam failure from the base station, and the configuration information may include one or more of the following. One or more maximum count values related to the maximum number of BFIs, BFI_count, to be counted before indicating beam failure to the gNB (e.g., default value C max_1 and a second value C max_2 ); beam failure detection duration T BFI ; delay threshold D related to the remaining delay of the PDU set T ; D T association between and the maximum count value (e.g., mapping relationship); and / or RSRP threshold. The WTRU may receive one or more PDUs of the PDU set via the beam. The WTRU may receive a reference signal (e.g., CSI-RS) via the same beam (e.g., periodically) and may perform a first RSRP measurement. If the measured RSRP on the beam is less than the RSRP threshold, the WTRU may increment BFI_count (e.g., C n ) by one (e.g., C n+1 ) and may determine the remaining delay D r of the PDU set based on the received PDU. For example, C n may be a variable correlated with the current value of BFI_count. If the remaining delay D r is less than a value (e.g., a comparison value, (C max_1 -1) * T BFI ), the WTRU may select a second maximum count threshold (e.g., C r less than C max_1 ) based on the remaining delay D max_2 and the association information. The WTRU may perform a second RSRP measurement (e.g., for 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 send a beam failure indicator to the gNB.

Brief Description of the Drawings

[0011]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0012] Exemplary network for the implementation of the present invention FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of 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 multicarrier (FBMC), etc.

[0013] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it is to 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 can 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", can be configured to transmit and / or receive wireless signals and can be a user equipment (UE), a mobile station, a fixed subscriber unit or a mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or a Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can also be interchangeably referred to as a UE.

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

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

[0016] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via 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.). Air interface 116 may be established using any suitable radio access technology (RAT).

[0017] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN 104 / 113, and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish the air interfaces 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 Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

[0021] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless 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), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0022] The base station 114b in FIG. 1A can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by, e.g., a drone), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0023] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video delivery, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same RAT or a different RAT as RAN 104 / 113. For example, in addition to being connected to a RAN 104 / 113 that can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0024] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN 108 can include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 can include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 can include another CN connected to one or more RANs that may employ the same RAT or a different RAT as the RAN 104 / 113.

[0025] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A can be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

[0026] Figure 1B is a system diagram illustrating an exemplary WTRU102. As shown in Figure 1B, the WTRU102 can 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU102 can include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0027] The processor 118 can be a general-purpose processor, a dedicated 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 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120 which can be coupled to the transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0029] Although the transmit / receive element 122 is depicted in FIG. 1B 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 via the air interface 116.

[0030] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have a multimode functionality. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

[0031] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, 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) and may receive data input by a user therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any suitable type of 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), 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).

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

[0033] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from GPS chipset 136, WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

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

[0035] WTRU102 may include full duplex radio in which some or all of the transmission and reception of signals associated with a particular subframe (e.g., for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via processor 118). In one embodiment, WRTU102 may include half duplex radio for the transmission and reception of some or all of any of the signals (e.g., associated with a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

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

[0037] RAN 104 may include eNodeBs 160a, 160b, 160c, but it will be understood that RAN 104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a, for example, may transmit and / or receive radio signals from WTRU 102a using multiple antennas.

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

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

[0040] The MME 162 can be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0041] The SGW 164 can be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and the function of managing and storing the context of the WTRUs 102a, 102b, 102c.

[0042] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0043] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as the PSTN108 to the WTRU102a, 102b, 102c in order to facilitate communication between the WTRU102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and the PSTN108. In addition, CN106 may provide the WTRU102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0044] The WTRU is described as a wireless terminal in FIGS. 1A-1D, but in certain representative embodiments, it is contemplated that such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0046] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to another type of wired network / wireless network that carries traffic entering and / or exiting the distribution system (DS) or BSS. Traffic to an STA originating outside the BSS may reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, the source STA may send the traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the "ad hoc" communication mode.

[0047] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS, but can also be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0048] High Throughput (HT) STAs can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[0049] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining a plurality of consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may divide the data into two streams. The Inverse Fast Fourier Transform (IFFT) process and the time - domain process may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0050] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities, including certain capabilities, such as support for a particular and / or limited bandwidth (e.g., support only for these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0051] A WLAN system that supports multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes 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 can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operation mode), when the primary channel is in operation, even if most of the frequency band remains in an inoperative state and may be available, the entire available frequency band may be considered to be in operation.

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

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

[0054] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to / from WTRU 102a using, for example, multiple antennas. In one embodiment, gNBs 180a, 180b, and 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 one embodiment, gNBs 180a, 180b, and 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).

[0055] The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0056] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as mobility anchor points. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle to communicate with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c may function as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, and 102c.

[0057] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0058] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0059] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can perform roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 can provide control plane functions for exchange between RAN 113 and other RANs (not shown) that employ other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0060] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0061] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can 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, and providing mobility anchoring.

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

[0063] In view of FIGS. 1A-1D, and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a and b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a and b, SMFs 183a and b, DNs 185a and b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0065] One or more emulation devices can perform one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a non-deployed (e.g., for testing) wired and / or wireless communication network to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device to transmit and / or receive data.

[0066] Link performance management may be implemented. The time-varying nature of the radio propagation environment and the imperfections of physical hardware may introduce fading and severe impairments to the signals reaching the receiver. To maintain acceptable link performance and provide guaranteed QoS and capacity, various physical layer techniques, such as the deployment of multiple antennas with beamforming capabilities, may be employed. Due to insufficient channel conditions, WTRU mobility, etc., instantaneous link performance fluctuations may still occur, which may cause a significant drop in the received signal power condition and lead to insufficient QoS provision or even service interruption. The L1 / L2 configuration may be provided for performance management, enabling the link to have the ability to restore its nominal operation in case of performance degradation or connection loss.

[0067] Radio link failure and RRC re-establishment may occur. In RRC_CONNECTED, the WTRU may perform Radio Link Monitoring (RLM) in the active BWP based on the reference signals (e.g., SSB / CSI-RS) and the signal quality thresholds configured by the network. SSB-based RLM may be configured for the initial DL BWP, for the initial DL BWP, and for DL BWPs (e.g., only those) that include the SSB associated with the initial DL BWP. In the case of other DL BWPs, RLM may be performed based on CSI-RS (e.g., only based on it).

[0068] The WTRU may declare a Radio Link Failure (RLF) when one or more of the following criteria are met. Expiration of a timer started after an indication of a radio problem from the physical layer (e.g., if the radio problem is restored before the timer expires, the WTRU may stop the timer); random access procedure failure; and / or RLC failure.

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

[0070] Beam management may be performed. For example, beam management may be defined as a set of L1 / L2 procedures for acquiring and maintaining a set of transmit receive points (TRxPs) and / or WTRU beams that may be used for DL and UL transmission / reception, and the definition may include one or more of the following aspects. Beam determination (e.g., when a TRxP or WTRU selects its own Tx / Rx beam), beam measurement (e.g., when a TRxP or WTRU measures the characteristics of a received beamforming signal), beam reporting (e.g., when a WTRU reports information on a beamforming signal based on beam measurement values), and / or beam sweeping (e.g., an operation that covers a spatial area with beams transmitted and / or received during a time interval in a predetermined manner).

[0071] The Tx / Rx beam correspondence at the TRxP and the WTRU may be defined as follows. The Tx / Rx beam correspondence at the TRxP may be valid if one or more of the following conditions are met: the TRxP can determine a TRxP Rx beam for uplink reception based on downlink measurement values of the WTRU on one or more Tx beams of the TRxP, and / or the TRxP can determine a TRxP Tx beam for downlink transmission based on uplink measurement values of the TRxP on one or more Rx beams of the TRxP.

[0072] Tx / Rx beam correspondence in a WTRU may be effective when one or more of the following conditions are met: the WTRU can determine a WTRU Tx beam for uplink transmission based on downlink measurement values of the WTRU on one or more Rx beams of the WTRU; the WTRU can determine a WTRU Rx beam for downlink reception based on an indicator of the TRxP based on uplink measurement values on one or more Tx beams of the WTRU; and / or the capability indicator of the WTRU beam correspondence related information to the TRxP is supported.

[0073] DL L1 / L2 beam management procedures may be supported within one or more TRxPs. Using a first procedure (e.g., P-1), WTRU measurements regarding different TRxP Tx beams can be enabled to support the selection of TRxP Tx beam / WTRU Rx beam. In the case of beamforming at the TRxP, P-1 may include internal / inter-TRxP Tx beam sweeping from different sets of beams. In the case of beamforming at the WTRU, it may include WTRU Rx beam sweeping from different sets of beams. Using a second procedure (e.g., P-2), WTRU measurements regarding different TRxP Tx beams can be enabled to, for example, change the internal / inter-TRxP Tx beams from a smaller set of beams for beam refinement than in P-1, if possible. P-2 may be a special case of P-1. When the WTRU uses beamforming, a third procedure (e.g., P-3) can be used to enable WTRU measurements on the same TRxP Tx beam and change the WTRU Rx beam.

[0074] Aperiodic beam reporting triggered by the network may be supported under P-1, P-2, and P-3 related operations.

[0075] RS (e.g., at least CSI-RS)-based WTRU measurements for beam management may be composed of K beams, where K may be equal to the total number of configured beams. The WTRU may report measurement results of N selected Tx beams, where N may be a fixed number or may not be a fixed number. RS-based procedures for mobility purposes may or may not be excluded. The reported information may include, when N < K, the measured quantities for N beams and information indicating the N DL Tx beams. Specifically, when the WTRU is configured using K' > 1 non-zero power (NZP) CSI-RS resources, the WTRU may report N' CRI (CSI-RS resource indicators). For example, K' may refer to the number of CSI-RS resources, and K may refer to the number of configured beams. N' may refer to the number of CSI-RS resource indicators to be reported, and N may refer to the number of beams for which the WTRU reports measurement values.

[0076] The WTRU may be configured using one or more of the following upper layer parameters for beam management. A reporting setting with N ≥ 1 and a resource setting with M ≥ 1; a reporting setting; and / or a resource setting.

[0077] The WTRU may be configured using a reporting setting with N ≥ 1 and a resource setting with M ≥ 1. The link between the reporting setting and the resource setting may be configured in an agreed CSI measurement setting. CSI-RS based procedures (e.g., P-1 and / or P-2) may be supported using the resource and reporting settings. Procedures (e.g., P-3) may be supported using or without using the reporting setting.

[0078] The WTRU may be configured using a reporting setting. The reporting setting may include one or more of information indicating the selected beams, L1 measurement reports, time domain behavior (e.g., aperiodic, periodic, semi-persistent), and / or frequency granularity (e.g., when multiple frequency granularities are supported).

[0079] A WTRU may be configured using resource configuration. The resource configuration may include one or more of time domain behavior (e.g., aperiodic, periodic, semi-persistent), 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 present).

[0080] One or more alternatives to beam reporting may be supported. In a first alternative, the WTRU may report information about the TRxP Tx beam that may be received using a selected WTRU Rx beam set, where the Rx beam set may refer to a set of WTRU Rx beams used to receive DL signals. WTRU implementation issues regarding how to construct the Rx beam set may be disclosed. (E.g., each) Rx beam within the WTRU Rx beam set may correspond to a selected Rx beam within (e.g., each) panel. In the case of a WTRU having two or more WTRU Rx beam sets, the WTRU may report the TRxP Tx beam and the 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 able to be received simultaneously at the WTRU.

[0081] In a second alternative, the WTRU may report information regarding the TRxP Tx beam for each WTRU antenna group, where the WTRU antenna group may refer to a receiving WTRU antenna panel or subarray. In the case of a WTRU having two or more WTRU antenna groups, the WTRU may report the TRxP Tx beam and 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 able to be received simultaneously at the WTRU.

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

[0083] SSB-based beam failure detection may be based on the SSB associated with the initial DL BWP and may be configured for the initial DL BWP and / or for a DL BWP that includes the SSB associated with the initial DL BWP (e.g., for that only). In the case of other DL BWPs, beam failure detection may be performed based on CSI-RS (e.g., for that only).

[0084] The MAC entity can be configured by RRC for each serving cell using beam failure recovery procedures, which can 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. The beam failure can be detected by counting the beam failure instance indicators from the lower layer to the MAC entity. If beamFailureRecoveryConfig is reconfigured by the upper layer during an ongoing random access procedure for beam failure recovery of the SPCell, the MAC entity may stop the ongoing random access procedure and start a random access procedure using the new configuration.

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

[0086] A WTRU variable (e.g., BFI_COUNTER) that can be initially set to 0 can be used to count beam failure instances and declare a beam failure when it reaches a threshold (e.g., C max and / or beamFailureInstanceMaxCount, also referred to as "maximum count").

[0087] After a beam failure is detected, the WTRU may trigger beam failure recovery by initiating a random access procedure on the PCell and / or select a beam suitable for performing beam failure recovery (e.g., if the gNB provides dedicated random access resources for a particular beam, they may be prioritized by the WTRU).

[0088] When the random access procedure is completed, the beam failure recovery may be considered complete.

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

[0090] One or more virtual reality 1 (VR1) applications / use cases may be used. VR1 applications (e.g., immersive 6 degrees of freedom (6DoF) streaming) can be modeled using service flows applicable to viewport-dependent streaming architectures. Similar to adaptive streaming (e.g., DASH), viewport-dependent streaming enables the dynamic update of the quality of media and / or video based on the available bitrate in the network and wireless interface. According to the service / traffic flow, the tracking and pose information of the viewport of the XR device (e.g., small packet size less than 100B) is periodically transmitted to the XR server at a relatively low data rate (e.g., 0.5 - 2Mbps, 60 - 500Hz) in the uplink (UL). In response, the XR server sends in the downlink (DL) at a relatively high data rate (e.g., 6 - 18MBps in the case of 4k omnidirectional and FoV area streaming), adaptively sending quasi-periodically the viewport-optimized media (e.g., H.264 / 265 video) (e.g., 40 / 60 / 120fps), which is then rendered on the XR device display.

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

[0092] A virtual reality 2 (VR2) application can be used. The VR2 application (e.g., immersive game spectator mode) can be modeled using a service flow applicable to a split rendering architecture. The XR server can perform prerendering and encoding of 2D media / video frames based on the pose information periodically sent by the XR device at a low data rate (e.g., 0.5 - 2 Mbps, 60 - 500 Hz). The rendering is mainly performed on the XR server and is sent in DL at a high data rate and low latency (e.g., 30 - 45 Mbps, 10 - 20 ms). The XR device decompresses the received media / video and performs asynchronous time-warping (ATW) to correct the viewport based on the latest pose information. The RTT latency for sending pose information in UL and receiving the prerendered media in DL can reach up to 50 ms, but ATW enables, based on in-device processing, meeting the latency requirement from motion to photons (less than 20 ms).

[0093] The traffic characteristics of VR2 can be as follows. UL traffic can include pose / viewport information, can have a small packet size (e.g., a fixed size less than 100 B), a low data rate (e.g., 0.5 - 2 Mbps), and can be a single flow. UL traffic can be periodic (e.g., having a periodicity range of 60 - 500 Hz). DL traffic can include a 3D scene in the frame buffer, can have a large packet size (e.g., a variable size with a Gaussian distribution or a fixed size of 1500 B or more), a high data rate (e.g., 30 - 45 Mbps), a latency round-trip time of 30 ms or 50 ms, and can be a multi-flow (e.g., can include 3D video / media and / or metadata). DL traffic can be quasi-periodic (e.g., periodicity as a function of the frame rate of 60 / 90 fps).

[0094] An Augmented Reality 1 (AR1) application can be used. The AR1 application (e.g., real-time communication with a store clerk) can be characterized using a service flow applicable to a distributed computing architecture. According to the service / traffic flow, the XR device sends pose information (e.g., 0.5 - 2 Mbps, 60 - 500 Hz) and / or video (e.g., 10 Mbps, 10 Hz frame update rate) to the XR server in UL. The received information is used by the XR server to generate a scene, which is then converted into a 2D (video) or 3D media (3D object) format together with metadata (e.g., scene description). The compressed media and metadata (e.g., characterized by a Pareto distribution) are delivered quasi-periodically in DL at a relatively high data rate (e.g., 30 - 45 Mbps, 40 / 60 / 120 fps). The XR device then locally generates an AR scene by overlaying 3D objects on a 2D video and rendering the scene within the device display.

[0095] The traffic characteristics of AR1 can be as follows. UL traffic can include pose information and / or 2D video stream information. The pose information can have a small packet size (e.g., a constant size less than 100 B), a low data rate (e.g., 0.5 - 2 Mbps), and can be periodic at 60 - 500 Hz. The video information can have a relatively large packet size, a data rate of 10 Mbps, can be periodic with a 10 Hz update periodicity, and can be multi-flow video. DL traffic can include 2D / 3D pre-rendered media and XR metadata, can have a large packet size (e.g., Pareto distribution) and a high data rate (e.g., 30 - 45 Mbps), and can be multi-flow (e.g., can include 2D / 3D media and / or metadata). DL traffic can be quasi-periodic (e.g., periodic as a function of the frame rate of 60 / 90 fps).

[0096] An Extended Reality 2 (AR2) application can be used. The AR2 application (e.g., XR meeting, AR anime avatar call) can use service / traffic flows applicable to the XR conversation architecture when two or more XR clients / devices perform peer-to-peer communication with intermediate media processing in the network. Different types of media that can be supported for the AR2 application can include 2D+ / RGBD (e.g., 2.7 Mbps), 3D mesh (e.g., 30 Mbps), and / or 3D Video point cloud coding (VPCC) / Geometry-based point cloud compression (GPCC) (e.g., 5 - 50 Mbps) based on the type of user representation. The XR client in the device can initiate a call setup procedure, based on which the session control function triggers network-based media processing. The session control function forwards the call setup to the second XR client and / or device, and then transfers real-time media processing and streaming to both clients with low latency (e.g., E2E < 100 ms). During the XR call, 2D / 3D media, and optionally, user pose information are transmitted quasi-periodically in UL and DL between XR clients / devices.

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

[0098] An XR conferencing application can be used. The XR conferencing application can provide an immersive conferencing experience among geographically separated users by representing the users in 3D volumetric representations (e.g., point clouds or meshes). One or more cameras (e.g., with depth perception capabilities) can be placed at the location of each user (e.g., each) to enable interaction (e.g., viewing, listening, rotating, zooming in, resizing, etc.) with the complete 3D volumetric representation of each other on their respective devices (e.g., headsets / glasses). The XR conferencing application can support simultaneous UL and DL media traffic using media consisting of audio, video, and / or 3D objects. Media formats that can be applied to capture users in 3D volumetric format can include 2D+ / RGBD (over 2.7 Mbps for one camera, over 5.4 Mbps for two cameras), 3D mesh (about 30 Mbps), and / or 3D VPCC / GPCC (5 - 50 Mbps). The media processor can be centrally located or distributed at the edge. Additionally, the service / traffic flow between XR clients / users via in-network media processors can be similar to the AR2 and XR conversation use cases. Participating in an XR conferencing session can initially result in a download peak to download the virtual environment and associated media objects within the XR application. Throughout the remaining session, the data rate can vary depending on the number of users, the users' upload formats, and the refresh rate of the virtual 2D / 3D objects / environments.

[0099] The traffic characteristics of the XR session can be as follows. The UL traffic may include 2D / 3D media, and the user's pose and / or real-time video. The UL traffic may have a relatively large packet size, a data rate of 2.7 to 50 Mbps, and can be multi-flow (2D / 3D media). The UL traffic may be quasi-periodic (e.g., 60 to 500 Hz). The UL traffic may have a low encoder packet error rate (PER) of less than 1e-3. The DL traffic may include 2D / 3D media, the user's pose and / or real-time video, and 2D / 3D objects / environments (which may be from a third party, for example). The DL traffic may have a large packet size, a data rate of 2.7 to 50 Mbps, and an E2E PDB of less than 100 ms, and can be multi-flow (e.g., may include 2D / 3D media). The DL traffic may be quasi-periodic (e.g., 60 to 500 Hz) and may have a low encoder PER of less than 1e-3.

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

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

[0102] Current processes for link performance management and link maintenance in the RAN for XR services can be difficult for one or more of the following reasons. In the RAN, due to instantaneous variations in the propagation channel or handover, temporary interruptions and / or downgrades in link performance can occur, resulting in beam switching or radio link and / or beam failures. XR services (e.g., when information units can be carried within a PDU set) can impose strict end-to-end QoS requirements (e.g., across all PDUs within a PDU set), and nominal link performance (e.g., with minimal interruptions and fast link / beam recovery) may need to be maintained within the RAN during the transmission of PDUs within the PDU set in order to meet the strict QoS requirements with minimal interruptions or performance degradation. If link performance instantaneously degrades as a result of a radio link and / or beam failure or beam switching, the recovery time, defined as the duration spent until nominal link performance is restored, may need to be small enough to maintain the QoS requirements. A single XR application / experience can consist of multi-flow traffic generated / received by a single WTRU (e.g., HMD: video and pose data) or a group of WTRUs (e.g., HMD, tactile glove), as shown, for example, in FIG. 2. FIG. 2 illustrates a group of cooperative XR devices supporting the same XR application. Multi-flow traffic can be within a single device (e.g., HMD: video and pose data) and / or across multiple devices (e.g., HMD, tactile glove). In the case of a single XR application / experience with multi-flow traffic across multiple devices (e.g., a cooperative group of WTRUs), the recovery time in one WTRU can affect the overall XR experience. Link / beam management can be performed without considering the interdependencies and associations of PDUs within a PDU set. In the case of XR, it may be necessary to consider traffic association and interdependencies across PDUs within the PDU set when initiating and performing beam / link management procedures.Therefore, adaptive beam / link management can be supported for a WTRU (e.g., or a group of WTRUs) executing an XR application.

[0103] Since current processing of link performance management is done on a per-device basis, in scenarios where a user is executing an XR application on a coordinated group of devices, traffic association and interdependencies in QoS across a coordinated group of WTRUs may not be considered when initiating (link) recovery procedures. For example, how to adjust link management procedures across a coordinated WTRU group, how to 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 adjust link failure recovery procedures and enable faster failure recovery procedures when preventing RLC failures in one or a subset of WTRUs within a coordinated group may be considered.

[0104] A coordinated WTRU group may be used. As used herein, a network may include any of, for example, a base station (e.g., gNB, TRP, 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 either a QoS flow or a data flow (e.g., a flow of data consisting of one or more PDUs or a set of PDUs that may be associated with one or more QoS requirements, such as latency, data rate, reliability, etc.). A set of PDUs (e.g., a media unit, a video frame) may include one or more PDUs. A set of PDUs may be associated with PDU set-level QoS requirements (e.g., data rate, latency, error rate, and / or reliability), which may be applicable to one or more (e.g., all) of the PDUs associated with the set of PDUs. Different PDUs in a PDU may be associated with individual PDU-level QoS requirements. Such associations and interdependencies may be visible to the AS layer (e.g., using associated IDs) and / or recognized during transmission in the UL of data and / or reception in the DL of data and processed in the AS layer.

[0105] In an example, the WTRU may be enabled to dynamically adapt a max count threshold, which may be used to determine when to send an indication of beam failure (BF) to the gNB based on association information (e.g., mapping) between the remaining latency in the PSDB and a set of max count thresholds for indicating a BFI. The 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 determine the remaining latency of a set of PDUs. The WTRU may select a configuration to use to indicate beam failure to the gNB.

[0106] As used herein, the terms "collaborative XR" or "collaborative WTRU group" may, without limitation, refer to supporting XR applications / services, whereby one or more WTRUs may perform at least one XR-related action, resulting in providing a user with an XR experience, which may include a sense in which a user may perceive full or partial immersion into different real / virtual environments, and / or the ability to interact with real and / or virtual objects including avatars.

[0107] As used herein, the term "WTRU" may include one or more of the following: a stand-alone WTRU / device / node (e.g., an XR device, XR glasses, a smartwatch); a non-stand-alone device / node (e.g., a device, sensor, wearable device, haptic glove associated with a WTRU); 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 stationary / 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.

[0108] A collaborative group may consist 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 collaborative WTRU or a member WTRU.

[0109] An anchor WTRU may refer to any WTRU involved in performing one or more of the following in the context of cooperative XR. Hosting an application function (e.g., an XR application) for which requests for any XR action may be received; Receiving requests for XR actions from application functions (e.g., edge servers, remote servers) located within the network; Initiating discovery procedures for determining other nearby WTRUs / devices / nodes for performing any XR action within a cooperative group; And / or establishing a connection and / or session (e.g., an XR session, a PDU session, an application session) by operating as a primary anchor point for communicating with an RAN function / node (e.g., a gNB), a CN function, and / or an application function, including sending and / or receiving requests for session establishment and any of 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 a connection to the network, the interface between the anchor WTRU and the network (e.g., a gNB) may be referred to as the primary Uu link.

[0110] The terms "coordinated WTRU" and "member WTRU" may be used interchangeably and, in the context of coordinated XR, may refer to any WTRU involved in performing one or more of the following. Initiating a discovery procedure and / or receiving a request to make the WTRU discoverable (e.g., via sidelink or via the network) for performing any of the XR actions described herein; sending information related to XR actions (e.g., FoV parameters including pose information, direction, FoV width, and other FoV metadata, UL data including 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 an anchor WTRU; optionally receiving information (e.g., RRC configuration information, application configuration information) that may be used to determine any of the XR actions, together with the anchor WTRU; and / or sending XR action-related messages / reports including pose and / or FoV measurements and estimates via a sidelink interface (e.g., NR sidelink, Bluetooth, WiFi Direct, etc.) to the anchor WTRU and / or the network. When supporting a connection to the network, the interface between the coordinated WTRU and the network (e.g., gNB) may be referred to as a secondary Uu link. A coordinated WTRU may be associated with different coordination groups and anchor WTRUs.

[0111] An XR experience may refer to the overall experience of an end user, which may result from the coordinated transmission and / or reception of accurate data to / from an accurate end device in a reliable and timely manner.

[0112] The term used herein in relation to "multimodality" may be associated with supporting one or more applications / services common to one or more WTRUs and may refer to, for example, any association within a coordinated WTRU group between multiple flows and / or multiple WTRUs.

[0113] The terms used herein in connection with the "anchor WTRU" and the "cooperating WTRU" are non-limiting examples. Other terms that may be used when referring to an anchor WTRU may include, for example, "central WTRU", "primary WTRU", "main WTRU", "initiating WTRU", etc. Other terms that may be used when referring to a cooperating WTRU may include, for example, "member WTRU", "assisting WTRU", "supporting WTRU", "secondary WTRU", etc.

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

[0115] A tertiary WTRU may be a type of WTRU associated with a role and functional capabilities in a cooperating group, similar to a secondary WTRU. It may participate in XR actions for shorter durations and / or smaller partial tasks and, as a result, may require a partial configuration (e.g., takes less time to complete or perform an XR action and / or incurs less overhead).

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

[0117] A WTRU (e.g., an anchor WTRU) within a coordinated WTRU group associated with an application / experience may assist in early indication of link failure (e.g., RLF and / or beam failure) instances for one or more WTRUs, as well as prevention of link failure (e.g., RLF and / or beam failure). Such assistance for preventing link failure may be implemented, for example, as part of link management procedures and / or link maintenance procedures. The anchor WTRU may also assist the network by providing information common to the group, enabling link failure prevention for WTRUs affected within the coordinated group, and / or coordinating faster link failure recovery procedures and maintaining traffic (group QoS) synchronization across WTRUs within the application.

[0118] In an example, the anchor WTRU uses information / metrics received from the application / upper layer (e.g., camera FoV, pose information) and information collected from cooperating WTRUs regarding channel measurements (e.g., BLER, RSRP, RSRQ, RSSI measurements) to predict the next link failure (e.g., RLF and / or beam failure), and / or the duration of a link failure, in one or more links corresponding to the cooperating WTRUs. Further, a single link failure prediction corresponding to a (e.g., one) WTRU within the cooperation group can also be used as a predictor of simultaneous link failures that may occur to another WTRU within the group. Depending on the predicted duration of the link failure (e.g., RLF and / or beam failure) and the QoS associated with each traffic (e.g., PDB) corresponding to the WTRU, the anchor WTRU can then be triggered to send an early link failure (e.g., RLF and / or beam failure) indicator to the network. The network can then take one or more steps (e.g., scheduling on different RBs, transmitting on another carrier, replicating packets, increasing signal power, switching to a different beam, etc.) to avoid link failures and maintain the QoS requirements for traffic to (e.g., each) WTRU and the joint QoS requirements (e.g., the difference in reception times of PDUs in different data traffics is below a threshold).

[0119] For beam failure detection, the cooperating WTRU may provide the anchor WTRU and the network with application / upper layer information (e.g., spatial orientation and / or position information) as well as beam-related (e.g., the current beam it is using) information, which may, in turn, provide the (e.g., cooperating) WTRU with assistance / configuration information regarding when / how the cooperating WTRU may request assistance from the anchor WTRU for fast beam failure recovery or may follow default (e.g., legacy) procedures. The anchor WTRU may use information regarding the QoS requirements (e.g., PDB) corresponding to the cooperating WTRU when providing the cooperating WTRU with configuration information regarding when / how the cooperating WTRU may request assistance from the anchor WTRU for fast beam failure recovery. The anchor WTRU may also use the joint QoS requirements corresponding to the cooperation group when providing configuration information that may be used when two or more cooperating WTRUs need assistance simultaneously for fast beam failure recovery.

[0120] For beam switching for optimal beam tracking, the anchor WTRU may use changes in spatial information received from the application / upper layer (e.g., changes in WTRU angular orientation or relative position) and information regarding some aspects of traffic characteristics (e.g., data arrival rate), and / or information obtained from the cooperating WTRU. For example, the anchor WTRU may use changes in spatial information (e.g., including traffic information) to determine the optimal beam that can be switched to. The anchor WTRU may be configured to provide assistance to the network and the cooperating WTRU when tracking the optimal beam and switching to the optimal beam as the XR experience progresses and the WTRU moves around. When adjusting and providing a faster optimal beam switching capability, the anchor WTRU may ensure that the joint QoS requirements for the cooperation group are maintained.

[0121] The joint QoS requirements when receiving / sending data / PDUs in multiple flows may apply to any of the QoS metrics including but not limited to latency, data rate, and reliability. In the case of joint QoS requirements corresponding to the data rate, when PDUs in one or more associated flows are transmitted and / or received by one or more WTRUs within a cooperation group, the PDUs may be considered to meet the joint QoS using the data rate values associated with the individual flows and at least the joint minimum or joint maximum data rate values associated with one or more flows associated with the application. Similarly, when the joint QoS limit corresponds to latency, the PDUs in one or more associated flows may be considered to meet the joint QoS when the PDUs are transmitted and / or received by the WTRU within the latency limit associated with the individual flow (e.g., PDB) and within at least the joint minimum or joint maximum latency limit associated with one or more flows belonging to the application.

[0122] PDUs in different traffic flows corresponding to (e.g., each) WTRU within a cooperation group may be required to meet the joint QoS requirements (e.g., to avoid drift conditions where PDUs in different associated data flows may drift from each other). Thus, for example, when determining the conditions 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), in addition to the individual QoS requirements, the association and / or dependency of the traffic across the WTRUs within the cooperation group may need to be considered. However, link failure (e.g., RLF and / or beam failure) indicators and recovery or prevention procedures that do not consider the association between PDUs of different traffic going to / from (e.g., each) WTRU within a cooperation group may result in timing differences in the reception of PDUs in different data traffics that exceed the required limits (e.g., do not meet the joint QoS requirements).

[0123] The WTRU may receive traffic information from the application / upper layer and information regarding associations between WTRUs within a cooperation group.

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

[0125] The traffic information may be used by the anchor WTRU / network to determine traffic associations between different WTRUs within the cooperative WTRU group and to assist one or more network / anchor WTRU related actions to enable link management. Such information may be received periodically or aperiodically / dynamically, for example, in RRC signaling, MAC CE, DCI, NAS layer signaling, SL, or application layer signaling.

[0126] Information received by a WTRU (e.g., an anchor WTRU) and / or a network to identify an association between the WTRU and a data flow may include an identifier / ID associated with a coordination 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 within a coordinated WTRU group may receive information / ID regarding the anchor WTRU). Different identifiers / IDs associated with coordinated XR may be assigned / composed by one or more of the following (e.g., via RRC, MAC CE, control PDU, DCI, application / NAS layer signaling, etc.). Anchor WTRU, network, and / or application function.

[0127] The WTRU may send information to the network / anchor WTRU to handle link performance management (e.g., RLF / beam failure and beam management) across a group of coordinated WTRUs.

[0128] A WTRU (e.g., an anchor WTRU and / or a coordinated WTRU) may send information related to the handling of data communication, common QoS requirements, and link performance management (e.g., RLF and / or beam failure, beam management) across a coordinated WTRU group for one or a subset of the WTRUs within the coordinated WTRU group to the network and / or the anchor WTRU. Such information may be sent periodically or non-periodically / dynamically (e.g., based on the detection of an event as described herein) as assistance information and / or status indicators. The anchor WTRU may send 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).

[0129] Information sent by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) to a network and / or an anchor WTRU may include the ID of the anchor WTRU, the ID of the cooperating WTRU, and a cooperation group ID (e.g., sent to the network), and / or traffic characteristics and / or parameters of data / traffic associated with (e.g., each) cooperating WTRU within the cooperation group. The WTRU may send QoS requirements (e.g., per WTRU) including data rate, latency, reliability, absolute / relative priority values, etc. The WTRU may also send joint QoS requirements associated with the cooperation group.

[0130] The anchor WTRU may send any of the information described herein to the network upon the occurrence of one or more of the following events: during connection / session establishment and / or (re)configuration; when changing / updating data / traffic flows within the cooperation group; when receiving upper layer and / or application information; when detecting changes in measurements and / or mobility in one or a subset of WTRUs within the cooperation group; and / or when completing RLF recovery and re-establishing an RRC connection.

[0131] The anchor WTRU may send any of the information described herein to the network during connection / session establishment and / or (re)configuration. For example, the anchor WTRU may send 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 within the cooperating WTRU group.

[0132] The anchor WTRU may send any of the information described herein to the network when changing / updating data / traffic flows within the cooperation group. For example, the anchor WTRU may send information when adding a new WTRU to the cooperating WTRU group and / or when a WTRU is released from the cooperation group.

[0133] When the anchor WTRU receives upper layer / application information, it may send any of the information described herein to the network. For example, the anchor WTRU may send information when it receives an indicator indicating a change such as a supported data type, traffic characteristics, QoS requirements, etc. (e.g., from an application function hosted in any of the WTRUs within the cooperative group or network).

[0134] When the anchor WTRU detects a change in measurement and / or movement in one or a subset of the WTRUs within the cooperative group, it may send any of the information described herein to the network. For example, the anchor WTRU may send information when the RSRP, RSRQ, RSSI measurement values of a signal, channel, radio link, carrier, etc. exceed / fall below a threshold, and / or when the attitude / position measurement values (e.g., location information, attitude in 6DoF) exceed / fall below an attitude threshold.

[0135] When the anchor WTRU completes RLF recovery and re - establishes an RRC connection, it may send any of the information described herein to the network. For example, the anchor WTRU may send information when it successfully completes RRC re - establishment during RLF recovery in one or a subset of the WTRUs within the cooperative group.

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

[0137] A WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) within a coordination group may receive configuration information used by the WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) from the network and / or the anchor WTRU to enable the network to maintain link performance (e.g., in beam management), 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, and determine when the WTRU may trigger an early link failure (e.g., RLF and / or beam failure) indicator or switch to an optimal beam for a WTRU or a subset of WTRUs within the WTRU's coordination group.

[0138] The configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include one or more of the following: thresholds related to individual QoS per WTRU; thresholds related to participating QoS (e.g., joint PDB); thresholds related to beam active intervals; thresholds related to instances when the WTRU may send a beam failure indicator; information for associating the remaining delay for a PDU set with a maximum count value (e.g., a value for the number of consecutive BFIs); and / or information regarding a set of available beams.

[0139] The configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include thresholds related to individual QoS per WTRU. For example, the WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may receive thresholds for each WTRU within a cooperating WTRU group associated with their respective PDBs and the expected duration of an expected link failure (e.g., RLF and / or beam failure) instance.

[0140] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may include thresholds related to the participating QoS (e.g., a common PDB). For example, a WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may receive thresholds associated with common QoS requirements on a coordinating WTRU group. The common QoS requirements for PDUs within two or more WTRUs within a coordination group may be related to, for example, a common latency limit associated with the time difference between the reception times of PDUs within (e.g., each) WTRU.

[0141] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may include thresholds related to beam active intervals. For example, a WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may receive thresholds associated with the rate of beam switching.

[0142] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may include thresholds related to the instance when the WTRU may send a beam failure indicator. For example, a WTRU (e.g., an anchor UE and / or a coordinating UE) may receive a threshold related to the measured RSRP to detect a beam failure instance (BFI). A WTRU (e.g., an anchor WTRU and / or a coordinating WTRU) may receive, prior to indicating a beam failure to a gNB, a set of maximum counts of BFIs to be counted, a maximum count threshold related to the BFIs count (e.g., a default C max_default value and / or a secondary C max value). In addition to the maximum count C max threshold, a WTRU may also receive a beam failure detection duration timer T BFI for beam failure detection.

[0143] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include information for associating the remaining delay of a PDU set with a maximum count value. For example, a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may use a maximum count C r based on a remaining delay D max to select an associated value (e.g., a mapping relationship) for the purpose of selecting a value.

[0144] Configuration information received by a WTRU (e.g., an anchor WTRU and / or a cooperating WTRU) may include information regarding a set of available beams. For example, the network may provide the anchor WTRU with information including a set of available beams that cover an area where a cooperating group of WTRUs exists. The information provided may also include corresponding beam directions, orientations, and / or widths, enabling the anchor WTRU to perform some mapping of a beam pattern / grid across the cooperating group of WTRUs, as shown in FIG. 3. FIG. 3 illustrates an exemplary beam pattern / grid mapping. Beams covering the area may each be assigned a respective beam ID (e.g., B-1, B-2,...B-20 shown in FIG. 3).

[0145] A WTRU may receive configuration information via, for example, AS layer signaling (e.g., RRC signaling / messages, MAC CE or DCI) or non-AS (NAS) layer signaling (e.g., PDU session related messages).

[0146] A WTRU may assist in an early trigger of a link failure indicator to prevent link failures and / or enable fast link failure recovery procedures.

[0147] After receiving the configuration information, one or more WTRUs within the coordination group may start receiving PDUs from a transmitting entity (e.g., a base station) via their corresponding Uu links. The WTRUs within the group may also perform measurements on the channel (e.g., RSRP, RSRQ, RSSI measurements) to determine, for example, link quality. The WTRUs may be configured to perform the measurements periodically, or may be triggered to perform the measurements when receiving a command from, for example, the network or an anchor WTRU.

[0148] The anchor WTRU may be configured to receive reported channel measurement values (e.g., RSRP, RSRQ, RSSI, etc.) from one or more WTRUs within the coordination group. The anchor WTRU may use the received measurement values to determine / predict the next link failure (e.g., RLF and / or beam failure) for one or more Uu links corresponding to one or more WTRUs within the coordination group. The anchor WTRU may also be able to determine / predict a link failure (e.g., RLF and / or beam failure) for a WTRU based on its prediction of a link failure for another WTRU within the same coordination group sharing similar channel characteristics. (For example, each) link failure prediction may be accompanied by a predicted link failure duration, based on which the anchor WTRU may trigger an early link failure indicator for the WTRU, or an early and joint link failure indicator for a subset of WTRUs within the coordination group.

[0149] The anchor WTRU may predict that a link failure (e.g., RLF and / or beam failure) is about to occur on one of the Uu links within the coordination group. The anchor WTRU may obtain a prediction that a link failure (e.g., RLF and / or beam failure) is about to occur based on the collected traffic information (e.g., FoV from a camera, pose information) and / or link quality measurements (e.g., RSRP, RSRQ, RSSI measurements) performed by one or more WTRUs within the group.

[0150] The anchor WTRU may also send to the network an early indicator that a link failure may occur at the time of the link failure if it predicts that the duration of the link failure occurrence within the cooperating WTRU will continue longer than, for example, half (or some fraction thereof) of the PDB associated with the corresponding traffic. The anchor WTRU may also include information (e.g., WTRU ID) indicating the WTRU corresponding to the early RLF indicator.

[0151] The anchor WTRU may predict the occurrence of link failures in two or more Uu links within the cooperation group. The anchor WTRU may be able to predict link failures in two or more Uu links based on the collected traffic information (e.g., FoV from a camera, pose information), and / or link quality measurements (e.g., RSRP, RSRQ, RSSI measurements) from the cooperating WTRUs corresponding to (e.g., each) link. The anchor WTRU may also be able to predict link failures in two or more Uu links based on the prediction of link failure for a single link (e.g., two Uu links may experience similar channel conditions, and thus, a predicted link failure (e.g., RLF and / or beam failure) for one link may serve as an indicator that a link failure (e.g., RLF and / or beam failure) is likely to occur in the other link as well). (E.g., each) link failure prediction may also involve predicting the duration of the link failure (e.g., RLF and / or beam failure).

[0152] If the anchor WTRU determines that the predicted link failure duration for all Uu links except one Uu link for which it predicted the occurrence of a link failure is shorter than, for example, half (or some fraction thereof) of the PDB assigned to the corresponding link, the anchor WTRU may send to the network (e.g., only to that WTRU) an early link failure indicator for the WTRU for which it is predicted that the link failure duration in that Uu link will continue longer than half (or some fraction thereof) of the PDB. The anchor WTRU may also include information (e.g., WTRU ID) indicating the WTRU corresponding to the early link failure indicator.

[0153] If the anchor WTRU determines that the predicted link failure duration for two or more Uu links will continue for longer than, for example, half (or some fraction thereof) of the PDB assigned to the link, the anchor WTRU may send an early and joint link failure (e.g., RLF and / or beam failure) indicator for the group of WTRUs for which link failure is predicted to the network. The anchor WTRU may also include information (e.g., WTRU ID) indicating the corresponding (e.g., each) WTRU and the joint QoS requirements for the group of WTRUs in the early link failure indicator. When the anchor WTRU undertakes the step of allocating additional resources to prevent link failure (e.g., RLF and / or beam failure), the anchor WTRU may include joint QoS requirement information regarding the group of WTRUs when sending an early indicator of joint link failure to the network as assistance information for the network.

[0154] After sending the early link failure (e.g., RLF and / or beam failure) indicator, the network may perform one or more actions to prevent link failure from occurring on the corresponding link(s). Actions performed by the network may include, for example, one or more of the following: increasing power for the link(s) indicated by the early RLF; switching the beam indicated by the early beam failure; transmitting on a different band / carrier; replicating packets; and / or employing multiple TRPs.

[0155] The network may respond to an anchor WTRU indicating that a link failure (e.g., RLF and / or beam failure) for one or more WTRUs within a coordination group is inevitable and imminent (e.g., due to lack of resources, unfavorable channel conditions, etc.). The anchor WTRU may then indicate to the WTRU or subset of WTRUs for which the link failure has been declared inevitable to start link recovery procedures (e.g., RRC re-establishment and / or beam reselection) without waiting for the expiration of a timer (e.g., T301 timer for triggering RLF), or without counting the maximum number of beam failure instances (e.g., beamFailureInstanceMaxCount) for triggering the beam failure indicator configured in the WTRU until a link failure (e.g., RLF and / or beam failure) is reported. The anchor WTRU may also share with the network information (e.g., cell ID, beam ID) that may be common among a group of WTRUs and that may be used to enable faster link failure (e.g., RLF and / or beam failure) recovery.

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

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

[0158] A coordinated WTRU or a subset of coordinated WTRUs within a coordination group may detect a beam failure instance when the WTRU or subset of WTRUs measures beam quality and it falls below a preconfigured threshold (e.g., an RSRP threshold). Based on the received configuration (e.g., received from the network and / or an anchor WTRU), a coordinated WTRU or subset of coordinated 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 default beam failure recovery procedures according to the network. A coordinated WTRU or subset of WTRUs may decide to adopt anchor-WTRU-assisted or network-configured beam failure recovery procedures based on one or more of the following conditions. If one or more coordinated WTRUs detect a beam failure instance and the PDB value of the traffic corresponding to the WTRU, or the joint PDB value (e.g., in the case of beam failure instances of two or more WTRUs) is less than the anchor assistance time threshold, the WTRU or group of WTRUs may adopt network configuration (e.g., default) procedures for beam failure detection and recovery. If one or more coordinated WTRUs detect a beam failure instance and the PDB value of the traffic corresponding to the WTRU, or the joint PDB value (e.g., in the case of beam failure instances of two or more WTRUs) is greater than the anchor assistance time threshold, the WTRU or group of WTRUs may send an indication to the anchor WTRU requesting assistance for fast beam failure recovery.

[0159] The coordinated WTRU and the network may provide the anchor WTRU with current information regarding Tx / Rx beam allocation (e.g., beam orientation, beam width, AoD and AoA of the boresight, etc.), enabling the anchor WTRU to obtain a close representation of the Tx / Rx beam pattern around the coordinated WTRU group as shown in FIG. 4. FIG. 4 illustrates a representation of the (initial) Tx / Rx beam pattern around the coordinated WTRU. The representation shown in FIG. 4 may be derived from the beam pattern / grid map shown in FIG. 3.

[0160] When a coordinated WTRU or a subset of WTRUs sends an indicator requesting assistance for fast beam failure recovery to an anchor WTRU, it may include application / upper layer spatial information (e.g., current relative position and / or angular orientation) and / or lower layer information (e.g., current beam allocation). The anchor WTRU may assist the coordinated WTRU by notifying the network of the set of beams that are most suitable for switching to a set of WTRUs or WTRUs that request assistance for fast beam failure recovery and sending an indicator to allocate that set of beams.

[0161] Based on the current spatial information provided to it and the representation of the Tx / Rx beam patterns made available to it (e.g., as shown in FIG. 4), the anchor WTRU may determine and be able to allocate the beam that is most suitable for switching to a set of WTRUs or WTRUs. As shown in FIG. 4, the beams may be grouped into beam patterns. For example, 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., WTRU-2 in FIG. 4) to which a first beam (e.g., beam "B-3") is allocated for communicating with a transmitting entity (e.g., a base station) requests assistance from an anchor WTRU (e.g., WTRU-1 in FIG. 4) for fast beam failure recovery, the anchor WTRU knows the currently allocated beam of the WTRU (e.g., the beam in which the beam failure instance was detected) and the spatial information (e.g., angular orientation and / or position), and may determine that the WTRU can recover that beam if the WTRU is allocated a different beam (e.g., beam B-4) by the network.

[0162] Next, when the network communicates with a subset of the coordinated WTRUs or the WTRUs that detected a beam failure instance, it may switch to the beam indicated by the anchor WTRU. The network may also indicate to the WTRU or subset of WTRUs to start measuring the beam it switched to (e.g., RSRP, RSRQ measurements). If the WTRU or subset of WTRUs still detects a beam failure instance based on the measurements performed on the newly selected beam(s), the WTRU or subset of WTRUs may fallback to default (e.g., network configuration) procedures to initiate beam failure recovery procedures. If the WTRU or subset of WTRUs does not detect a beam failure instance during measurements on the newly selected beam(s), the WTRU or subset of WTRUs may maintain transmission and reception on the beam(s).

[0163] The WTRU may coordinate fast beam switching and may provide optimal beam tracking across a coordinated set of WTRUs.

[0164] In an example, after receiving configuration information and / or application related information, the anchor WTRU may determine a beam availability interval for the beam(s) assigned to (e.g., each) WTRU within the coordinated group set. The beam availability interval may be related to the range of spatial changes (e.g., angular orientation, relative position changes) that a WTRU may experience before the beam assigned to the WTRU becomes no longer optimal. WTRUs within the coordinated group may start receiving PDUs from a transmission entity (e.g., base station) in their assigned Tx / Rx beams.

[0165] The anchor WTRU can determine / predict the expected changes in some aspects of the spatial information corresponding to the cooperative WTRU or a subset of WTRUs, using a set of PDUs received from a transmitting entity (e.g., a base station, an application layer), and / or application / configuration information (e.g., the range of possible spatial changes for the WTRU). The aspects of the spatial information that the anchor WTRU may be able to determine / predict can include the angular orientation of the WTRU along a given axis, and / or the position of the WTRU with respect to the anchor WTRU and / or the transmitting entity (e.g., a base station).

[0166] Based on the changes in the aspects of the spatial information expected to be experienced by the cooperative WTRU or a subset of WTRUs, and / or the changes in the configuration information provided by the network, the anchor WTRU can determine the beam switching rate for the cooperative WTRU or a subset of WTRUs. The configuration information provided by the network to the anchor WTRU / cooperative WTRU can include a beam pattern / grid map corresponding to a cooperative group (e.g., as shown in FIG. 3), and the current beam allocation for each WTRU within the cooperative group (e.g., as shown in FIG. 4).

[0167] If the rate of beam switching for the cooperative WTRU or a subset of WTRUs is greater than the effective interval of the corresponding beam or subset of beams, the anchor WTRU can determine the optimal beam or set of optimal beams to which the WTRU or subset of WTRUs can switch. The anchor WTRU can determine a new optimal beam for the WTRU, or a set of optimal beams for a subset of WTRUs, based on the expected changes in the spatial information and the beam pattern / grid map (e.g., as shown in FIG. 3) available to the anchor WTRU.

[0168] Upon receiving an indicator from the anchor WTRU, the network can switch the beam or set of beams when communicating with the corresponding WTRU or set of WTRUs.

[0169] The WTRU may determine an instance when it is suitable to schedule CSI-RS / SRS based on the expected DL / UL traffic and channel conditions. In addition to determining the characteristics of the traffic expected in DL and / or UL, the WTRU may obtain information regarding the quality of the propagation channel and / or the received signal strength for a given future duration based on the received DL and / or UL traffic and / or measurements via beamformed DMRS. Based on the information obtained by the WTRU and the expected changes in the channel and / or the received DL / UL signal strength, the WTRU may determine whether to send to the network an indication of the next DL and / or UL transmission instance / occasion when it is suitable for the network to transmit CSI-RS to the WTRU and / or for the WTRU to transmit SRS to the network, as a result of which some measure of channel quality (e.g., RSRP) may be reported for link adaptation, beam management, and / or RLM.

[0170] The WTRU may also be an anchor WTRU that determines a suitable DL / UL transmission time for scheduling CSI-RS / SRS transmission to member WTRUs or a set of member WTRUs within a cooperation group of the WTRU. When necessary and in accordance with the characteristics of the expected DL and / or UL traffic, by scheduling the transmission of CSI-RS and / or SRS (e.g., only thereof), the network may conserve resources and improve the capacity of the WTRU. Additionally, in the case of a cooperation group of WTRUs that are located close to each other and for which the link quality to the member WTRUs may be similar or identical, the anchor WTRU (e.g., only thereof) may be configured to report channel quality measurements (e.g., RSRP) of itself and / or the member WTRUs using CSI-RS and / or SRS, thereby conserving resources and improving capacity across the group of cooperating WTRUs.

[0171] The CSI-RS and SRS resource configurations can be periodic, aperiodic, or semi-persistent CSI-RS transmissions. In periodic transmissions, the WTRU can expect to receive / transmit CSI-RS / SRS in a resource set that can be reserved at periodic intervals. In aperiodic transmissions, the WTRU can receive explicit signaling (e.g., in DCI) from the network indicating a CSI-RS / SRS transmission instance. In the case of XR services, periodic transmission of CSI-RS / SRS can generate additional overhead, which can potentially reduce capacity. Aperiodic transmission of CSI-RS / SRS after data / control / periodic CSI-RS transmission can be good enough to meet strict latency requirements. Semi-persistent CSI-RS / SRS transmission can reduce resource overhead as, even when the WTRU is configured with a periodic resource set, the CSI-RS / SRS is transmitted (e.g., only then) after explicit activation via MAC CE and / or can be deactivated after a certain time. However, semi-persistent CSI-RS / SRS transmission may not be suitable for beam management or RLM in services with faster response times. In the case of XR services, a solution based on a dynamic / adaptive CSI-RS / SRS configuration that provides robust link management with a balanced trade-off between capacity and latency can be useful.

[0172] The WTRU may obtain measurements regarding link and / or channel quality and received DL and / or UL signal strength using a reference signal (e.g., DMRS) that may be scheduled using PDSCH / PUSCH. The WTRU may receive CSI-RS (e.g., only) when it is expected to report to the network about the expected changes in channel quality and / or DL / UL received signal strength. The WTRU (e.g., anchor WTRU) may send information associated with an application to the network as assistance information and / or status information / indicators. In an example, the information associated with the application that may be sent by the WTRU to the network may include the traffic characteristics and / or parameters of the application. The WTRU may send QoS requirements (e.g., per WTRU in the case of a WTRU cooperation group) including data rate, latency, reliability, absolute / relative priority values, etc. In the case of a WTRU cooperation group, the WTRU may send the location (e.g., location and / or orientation) of the WTRU within the cooperation group with respect to the anchor WTRU.

[0173] The WTRU (e.g., anchor WTRU) may send information to the network at one or more of the following times: during connection / session establishment and / or (re)configuration; when changing / updating data / traffic flows within the cooperation group; when receiving upper layer / application information; and / or when detecting changes in measurements and mobility of one or a subset of the WTRUs within the cooperation group.

[0174] The WTRU (e.g., anchor WTRU) may send information to the network during connection / session establishment and / or (re)configuration. For example, the WTRU may send information to the network during RRC connection, PDU session, application session establishment, and / or (re)configuration; when changing the RRC state in any of the WTRUs within the cooperating WTRU group; and / or when successfully completing RRC re-establishment during RLF recovery in one or a subset of the WTRUs within the cooperation group.

[0175] A WTRU (e.g., an anchor WTRU) may send information to the network when changing / updating data / traffic flows within a cooperative group. For example, the WTRU may send information to the network when a new WTRU is added to a cooperative WTRU group and / or when a WTRU is released from a cooperative group.

[0176] A WTRU (e.g., an anchor WTRU) may send information to the network when receiving higher layer / application information. For example, the WTRU may send information to the network when receiving an indicator (e.g., from the application layer) indicating a change in traffic characteristics, QoS requirements, etc.

[0177] A WTRU (e.g., an anchor WTRU) may send information to the network when detecting a change in measurements and / or movement within one or a subset of the WTRUs in a cooperative group. For example, the WTRU may send information to the network when one or more of the WTRUs in a cooperative group move a certain distance beyond a threshold where the link / channel quality may no longer be the same and / or may not be correlated.

[0178] A WTRU (e.g., an anchor WTRU) may determine an instance and / or period in which CSI-RS is suitable to be transmitted to the WTRU and / or the WTRU is suitable to send SRS to the network (e.g., regarding a trade-off between resource overhead, reliability, and / or latency) based on configuration information sent 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 the following. A threshold related to measured channel quality and / or received signal strength; a threshold related to spatial orientation and / or angular orientation; a threshold related to QoS; and / or information regarding a set of WTRUs within a cooperative group of WTRUs covered by the same CSI-RS / SRS transmission.

[0179] 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 measurements or signal strength measurements such that threshold 1 < threshold 2) related to the channel quality of its Uu link (e.g., CQI) and / or received signal strength in DL and / or UL (e.g., RSRP, SNR, etc.).

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

[0181] 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 PDB and required PER / BLER. The cooperative group of WTRUs (e.g., anchor WTRUs) may receive thresholds associated with joint QoS (e.g., joint PDB).

[0182] The configuration information received by the WTRU may include information regarding a set of WTRUs within a cooperative group of WTRUs 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.) that the WTRU obtains based on the CSI-RS and / or SRS that the WTRU is configured with. As an example, one (e.g., the only) WTRU (e.g., an anchor WTRU) may be configured using CSI-RS and / or SRS without constituting the remaining WTRUs, and / or measurements obtained from and / or by the WTRU may be valid for one or more (e.g., all) of the other WTRUs within the group. The group of cooperative WTRUs may be further grouped based on their relative proximity to each other. One or more representative WTRUs within a subgroup within the group may be configured using CSI-RS and / or SRS. In this case, the channel quality reports sent by and / or obtained from the representative WTRU may be considered to cover one or more (e.g., all) of the WTRUs within the subgroup.

[0183] Figure 5 illustrates an example of a cooperative group of WTRUs receiving CSI-RS. As shown in Figure 5, the WTRUs within one or more (e.g., all) of the cooperative groups may receive CSI-RS (e.g., on the left side of Figure 5). Alternatively, one WTRU (e.g., an anchor WTRU) may receive CSI-RS (e.g., in the center of Figure 5), or one WTRU per subgroup may receive CSI-RS (e.g., on the right side of Figure 5).

[0184] For example, as shown in FIG. 5, gNB 502 may transmit CSI-RS to a coordination group of WTRUs 508 that may include WTRUs 510, 512, 514, 516, and 518. On the left side of FIG. 5, all of WTRUs 510, 512, 514, 516, and 518 may receive CSI-RS and / or may transmit RSRP reports to gNB 502. Alternatively, the WTRUs may be grouped into subgroup 520, and one WTRU (e.g., WTRU 514) may receive CSI-RS and / or may transmit an RSRP report. Alternatively, the WTRUs may be split into two or more subgroups, e.g., 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. For each subgroup, one WTRU (e.g., WTRUs 512 and 516) may receive CSI-RS and / or may transmit an RSRP report to gNB 502.

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

[0186] After preparing and transmitting the UL PDU, a WTRU (e.g., an anchor WTRU) may be able to determine and / or predict the manner of traffic expected in the DL and / or UL for a given future duration. In the case of a WTRU's cooperation group, the WTRU may determine and / or predict the characteristics of DL traffic that the member WTRUs are expected to receive in the DL and / or transmit in the UL during a certain future period. The characteristics and / or manner of DL and / or UL traffic that the WTRU may be 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 the expected arrival time of DL / UL PDUs.

[0187] In an example applicable to DL transmission, a WTRU (e.g., an anchor WTRU) may determine and / or predict changes in the measured channel quality and / or received signal strength, expected changes in QoS, and / or expected changes in joint QoS across the WTRU's cooperation group (e.g., PDB, required PER). If the WTRU determines and / or predicts that a change in the expected channel quality measurement (e.g., SNR / SINR, RSRP, CQI, etc.) exceeds a first threshold of a configured threshold related to the channel quality measurement and / or is below a second threshold, the WTRU may further determine and / or predict a change in the QoS of the traffic expected in the DL. If the WTRU further determines that a change in the QoS of the traffic expected in the DL and / or UL exceeds a configured threshold related to QoS and / or joint QoS, the WTRU may send an indication to the network to transmit 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 purposes, and / or to manage expected radio link or beam failures.

[0188] When the WTRU determines and / or predicts that the change in the expected channel quality measurement (e.g., SNR / SINR, RSRP, CQI, etc.) exceeds a second threshold (e.g., implies a significant expected change in the channel quality measurement), the WTRU may send an indication to the network to transmit CSI-RS in the next PDSCH transmission instance to report the expected change in the channel quality measurement and / or received signal strength (e.g., SNR, RSRP), regardless of the expected change in QoS and / or joint QoS.

[0189] After determining that the WTRU (e.g., anchor WTRU) is expected to send an indication to the network to transmit CSI-RS, if the next transmission time instance at which the network can transmit CSI-RS is after the PDB required to maintain a good quality of experience (QoE) and / or may lead to a long delay before the WTRU receives the CSI-RS and reports back the measurements regarding the change in channel quality and / or received signal strength, the network may be able to take appropriate actions (e.g., switch beams, increase power, etc.). In this case, instead of indicating that the CSI-RS will be transmitted in the next DL transmission time instance, the WTRU may indicate to the network to transmit CSI-RS in the next DRX on-cycle even if there is no scheduled DL traffic, for an emergency report of channel quality measurement.

[0190] In an example applicable to UL transmission, based on the PDU received in DL and / or the PDU transmitted in UL, a WTRU (e.g., an anchor WTRU) may determine and / or predict a change in its spatial orientation and / or angular orientation, and as a result, may affect the channel / wireless link / beam quality and the signal strength received in UL. Based on the magnitude of the change in spatial orientation and / or angular orientation, the WTRU may determine when to send an indicator to the network that includes a request to send SRS so that the network can immediately measure the change in channel quality and / or received signal (e.g., beam) strength corresponding to the change in the spatial orientation and / or angular orientation of the WTRU and / or take an appropriate action (e.g., switch beams).

[0191] If a WTRU (e.g., an anchor WTRU) determines and / or predicts that a change in the spatial orientation and / or angular orientation of the WTRU exceeds a configured threshold, the WTRU may send a request to the network to obtain a resource grant to send SRS in the next available transmission instance.

[0192] After receiving the indicator, a WTRU (e.g., an anchor WTRU) may receive an acknowledgment for predicting CSI-RS in the next PDSCH transmission instance or the next DRX cycle and / or for sending SRS to the network in the next PUSCH transmission instance.

[0193] 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 of the WTRU measurement configuration for performing RRM-related measurements.

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

[0195] In an example, the WTRU may perform RRM-related measurements periodically on a configured resource set. For example, the WTRU may reserve or utilize one or more configured resource sets at periodic intervals. The RRM-related measurements may be measurements performed for the purpose of selecting one or more cells, such as to support radio access technology (RAT) handover, to support bandwidth part (BWP) switching, etc. For example, the configured resource set may include one or more of SSB or CSI-RS. Measurement instances that occur at short intervals (e.g., relatively short measurement periodicity) may cause more frequent interruptions in the DL / UL reception / transmission of traffic for the WTRU for a given duration, which may lead to throughput reduction. Measurement instances that occur at short intervals may result in longer latency and may provide insufficient quality of experience (QOE) for XR applications. Measurement instances that occur at long intervals (e.g., relatively long periodicity) may not allow the gNB and the WTRU to adapt quickly to changes, and as a result, the network may not be able to update the RRM configuration quickly enough for packet delay budget (PDB) in XR traffic. 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 these changes in channel conditions and / or measurement reports sent by the WTRU, the WTRU may be configured to use a modified RRM configuration, which may include updates such as one or more BWP configurations / switching, cell (e.g., radio link monitoring (RLM)) configurations, or beam configurations / handover. Measurement instances that occur at long intervals may lead to radio link failure. For XR services, embodiments based on dynamic / adaptive configured RRM-related measurement periodicity may provide robust link performance and at the same time may provide a balanced trade-off between capacity and latency.

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

[0197] The WTRU may start DL / UL reception / transmission and perform RRM-related measurements on a per-period basis (e.g., every T1 period) in a state where DL / UL reception / transmission may be interrupted during the configured measurement duration (e.g., measurement gap). The WTRU may also measure changes in the link quality and / or propagation channel while receiving DL traffic using, for example, a reference signal (e.g., demodulation reference signal (DMRS)). The WTRU may determine that a change (e.g., a change in periodicity) in the RRM-related procedure should occur based on the observed rate of change of the link and / or channel quality. For example, the observed rate of change of the link and / or channel quality may include the rate of change of the DMRS-based reference signal received power (RSRP). For example, the RRM-related procedure may include one or more of handover, cell reselection, radio link monitoring, BWP switching, etc. The WTRU may receive from the gNB configuration information consisting of the measured rate of change of the link and / or channel quality (e.g., the rate of change of the measured RSRP value) and / or a threshold related to the packet arrival rate in XR traffic. When these thresholds are exceeded, the WTRU may be configured to adapt one or more RRM configuration parameters (e.g., measurement periodicity).

[0198] The WTRU may obtain measurements regarding link and / or channel quality and received DL strength (e.g., RSRP) using reference signals. For example, DMRS that may be scheduled together with physical downlink shared channel (PDSCH) transmission may be used for the measurements. The WTRU may also determine a rate R m at which the link and / or channel quality measurements change between measurement instances. The measured rate of change R m of the link and / or channel quality between measurement instances may indicate that one or more of the following events are expected to occur. An increase in the mobility of the WTRU, a blockage, and / or a link / beam failure. The WTRU may further determine that RRM-related procedures corresponding to the event (e.g., blockage, 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.

[0199] Based on the observed rate R m at which the link and / or channel quality measurements change between measurement instances, the WTRU may determine whether to switch the 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 may send an indication to the gNB. The indication may indicate that the WTRU has changed its RRM measurement periodicity and / or adapted one or more RRM-related configuration parameters. The indication may indicate the changed periodicity / RRM configuration parameter value. If the WTRU determines that the rate R mIf it is determined that the packet arrival rate of XR traffic is greater than the packet arrival rate of the WTRU, 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), as a result of which the WTRU may perform RRM-related measurements at shorter intervals. However, if the rate R m at which the link and / or channel quality measurement values (e.g., measured RSRP, RSRQ, etc.) change between measurement instances is determined to be less than the packet arrival rate, the WTRU may maintain the RRM-related measurement interval (periodicity) at a first value (e.g., T1).

[0200] The WTRU may dynamically adapt the maximum number of BFI counts that need to be performed before declaring a beam failure and / or sending a beam failure indicator to the gNB. In an example, the WTRU may receive configuration information consisting of two or more maximum count values related to the number of BFIs that the WTRU has to count before declaring a beam failure and sending a beam failure indicator to the network. During reception of PDUs from a PDU set, the WTRU may need to maintain nominal link performance, adapt dynamically to channel conditions, meet the PDU set-level delay budget, and maintain dependencies across the PDUs within the PDU set. In the case of a beam / link failure instance, the WTRU may switch to an alternative beam and / or perform beam failure recovery procedures 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 indicate a beam failure instance to the network and may start beam failure recovery procedures before the maximum number of (C max)The beam failure instance can be statically configured to count. Such a configuration can allow the WTRU to wait for a predetermined duration for favorable channel conditions and may allow the beam to recover on its own. Thus, the configuration can prevent the WTRU from declaring beam failure too early and from unnecessarily triggering beam failure recovery procedures. However, during the occurrence of beam failure while receiving PDUs of a PDU set in a delay-sensitive application, such a static configuration may not be sufficient to meet the PDU set-level delay requirement.

[0201] In an exemplary solution, the WTRU may be configured with a plurality of maximum counts (C max ) values for counting the BFI before sending the BF indicator, and based on the remaining delay D r to receive one or more (e.g., all) PDUs of the PDU set after the occurrence of beam failure, the appropriate C max value can be dynamically selected.

[0202] The WTRU may receive additional configuration information related to the beam failure detection duration T BFI , and the RSRP threshold for detecting beam failure instances. In a scenario (e.g., a legacy scenario), the WTRU may be configured to measure the RSRP during CSI-RS and / or SRS measurement instances, and the physical (PHY) layer may detect beam failure if the measured RSRP falls below the threshold. When beam failure is detected, the PHY layer within the WTRU may send an indicator to the MAC layer, and the MAC layer may then start counting the BFI count C 1 and start the BFI timer. The timer in the MAC layer may continue to operate until the MAC layer receives a second indicator of beam failure from the PHY layer, in which case the MAC layer may update the BFI count to C 2 and reset the BFI timer. The MAC layer increments the BFI count by one each time it receives an indicator of beam failure from the PHY layer, C n+1Only increment and can continue to reset the timer. When the counter reaches the maximum count, i.e., C n+1 =C max the MAC layer may send an indication to the network requesting to start the beam failure recovery procedure. However, if the BFI timer expires (e.g., reaches T BFI ) before the WTRU receives the next BFI indication, the MAC layer may assume that the beam RSRP has recovered and may reset its BFI count to 0 (e.g., C 0 ).

[0203] For dynamic adaptation of the maximum count (C max ), the WTRU may also receive a mapping relationship based on the association between the remaining delay D r of the PDU set after the first beam failure instance and the set of maximum count values (e.g., C max_default , C max_default , C max_1 , C max_2 , etc.) that the WTRU may select. The maximum count values may also be configured in descending order such as C max_default >C max_1 >C max_2 >... etc. In the example, the WTRU may adopt the mapping based on the remaining delay of the PDU set, D r , and use C r if D max_default <(C * -1) BFI T max_1 , and use C r if D max_1 <(C * -1) BFI T max_2 , etc.

[0204] In an example, the WTRU may start receiving the PDUs of the PDU set using the optimal beam. At the start of receiving the PDU set, the WTRU may also receive an indicator from the gNB (e.g., within DCI) along with information regarding the first PDU of the PDU set. For example, the indicator may indicate that a given PDU (e.g., the first PDU) is the start of the PDU set (e.g., the first PDU is the first PDU of the PDU set). The indicator regarding the first PDU may be sent at the start of each PDU set as part of the downlink control information (DCI).

[0205] In an example, after obtaining an indicator regarding the first PDU of the PDU set, the WTRU may start receiving the PDUs of the PDU set via the beam. FIG. 7 illustrates an example of an adaptive setting of the maximum count value of the BFI for sending a beam failure recovery request to the gNB. As shown in FIG. 7, the WTRU may also measure the RSRP and periodically receive CSI-RS and / or SRS to determine the received power of the beam. If the WTRU measures an RSRP value below the RSRP threshold and / or receives at least one PDU incorrectly, the PHY layer within the WTRU may send a first indicator of the beam failure instance to the MAC layer, and then the MAC layer may start incrementing the BFI count C 1 and may start the beam failure detection timer T BFI Based on the received PDUs, the MAC layer within the WTRU may determine the remaining delay D r regarding the PDU set after experiencing the first BFI. Then, the WTRU may adopt a mapping relationship between the remaining delay D r and the set C max of available maximum count values and the beam failure detection timer to start the beam recovery procedure and determine the maximum number of BFIs to count before sending a beam failure indicator to the network to maintain the delay budget. In an example, the MAC layer in the WTRU may be configured to switch back to the default maximum count value C max_default after receiving one or more (e.g., all) PDUs of the PDU set.

[0206] In an example, the WTRU may receive a set of configurations including one or more thresholds (C max ) related to a maximum count, a BF detection timer (T BFI ), one or more mapping relationships between the remaining delay value and the maximum count threshold, and / or a threshold related to RSRP management (e.g., 702 in FIG. 7). The WTRU may start receiving PDUs of a PDU set (e.g., 704 in FIG. 7) (e.g., including an indicator of the start PDU of the PDU set). The WTRU may measure the RSRP on a beam and may determine that the RSRP on the beam is below the RSRP threshold (e.g., the WTRU encounters a BFI) (e.g., 704 in FIG. 7). The WTRU may determine the remaining delay D r to satisfy the PSDB of the PDU set (e.g., 704 in FIG. 7 and / or as described herein). The WTRU may use the mapping relationship to select an appropriate maximum count threshold C max for the number of BFIs to be counted (e.g., 706 in FIG. 7). The WTRU may use C max_2 as the threshold for the maximum number of BFIs to be counted before sending a beam failure indicator to the gNB (e.g., 708 in FIG. 7).

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

[0208] For example, a WTRU may receive configuration information from a network indicating a plurality of associations between a reference signal received power (RSRP) threshold, a beam failure detection duration value, and / or the respective number of consecutive BFIs and remaining latency values. The WTRU may receive PDUs associated with a PDU set via 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 of the PDU set (e.g., and / or an indication that the PDU is the first PDU of a plurality of PDUs within the PDU set). The WTRU may perform a first RSRP measurement associated with the beam. The WTRU may determine that the first RSRP measurement value is less than the received RSRP threshold. Based on the determination that the first RSRP measurement value is less than the received RSRP threshold, the WTRU may increment the counter. The WTRU may determine the remaining latency value associated with the PDU set based on the received PDU. The WTRU may determine a comparison value (e.g., (C max_1 -1) * T BFI ) based on a default value of the number of consecutive BFIs and the beam failure detection duration value. The WTRU may compare the remaining latency value with the comparison value. The WTRU may select a value for the number of consecutive BFIs based on the remaining latency value associated with the PDU set and the plurality of associations. For example, the WTRU may select a value for the number of consecutive BFIs if the remaining latency value is less than the comparison value. The WTRU may perform a second RSRP measurement and, if the WTRU determines that the second RSRP measurement value is less than the received RSRP threshold, may increment the counter. The WTRU may send an indication of beam failure based on the value selected for the number of consecutive BFIs. For example, the WTRU may send an indication of beam failure based on the number of consecutive BFIs having reached (e.g., being equal to or greater than) the selected value.

[0209] The processes and means described herein may be applicable to other wireless technologies and to other services.

[0210] The WTRU may refer to identification information of a physical device, or subscription-related identification information, such as identification information of a user, e.g., MSISDN, SIP URI, etc. The WTRU may refer to application-based identification information, such as a user name that may be used for each application.

[0211] 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 (transmitted via a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and / or optical media such as CD-ROM disks, and / or digital versatile disks (DVD). A radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, and / or any host computer may be implemented using a processor associated with software.

Claims

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

2. The method of claim 1, further comprising receiving an indication that the PDU is a first PDU among a plurality of PDUs in the set of PDUs.

3. incrementing a counter based on the determination that the first RSRP measurement value is less than the received RSRP threshold; determining a comparison value based on a default value for the number of consecutive BFIs and a beam failure detection duration value; comparing the remaining latency value associated with the set of PDUs with the comparison value; selecting, based on the remaining latency value and the configuration information, the value for the number of consecutive BFIs, conditioned on the remaining latency value being less than the comparison value.

4. The method of claim 3, wherein the configuration information further includes the beam failure detection duration value.

5. determining that a timer has not expired; incrementing the counter based on the determination that the first RSRP measurement value is less than the received RSRP threshold and the determination that the timer has not expired.

6. initializing a counter to a first counter value; If it is determined that the first RSRP measurement value is less than the received RSRP threshold value, further including incrementing the counter to a second counter value, the method according to claim 1.

7. Performing a second RSRP measurement; Determining that the second RSRP measurement value is less than the received RSRP threshold value; If it is determined that the second RSRP measurement value is less than the received RSRP threshold value, further including incrementing the counter to a third counter value, the method according to claim 6.

8. Transmitting the indicator of the beam failure based on the selected value of the number of consecutive BFIs, Determining that the second counter value is greater than or equal to the value of the number of consecutive BFIs; Transmitting the indicator of the beam failure based on the determination that the second counter value is greater than or equal to the value of the number of consecutive BFIs, the method according to claim 6.

9. A wireless transmit / receive unit (WTRU) comprising: A processor, the processor: Receiving configuration information from a network, including a plurality of associations between a reference signal received power (RSRP) threshold value, the respective number of consecutive beam failure instances (BFIs), and remaining delay values; Receiving, via a beam, a packet data unit (PDU) associated with a set of PDUs; Performing a first RSRP measurement associated with the beam; Determining that the first RSRP measurement value is less than the received RSRP threshold value; Determining, based on the received PDU, the remaining delay value associated with the set of PDUs; Selecting a value of the number of consecutive BFIs based on the remaining delay value associated with the set of PDUs and the plurality of associations; Configured to transmit, to the network, an indicator of beam failure based on the selected value of the number of consecutive BFIs, a wireless transmit / receive unit (WTRU).

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

11. The processor: Incrementing a counter based on the determination that the first RSRP measurement value is less than the received RSRP threshold value, Based on the default value of the number of consecutive BFIs and the beam failure detection duration value, a comparison value is determined. The remaining delay value associated with the PDU set is compared with the comparison value. The WTRU according to claim 9, further configured to select the value of the number of consecutive BFIs based on the remaining delay value and the configuration information on the condition that the remaining delay value is less than the comparison value.

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

13. The processor determines that the timer has not expired, and increments the counter based on the determination that the first RSRP measurement value is less than the received RSRP threshold value and the determination that the timer has not expired. The WTRU according to claim 11 is further configured as such.

14. The processor initializes the counter to a first counter value, and increments the counter to a second counter value when it is determined that the first RSRP measurement value is less than the received RSRP threshold value. The WTRU according to claim 9 is further configured as such.

15. The processor performs a second RSRP measurement, determines that the second RSRP measurement value is less than the received RSRP threshold value, and increments the counter to a third counter value when it is determined that the second RSRP measurement value is less than the received RSRP threshold value. The WTRU according to claim 14 is further configured as such.

16. The fact that the processor is configured to transmit the indicator of beam failure based on the selected value of the number of consecutive BFIs means that the processor determines that the second counter value is greater than or equal to the value of the number of consecutive BFIs, and includes being configured to transmit the indicator of beam failure based on the determination that the second counter value is greater than or equal to the value of the number of consecutive BFIs. The WTRU according to claim 14 is configured as such.

Images