Method and apparatus for mobility procedure for height orientation system

Abstract

A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: transmitting, to a network, information indicating a capability for determining a WTRU orientation associated with a receive beam; receiving information indicating a plurality of parameter sets associated with a beam fault detection and recovery (BFDR) process, the plurality of parameter sets being associated with a plurality of receive beams, respectively, and each parameter set of the plurality of parameter sets comprising a criterion associated with a receive beam of the plurality of receive beams and one or more WTRU orientations; determining, according to the one or more measurements, a BFDR configuration corresponding to a second receive beam of the plurality of receive beams based on a first receive beam of the plurality of receive beams and based on a second WTRU orientation associated with the second receive beam; and performing a BFDR procedure on the second receive beam based on the standard and the second WTRU orientation.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 324,916, filed on March 29, 2022, which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to methods and apparatus for mobility procedures for highly directional systems. Background Art

[0004] It is known that there are several aspects that limit the field of view of a wireless transmit / receive unit (WTRU) that may be due to: (i) HW / FW capabilities such as multi-panel availability, number of transceiver chains, and computing power; (ii) WTRU QoS in terms of power consumption, feasibility of measurements given available HW and active flows / services, and (iii) network capabilities and resource configuration to provide measurement gaps to the WTRU in a timely manner. Limitations in the field of view of the WTRU may result in service disruptions. There is a need to develop effective methods to deal with such issues. Summary of the invention

[0005] In an embodiment, a method implemented in a wireless transmit / receive unit may include the step of sending information to a network indicating a capability for determining a WTRU orientation associated with a receive beam. The method may also include the step of receiving information indicating a plurality of parameter sets associated with a beam failure detection and recovery process, wherein the plurality of parameter sets are respectively associated with a plurality of receive beams, and wherein each of the plurality of parameter sets includes criteria associated with a receive beam in the plurality of receive beams and one or more WTRU orientations. The method may also include the step of determining a beam failure detection and recovery configuration corresponding to a second receive beam in the plurality of receive beams based on one or more measurements, based on a first receive beam in the plurality of receive beams and based on a second WTRU orientation associated with a second receive beam in the plurality of receive beams; and the step of performing a beam failure detection and recovery process on the second receive beam based on the received criteria associated with the second receive beam and based on the second WTRU orientation.

[0006] The method may comprise the step of transmitting information indicative of the received criterion associated with the second receive beam.

[0007] The WTRU may include an antenna panel, and the WTRU position may be associated with a receive beam formed by the antenna panel.The received criteria for each parameter set in the plurality of parameter sets may be based on any instance of a beam failure counter and a beam failure detection time period.

[0008] The one or more measurements may include any of the rotational measurements of the WTRU. The one or more measurements may also include a channel quality measurement.

[0009] The method may also include receiving information indicating rotation measurements of the WTRU from network measurements and / or a gyro sensor.The WTRU orientation may include a plurality of angular ranges.

[0010] Indicating a capability for determining the WTRU's orientation associated with a receive beam may include indicating information including any of one or more parameters, the one or more parameters including the number of antenna panels, the angular coverage of at least one antenna panel, the maximum / minimum WTRU transmit / receive (Tx / Rx) beamwidth, and the location of the antenna panel on the WTRU. The angular coverage may include an azimuth dimension and an elevation dimension. The location of the antenna panel on the WTRU may be relative to the antenna panel used to send information to the network. The location of the antenna panel on the WTRU may include information indicating an absolute location relative to the center of the WTRU.

[0011] The information indicating the capability may be sent using a radio resource control uplink message. The information indicating the capability may be sent using uplink control information on a control channel. Each parameter set in the plurality of parameter sets includes a configuration identifier.

[0012] The method may also include receiving information indicating a configuration for transmitting multiple SRSs and transmitting the indicated SRSs through different WTRU beams according to the received configuration.

[0013] In an embodiment, a WTRU including a processor, a transceiver unit, and a storage unit may be configured to: send information indicating a capability for determining a WTRU orientation associated with a receive beam to a network; receive information indicating a plurality of parameter sets associated with a beam failure detection and recovery process, wherein the plurality of parameter sets are respectively associated with a plurality of receive beams, and wherein each of the plurality of parameter sets includes criteria associated with a receive beam among the plurality of receive beams and one or more WTRU orientations; determine, based on one or more measurements, a beam failure detection and recovery configuration corresponding to a second receive beam based on a first receive beam among the plurality of receive beams and based on a second WTRU orientation associated with a second receive beam among the plurality of receive beams; and perform a beam failure detection and recovery process on the second receive beam based on the received criteria associated with the second receive beam and based on the second WTRU orientation.

[0014] The WTRU may be configured to send information indicative of the received criteria associated with the second receive beam.

[0015] The WTRU may include an antenna panel, and wherein the WTRU orientation is associated with a receive beam formed by the antenna panel.

[0016] The received criteria for each parameter set in the plurality of parameter sets is based on any one of an instance of a beam failure counter and a beam failure detection time period.

[0017] The one or more measurements may include a rotation measurement of the WTRU. The one or more measurements may also include a channel quality measurement.

[0018] The WTRU may be further configured to receive information indicating rotation measurements of the WTRU from network measurements and / or a gyro sensor.The WTRU orientation may include multiple angular ranges.

[0019] Indicating a capability for determining the WTRU orientation associated with a receive beam may include indicating information including any of one or more parameters including the number of antenna panels, the angular coverage of at least one antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth, and the location of the antenna panels on the WTRU. The angular coverage may include an azimuth dimension and an elevation dimension.

[0020] The location of the antenna panel on the WTRU may be relative to the antenna panel used to send information to the network.

[0021] The location of the antenna panel on the WTRU may include information indicating the absolute location relative to the center of the WTRU.

[0022] The information indicating the capability may be sent using a radio resource control uplink message.The information indicating the capability may be sent using uplink control information on a control channel.

[0023] Each parameter set in the plurality of parameter sets may include a configuration identifier.

[0024] The WTRU may also be configured to receive information indicating a configuration for transmitting multiple SRSs and transmit the indicated SRSs through different WTRU beams according to the received configuration. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] A more detailed understanding can be obtained from the following detailed description given in the form of examples in conjunction with the accompanying drawings. The figures in these drawings, like the detailed description, are exemplary. Therefore, these figures and detailed description should not be regarded as limiting, and other equally effective examples are possible and likely. In addition, the same reference numerals in the figures represent the same elements, among which:

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

[0027] Figure 1B is a diagram showing the Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG.

[0028] Figure 1C is a diagram showing the Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used in a communication system shown in FIG.

[0029] Figure 1D It is shown that according to the embodiment, Figure 1A A system diagram of yet another example RAN and yet another example CN used within a communication system shown in FIG.

[0030] Figure 2 is a sequence diagram illustrating an example of an intra-gNB handover in New Radio (NR);

[0031] Figure 3 is a sequence diagram showing an example of intra-NR RAN conditional handover;

[0032] Figure 4 is a diagram showing an example of parallel operation processes of a WTRU following a rotation or blocking event;

[0033] Figure 5 is a diagram showing an example of cell coverage using different gain beams;

[0034] Figure 6 is a system diagram showing an example of the effect of a WTRU's rotation / orientation on its field of view;

[0035] Figure 7 is a diagram illustrating an example of WTRU rotation and its impact on WTRU beam selection;

[0036] Figure 8 is a system diagram showing an example of edge beams for a WTRU;

[0037] Fig. 9 is a system diagram illustrating an example of a method performed by a WTRU to support a conditional handover (CHO) procedure;

[0038] Fig.10 is a system diagram illustrating an example of a WTRU Tx / Rx beam based beam failure detection process;

[0039] Fig.11 is a graph showing examples of simulation performance of four techniques for highly directional system communication improvement;

[0040] Fig.12is a system diagram showing an example of using antenna panel measurements to achieve faster inter-cell handover;

[0041] Fig.13 is a flow chart illustrating an example of a method performed by a WTRU for antenna panel selection / switching based on network reporting;

[0042] Fig.14 is a flow chart illustrating an example of a method performed by a WTRU for antenna panel selection / switching based on WTRU measurements; and

[0043] Fig.15 is a flow chart illustrating an example of a method performed by a WTRU for performing beam failure and detection recovery. DETAILED DESCRIPTION

[0044] In the following detailed description, many specific details are set forth to provide a comprehensive understanding of the embodiments and / or examples disclosed herein. It is understood that these embodiments and examples can be practiced without some or all of the specific details described herein. In other cases, well-known methods, processes, components, and circuits are not described in detail to avoid confusing the following description. In addition, the embodiments and examples not specifically described herein can be replaced or combined with the embodiments and other examples described herein, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively referred to as "provided") to practice.

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

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

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

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

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

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

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

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

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

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

[0055] Figure 1AThe base station 114b in the example may be a wireless router, a home Node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

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

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

[0061] The transmit / receive element 122 may be configured to transmit or receive signals to or 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 an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0062] although Figure 1B 102 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 an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

[0064] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 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 user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0067] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 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.

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

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

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

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

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

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

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

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

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

[0077] although Figures 1A to 1D WTRUs are described in the EMBODIMENTS as wireless terminals, but it is contemplated in certain representative embodiments that such terminals may communicate with a communication network using (eg, temporarily or permanently) a wired communication interface.

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

[0079] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another wired / wireless network that transfers a communication stream into and / or out of the BSS. A communication stream originating from outside the BSS and directed to a STA may be reached by the AP and may be transmitted to the STA. A communication stream originating from a STA and directed to a destination outside the BSS may be sent to the AP for transmission to the corresponding destination. A communication stream between STAs within a BSS may be sent by the AP, for example, where a source STA may send a communication stream to the AP, and the AP may transmit the communication stream to a target STA. A communication stream between STAs within a BSS may be considered and / or referred to as a point-to-point communication stream. A point-to-point communication stream may be sent between a source STA and a target STA (e.g., directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

[0080] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can send beacons on a fixed channel (e.g., a primary channel). The primary channel can be a fixed width (e.g., a 20MHz wide bandwidth) or a width dynamically set through signaling. The primary channel can be an operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, such as in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) can listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0081] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0082] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or combining two discontinuous 80MHz channels, which can be called an 80+80 configuration. For the 80+80 configuration, the data can be passed through a segment parser after channel coding, which can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The stream can be mapped onto two 80MHz channels, and the data can be sent by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0098] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test lab and / or a wired and / or wireless communication network that is not deployed (e.g., tested) to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can use direct RF coupling and / or wireless communication through RF circuits (e.g., which can include one or more antennas) to send and / or receive data.

[0099] The NR inter-gNB handover procedure is referred to herein as legacy handover. When the WTRU is in radio resource control (RRC) connected mode, cell / gNB level mobility may require triggering explicit RRC signaling. The WTRU may report cell quality measurements to its serving (e.g., source) cell when the neighbor cell quality deviates better for a preset time to trigger (TTT) duration. With reference to “NR and NG-RAN General Description; Stage 2, 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.300, December 2021, v16.8.0”, different events may be defined for WTRU measurement reporting triggers, referred to as A1, A2, A3, A4, A5, etc. The TTT and cell-specific offset may be specified during the measurement configuration step. If a handover (HO) decision is made based on the measurement report, the source gNB may issue a handover request to the target gNB. If the WTRU is admitted by the target gNB, the target gNB may send a handover request confirmation to the source gNB, which contains the RRC message to be sent to the WTRU. Next, the source gNB may initiate the handover and may send an RRC reconfiguration message to the WTRU. It may also include a set of dedicated random access channel (RACH) resources. Finally, the WTRU may synchronize to the target cell and complete the RRC handover procedure. The overall handover (HO) process is as follows Figure 2 shown. Figure 2 Excerpt from 3GPP TS 38.300 Version 16.4.0 Release 16 Fig. 9 .2.3.2.1-1.

[0100] refer to Figure 2 , in step 0, the WTRU context within the source gNB may contain information about roaming and access restrictions, which was provided when the connection was established or at the last TA update.

[0101] In step 1, the source gNB can configure the WTRU measurement process, and the WTRU can report according to the measurement configuration.

[0102] In step 2, the source gNB may decide to switch the WTRU based on the measurement report and RRM information.

[0103] In step 3, the source gNB may send a handover request message to the target gNB, passing a transparent RRC container containing the information required to prepare the handover on the target side. This information may include at least the target cell ID, KgNB, the C-RNTI of the WTRU in the source gNB, the RRM configuration including the WTRU inactive time, the basic AS configuration including antenna information and DL carrier frequency, the current QoS flow to DRB mapping rules applied to the WTRU, SIB1 from the source gNB, WTRU capabilities for different RATs, PDU session related information, and may include measurement information reported by the WTRU (including beam related information, if any). The PDU session related information may include slice information and QoS flow level QoS profile. The source gNB may also request DAPS handover for one or more DRBs.

[0104] After issuing the handover request, the source gNB may not reconfigure the WTRU, including performing reflective QoS flow to DRB mapping.

[0105] In step 4, the target gNB may perform admission control. If slice information is sent to the target gNB, slice-aware admission control may be performed. If a PDU session is associated with an unsupported slice, the target gNB may reject such a PDU session.

[0106] In step 5, the target gNB may use L1 / L2 to prepare for the handover and send a HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which may include a transparent container to be sent as an RRC message to the WTRU to perform the handover. The target gNB may indicate whether the DAPS handover is accepted. Data forwarding may begin once the source gNB receives the HANDOVER REQUEST ACKNOWLEDGE, or once the sending of the handover command is initiated in the downlink. For DRBs configured with DAPS, downlink PDCP SDUs may be forwarded using the SN assigned by the source gNB until the SN allocation is handed over to the target gNB in ​​step 8b, and then normal data forwarding may occur as defined in 9.2.3.2.3 of document 3GPP TS 38.300 Version 16.4.0 Release 16.

[0107] In step 6, the source gNB may trigger a Uu handover by sending an RRCReconfiguration message to the WTRU containing the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifier for the selected security algorithm. It may also include a set of dedicated RACH resources, the association between RACH resources and SSBs, the association between RACH resources and WTRU-specific CSI-RS configurations, common RACH resources, and system information of the target cell. For DRBs configured with DAPS, the source gNB may not stop sending downlink packets until it receives a HANDOVER SUCCESS message from the target gNB in ​​step 8a. CHO cannot be configured simultaneously with DAPS handover. In step 7a, for DRBs configured with DAPS, the source gNB may send an EARLY STATUS TRANSFER message. The DL COUNT value conveyed in the EARLY STATUS TRANSFER message may indicate the PDCP SN and HFN of the first PDCP SDU forwarded by the source gNB to the target gNB. The source gNB may not stop allocating SNs to downlink PDCP SDUs until it sends an SN STATUS TRANSFER message to the target gNB in ​​step 8b.

[0108] In step 7, for DRBs for which DAPS is not configured, the source gNB may send an SN STATUS TRANSFER message to the target gNB to convey the uplink PDCP SN receiver status and downlink PDCP SN transmitter status for the DRBs for which the PDCP status remains applicable (i.e., for RLC AM). The uplink PDCP SN receiver status may include at least the PDCP SN of the first missing UL PDCP SDU and may include a bitmap of the reception status of out-of-sequence UL PDCP SDUs that the WTRU may need to retransmit in the target cell, if any. The downlink PDCP SN transmitter status may indicate the next PDCP SN that the target gNB should assign to new PDCP SDUs that do not yet have a PDCP SN. In case of DAPS handover, for DRBs using RLC-AM and not configured with DAPS, the uplink PDCP SN receiver status and downlink PDCP SN transmitter status may be transmitted via the SN STATUS TRANSFER message in step 8b (instead of step 7). For DRBs configured with DAPS, the source gNB may additionally send an EARLY STATUS TRANSFER message between step 7 and step 8b to notify the discard of the forwarded PDCP SDUs. The target gNB may not send forwarded downlink PDCP SDUs with a COUNT less than the transmitted DL COUNT value to the WTRU or discard them if transmission has not been attempted.

[0109] In step 8, the WTRU may synchronize to the target cell and complete the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB. In case of DAPS handover, the WTRU may not detach from the source cell after receiving the RRCReconfiguration message. The WTRU may release the source SRB resources, the security configuration of the source cell and stop DL / UL reception / transmission with the source after receiving an explicit release from the target node. From the RAN perspective, a DAPS handover may be considered complete only after the WTRU releases the source cell as per an explicit request from the target node. RRC may be suspended and subsequent handovers or inter-RAT handovers may not be initiated until the source cell has been released.

[0110] In step 8a / b, if DAPS handover occurs, the target gNB may send a HANDOVER SUCCESS message to the source gNB to inform the WTRU that it has successfully accessed the target cell. In response, the source gNB may send an SN STATUS TRANSFER message for the DRBs configured with DAPS, for which the description in step 7 applies, and normal data forwarding occurs as defined in 9.2.3.2.3 of document 3GPP TS 38.300 Version 16.4.0 Release 16. If DAPS is configured, the uplink PDCP SN receiver status and downlink PDCP SN transmitter status may also be transmitted in the SN STATUS TRANSFER message in step 8b for the DRBs using RLC-UM. For the DRBs configured with DAPS, the source gNB may not stop transmitting uplink QoS flows to the UPF until it sends the SN STATUS TRANSFER message in step 8b. The target gNB may forward the QoS flows of successfully received uplink PDCP SDUs to the UPF out of sequence until it receives an SN STATUS TRANSFER message with the first missing SN in the UL HFN and uplink PDCP SN receiver status indicating the start of uplink PDCP SDUs to be delivered to the UPF. The target gNB may not deliver any uplink PDCP SDUs with a UL COUNT lower than the provided value.

[0111] In step 9, the target gNB may send a PATH SWITCH REQUEST message to the AMF to trigger the 5GC to switch the DL data path to the target gNB and establish an NG-C interface instance pointing to the target gNB.

[0112] In step 10, the 5GC may switch the DL data path to the target gNB. The UPF may send one or more “end marker” packets per PDU session / tunnel on the old path to the source gNB, and may then release any U-plane / TNL resources directed to the source gNB.

[0113] In step 11, the AMF may confirm the PATH SWITCH REQUEST message using a PATH SWITCH REQUEST ACKNOWLEDGE message.

[0114] In step 12, upon receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB may send a WTRU CONTEXT RELEASE to notify the source gNB that the handover is successful. The source gNB may then release the radio and C-plane related resources associated with the WTRU context. Any ongoing data forwarding may continue. The RRM configuration may include beam measurement information associated with the SSB (for Layer 3 mobility) and the CSI-RS for the reported cell (if both types of measurements are available). In addition, if CA is configured, the RRM configuration may include a list of best cells on each frequency with available measurement information. And, the RRM measurement information may also include beam measurements for the listed cells belonging to the target gNB. The common RACH configuration for the beam in the target cell may be associated only with the SSB. The network may have a dedicated RACH configuration associated with the SSB and / or have a dedicated RACH configuration associated with the CSI-RS within the cell. The target gNB may include only one of the following RACH configurations in the handover command to enable the WTRU to access the target cell: i) common RACH configuration; ii) common RACH configuration + dedicated RACH configuration associated with SSB; iii) common RACH configuration + dedicated RACH configuration associated with CSI-RS. The dedicated RACH configuration may allocate RACH resources and quality thresholds for using them. When dedicated RACH resources are provided, the WTRU may prioritize them and will not switch to contention-based RACH resources as long as the quality thresholds of these dedicated resources are met. The order in which dedicated RACH resources are accessed may depend on the WTRU implementation. Upon receiving the handover command requesting a DAPS handover, the WTRU may suspend the source cell SRB, stop sending and receiving any RRC control plane signaling directed to the source cell, and establish an SRB for the target cell. After successfully performing a DAPS handover, the WTRU may release the source cell SRB configuration after receiving a source cell release indication from the target cell. When a DAPS handover to the target cell fails and the source cell link is available, the WTRU may revert to the source cell configuration and resume the source cell SRB for control plane signaling transmission.

[0115] The HO process may fail due to poor channel quality at the target gNB, the source gNB, or both. In scenarios with directional links, the handover problem is exacerbated because the link quality of the target and source gNBs may suddenly deteriorate due to a mobile blocker or WTRU rotation. First, blocking of the target gNB during the handover process may cause a handover failure (HOF). When the WTRU receives the RRC reconfiguration message, a handover failure timer T304 may be started. If the T304 timer expires before the handover is completed, a HOF may be declared and the WTRU may perform a connection reestablishment. Second, after a sudden WTRU rotation or blocking, the source gNB may not be able to initiate the handover process in time based on the most recent measurement reports. Even measurement reports from the WTRU may be lost due to poor link quality. Therefore, without handover assistance from the source gNB, the WTRU may need to wait for the source gNB to recover from the interruption or declare a radio link failure (RLF) even if there is a potential target gNB with good channel quality.

[0116] As a potential solution for the target gNB being blocked, Dual Activation Protocol Stack (DAPS) handover is specified in 3GPP Rel.16. In DAPS handover, the WTRU may not release the source cell connection until the random access to the target gNB is completed. If the target gNB link deteriorates before the random access is completed, the WTRU may fall back to the source gNB.

[0117] To address the blocking problem of the source gNB, conditional handover (CHO) is specified in 3GPP Rel.16. In CHO, the WTRU can be configured to perform a handover when one or more handover execution conditions are met. The source gNB can proactively configure the WTRU to evaluate the CHO execution conditions defined for the candidate gNB. Once the conditions are met, for example, when the offset of the target gNB is better than the source gNB, the WTRU can initiate a handover to the target gNB without source gNB signaling. Therefore, even if the source gNB is in an interrupted state due to sudden blocking or rotation, the WTRU can still successfully complete the handover to the target gNB if the CHO execution conditions are met. The entire CHO process is as follows: Figure 3 shown. Figure 3 Extract from 3GPP TS38.300 Version 16.4.0 Release 16 Fig. 9 .2.3.4.2-1.

[0118] refer to Figure 3 , steps 0 and 1 are the same as Figure 2 Step 0 is similar to step 1.

[0119] In step 2, the source gNB may decide to use CHO.

[0120] In step 3, the source gNB may request CHO for one or more candidate cells belonging to one or more candidate gNBs. A CHO request message may be sent for each candidate cell.

[0121] Step 4 and Figure 2 similar.

[0122] In step 5, the candidate gNB may send a CHO response (HOREQUEST ACKNOWLEDGE) including the CHO candidate cell configuration to the source gNB. The CHO response message may be sent for each candidate cell.

[0123] In step 6, the source gNB may send an RRCReconfiguration message to the WTRU containing the configuration of the CHO candidate cells and the CHO execution conditions. The CHO configuration of the candidate cells may be followed by other reconfigurations from the source gNB. The configuration of the CHO candidate cells may not contain a DAPS handover configuration.

[0124] In step 7, the WTRU may send an RRCReconfigurationComplete message to the source gNB.

[0125] In step 7a, if early data forwarding is applied, the source gNB may send an EARLY STATUS TRANSFER message.

[0126] In step 8, the WTRU may maintain connection with the source gNB after receiving the CHO configuration and start evaluating the CHO execution conditions of the candidate cells. If at least one CHO candidate cell meets the corresponding CHO execution conditions, the WTRU may detach from the source gNB, may apply the stored corresponding configuration for the selected candidate cell, may synchronize to the candidate cell and complete the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB. The WTRU may release the stored CHO configuration after successfully completing the RRC handover procedure.

[0127] In step 8a / b, the target gNB may send a HANDOVER SUCCESS message to the source gNB to inform the WTRU that it has successfully accessed the target cell. In response, the source gNB may Figure 2 The source gNB sends the SN STATUSTRANSFER message according to the principle described in step 7 of the HANDOVER SUCCESS message. Once the source gNB receives the HANDOVER SUCCESS message, it can initiate subsequent data forwarding.

[0128] In step 8c, the source gNB may send a HANDOVER CANCEL message to other signaling connections or other candidate target gNBs (if any) to cancel the CHO of the WTRU.

[0129] Steps 9 to 12 and Figure 2 similar.

[0130] Although CHO can protect against mobile blockers and can significantly reduce the number of RLFs, its success may depend on the availability of candidate gNBs before the blocker arrives, the link quality of the corresponding links, and the conditional thresholds of the target gNB. Even if candidate gNBs are present, the WTRU may need to be able to maintain link quality with the selected candidate gNB until the handover is completed. In addition, the conditional thresholds for handover execution may also need to be carefully configured. Higher thresholds may cause the WTRU to often fail to perform a handover to the target gNB in ​​a timely manner, resulting in an increased number of handover failures. On the other hand, lower thresholds may result in suboptimal selection of the new serving gNB.

[0131] The WTRU may perform radio link monitoring (RLM) based on the synchronization signal block (SSB) or / and the channel state information reference signal (CSI-RS) and the signal quality threshold configured by the network.

[0132] The standards that declare RLF are listed in the document "NR; Radio Resource Control (RRC); Protocol Specification, 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.331, December 2021, v16.7.1", including the following standards that are relevant to our discussion:

[0133] RLF based on T310: Based on link quality measurement (using SSB or / and CSI-RS), if an out-of-sync indication (e.g., a measurement value below a given threshold) is received consecutively for a preset number of times N310, the RLF timer T310 may be started. If the channel quality recovers before the T310 timer expires, the T310 timer may be reset; otherwise, after the T310 timer expires, RLF may be declared.

[0134] T312 based RLF: The WTRU may start a T312 timer upon triggering a measurement report for which a T310 timer is already running. The T312 timer may allow the WTRU to differentiate between a RLF caused by a handover failure or a RLF caused by a coverage hole. The T312 timer may (e.g., typically) be shorter than the T310 timer. Thus, if the channel quality of the source gNB is below a threshold, the shorter T312 timer may expire earlier and an RLF may be declared in a timely manner.

[0135] Random Access Procedure Failure: RLF may be declared if multiple RACH attempts to connect to the gNB fail consecutively.

[0136] In frequency range 2 (FR2), beam level measurements and beam management may be integral to achieve high capacity channels. As the system changes due to WTRU movement and mobile blockers, the best beam pair may be constantly updated. Mobile blockers and / or WTRU rotations may cause the current beam pair to degrade rapidly without sufficient time for the regular beam to adapt. In this case, the WTRU may detect a beam failure and may initiate a beam recovery procedure. The WTRU may declare a beam failure if the number of beam failure indications reaches a configured threshold beamFailureInstanceMaxCount before the configured timer beamFailureDetectionTimer expires. After a beam failure, the WTRU may initiate a random access procedure using the configured candidate beams and preamble. If the WTRU is unable to synchronize with the gNB after multiple RACH attempts, an RLF may be declared.

[0137] After a blocking or rotation event, the BFDR, RLM, and switching processes can run simultaneously, e.g. Figure 4 shown. Figure 4 Depicted are examples of parallel running processes following a WTRU rotation or blocking event. Figure 4 , each individual process (e.g., beam monitoring, radio link monitoring, traditional handover, conditional handover) may result in RLF. When the WTRU is configured to use traditional HO, link disruption may interrupt measurement reporting and / or HO initiation. The HO operation may fail. In the meantime, the BFDR process may attempt to recover through BFR. If the recovery attempt fails, the BFDR process may declare RLF. When the WTRU is configured to use CHO, once a mobile blocker blocks the link with the source gNB, the CHO conditions may be met and the WTRU may initiate a CHO to another gNB within its field of view (FoV).

[0138] Serving gNB and source gNB are used interchangeably herein. Random access and RACH are used interchangeably herein. WTRU beam, WTRU Tx / Rx beam, WTRU Rx beam and WTRU Tx beam are used interchangeably herein, assuming that the WTRU has beam-corresponding capability.

[0139] Propagation at higher frequency bands may be more challenging than at lower frequency bands. High propagation losses at higher frequencies may require the use of high antenna gain and directional (e.g., beamforming) transmissions based on narrow beams. To increase antenna gain on wide sector beams, larger antenna arrays (e.g., with the number of antenna elements ranging from tens to hundreds) may be used to form high gain beams. Figure 5 An example of the impact of using narrow beams at higher frequencies on coverage and path loss compensation is shown. Figure 5 Depicted are examples of cell coverage using beams of different gains. Figure 5 In such directional systems, since each Tx beam has limited spatial coverage, multiple beams are required to transmit DL common channels (e.g., system information, paging, etc.) to cover the entire cell area. The number of concurrent high-gain beams that a gNB can support may be limited by the cost and complexity of the transceiver architecture used.

[0140] As the carrier frequency increases, the number of beams required to cover the entire cell increases as higher beamforming gain is required to overcome propagation loss limitations. As shown in Table 1, a link budget analysis was performed for multiple coverage ranges at different mmWave carrier frequencies to estimate the number of beams required to cover a + / -45 degree sector. As the carrier frequency increases, the number of beams required to cover a sector increases significantly. Table 1 depicts an example of a link budget analysis showing the number of beams and number of antenna elements required at different carrier frequencies.

[0141]

[0142] Table 1: Link budget analysis

[0143] At higher frequencies (e.g., sub-THz bands), due to high attenuation and path loss, larger antenna arrays (e.g., tens to hundreds of antenna elements) may be used to form high gain and narrower beams, such as directional transmissions, and may need to increase coverage distance. As the frequency increases, the beams may become narrower (e.g., almost "laser-like" beams), and the number of beams used by a base station (e.g., gNB) to cover its coverage area may be much larger than for NR systems operating at mmWave frequencies (e.g., sub-71 GHz bands). The highly directional links resulting from the narrower beams at the WTRU and gNB may be more sensitive to dynamic environments than traditional links. One reason for this dynamic environment may be WTRU rotation, which is caused by rotational motion of handheld / wearable devices (e.g., smartphones, gaming consoles, and VR / XR headsets, etc.). These motions may originate from gestures, head movements, etc. WTRU rotation may result in channel changes between the serving gNB and the WTRU, which may result in beam misalignment or even link / connection failures.

[0144] Antenna arrays / panels that require a large number of antennas to facilitate directional links at higher frequencies may typically have limited angular coverage, e.g., less than 360 degrees of coverage. This limitation may come from how these antennas / panels are implemented on different devices and the nature / style of these devices.

[0145] A WTRU with a limited number of antenna array panels may have limited angular coverage. Rapid changes in the WTRU's orientation due to rotation may cause a sudden outage of the serving / source gNB, and the WTRU may not be configured to switch to a new gNB that may be best suited to establish a connection with the WTRU's updated angular coverage after rotation. This may cause a long outage for the WTRU. Figure 6 An example of a rotating single-antenna panel WTRU is shown where the WTRU does not see different gNBs simultaneously at its orientation due to the limited angular coverage of the panel (90 degrees). Figure 6 Depicted is an example of the effect of a WTRU's rotation / orientation on its field of view.

[0146] Delays in cell reselection and handover using existing Layer 1 / Layer 2 and Layer 3 based mobility procedures may significantly increase the duration of the outage. The situation may be better for WTRUs equipped with multiple antenna panels compared to single antenna panel WTRUs. Nevertheless, multi-panel devices may have to be equipped with multiple transceivers to effectively expand their angular coverage beyond that of a single antenna panel WTRU. The presence of multiple antenna panels and multiple transceivers can significantly increase the cost and footprint of the device, and the ability of many handheld and wearable devices to remain competitive in terms of cost and footprint may be limited.

[0147] The term field of view (FoV) is used herein to refer to the angular coverage or angular range of an antenna panel for a given direction. Depending on the WTRU orientation and the angular coverage of the antenna, the WTRU may be limited to communicating with gNBs that are within the Field of View provided by the antenna panel at that time. In the case of non-line-of-sight communications, there may be gNBs that are outside the WTRU's FoV with which a communication link can be established. The WTRU may have a single or multiple antenna panels. More antenna panels and more transceivers extend the field of view - however, the limited available transceivers still limit functionality.

[0148] The FoV may be more appropriately attributed to the antenna panel rather than the WTRU. In this case, even a multi-panel WTRU will have different FoVs for different antenna panels. Despite the presence of multiple panels, there are many physical and environmental limitations that may limit the FoV of the WTRU to that of a single antenna panel or to the FoV of a limited number of antenna panels. Limitations in available transceiver chains restrict the simultaneous use of antenna panels. This may also require periodic measurement gaps in different directions and may require disconnection from the primary serving beam / cell to make these measurements. Applications with demanding QoS requirements may limit the feasibility of timely measurements from non-FoV directions as periodic gaps may not be introduced relative to the data flow from the serving beam / cell. Therefore, FoV limitations may be exacerbated despite the presence of multiple antenna panels on the device. Many IoT type devices may experience FoV limitations due to power consumption reasons, i.e., continuous measurements of neighboring beams / cells by such devices may reduce power efficiency.

[0149] The WTRU may be configured to send information (e.g., explicitly) about its location to the network (e.g., serving gNB). Using the WTRU location information, the network (e.g., serving gNB) may provide the WTRU with the configuration of CHO. The network may use the WTRU location information to determine (e.g., predict) potential (e.g., neighboring) gNBs to be configured for CHO. The WTRU may perform a handover using a given CHO configuration.

[0150] The WTRU may be configured to send information about its capabilities (e.g., WTRU capabilities) to the network (e.g., serving gNB), the information including one or more parameters including the number of antenna panels, the (e.g., maximum) angular coverage of each antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3 dB or half-power beamwidth), the location of the antenna panels on the device, etc. The total number of beams that can be formed within the FoV of the antenna panels may be provided in the WTRU capability information or may be derived using the beamwidth and angular coverage information. Angular coverage information may be provided to the network in both azimuth and elevation dimensions. The location (e.g., 2D or 3D coordinates) of the (e.g., other) antenna panels may be provided relative to the antenna panels used / selected to communicate with the network (e.g., serving gNB). Alternatively, the absolute location relative to the center of the device may be provided in 2D or 3D coordinates or in named directions such as North, Southeast, etc. The WTRU capability information may be sent using higher layer signaling (e.g., RRC uplink messages). In an embodiment, the WTRU capability information may be sent as uplink control information via a control channel (eg, the Physical Uplink Control Channel (PUCCH)) or via a data channel (eg, the Physical Uplink Data Channel (PUSCH)).

[0151] The WTRU may communicate with the network (e.g., serving / source gNB) using one of the antenna panels (e.g., the antenna panel that causes the channel quality between the WTRU and the gNB to be above a threshold). Any (e.g., each) antenna panel may form one or more Tx and / or Rx beams in one or more directions of communication. Based on the WTRU orientation, the WTRU may use or select a Tx / RxWTRU beam to communicate with the network (e.g., serving / source gNB). The selection may be based on a Tx / Rx beam training / measurement process. For example, the WTRU may select a Tx / RxWTRU beam that provides the best communication link (e.g., channel quality above a minimum threshold) between the WTRU and the network (e.g., serving gNB). Changes in the WTRU orientation due to WTRU rotation may require changes in the Tx / RxWTRU beams.

[0152] Figure 7 Depicts an example of WTRU rotation and its impact on WTRU beam selection. Figure 7 Step (a) and step (b), after the WTRU rotates from (a) to (b), the WTRU may use different beams to communicate with the gNB. As a non-limiting example, the WTRU may track the device orientation or rotation angle, such as using measurements provided / configured by the network or using a gyroscope sensor, and may use appropriate Tx / Rx WTRU beams to communicate with the network (e.g., serving gNB). Due to the WTRU rotation, the gNB beam may not change, such as Figure 7 As shown in step (a) and step (b).

[0153] like Figure 7 As shown in step (c), after a large rotation (e.g., rotation above a rotation threshold), the serving gNB may be out of the FoV of the antenna panel used / selected to communicate with the serving / source gNB. There may be situations where other gNBs may be out of the FoV of the WTRU antenna panel while the WTRU is communicating with the serving / source gNB. Figure 6 An example is shown in Figure 1, where a single antenna panel WTRU has 90 degree angular coverage and the gNBs are deployed as shown. In this exemplary scenario, at any given point, there may be only one gNB in ​​the WTRU’s FoV and therefore measurements of neighboring gNBs may not be available. Without such measurements, the serving / source gNB will not be able to configure the WTRU to handover to a neighboring target gNB. Therefore, when the WTRU is significantly (e.g., in Figure 6, the WTRU may not be able to perform a handover to a new target gNB in ​​its FoV when the WTRU is rotated 90 degrees in the example shown in . In this case, the WTRU may first need to declare a radio link failure with the (e.g., previous) serving / source gNB and then may need to discover the new gNB in ​​its FoV to establish a connection. This may cause significant delays and outages to the WTRU.

[0154] The network (e.g., serving / source gNB) may configure the WTRU to report its position. This information may help the gNB predict / determine a (e.g., neighboring) target gNB for a potential handover. For example, if the WTRU rotates, the gNB may determine the (e.g., neighboring) gNBs that may soon enter the WTRU's FoV (e.g., without using any WTRU measurements on the neighboring gNBs).

[0155] In an embodiment, the WTRU may be configured to perform event / trigger based reporting. The WTRU may be configured to perform event based reporting based on an event of whether the WTRU is communicating with the serving / source gNB using one of the center or edge WTRU Tx / Rx beams. As a non-limiting example, an event may be triggered when the WTRU starts using one of the 'N' (N>=1) (e.g., edge) WTRU beams formed at the edge of the angular coverage or FoV provided by the antenna panel. This may apply to both ends of the angular coverage.

[0156] Figure 8 An example of an edge beam is depicted. Figure 8 , for the case of N=2, if the WTRU uses the last two beams on either side, i.e., beam 1, beam 2, beam 8, or beam 9, an event for reporting may be triggered. Such reporting may indicate to the gNB that the WTRU is at the edge of the WTRU's angular coverage and the gNB may soon be out of the WTRU's FoV. In this case, the gNB may predict / determine other potential target gNBs for potential handover and may configure the WTRU to perform a CHO with the selected target gNB. Reference Figure 8 If the WTRU reporting is triggered due to the use of beam 1 or beam 2, gNB1 can configure gNB3, otherwise, if the WTRU reporting is triggered based on beam 8 or beam 9, gNB1 can configure gNB2 for CHO.

[0157] In an embodiment, the WTRU may be configured with a time period, such as a "trigger time". The trigger time may be used to trigger a report. For example, a WTRU report indicating that an edge beam is being used may be triggered when, for example, if the WTRU uses / selects one of the N edge beams to communicate with the serving gNB for a minimum duration of the trigger time value.

[0158] In an embodiment, if the WTRU's active Tx / Rx beam is one of the edge beams and the channel quality measurement through this beam is below a configured threshold, the WTRU may be configured to provide an indication of its Tx / Rx beam to the gNB. For the case of DL transmissions, this event is triggered when the WTRU receives through one of its edge beams and the channel quality measurement on the resources associated with the DL transmission (DMRS, CSI-RS or SSB) is below the configured RSRP threshold. Similarly, different quality metrics may be used, such as RSRQ, etc. In an embodiment, reporting this event may be done when the estimated quality of a reference signal (e.g. RSRP) is within a given range. This may make sense because if the signal quality becomes very bad, there are predefined events that will be triggered with reference to a handover configuration or a radio link failure.

[0159] In an embodiment, the WTRU may be configured (e.g., by the network) to send a single bit of information in the WTRU report indicating that one of the configured edge beams is in use. This single bit of information may be used to indicate the edge (e.g., left or right) of the FoV being used / selected. For example, if one of the N edge beams at the left edge of the FoV is used (e.g., when N=2, Figure 8 If the reporting is triggered by using one of the N edge beams at the left edge of the FoV (e.g., when N=2, Figure 8 If the report is triggered by beam 8 or beam 9), the WTRU can send "0".

[0160] In another embodiment, the WTRU may be configured (e.g., by the network) to send "ceil(log2(N))+1" bits in the WTRU report to indicate that one of the configured edge beams is in use. The most significant bit may be used to indicate the edge of the FoV and the remaining bits may be used to indicate the beam. For example, for a Figure 8 As shown, N=2, the WTRU may use the following indications: 10 for beam 1, 11 for beam 2, 01 for beam 8, and 01 for beam 9.

[0161] In another embodiment, the WTRU may be configured (e.g., by the network) to send the (e.g., absolute) WTRU beam ID in the WTRU report. A beam index format / pattern may be used, for example, the beam index may start from the leftmost beam of the FoV of the antenna panel, such as Figure 8 The WTRU may be configured (e.g., by the network) to support the beam indexing method / format. The WTRU may be configured to send ceil(log2(maximum number of beams that can be formed to cover the FoV of the antenna panel)) bits in the WTRU report. For example, for N=2, Figure 8As shown, the WTRU may use the following indications: 0000 for beam 1, 0001 for beam 2, 0111 for beam 8, and 1000 for beam 9.

[0162] The WTRU report may be triggered by the use of one of the configured edge beams, and the report may be sent as uplink control information (e.g., via an uplink control channel PUCCH). The WTRU may be configured with an uplink resource configuration for sending the report. The configuration may include at least one of the following: periodicity, time offset, prohibition timer, uplink control channel (e.g., PUCCH) configuration (e.g., format, time / frequency resources, etc.), etc. The configuration may be communicated to the WTRU using, for example, higher layer (e.g., RRC) signaling, etc. Alternatively, the WTRU may use higher layer signaling containing the report (e.g., sending an RRC message). Alternatively, the WTRU may be configured to send the report as an uplink MAC-CE message. Alternatively, the WTRU may send the report using an uplink data channel (e.g., PUSCH). For the uplink data channel, the WTRU may be configured with time-frequency resources. If the WTRU does not have allocated resources, the WTRU may request the network (e.g., serving gNB) to allocate time-frequency resources (e.g., by sending a scheduling request).

[0163] A reporting configuration including one or more parameters may be communicated to the WTRU (e.g., in an RRC configuration or system information), including the value of N, a trigger time, a reporting format (e.g., how many bits are required, absolute versus relative beam indication), and a beam index mode (e.g., in the case of absolute beam index reporting).

[0164] In an embodiment, the reporting configuration may be antenna panel specific. If the WTRU supports multiple antenna panels, the WTRU may be configured with a reporting configuration for each panel. In an embodiment, the WTRU may be configured to send an uplink indication (e.g., using uplink control information, RRC signaling, or uplink MAC-CE message) upon any change in the antenna panel that the WTRU uses / selects to communicate with the network (e.g., serving / source gNB). In an embodiment, the uplink indication may contain information of the antenna panel, such as an antenna panel identification, if other information (e.g., angular coverage of each panel, maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth)) has been sent by the WTRU to the network (e.g., serving gNB), for example, as part of the WTRU capabilities. In an embodiment, the WTRU may send the antenna panel identification, the angular coverage of any (e.g., each) antenna panel, and / or the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3 dB or half-power beamwidth) to the serving gNB when any change occurs to the antenna panel that the WTRU uses / selects to communicate with the serving gNB. After sending the indication, the WTRU may receive a reporting configuration (e.g., containing one or more parameters including the value of N, trigger time, reporting format), for example, when the WTRU is not already configured with a reporting configuration for the reported antenna panel.

[0165] In an embodiment, the WTRU may be configured (e.g., by the network) to send periodic WTRU reports indicating the WTRU Tx / Rx beams used / selected by the WE to communicate with the network. For antenna panels, a beam index format / pattern may be used, for example, the beam index may start from the leftmost beam of the FoV of the antenna panel, such as Figure 8 The WTRU may be configured (e.g., by the network) to support the beam indexing method / format. The WTRU may be configured to send ceil(log2(maximum number of beams that can be formed to cover the FoV of the antenna panel)) bits in the WTRU report. For example, Figure 8 As shown, the WTRU can use the following indications: 0000 represents beam 1, 0001 represents beam 2, 0010 represents beam 3, 0011 represents beam 4, 0100 represents beam 5, 0101 represents beam 6, 0110 represents beam 7, 0111 represents beam 8, and 1000 represents beam 9.

[0166] The network (e.g., serving gNB) may configure the WTRU with a periodic reporting configuration, for example, via higher layer signaling (e.g., RRC signaling). The reporting configuration may contain one or more parameters, including period, offset, etc. The WTRU may send the report as part of the uplink control information using an uplink control channel. The configuration of the uplink control channel resources (e.g., uplink channel format, time-frequency resources, etc.) may be configured to the WTRU, for example, as part of the reporting configuration.

[0167] In an embodiment, the WTRU may be configured to send a WTRU report indicating the WTRU Tx / Rx beam that the WTRU uses / selects to communicate with the network in a semi-persistent manner. The WTRU may be pre-configured with one or more reporting configurations, at least one (e.g., each) reporting configuration containing one or more parameters including periodicity, offset, uplink control channel parameters (e.g., format, time-frequency resources, etc.), reporting configuration ID, etc., using higher layer signaling (e.g., RRC signaling). The WTRU may activate reporting, for example, when the WTRU receives a downlink MAC-CE or downlink control information containing a reporting configuration ID that the WTRU needs to use. In an embodiment, the WTRU may be pre-configured with one or more reporting configurations, at least one (e.g., each) reporting configuration containing one or more parameters including periodicity, offset, reporting configuration ID, etc., using higher layer signaling (e.g., RRC signaling). The WTRU may activate reporting, for example, when the WTRU receives a downlink control information (e.g., DCI 01) containing a reporting configuration ID that the WTRU needs to use. The downlink control information (DCI) may be scrambled with the WTRU's radio network temporary identifier (RNTI) (e.g., C-RNTI), or a new RNTI may be used for this purpose, such as the semi-persistent WTRU beam information RNTI (SP-UBI-RNTI), which the WTRU may use to descramble the DCI. The DCI may contain the time-frequency resource allocation information used by the WTRU to send reports. In an embodiment, when the WTRU receives a command to disable / terminate reporting from the network, the WTRU may stop sending periodic reports. For example, the command to disable / terminate reporting may be received in a downlink MAC-CE or DCI.

[0168] In an embodiment, the WTRU may be configured to send a WTRU report indicating the WTRU Tx / Rx beam that the WTRU uses / selects to communicate with the network in an aperiodic manner. The WTRU may send a report, for example, when the WTRU receives downlink control information (e.g., DCI 01) indicating that a WTRU report is required. The DCI may be scrambled with the WTRU's RNTI (e.g., C-RNTI), or a new RNTI may be used for this purpose, such as the Aperiodic WTRU Beam Information RNTI (A-UBI-RNTI), which may be used by the WTRU to descramble the DCI. The DCI may contain time-frequency resource allocation information for the WTRU to send the report.

[0169] In an embodiment, the reporting configuration may be antenna panel specific. In the case where the WTRU supports multiple antenna panels, the WTRU may be configured with a reporting configuration for at least one (e.g., each) antenna panel. In an embodiment, the WTRU may be configured to send an uplink indication (e.g., using uplink control information, RRC signaling, or uplink MAC-CE message) when any change occurs to the antenna panel that the WTRU uses / selects to communicate with the network (e.g., serving gNB). In an embodiment, the uplink indication may include information of the antenna panel (e.g., antenna panel identification) if other information (e.g., angular coverage of the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth) of any (e.g., each) antenna panel) has been sent by the WTRU to the network (e.g., serving gNB), for example, as part of the WTRU capabilities. In an embodiment, the WTRU may send the antenna panel identification, the angular coverage of any (e.g., each) antenna panel, and / or the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth) to the serving gNB upon any change in the antenna panel that the WTRU uses / selects to communicate with the serving gNB. After sending this indication, the WTRU may receive a new / reconfigured reporting configuration (e.g., for periodic or semi-persistent reporting), such as when the WTRU is not already configured with a reporting configuration for the reported antenna panel.

[0170] For all different types of reporting mechanisms, the reporting can be configured to depend on the priority of the communication flow that the WTRU is exchanging with the network. This can be important because in some cases, the WTRU may be exchanging communication flows of different priorities. The priority can be either the logical channel priority from the MAC layer or a priority indication available from higher layers and passed to lower layers for use in the position reporting framework.

[0171] In various embodiments, the WTRU position indication may be provided based on the uplink SRS. This approach may be used when the SRS is used for uplink beam management, for example when the WTRU does not support beam mapping. In an embodiment, for at least one (e.g., each) antenna panel, the WTRU may be configured to assign a different SRS, such as an SRS ID, to each WTRU Tx beam. The association between the physical beam and the SRS ID may be configured for the WTRU. For example, referring to Figure 8 , beam 1 may be configured to use the lowest SRS ID, e.g. SRS ID 1, then beam 2 may be configured to use SRS ID 2, and so on. Based on the SRS selected by the gNB for communication (e.g., based on the uplink beam management process) and other information, the network may determine the WTRU orientation (e.g., which WTRU Tx beam the WTRU is using / selected). Other information may be any of the total number of beams supported by the WTRU (e.g., for the WTRU antenna panel being used for communication) and the association between the physical beams and the SRS IDs, where the total number of beams supported by the WTRU may be part of the WTRU capability information or may be derived from the maximum angular coverage, beam width information given in the WTRU capability information. The network may configure the association between the physical beams and the SRS IDs for any (e.g., each) antenna panel to the WTRU via higher layer signaling (e.g., RRC signaling) or system information.

[0172] In an embodiment, if the WTRU is configured with event, periodic, semi-persistent or non-periodic reporting to indicate the WTRU Tx beam used / selected to communicate with the serving gNB, the WTRU may use the SRS ID associated with that beam.

[0173] Based on the explicit or implicit indication of the WTRU Tx or Rx beam, the serving gNB (e.g., source gNB) may determine one or more candidate / potential cells / gNBs for CHO of the WTRU. Figure 8 , if the WTRU communicates with the serving gNB (e.g., gNB1) using beam 1, then gNB1 may configure gNB2, otherwise, if the WTRU communicates with gNB1 using beam 9, then gNB1 may configure gNB3 for CHO. The serving gNB may communicate with the selected candidate gNB to configure CHO. The serving gNB may receive confirmation and CHO configuration (e.g., containing PCI-ID, SSB to RACH resource mapping, CFRA related parameters, etc.) from the candidate gNB.

[0174] The serving gNB may send an RRC reconfiguration message containing the CHO configuration of the candidate gNB and the CHO execution conditions to the WTRU. The CHO execution conditions may contain reference signal information (e.g., reference signals to be measured, time-frequency resources, etc.). Thresholds need to be applied to derive switching conditions based on measurement results (e.g., measurement results based on A3 / A5 events). After the rotation, if one of the configured candidate gNBs enters the FoV of the WTRU antenna panel and if the CHO execution conditions are met based on the WTRU measurement results, the WTRU may be separated from the serving / source gNB and the WTRU may apply the given configuration of the selected candidate gNB to synchronize and switch to the selected gNB.

[0175] refer to Fig. 9 In an embodiment, a method performed by a WTRU to support a CHO procedure may include any of the following operations:

[0176] In step 1, the WTRU may send WTRU capability information to the serving gNB (e.g., gNB1), which may include the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth), the location of the antenna panels on the WTRU, etc.

[0177] In step 2, the WTRU may receive a reporting configuration for event-based reporting from the serving gNB, which includes the value of the edge beam N, the trigger time, the reporting format (e.g., how many bits are required, absolute and relative beam indications), uplink resource configuration, etc.

[0178] In step 3, under the condition that the WTRU uses one of the N edge beams of the antenna panel (the antenna panel currently used to communicate with the serving gNB) for the duration of the trigger time, the WTRU may send a report containing bit information associated with the beam to the serving / source gNB using a MAC-CE message.

[0179] In step 4, the WTRU may receive an RRC reconfiguration message from the serving gNB (e.g., gNB1), which contains the CHO configuration and CHO execution conditions of one or more candidate gNBs (e.g., gNB2).

[0180] In step 5, the WTRU may start evaluating the CHO execution conditions for the candidate gNBs (e.g., gNB2). If at least one candidate gNB satisfies the corresponding CHO execution conditions, the WTRU may detach from the source gNB (e.g., gNB1), apply the corresponding configuration stored for the selected candidate cell (e.g., gNB2), synchronize to the candidate gNB, and complete the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB (e.g., gNB2).

[0181] Apart from Fig. 9 In addition to the above steps shown in , the method may include any of the following operations:

[0182] Under the condition that the WTRU uses one of the N edge beams of the antenna panel and the channel quality measurement resource (DMRS, CSI-RS or SSB) associated with the DL transmission falls within the range configured for the WTRU, the WTRU may send a report containing bit information associated with the beam to the source gNB (e.g., gNB1) using a MAC-CE message;

[0183] The WTRU may be configured to send reports using uplink control information;

[0184] The WTRU may send the report using higher layer signaling (e.g., sending an RRC message);

[0185] The report may contain one bit of information to indicate that one of the N edge beams is being selected / used;

[0186] The report can contain 'ceil(log2(N))+1', where the most significant bit can be used to indicate the edge of the FoV and the remaining bits can be used to indicate the beam;

[0187] The report may contain the absolute WTRU beam ID, where the beam index format / mode may be conveyed;

[0188] The WTRU may be configured with a periodic reporting configuration to send the selected WTRU Tx / Rx beam using RRC signaling;

[0189] The WTRU may be configured to send reports in a semi-persistent manner to report the selected WTRU Tx / Rx beams using RRC and MAC-CE or DCI signaling;

[0190] The WTRU may be configured to send reports in an aperiodic manner to report the selected WTRU Tx / Rx beams using DCI signaling;

[0191] The WTRU may be configured with a reporting configuration for each antenna panel;

[0192] The WTRU may be configured to send an indication upon any change in the antenna panel that the WTRU uses / selects to communicate with the network.After sending the antenna panel change indication, the WTRU may receive a new reporting configuration for the new antenna panel.

[0193] In another embodiment, a method performed by a WTRU to support a CHO procedure may include any of the following operations:

[0194] The WTRU may send WTRU capability information including the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth), and / or the location of the antenna panels on the device, etc.

[0195] The WTRU may receive an association mechanism between the physical beam and the SRS ID for each antenna panel.

[0196] The WTRU may receive an RRC reconfiguration message from the serving gNB containing the CHO configuration and CHO execution conditions for one or more candidate gNBs.

[0197] The WTRU may start evaluating the CHO execution conditions for the candidate gNBs. If at least one of the CHO candidate gNBs satisfies the corresponding CHO execution conditions, the WTRU may detach from the source gNB, apply the stored corresponding configuration of the selected candidate cell, synchronize to the candidate gNB and complete the RRC handover process by sending an RRCReconfigurationComplete message to the target gNB.

[0198] In addition to the above operations, the method may also include any of the following operations:

[0199] The WTRU may be configured to transmit the SRS-ID of the WTRU beam used for communication with the serving / source gNB;

[0200] The WTRU may be configured to send the SRS-ID of the WTRU beam used for communication with the serving / source gNB as an event-based reporting, where an event may be defined as when the WTRU selects / uses one of the N edge beams;

[0201] The WTRU may be configured to send reports using MAC-CE or uplink control information or RRC signaling;

[0202] The WTRU may be configured with a periodic reporting configuration to send the SRS-ID of the selected WTRU Tx / Rx beam using RRC signaling;

[0203] The WTRU may be configured to send reports in a semi-persistent manner to report the SRS-ID of the selected WTRU Tx / Rx beam using RRC and MAC-CE or DCI signaling;

[0204] The WTRU may be configured to send reports in an aperiodic manner to report the SRS-ID of the selected WTRU Tx / Rx beam using DCI signaling;

[0205] The WTRU may be configured to send an indication upon any change in the antenna panel that the WTRU uses / selects to communicate with the network.After sending the antenna panel change indication, the WTRU may receive a new reporting configuration for the new antenna panel.

[0206] The following embodiments relate to a scenario where the WTRU rotates and the angular coverage or FoV of the WTRU antenna panel may have new gNB / gNBs that were not in the FoV of the WTRU antenna panel before the WTRU rotated.

[0207] Due to the lack of WTRU measurement reports associated with these gNBs, the source gNB may not be able to configure the WTRU with handover configurations for the gNBs / gNBs available in the updated FoV after the WTRU's rotation. Therefore, after a sudden WTRU rotation (e.g., or blocking), the source gNB may not be able to initiate the handover procedure in a timely manner based on the latest measurement reports. Without handover assistance from the source gNB, the WTRU may need to wait for the source gNB to recover from the outage or declare RLF even if there are potential target gNBs with good channel quality (e.g., above a threshold). In this case, the channel quality of the source gNB may deteriorate (e.g., below a threshold) due to the WTRU rotational motion, and since there are no other gNBs (e.g., with good channel quality, e.g., channel quality above a threshold) configured for handover, the WTRU may perform a beam failure detection procedure to declare that the channel quality of the current gNB beam of the source gNB is poor (e.g., below a threshold), and may perform a beam failure recovery procedure to determine another suitable gNB beam. If the channel quality does not recover (e.g., above a threshold) during the beam failure detection and recovery procedures, the WTRU may declare RLF. In fact, both beam failure / recovery and radio link procedures will be started at the WTRU according to the configuration parameters, and the WTRU can declare the events to the higher layers accordingly.

[0208] When the source gNB is out of the FoV of the WTRU antenna panel, the channel quality may deteriorate (e.g., below a threshold). This condition may continue to deteriorate until the source gNB enters the FoV of the WTRU antenna panel again. Therefore, when the source gNB is out of the FoV of the WTRU antenna panel, the long beam failure detection and recovery process declaring RLF may unnecessarily increase the outage duration.

[0209] In an embodiment, the parameters of the beam failure detection and recovery process based on the WTRU orientation are dynamically adjusted. The WTRU may be configured to send information about its capabilities (e.g., WTRU capabilities) to the network (e.g., serving / source gNB), the information including one or more parameters including the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth), the location of the antenna panels on the WTRU, etc. The total number of beams that can be formed within the FoV of the antenna panel may be provided in the WTRU capability information or may be derived using the beamwidth and angular coverage information. Angular coverage information in azimuth and elevation dimensions may be provided to the network. The location (e.g., 2D or 3D coordinates) of the (e.g., other) antenna panels may be provided relative to the antenna panel used / selected to communicate with the network (e.g., serving gNB). Alternatively, the absolute location relative to the center of the device may be provided in 2D or 3D coordinates or named directions such as north, southeast, etc. The WTRU capability information may be sent using higher layer signaling (eg, RRC uplink message). In another example, the WTRU capability information may be sent as uplink control information on a control channel (eg, PUCCH).

[0210] The WTRU may receive a beam failure detection configuration from the network (e.g., a serving / source gNB). The beam failure detection configuration may contain one or more parameters. The WTRU may be configured with multiple beam failure detection configurations, each configuration containing one or more parameters with different values ​​compared to the other configurations, and may have an identifier, such as a beam failure detection configuration ID (or a radio link monitoring configuration ID, if the beam failure configuration is included in the radio link monitoring configuration). In an embodiment, the WTRU may also receive an association / mapping between a beam failure detection configuration and each or a group of WTRU beams (e.g., WTRU Tx / Rx beams).

[0211] In an embodiment, a beam failure maximum count (e.g., beamFailureInstanceMaxCount) value (e.g., the maximum number of beam failure instances for triggering a beam failure receiver) may be associated with a selected WTRU's Tx / Rx beam. A different / separate beam failure maximum count value may be configured for each or a group of WTRU beams. For example, referring to Figure 8 , the edge beams (e.g., beam 1, beam 2, beam 8, beam 9) may be configured with a smaller beam failure maximum count value (e.g., beamFailureInstanceMaxCount=2) than the values ​​assigned to the center beams (e.g., beam 5 and beam 6) (e.g., beamFailureInstanceMaxCount=8). This is because when the WTRU uses / selects one of the edge beams to communicate with the serving / source gNB, the source gNB may be out of FoV range if the WTRU rotates and the channel quality deteriorates; therefore, the lower the beam failure maximum count value, the faster the beam failure detection may be. Beams may be grouped and may be assigned the same beam failure maximum count value. Alternatively, each beam may be assigned a different / separate beam failure maximum count value. The WTRU may use the relevant value of the beam failure maximum count based on the selected WTRU Tx / Rx beam before losing connectivity with the serving gNB. This loss of connectivity may be a result of WTRU rotation or some other external environmental factors. If the WTRU switches the WTRU Tx / Rx beam, the WTRU may use the beam failure maximum count associated with the new WTRU Tx / Rx when the WTRU performs the beam failure detection procedure.

[0212] In an embodiment, the value of the beam failure detection timer (e.g., beamFailureDetectionTimer) may be associated with the Tx / Rx beam of the selected WTRU. A different / separate beam failure detection timer value may be configured for each or a group of WTRU beams. For example, referring to Figure 8 , the edge beams (e.g., beam 1, beam 2, beam 8, beam 9) may be configured to have a smaller (or higher) beam failure detection time value (e.g., beam Failure Detection Timer = 1) compared to the values ​​assigned to the center beams (e.g., beam 5 and beam 6) (e.g., beam Failure Detection Timer = 10). Assigning / determining a smaller value to the edge beams may enable the WTRU to complete the beam failure detection process faster when the serving / source gNB moves out of the FoV of the WTRU antenna panel (e.g., due to WTRU rotation), and this may help declare RLF faster. Beams may be grouped and may be assigned the same beam failure detection time value. Alternatively, a different / separate beam failure detection time value may be assigned / determined for each beam. The WTRU may use a relevant value for the beam failure detection time based on the selected WTRU Tx / Rx beam. If the WTRU switches the WTRU Tx / Rx beam, the WTRU may use the beam failure detection time associated with the new WTRU Tx / Rx when the WTRU performs the beam failure detection procedure.

[0213] The network (e.g., serving / source gNB) may provide a beam failure detection configuration having one or more parameters associated with the WTRU's Tx / Rx beams to the WTRU via higher layer signaling (e.g., RRC signaling, system information, MAC-CE, or DCI).

[0214] refer to Fig.10 , shows an embodiment of a beam failure detection process based on a WTRU Tx / Rx beam, where different beam failure maximum count values ​​and beam failure detection timer values ​​are given for center and edge WTRU beams. Based on the selected WTRU beam, the WTRU can determine the appropriate configuration for the beam failure detection process.

[0215] In an embodiment, the value of the out-of-sync threshold (e.g., Q_out_LR) used as a quality threshold for determining a beam failure instance may be associated with a Tx / Rx beam selected by the WTRU. As a non-limiting example, a beam failure instance may be declared when the quality of a downlink control channel (e.g., RSSI / RSRP) used to monitor beam quality is below an out-of-sync threshold. One or more out-of-sync thresholds may be configured for one or more Tx / Rx beams of the WTRU. For example, with respect to a beam assigned to a center beam (e.g., Figure 8 Compared with the values ​​of beams 5 and 6 in the figure, the edge beams (for example, Figure 8 1, Beam 2, Beam 8, Beam 9 in the WTRU antenna panel). This is to enable the WTRU to complete the beam failure detection procedure faster when the serving / source gNB is out of the FoV range of the WTRU antenna panel (e.g. due to WTRU rotation), and this can help declare RLF faster. The network (e.g., serving / source gNB) may configure the out-of-sync threshold and its association with the WTRU Tx / Rx beams to the WTRU through, for example, higher layer signaling (e.g., RRC signaling), MAC-CE, DCI, or system information.

[0216] In an embodiment, the WTRU may be configured with multiple radio link failure detection configurations, each configuration containing one or more parameters (e.g., timer T310, timer 312, constant N310, etc.) whose values ​​are different from other configurations. The WTRU may have an identification, such as a radio failure detection configuration ID (or a radio link monitoring configuration ID if the radio link failure configuration is included in the radio link monitoring configuration). In an embodiment, the WTRU may also receive an association / mapping between a radio link failure detection configuration and each or a group of WTRU beams (e.g., WTRU Tx / Rx beams).

[0217] In an embodiment, the value of counter N310 (e.g., the maximum number of consecutive instances in which a link is declared out of sync (e.g., link quality is below a threshold)) may be associated with the Tx / Rx beam of the selected WTRU. In an embodiment, the value of timer T310 (which is triggered after receiving N310 consecutive out-of-sync indications for the link with the source gNB, and after its expiration, the WTRU declares a radio link failure) may be associated with the Tx / Rx beam of the selected WTRU. In an embodiment, the value of timer T312 may be associated with the Tx / Rx beam of the selected WTRU. For example, referring to Figure 8 , N310, T310, or / and T312 for edge beams (e.g., beam 1, beam 2, beam 8, beam 9) may be configured to have smaller values ​​than those assigned to center beams (e.g., beam 5 and beam 6). This is because when the WTRU uses / selects one of the edge beams to communicate with the serving / source gNB, the source gNB may be out of FoV if the WTRU rotates and the channel quality deteriorates; therefore, using smaller values ​​for N310, T310, or / and T312, radio link failure detection may be faster.

[0218] In an embodiment, when the WTRU is configured with multiple beams or / and radio link failure detection configurations, and in the event that the WTRU switches its Tx / Rx beams and determines to switch beams or radio link failure detection configurations (e.g., to start using a configuration that is different from the previous configuration) (where the configuration difference relative to the previous configuration may be, for example, in one of beam failure maximum count, beam failure timer, out-of-sync threshold, etc.), the WTRU may send an indication to the network (e.g., serving / source gNB). The indication may include the ID of the beam or radio link failure detection configuration that the WTRU determined to switch. In an embodiment, the indication may include the parameters that the WTRU determined to switch (e.g., beam failure maximum count, beam failure detection timer, out-of-sync threshold, N310 constant, T310 timer, T312 timer, etc.) and their values ​​(e.g., new values). The WTRU may be configured to send the indication to the network via MAC-CE or RRC signaling or as uplink control information.

[0219] In an embodiment, the WTRU may be pre-configured with multiple beams or / and radio link failure detection configurations (e.g., each configuration may be identified by an ID and may have one or more parameters associated with one or more Tx / Rx beams of the WTRU that have different values ​​than other configurations), and only one configuration may be activated initially. The network may provide the pre-configured and activated configurations to the WTRU through, for example, higher layer signaling (e.g., RRC signaling or system information). The WTRU may be configured to perform event-based reporting for one of its selected edge beams. In an embodiment, the WTRU may be configured to send a periodic, semi-persistent, or aperiodic report containing the WTRU Tx / Rx beam information to the WTRU. The network (e.g., serving / source gNB) may determine to configure different beams or / and radio link failure detection configurations based on the WTRU's Tx / Rx beam selection. After sending such a report, the WTRU may receive an activation command, for example, using RRC signaling, a MAC-CE command, or a DCI, containing the beam or / and radio link failure detection configuration ID to be activated. Upon receiving the activation command, the WTRU may deactivate the previous configuration and start using the latest received beam and / or radio link failure detection configuration.

[0220] In an embodiment, the WTRU may initially be configured with one beam or / and radio link failure detection configuration, for example, through higher layer signaling (e.g., RRC signaling) or system information. The WTRU may be configured for event-based reporting for one of its selected edge beams. In an embodiment, the WTRU may be configured to send periodic, semi-persistent, or aperiodic reports to the WTRU containing the WTRU Tx / Rx beam information. The network (e.g., serving / source gNB) may determine to configure different beam failure detection configurations based on the WTRU's Tx / Rx beam selection. After sending such reports, the WTRU may receive another (e.g., new) beam or / and radio link failure detection configuration from the network, for example, using RRC signaling, MAC-CE command, or DCI, containing values ​​for parameters (e.g., beam failure maximum count, beam failure detection timer, N310 constant, T310 timer, T312 timer, etc.). Upon receiving the new beam or / and radio link failure detection configuration, the WTRU may start using the configuration.

[0221] In an embodiment, when SRS is used for uplink beam management, for example, when the WTRU does not support beam correspondence, the WTRU may be configured to allocate a different SRS, such as an SRS ID, to each WTRU Tx beam, and the association between the physical beam and the SRSID may be configured to the WTRU.

[0222] Based on the SRS selected by the gNB for communication (e.g., based on the uplink beam management procedure) and other information, the network may determine the WTRU position (e.g., which WTRU Tx beam the WTRU is using / selected). Other information may include the total number of beams supported by the WTRU (e.g., the WTRU antenna panel being used for communication), which may be part of the WTRU capability information or may be derived from the maximum angular coverage and beamwidth information given in the WTRU capability information. In addition, the WTRU position may be determined based on the SRS selected by the gNB for communication, other information, and the association between the physical beam and the SRS ID.

[0223] The network may configure the WTRU with the association between the physical beam and the SRS ID for any (e.g., each) antenna panel via higher layer signaling (e.g., RRC signaling or system information). In an embodiment, the WTRU may be configured to perform event-based reporting for one of its selected edge beams, where the WTRU may use the SRS-ID of the associated reporting beam. Based on the network (e.g., serving / source gNB) determining the WTRU position using the selected SRS ID or WTRU report, the network (e.g., serving / source gNB) may dynamically configure the WTRU with the appropriate beam failure detection configuration based on the WTRU beam associated with the SRS ID. The beam or / and radio link failure detection configuration may be dynamically sent to the WTRU using, for example, MAC-CE, DCI, or RRC signaling. Upon receiving the new beam or / and radio link failure detection configuration, the WTRU may begin using the configuration.

[0224] In an embodiment, the beam or / and radio link failure detection configuration may be antenna panel specific. In the case where the WTRU supports multiple antenna panels, the WTRU may be configured with a beam or / and radio link failure detection configuration for any (e.g., each) antenna panel. In one example, the WTRU may be configured to send an uplink indication (e.g., using uplink control information, RRC signaling, or uplink MAC-CE message) when any change occurs to the antenna panel that the WTRU uses / selects to communicate with the network (e.g., serving gNB). In an embodiment, if other information (e.g., angular coverage of any (e.g., each) antenna panel, maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth)) may have been sent by the WTRU to the network (e.g., serving gNB), for example as part of the WTRU capabilities, the uplink indication may include information of the antenna panel (e.g., antenna panel identification). In another example, the WTRU may send the antenna panel identification, the angular coverage of any (e.g., each) antenna panel, or / and the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3 dB or half-power beamwidth) to the serving gNB when any change occurs to the antenna panel used / selected by the WTRU to communicate with the serving gNB. After sending this indication, the WTRU may receive new / reconfigured beams or / and radio link failure detection configurations, for example, including multiple configurations associated with different WTRU Tx / Rx beams, for example, when the WTRU is not yet configured with the beams or / and radio link failure detection configurations of the reported antenna panel.

[0225] In an embodiment, a method performed by a WTRU to support a beam failure detection procedure may include at least one of the following actions:

[0226] The WTRU can send WTRU capability information to the network, which includes the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth) and / or the location of the antenna panels on the WTRU, etc.

[0227] The WTRU may receive one or more beam failure detection configurations from the network, at least one (e.g., each) beam failure detection configuration comprising an ID and different / independent values ​​of one or more parameters associated with one or more Tx / Rx beams of the WTRU.

[0228] When the WTRU's beam changes with the same antenna panel and the same serving / source gNB, the WTRU may determine the beam failure detection configuration to use based on the selected WTRU beam and the given configuration.

[0229] If the beam failure configuration is different from the previously selected configuration, the WTRU may send a WTRU indication containing a beam failure detection configuration ID to the network.

[0230] Refer to the above method:

[0231] The indication may include parameters (e.g., beam failure maximum count, beam failure detection timer, out-of-sync threshold, etc.) for which the WTRU may determine switching and their values ​​(e.g., new values).

[0232] The WTRU can receive an association between a beam failure detection configuration and a WTRU beam: in the beam failure detection configuration, the value of the beam failure detection maximum count can be associated with a WTRU beam or a group of WTRU beams; in the beam failure detection configuration, the value of the beam failure detection timer can be associated with a WTRU beam or a group of WTRU beams; in the beam failure detection configuration, the value of the desynchronization threshold can be associated with a WTRU beam or a group of WTRU beams.

[0233] The WTRU can be configured with multiple beam failure detection configurations, where one configuration is initially activated: the WTRU can be configured to report (based on an event, periodic, semi-persistent or non-periodic when the WTRU starts using one of the N edge beams) its selected Tx / Rx beam; the WTRU can be configured to activate the beam failure detection configuration based on its reporting of the WTRU Tx / Rx beam.

[0234] The WTRU can be configured with an association mechanism between the physical beam and SRS ID for each antenna panel: the WTRU can use the SRS ID to report the WTRU beam (if configured); the WTRU can receive a beam failure detection configuration when any change occurs to the WTRU beam and the network determines to change the configuration based on the WTRU beam change detected by it using the SRS ID.

[0235] The WTRU may be configured with a beam failure detection configuration for any (eg, each) antenna panel.

[0236] The WTRU may be configured to send an indication upon any change in the antenna panel that the WTRU uses / selects to communicate with the network: after sending the antenna panel change indication, the WTRU may receive a new beam fault detection configuration (and its association with the WTRU beam) for the new antenna panel.

[0237] In an embodiment, a method performed by a WTRU to support a link failure detection procedure may include at least one of the following actions:

[0238] The WTRU may send capability information to the network that includes, among other things, the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth), and / or the location of the antenna panels on the device.

[0239] The WTRU may receive one or more radio link failure detection configurations from the network, at least one (eg, each) radio link failure detection configuration comprising an ID, and different / independent values ​​of one or more parameters associated with one or more Tx / Rx beams of the WTRU.

[0240] When the WTRU's beam changes while the antenna panel and the serving / source gNB are the same, the WTRU may determine the radio link failure detection configuration to use based on the selected WTRU beam and the given configuration.

[0241] If the radio link failure configuration is different from the previously selected configuration, the WTRU may send an indication to the network containing a beam failure detection configuration ID.

[0242] Refer to the above method:

[0243] The indication may include parameters (e.g., N310 constant, T310 timer, T312 timer, etc.) and their values ​​(e.g., new values) by which the WTRU may determine the handover;

[0244] The WTRU may receive an association between a radio link failure detection configuration and a WTRU beam: In the radio link failure detection configuration, the values ​​of N310, T310 or / and T213 may be associated with a WTRU beam or a group of WTRU beams.

[0245] The WTRU can be configured with multiple radio link failure detection configurations, of which one configuration is initially activated: the WTRU can be configured to report (based on an event, periodic, semi-persistent or non-periodic when the WTRU starts using one of the N edge beams) its selected Tx / Rx beam; the WTRU can be configured to activate the radio link failure detection configuration based on its reporting of the WTRU Tx / Rx beam.

[0246] The WTRU can be configured with an association mechanism between the physical beam and SRS ID for each antenna panel: the WTRU can use the SRS ID to report the WTRU beam (if configured); the WTRU can receive the radio link failure detection configuration when any change occurs to the WTRU beam and the network determines to change the configuration based on the WTRU beam change detected by it using the SRS ID.

[0247] The WTRU may be configured with a radio link failure detection configuration for each antenna panel.

[0248] The WTRU may be configured to send an indication when any change occurs to the antenna panel that the WTRU uses / selects to communicate with the network: after sending the antenna panel change indication, the WTRU may receive a new radio link failure detection configuration (and its association with the WTRU beam) for the new antenna panel.

[0249] In various embodiments, information locally available to the WTRU device about its mobility may be used to optimize the beam failure detection process.

[0250] In an embodiment, the WTRU may be equipped with a gyroscope. Many smartphones and wearable devices are currently equipped with such gyroscopes. These gyroscopes can provide the WTRU with an indication of its rotation amount and direction in terms of clockwise or counterclockwise rotation. Prior to the rotation event, if this WTRU is connected to its serving / source gNB via one of its edge beams and has received the rotation amount and direction from the gyroscope, the WTRU can determine whether this rotation will change the WTRU FoV to move out of the coverage of its serving gNB. After determining to be out of coverage of its last serving gNB, the WTRU may shorten the beam failure detection procedure. The configuration parameters to be adopted when the WTRU determines to be out of coverage may be configured via the static or dynamic configuration described earlier in this embodiment. In an extreme case, the WTRU may be configured with zero wait beam failure detection (e.g., after determining to be out of coverage, the WTRU may declare BFD with zero delay).

[0251] In an embodiment, the WTRU may declare a radio link failure with zero delay after determining that the WTRU is out of coverage of its source gNB.

[0252] The rotation information is not necessarily available locally at the WTRU. The WTRU may receive information about its rotation through different mechanisms. This may come from different radio interfaces that the WTRU may be equipped with and may be calculated from other positioning / localization signals that may be available. Similarly, the availability of local or external measurements of departure angle, arrival angle, etc. may be used to determine the amount of rotation performed by the WTRU, which can then be used to speed up the beam failure or link failure process, which in turn allows the WTRU to find a suitable neighboring beam / gNB faster and reduce outage time.

[0253] Faster beam or radio link failure detection or short-circuiting of the beam failure detection (BFD) process may not be limited to WTRUs using one of the edge beams. Even if the WTRU is connected to its serving / source gNB through one of its middle beams, a large rotation event may cause this WTRU to go out of the coverage of its serving gNB. To cover such practical situations, after a rotation event, the WTRU may be configured to evaluate whether the current rotation will result in a loss of coverage. This evaluation may use information such as the WTRU FoV parameters, the last serving beam before the rotation event, and the rotation. This may enable the WTRU to determine its in-coverage or out-of-coverage status with minimal latency. This is actually even faster than the time required for a single measurement of the SSB or CSI-RS. For some WTRUs / devices with a large number of rotation events or limitations in computational complexity due to energy consumption or hardware availability, it may not be possible to evaluate the in-coverage / out-of-coverage status after each rotation. This process can be simplified by adjusting such evaluation if the WTRU is connected to the serving gNB through one of its N edge beams (N is a configuration parameter), or if the rotation amount exceeds (e.g., exceeds) the configured rotation threshold, or both.

[0254] In an embodiment, a method performed by a WTRU to support a beam failure detection procedure may include at least one of the following actions:

[0255] The WTRU can send WTRU capability information to the network, which includes the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth) and / or the location of the antenna panels on the WTRU, etc.

[0256] The WTRU may receive a beam failure detection configuration from the network as well as an indication / flag as to whether the WTRU is allowed to speed up the beam failure detection process based on the rotation information available on the WTRU side.

[0257] In the event that the source gNB / active beam experiences a degradation in quality, the WTRU may utilize the previous coverage status of its active beam and the amount of rotation it has undergone to evaluate / determine its current coverage status. If the rotation causes the WTRU to be out of the previous FoV, the WTRU may use specific configuration parameters configured for beam failure detection with the source gNB to estimate the situation in which it is out of FoV and subsequently initiate a beam failure recovery procedure.

[0258] Follow the above method:

[0259] The WTRU may have received configuration parameters or indications so that when it determines to be out of the previous FoV, it declares beam failure with zero delay and initiates the beam recovery procedure.

[0260] After a rotation event, when it is determined to be out of the previous FoV, the WTRU may initiate a radio link failure procedure using the configured acceleration parameters.

[0261] The WTRU may receive an indication / flag from the network as to whether the WTRU is allowed to declare radio link failure detection based on the rotation information available on the WTRU side: When the source gNB moves out of the field of view based on the rotation information available to the WTRU, the WTRU may declare radio link failure detection with the source gNB.

[0262] The WTRU may be configured to send information about its capabilities (e.g., WTRU capabilities) to the network (e.g., serving gNB), the information including one or more parameters including the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3 dB or half-power beamwidth), the location of the antenna panels on the WTRU, etc. The total number of beams that can be formed within the FoV of the antenna panels may be provided in the WTRU capability information or may be derived using the beamwidth and angular coverage information. Angular coverage information in azimuth and elevation dimensions may be provided to the network. The location (e.g., 2D or 3D coordinates) of the (e.g., other) antenna panels may be provided relative to the antenna panels used / selected to communicate with the network (e.g., serving gNB). Alternatively, the absolute location relative to the center of the device may be provided, expressed as 2D or 3D coordinates or in named directions such as North, Southeast, etc. The WTRU capability information may be sent using higher layer signaling (e.g., RRC uplink messages). In an embodiment, the WTRU capability information may be sent as uplink control information via a control channel (eg, PUCCH).

[0263] The WTRU may receive a beam failure recovery configuration from the network (e.g., serving / source gNB). The beam failure recovery configuration may contain one or more parameters. The WTRU may be configured with multiple beam failure recovery configurations, each configuration containing one or more parameters having different values ​​compared to the other configurations, and may have an identification, such as a beam failure recovery configuration ID. In an embodiment, the WTRU may also receive an association / mapping between a beam failure recovery configuration and a WTRU beam (e.g., a WTRU Tx / Rx beam).

[0264] In an embodiment, the value of a beam failure recovery timer (e.g., beamFailureRecoveryTimer) may be associated with the Tx / Rx beam of the selected WTRU. The value of the beam failure recovery timer may include a timer for beam failure recovery, after which the WTRU may not use contention-free random access to establish a connection with the serving / source gNB.

[0265] Different / individual beam failure recovery timer values ​​may be configured for any (e.g., each) or a group of WTRU beams. Figure 8 , the edge beams (e.g., beam 1, beam 2, beam 8, beam 9) may be configured with a smaller beam failure recovery timer value (e.g., beam Failure Recovery Timer = 10 ms) compared to the values ​​assigned to the center beams (e.g., beam 5 and beam 6) (e.g., beam Failure Recovery Timer = 80 ms). This is because when the WTRU uses / selects one of the edge beams to communicate with the serving / source gNB, if the WTRU rotates and the channel quality deteriorates, the source gNB may be out of the FoV range. Therefore, the lower the value of the beam failure recovery timer, the less time it takes for the beam failure to recover and the earlier the radio link failure can be declared. The beams may be grouped and the same beam failure recovery timer value may be assigned. Alternatively, a different / separate beam failure recovery timer value may be assigned to each beam. The WTRU may use a relevant value for the beam failure recovery timer based on the selected WTRU Tx / Rx beam. If the WTRU switches WTRU Tx / Rx beams, the WTRU may use the beam failure recovery timer associated with the new WTRU Tx / Rx when performing the beam failure recovery procedure.

[0266] In an embodiment, the configuration of the random access procedure used to perform beam failure recovery (e.g., configured in the RRC information element RACH-ConfigGeneric) may be associated with the Tx / Rx beam of the selected WTRU. A different / separate random access procedure configuration may be configured for any (e.g., each) or a group of WTRU beams. For example, the configuration of the random access procedure may be configured such that the beam failure recovery procedure for the edge WTRU beam may be shortened compared to the center WTRU beam. For example, the total number of preambles used for random access may be configured based on the WTRU's beam. For example, reference may be made to FIG. 10A to FIG. 10B . Figure 8, the edge beams (e.g., Beam 1, Beam 2, Beam 8, Beam 9) may be configured to have a smaller total number of preambles compared to the values ​​assigned to the center beams (e.g., Beam 5 and Beam 6). In an embodiment, different time-frequency resource values, such as the number of SSBs per RACH occasion or / and the number of preambles per SSB (e.g., based on contention), may be configured based on the beam of the WTRU. In an embodiment, different power boost step values ​​or / and scaling factors for the backoff indicator may be configured based on the beam of the WTRU. Based on the selected WTRU Tx / Rx beam, the WTRU may perform beam failure recovery using the associated random access configuration. If the WTRU switches the WTRU Tx / Rx beam, the WTRU may use the random access configuration associated with the new WTRU Tx / Rx when the WTRU performs the beam failure recovery procedure.

[0267] In an embodiment, the value of the threshold (e.g., RSRP threshold (rsrp-ThresholdSSB)) used to determine whether a beam is a candidate beam (e.g., when received signal quality RSRP>Threshold) to perform beam failure recovery may be associated with the Tx / Rx beam of the selected WTRU. Different / separate thresholds may be configured for any (e.g., each) or a group of WTRU beams.

[0268] In an embodiment, a maximum value of the duration (e.g., maximum beam search timer) may be configured for the WTRU (e.g., by the network (e.g., serving / source gNB)) to search for candidate beams (e.g., received signal quality, e.g., RSRP / RSSI is above a threshold) during the beam recovery process. The WTRU may be configured to declare a radio link failure if a timer (e.g., maximum beam search timer) expires, e.g., the WTRU may be unable to determine a candidate beam for the serving / source gNB before the time expires. Different / separate timer (e.g., maximum beam search timer) values ​​may be configured for any (e.g., each) or a group of WTRU beams. For example, referring to Figure 8 , the edge beams (eg, beam 1, beam 2, beam 8, beam 9) may be configured to have smaller timer values ​​than the values ​​assigned to the center beams (eg, beam 5 and beam 6).

[0269] In an embodiment, a combined (e.g., single) timer (e.g., maximum overall beam failure recovery timer) may be configured for the WTRU, which may take into account both the candidate beam search and the random access procedure. The WTRU may be configured to declare a radio link failure if a timer (e.g., maximum overall beam failure recovery timer) expires, e.g., the WTRU may not be able to determine the candidate beams for the serving / source gNB and complete the RACH procedure before the time expires. Different / separate timer values ​​(e.g., maximum overall beam failure recovery timer) may be configured for any (e.g., each) or a group of WTRU beams. For example, referring to Figure 8 , the edge beams (eg, beam 1, beam 2, beam 8, beam 9) may be configured to have smaller timer values ​​than the values ​​assigned to the center beams (eg, beam 5 and beam 6).

[0270] The network (e.g., serving / source gNB) may provide a beam failure recovery configuration having one or more parameters (e.g., one or more of a beam failure recovery timer, a random access procedure configuration, an RSRP threshold, a maximum beam search timer, and / or a maximum overall beam failure recovery timer, etc.) associated with the WTRU's Tx / Rx beam to the WTRU via higher layer signaling (e.g., RRC signaling, system information, MAC-CE, or DCI).

[0271] In an embodiment, for example, when the WTRU is configured with multiple beam failure recovery configurations, and in the event that the WTRU switches its Tx / Rx beams and determines to switch beam failure recovery configurations (e.g., to start using a different configuration than the previous one), the WTRU may send an indication to the network (e.g., serving / source gNB). The configuration difference relative to the previous configuration may be, for example, one of a beam failure recovery timer, a random access procedure configuration, an RSRP threshold, a maximum beam search timer, or / and a maximum overall beam failure recovery timer, etc. The indication may contain an ID of the beam failure detection configuration that the WTRU determines to switch. In an embodiment, the indication may contain the parameters that the WTRU may determine to switch (e.g., beam failure recovery timer, random access procedure configuration, RSRP threshold, maximum beam search timer, or / and a maximum overall beam failure recovery timer, etc.) and their values ​​(e.g., new values). The WTRU may be configured to send the indication to the network via MAC-CE or RRC signaling or as uplink control information.

[0272] In an embodiment, the WTRU may pre-configure multiple beam failure recovery configurations (e.g., each configuration may be identified by an ID and may have one or more parameters associated with one or more Tx / Rx beams of the WTRU that have different values ​​than other configurations), and initially only one configuration may be activated. The network may provide the pre-configured and activated configurations to the WTRU through, for example, higher layer signaling (e.g., RRC signaling or system information). The WTRU may be configured to perform event-based reporting for its selection of one of the edge beams. In another example, the WTRU may be configured to send a periodic, semi-persistent, or aperiodic report containing the WTRU Tx / Rx beam information to the WTRU. The network (e.g., serving / source gNB) may determine to configure different beam failure recovery configurations based on the WTRU's Tx / Rx beam selection. After sending such a report, the WTRU may receive an activation command, such as using RRC signaling, a MAC-CE command, or a DCI, containing the beam failure recovery configuration ID to be activated. Upon receiving the activation command, the WTRU may deactivate the previous configuration and start using the most recently received beam failure recovery configuration.

[0273] In an embodiment, the WTRU may be initially configured with a beam failure recovery configuration, for example, via higher layer signaling (e.g., RRC signaling or system information). After sending a report (e.g., event-based, periodic / semi-persistent / aperiodic), the WTRU may receive another (e.g., new) beam failure recovery configuration from the network, for example, using RRC signaling, MAC-CE command, or DCI, containing values ​​of parameters (e.g., beam failure recovery timer, RSRP threshold, RACH configuration, etc.). After receiving the new beam failure recovery configuration, the WTRU may start using the configuration.

[0274] In an embodiment, when SRS is used for uplink beam management and the WTRU is configured to allocate a different SRS (e.g., SRS ID) for each WTRU Tx beam and the association between the physical beam and the SRS ID can be configured to the WTRU, the network can determine the WTRU orientation (e.g., which WTRU Tx beam the WTRU is using / selected) based on the SRS selected for uplink transmission. The network can configure the association between the physical beam and the SRS ID for each antenna panel to the WTRU through higher layer signaling (e.g., RRC signaling or system information). Based on the network (e.g., serving / source gNB) determining the WTRU orientation using the selected SRS ID or WTRU report, the network (e.g., serving / source gNB) can dynamically configure the WTRU with an appropriate beam failure recovery configuration based on the WTRU beam associated with the SRS ID. The beam failure recovery configuration can be dynamically sent to the WTRU using, for example, MAC-CE, DCI, or RRC signaling. After receiving the new beam failure recovery configuration, the WTRU can start using the configuration.

[0275] In an embodiment, the beam failure recovery configuration may be antenna panel specific. The WTRU may provide an indication when any change occurs to the antenna panel used to communicate with the serving / source gNB, and if the configuration for the requested / reported antenna panel is not yet available at the WTRU (e.g., previously configured by the network), the WTRU may receive a (e.g., new / different / another) beam failure recovery configuration associated with the new antenna panel.

[0276] In an embodiment, a method performed by a WTRU to support a beam failure recovery procedure may include at least one of the following actions:

[0277] The WTRU can send WTRU capability information to the network, which includes the number of antenna panels, the (e.g., maximum) angular coverage of any (e.g., each) antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth (e.g., 3dB or half-power beamwidth) and / or the location of the antenna panels on the WTRU, etc.

[0278] The WTRU may receive one or more beam failure recovery configurations from the network, at least one (e.g., each) beam failure recovery configuration comprising an ID and different / independent values ​​of one or more parameters associated with one or more Tx / Rx beams of the WTRU.

[0279] When the WTRU’s beam changes while the antenna panel and the serving / source gNB are the same, the WTRU may determine the beam failure recovery configuration to be used based on the selected WTRU beam.

[0280] If the beam failure configuration is different from the previously selected configuration, the WTRU may send a WTRU indication to the network containing the beam failure recovery configuration ID.

[0281] Refer to the above method:

[0282] The indication may include parameters for the WTRU to determine switching (e.g., beam failure recovery timer, random access procedure configuration, RSRP threshold, maximum beam search timer, or / and maximum overall beam failure recovery timer) and their values ​​(e.g., new values).

[0283] The WTRU may receive an association between a beam failure recovery configuration and a WTRU beam: in the beam failure recovery configuration, a value of a beam failure recovery timer may be associated with a WTRU beam or a group of WTRU beams; in the beam failure recovery configuration, a value of an RSRP threshold for determining a candidate beam may be associated with a WTRU beam or a group of WTRU beams; in the beam failure recovery configuration, a value of one or more parameters in a RACH configuration (including a total number of preambles, a number of SSBs per RACH occasion, a number of preambles per SSB (e.g., based on contention), a power boost step size, a scaling factor of a backoff indicator) may be associated with a WTRU beam or a group of WTRU beams; in the beam failure recovery configuration, a value of a maximum beam search timer used as a maximum duration for searching for a candidate beam search may be configured and associated with a WTRU beam or a group of WTRU beams; in the beam failure recovery configuration, a value of a maximum overall beam failure recovery timer used as a maximum duration for searching for a candidate beam search and performing a RACH may be configured and associated with a WTRU beam or a group of WTRU beams.

[0284] The WTRU can be configured with multiple beam failure recovery configurations, where one configuration is initially activated: the WTRU can be configured to report (based on an event, periodic, semi-persistent or non-periodic when the UWTRU starts using one of the N edge beams) its selected Tx / Rx beam, and the WTRU can be configured to activate the beam failure recovery configuration based on its reporting of the WTRU Tx / Rx beams.

[0285] The WTRU can be configured with an association mechanism between the physical beam and SRS ID for each antenna panel: the WTRU can use the SRS ID to report the WTRU beam (if configured); the WTRU can receive beam failure recovery configuration when any change occurs to the WTRU beam and the network determines to change the configuration based on the WTRU beam change detected by it using the SRS ID.

[0286] The WTRU may be configured with a beam failure recovery configuration for each antenna panel.

[0287] The WTRU may be configured to send an indication when any change occurs to the antenna panel that the WTRU uses / selects to communicate with the network: after sending the antenna panel change indication, the WTRU may receive a new beam fault recovery configuration (and its association with the WTRU beam) for the new antenna panel.

[0288] To verify the performance gain of some of the various embodiments, a system-level simulation can be performed using a MATLAB-based discrete-time event simulator to evaluate the WTRU's connectivity with rotation. As a non-limiting example, a deployment scenario is considered where a 3-meter-tall gNB is deployed on a circle with a radius of 10 meters centered around the WTRU of interest at the center. Two different densities of gNBs are considered, where 4 and 8 gNBs are uniformly deployed on the circle and spaced 90 and 45 degrees apart, respectively. The average outage performance of the WTRU is calculated by running one hundred simulation iterations, where each iteration is equivalent to four hours of simulation time.

[0289] Multiple rotation speeds have been tested to observe trends. While more frequent rotations result in more frequent handovers, leading to worse overall performance, the results for only one setting are shown here. The average time between two consecutive rotations is set to 5 seconds. For each rotation, the angle is uniformly selected from the range of 15 to 75 degrees. The direction of rotation (e.g., clockwise or counterclockwise) is randomly selected with equal probability at each rotation. A multiple antenna array (AA) configuration is considered on the WTRU side, where the number of AAs ∈ {1,2,3}. Each AA is assumed to have a 90 degree field of view. In the case of multiple AAs, the AAs are assumed to be located adjacent to each other, so the total field of view range is 90 degrees, 180 degrees, and 270 degrees when the WTRU uses 1, 2, and 3 AAs, respectively. Deployment densities below 4 gNBs, which have coverage holes for UEs with a FoV range of 90 degrees, are not evaluated. The outage probability is calculated as 1-reliability, where reliability is defined as {time in connected state} / {total simulation time}.

[0290] refer to Fig.11, the performance of four different techniques are compared: (i) BFDR: Using this technique, the WTRU may perform a beam failure detection and recovery procedure once the link with the source gNB goes out of coverage due to a WTRU rotation. When the WTRU declares a radio link failure with the source gNB after completing beam failure detection and recovery, the WTRU may (e.g., only) be able to discover another gNB and establish a connection with that gNB; (ii) CHO: Using this technique, the source gNB may pre-configure the WTRU with handover configurations for candidate target neighboring gNBs available within the WTRU's field of view. When the WTRU is connected to the source gNB, the WTRU is able to perform measurements with those neighboring gNBs; (iii) BFDR–Rot.Enh: In this BFDR with rotation-specific enhancement, the WTRU may declare (e.g., send to the network) a link failure detection with the source gNB once the source gNB goes out of coverage due to a WTRU rotation. The WTRU may (e.g., immediately) start discovering other gNBs; (iv) CHO – Rot.Enh: In this CHO with rotation-specific enhancements, the WTRU may pre-configure handover configurations for target neighboring gNBs that may not be in the current field of view when the WTRU is connected to the source gNB, but may come into view after the WTRU rotates.

[0291] Fig.11 The WTRU connection performance in terms of outage probability and outage duration for the four techniques is shown, with a gNB discovery time of 50 ms, a connection establishment time of 20 ms, a beam failure detection duration of 20 ms, a beam failure recovery duration of 50 ms, and a CHO trigger / execution time of 20 ms. Fig.11 (a) and (b), CHO outperforms BFDR in both outage probability (a) and average outage duration (b) in each deployment scenario, as long as more gNBs can be discovered through increased deployment density or more advanced WTRU antenna array arrangements. Specifically, Fig.11 In (a), we observe that in the scenario with 8 gNBs and 3 AAs, the outage probability of CHO is one-third of that of BFDR. However, in the scenario with 4 gNBs and 1 AA, the performance of BFDR and CHO is the same because there is no candidate gNB that can be configured as the target of CHO.

[0292] refer to Fig.11(a), the outage probability is only slightly reduced when the deployment density is doubled from 4 gNBs to 8 gNBs. In cases where WTRU rotation is the main limitation of the system, increasing the deployment density is not beneficial as long as there are no coverage holes, because all gNBs change simultaneously after a rotation event. For example, after a large rotation event, once the source gNB is out of view, the WTRU may (e.g., only) establish a connection: i) after going through the BFDR process and declaring a radio link failure; or ii) if CHO is configured after the CHO trigger / execution time. Therefore, even if a new gNB is available, the WTRU may go through a time-consuming procedure before establishing a new connection. Increasing the number of AAs can help reduce the outage probability and average outage duration for both BFDR and CHO. A WTRU with multiple AAs can combine them to achieve a larger overall FoV. After a rotation event, the WTRU can coordinate between AAs to seamlessly maintain a connection to the same gNB, thereby improving performance. Specifically, in a 4 gNB CHO scenario, a WTRU with 2 AAs can achieve a five-fold lower outage probability and a 50 ms shorter average outage duration compared to a WTRU with a single AA. Similar improvements in outage probability are observed in other configurations. Although the average outage duration may not decrease further when going from 2 AAs to 3 AAs, outage events may become less frequent, resulting in an overall improvement in system performance.

[0293] Fig.11 (b) depicts the average outage duration for different numbers of AAs, handover methods, and deployment densities. Note that in all scenarios, the outage duration for BFDR is approximately 90 ms, which corresponds to the total time elapsed during the BFDR and connection establishment processes. Note that discovery can be handled in the background (e.g., during the BFDR process) as long as the gNB is within the WTRU's field of view. When there are 4 gNBs and 1 AA, the outage duration for CHO is approximately 90 ms, which corresponds to an outage duration similar to the BFDR case, as there is no possible CHO target gNB. Once a CHO target is available, CHO can achieve a shorter outage. In this case, the outage duration is significantly reduced to approximately 40 ms, which corresponds to the CHO execution / trigger time and the connection establishment time, where the CHO execution / trigger time may be the time when the failure is detected and CHO is triggered.

[0294] Fig.11(a) and (b) illustrate the benefits of the rotational mobility (e.g., specific) enhancement for BFDR and CHO. Once the enhancement is put into use, the fault detection time for both BFDR and CHO can be reduced. The BFDR can declare RLF and initiate connection establishment with the discovered gNB without long delays. Similarly, using the CHO target configuration based on the WTRU orientation, CHO can be performed after the WTRU rotation without long delays during the radio link failure process. In both cases, if the discovered gNB is available, the outage duration may be the connection establishment delay. If the gNB is not found, the outage duration may be equal to the gNB discovery delay and the connection establishment delay. When the rotational (e.g., specific) enhancement is applied, both BFDR and CHO achieve similar outage probabilities. In the 4 gNB and 2 AA scenarios, the rotational mobility (e.g., specific) enhancement can reduce the outage probability of BFDR and CHO by up to 5.77 times and 2 times, respectively. Similarly, from Fig.11 As can be seen from (b), both BFDR and CHO can achieve similar interruption durations. Specifically, in the scenario with 4 gNBs and 1 AA, both BFDR and CHO achieve a shortened interruption duration of approximately 70 milliseconds, which is equivalent to discovering a new gNB and establishing a connection with it, thereby avoiding fault detection delays. This improvement is more pronounced in scenarios where the candidate gNB can be discovered in advance if it is within the FoV of the AA. This can be achieved by increasing the deployment density of gNBs or having multiple AAs at the WTRU. In this case, the interruption delay for both BFDR and CHO can be reduced to approximately 20 milliseconds, which is equivalent to the connection establishment delay.

[0295] The WTRU may be equipped with multiple antenna panels (e.g., one or more panels) to enable faster antenna panel selection / switching at the WTRU and / or faster switching between intra-cell and / or inter-cell transmission reception points (TRPs).

[0296] The WTRU may send its information to the network (e.g., the source gNB) to indicate its ability to support multiple antenna panels. The WTRU may send its multiple antenna panel capabilities, where the capability information may include the number of antenna panels supported and one or more attributes of one or more antenna panels. The attributes of the one or more antenna panels may include any of the following: an identification of the antenna panel (e.g., an identifier or index associated with the antenna panel), the number of beams supported by the antenna panel, the angular coverage of the antenna panel, the supported beamwidth of one or more beams within the antenna panel, the type of the antenna panel (indicating whether the antenna panel is used for uplink or downlink or both types of links), the type of any (e.g., each) antenna panel (indicating whether the antenna panel is used for measurement only or only for communication (e.g., data transmission) or only for control signaling or a combination of one or more of these functions), the number of layers and / or the number of different ports supported by the antenna panel, and the like. The WTRU may also send the layout of the antenna panels, for example, indicating the location of the antenna panels on the WTRU (e.g., relative to each other). For example, the WTRU may send the absolute position of the antenna panel or the relative position of the antenna panel relative to the antenna panel for which the absolute position was sent (e.g., in the form of 2-D / 3-D coordinates and / or angular distances in horizontal and azimuth). As another example, the WTRU may send the relative position of the antenna panel relative to a global reference or relative to a DL beam (e.g., selected during initial access) or a UL beam (e.g., measurable at the gNB) (e.g., in the form of 2-D / 3-D coordinates and / or angular distances in horizontal and azimuth).

[0297] The WTRU may be configured to perform measurements (e.g., L1 measurements or L2 / L3 measurements) using one or more DL beams (e.g., using associated CSI-RS / SSB or any other DL signal, such as a control channel) associated with one or more TRPs (e.g., intra-cell or / and inter-cell TRPs). The measurements may be configured to be periodic / semi-persistent / aperiodic. The WTRU may be given DL signals / resources (e.g., CSI-RS or / and SSB) for measurements. The WTRU may be configured to report measurements. Measurement reporting may be configured to be periodic / semi-persistent / aperiodic or event-based. The WTRU may use one or more antenna panels to perform measurements using one or more DL signals / resources (e.g., CSI-RS / SSB / PDCCH / PDSCH). Alternatively, the WTRU may be configured with antenna panels that need to be measured. For example, for each DL signal / resource configured for measurement, the WTRU may also be given one or more antenna panels that need to be used for measurement. The relevant antenna panels (e.g., antenna panel IDs) may be reported together with the measurements. The network may use these measurement reports to determine / update the transmission configuration indication (TCI) configuration associated with one or more antenna panels and / or TRPs.

[0298] The WTRU may be equipped with one or more TCI configurations that indicate one or more source DL signals / resources (e.g., CSI-RS, SSB, etc.) associated with one or more antenna panels or / and TRPs. Different (e.g., separate) or identical TCI configurations may be provided for DL ​​and UL. The WTRU may be configured to perform measurements on one or more antenna panels using the associated TCI configurations. The TCI configurations for the antenna panels may be dynamically updated (e.g., using DL MAC-CE or DCI). Alternatively, the WTRU may be given multiple TCI configurations for the antenna panels using, for example, RRC signaling, and then one or more TCI configurations may be dynamically activated or deactivated for the antenna panels using, for example, DL MAC-CE or DCI. In another solution, one or more downlink control (e.g., PDCCH) or data channels (e.g., PDSCH, for example, using measurements of associated DMRS) associated with one or more TRPs may be configured for measurements on the antenna panels. The measurements may take one or more of the following forms: RSRP, RSSI, SNR, SINR, BLER, BER, etc.

[0299] Antenna panels can be divided into different groups. For example, states can be defined for antenna panels, where the state of the antenna panel can be defined as service (e.g., service antenna panel) or candidate (e.g., candidate antenna panel) or other (neither service nor candidate) based on the configured measurements and conditions. The service antenna panel can be used for DL / UL communication with the network (e.g., for data, measurements, other control information transmission / reception). Candidate antenna panels can be used for DL ​​measurements and / or control information transmission / reception. Antenna panels that are neither service nor candidate can only be used for DL ​​measurements. For example, the WTRU can be configured to use service and candidate antenna panels for more frequent measurements than other antenna panels (e.g., non-service and non-candidate antenna panels). This can be used for power saving purposes on the WTRU side.

[0300] The WTRU may be configured to perform measurements on one or more antenna panels using relevant TCI configurations (e.g., DL CSI-RS / SSB). The WTRU may be configured with one or more conditions / events based on DL measurements (L1 / L2 / L3 measurements) to determine antenna panel switching or / and inter-cell / intra-cell TRP switching. In an embodiment, the WTRU may be configured with one or more quality thresholds (e.g., RSRP / RSSI / SINR / SNR / BER / BLER thresholds, etc.). The configuration of events and thresholds associated with one or more beams or / and one or more antenna panels may be provided to the WTRU using higher layer signaling (e.g., RRC) or system information or MAC-CE.

[0301] The WTRU may use DL measurements performed at one or more antenna panels (e.g., using CSI-RS / SSB configured in the relevant TCI configuration, or / and relevant downlink signals, e.g., downlink control channels) and configured thresholds for panel selection / switching. The dynamic selection of one or more antenna panels using DL measurements can be used to handle WTRU mobility (e.g., rotation).

[0302] The WTRU may use DL measurements performed at an antenna panel to determine whether the antenna panel can be used as a serving or candidate antenna panel. For example, if the measurement values of one or more DL measurements (e.g., or the configured number of measurements) performed at the antenna panel (or within a configured duration, e.g., trigger time) are higher than a configured threshold, e.g., when the RSRP of the configured CSI-RS received at the antenna panel is higher than the configured threshold T1, the WTRU may determine the antenna panel as a serving antenna panel. Multiple measurements may be considered within a configured time period, and the average of the measurements may be used to compare it with the configured threshold to determine whether the antenna panel can be used as a serving antenna panel. The WTRU may have one or more serving antenna panels. The WTRU may switch or select different antenna panels as serving antenna panels based on the measurements. Using this technique, the WTRU may dynamically update its set of serving antenna panels that includes one or more antenna panels.

[0303] The WTRU may use different (e.g., separate) criteria (e.g., separate thresholds, trigger times) to classify serving antenna panels for downlink or uplink or both types of transmissions.

[0304] The WTRU may also be configured to select one or more antenna panels as candidate antenna panels. For example, if the measurement values of one or more DL measurements performed at the antenna panel are higher than a configured threshold, e.g., when the RSRP of the CSI-RS received at the antenna panel is higher than the configured threshold T2 (e.g., T2 < T1), the WTRU may determine the antenna panel as a candidate antenna panel. Multiple measurements may be considered within a configured time period, and the average of the measurements may be used to compare it with the configured threshold to determine whether the antenna panel can be a candidate antenna panel. The WTRU may have one or more candidate antenna panels. The WTRU may switch or select different antenna panels as candidate antenna panels based on the measurements. Using this technique, the WTRU may dynamically update its set of candidate antenna panels that includes one or more antenna panels. The WTRU may use different (e.g., separate) criteria (e.g., separate thresholds, trigger times) to classify candidate antenna panels for downlink or uplink or both types of communications.

[0305] A candidate antenna panel can become a serving antenna panel. If one or more conditions are met, e.g., if the quality of the DL measurement may become better (e.g., RSRP > T1), then the candidate antenna panel can become a serving antenna panel. Similarly, e.g., in an embodiment, if the quality of the DL measurement may become worse (e.g., RSRP < T1 but RSRP > T2), then the serving antenna panel can become a candidate antenna panel. For example, when the quality of the DL measurement may become worse (e.g., RSRP < T2), the serving or candidate antenna panel can become a non-serving and non-candidate antenna panel.

[0306] The WTRU can use other constraints (e.g., power saving) to determine whether an antenna panel is serving or candidate.

[0307] In an embodiment, e.g., when any change occurs in the status of an antenna panel, the WTRU can indicate to the network its (e.g., preferred) selection that includes the serving or / and candidate antenna panel. The WTRU can include only the antenna panels whose status has changed based on the latest measurement. In one solution, an explicit antenna panel ID can be used. Alternatively, a TCI indication (QCL reference with respect to DL or UL beams) can be used to indicate the associated antenna panel. Alternatively, different sets can be configured, each containing one or more WTRU antenna panels, with combinations of different possible statuses of all the antenna panels, and each set has an index. This set configuration can be configured by the network or communicated by the WTRU to the network (e.g., in the WTRU capability information). When any change occurs in the status of an antenna panel, the WTRU can (e.g., only) include the index of the set of different antenna panel statuses based on the latest measurement.

[0308] Information containing the latest panel status of one or more antenna panels can be sent periodically, aperiodically, or semi-persistently. For example, the WTRU can be configured (e.g., using RRC configuration) with periodic PUCCH resources to send this information. In an embodiment, the WTRU can receive a DCI or MAC-CE message that requests the use of resources configured on the PUSCH or PUCCH to send this information in a dynamic or aperiodic manner. In an embodiment, the WTRU can be configured to send this information in a semi-persistent manner, e.g., using RRC (for a set of periodic configurations that includes uplink resources) and MAC-CE or DCI (for activating / deactivating one of the selected periodic configurations). In an embodiment, after sending a selection indication to the network, if the WTRU receives an acknowledgement (e.g., positive) from the network, then the WTRU can use the antenna panel according to the latest determined status. In an embodiment, the acknowledgement (e.g., positive) message from the network can indicate the selected (e.g., network-selected) antenna panel, e.g., which can be the same as, a subset of, or different from the antenna panel indicated by the WTRU.

[0309] Based on the WTRU indication of serving / candidate antenna panel selection, the DL measurement configuration may be updated for the WTRU (e.g., periodicity of resources, frequency resource allocation, changes in TCI configuration for TRP / panel, quality thresholds configured for events / conditions for antenna panel selection, etc.).

[0310] In an embodiment, the WTRU may be configured with conditions for using DL measurements on one or more antenna panels for handover to a different cell or TRP that is not a serving cell. For example, the WTRU may be configured with one or more quality thresholds for comparison with one or more DL measurements on one or more antenna panels (e.g., the thresholds may be the same or different for each panel) to determine whether the WTRU can trigger a handover to another cell / TRP. In an embodiment, the network may use the antenna panel layout and / or the TRP / cell layout on the WTRU to determine a handover configuration for the WTRU. Based on the measurements on different antenna panels, the WTRU orientation may be determined in some cases, for example, Fig.12 As shown, if one or more DL measurements associated with gNB1 are above a first configured quality threshold for antenna panel 1, but below a second configured quality threshold for antenna panel 2, then gNB1 can estimate the WTRU position knowing the relative positions of the antenna panels, and the WTRU can be configured with a handover configuration for gNB2. The WTRU may be configured with a CHO configuration that includes a handover configuration for one or more non-serving gNBs / cells, where, for example, the CHO evaluation conditions may include DL measurements associated with the WTRU antenna panels. For different non-serving cells, the evaluation conditions may differ in terms of the one or more antenna panels that need to be used to make the measurements. For example, for one or more non-serving cells / gNBs, the CHO execution conditions may include any reference signal information (e.g., reference signals to be measured, time-frequency resources, etc.), one or more antenna panels that need to be used to make the measurements, and thresholds that may need to be applied to derive handover conditions based on measurements (e.g., measurements based on L1 / L3 events). If the CHO execution conditions are met based on WTRU measurements: The WTRU may detach from the serving / source gNB and the WTRU may apply the given handover configuration for the selected candidate gNB / cell to synchronize and handover to the selected gNB / cell.

[0311] In an embodiment, the WTRU may be configured to perform event-based measurement reporting for one or more DL beams indicated using a TCI configuration and measured on associated one or more antenna panels. The WTRU may be configured to send a measurement report for one or more beams (e.g., CSI-RS / SSB / other DL signals) when an event occurs (e.g., when the L1 measurement quality (e.g., RSRP, RSSI, SNR, SINR, BLER, or BER, etc.) of the DL beam is lower than (e.g., or higher than) a configured threshold within a configured number of measurements or a configured duration (e.g., trigger time). Multiple measurements may be considered within a configured time period, and an average of the measurements may be used to compare it with the configured threshold to determine whether the event / condition has occurred. In one example, the WTRU may select one or more antenna panels to measure the configured DL beams. In another example, the WTRU may be configured to perform antenna panel (e.g., specific) measurements. For example, the WTRU may be configured with one or more antenna panels for measuring the configured DL beams. The measurement report may include at least a beam ID (e.g., an associated reference signal ID), associated measurements, associated panels, etc. Individual or joint measurement reports may be sent for any (e.g., each) antenna panel (e.g., event-based or periodic). The WTRU may be given the configuration for event-based measurements (e.g., DL beam, number of measurements or duration for which measurements need to be made, antenna panel information, and thresholds associated with one or more beams and / or one or more panels) using higher layer signaling (e.g., RRC) or system information or MAC-CE. The WTRU may send a report in an uplink RRC or MAC-CE message (e.g., when one or more conditions are met).

[0312] In an embodiment, the WTRU may be configured to perform periodic measurement reporting, for example using higher layer signaling (e.g., RRC or MAC-CE) that includes measurement reporting configuration and / or periodic uplink resources, for example including periodicity, time offset, prohibition timer, uplink control channel (e.g., PUCCH) configuration (e.g., format, time / frequency resources, etc.) for sending measurement reports. In another solution, the WTRU may be configured to perform dynamic aperiodic measurement reporting, for example using downlink control information that includes measurement reporting configuration and / or uplink resources (e.g., on an uplink shared channel) for sending measurement reports. If the WTRU does not have resources allocated for measurement reporting, the WTRU may request the network (e.g., serving gNB) to allocate time-frequency resources (e.g., by sending a scheduling request).

[0313] The network (e.g., serving / source gNB) may use measurements (e.g., L1 measurements) made at the WTRU using one or more antenna panels on one or more beams of one or more TRPs to achieve one or more purposes. Event-based, periodic, and / or aperiodic L1 measurements may be used to determine any blocking between the WTRU and one or more TRPs and / or may also be used to determine WTRU mobility (e.g., including WTRU position).

[0314] In an embodiment, the network (e.g., serving / source gNB) may use measurement reports from the WTRU to determine which antenna panels to select for communication (DL or UL or both) or / and measurement (DL or UL or both). For example, the network may use measurements sent by the WTRU (e.g., dynamically) to determine a serving antenna panel group containing one or more antenna panels (e.g., selected for DL / UL communication, DL / UL measurements, or / and other DL / UL control information transmission). In another example, the network may also use measurements sent by the WTRU to determine a candidate antenna panel group containing one or more antenna panels (e.g., selected for DL / UL communication, DL / UL measurements, or / and other DL / UL control information transmission).

[0315] After sending the measurement report to the network, the WTRU may receive a DL message containing the serving antenna panel and / or the set of candidate antenna panels selected by the network. The DL message may be received in a DL MAC-CE message. Alternatively, the DL message may be received as a DLRRC message or as part of downlink control information (DCI). Explicit or implicit indications may be used to indicate the serving and candidate antenna panels. An explicit antenna panel ID may be used. Alternatively, a TCI indication (relative to the QCL reference of a DL or UL beam) may be used to indicate the associated antenna panel. Alternatively, a set index containing the latest selected state of the antenna panel may be sent in a DL message (as described in the WTRU-based solution above).

[0316] In an embodiment, the WTRU may receive a network selection of a serving or / and candidate antenna panel and may also be configured with a condition (as described above in the WTRU-based solution) to determine if the state of the antenna panel (e.g., serving, candidate, other) has changed. The WTRU may be configured to send an indication if the state of the antenna panel has changed.

[0317] The network may use the measurement reports to update the DL measurement configuration (e.g., periodicity of resources, frequency resource allocation, TCI configuration changes for TRP / panels, etc.). For example, more measurements (e.g., frequent measurements) may be configured for a serving or / and candidate antenna panel compared to other panels.

[0318] In an embodiment, the network (e.g., a serving gNB) may select one or more TRPs to serve the WTRU (e.g., for downlink and / or uplink control / data transmission) using event-based, periodic, and / or aperiodic measurement reports. As a non-limiting example, the serving TRP may be a subset of the set of TRPs configured for measurement. Event-based and / or periodic (e.g., L1) measurements may enable dynamic selection of one or more serving TRPs for the WTRU. The selected one or more TRPs may be indicated to the WTRU using, for example, a downlink MAC-CE message or using downlink control information or RRC signaling. The network may indicate the selected TRP to the WTRU, for example, explicitly using a TRP ID or implicitly using a TCI framework, for example, using a QCL reference containing the relevant DL / UL beam (e.g., a QCL "D" reference).

[0319] In an embodiment, the network (e.g., serving / source gNB) may use event-based, periodic, and / or aperiodic measurement reports from the WTRU to determine a handover configuration (e.g., CHO configuration) for the WTRU for one or more non-serving cells / gNBs. Such measurements may help the serving / source gNB determine and configure one or more potential candidate (e.g., non-serving) target gNBs for CHO. The serving gNB may send an RRC reconfiguration message to the WTRU containing the CHO configuration of the candidate gNBs and the CHO execution conditions. In one example, for different non-serving cells, the evaluation conditions may differ in one or more panels that need to be used to perform measurements. For example, for one or more non-serving cells / gNBs, the CHO execution conditions may include reference signal information (e.g., reference signals to be measured, time-frequency resources, etc.), one or more panels that need to be used to perform measurements, and thresholds that need to be applied to derive handover conditions based on measurements (e.g., measurements based on L1 / L3 events). The WTRU may use the configuration to perform CHO.

[0320] refer to Fig.13 In an embodiment, a method for antenna panel selection / switching performed by a WTRU may include at least one of the following actions:

[0321] The WTRU can send WTRU capability information to the network, which includes the number of supported antenna panels, one or more of the following attributes of one or more panels: the number of beams supported by the antenna panel, the total angular coverage of the antenna panel, the beam width supported by the antenna panel, the type of antenna panel (DL / UL / both), the type of antenna panel (measurement / communication / control signaling), the number of layers or / and the number of different ports supported by the antenna panel, the antenna panel layout, etc.

[0322] The WTRU may receive a measurement configuration from the network, which may include DL signals / resources to be measured, quality thresholds, and conditions to trigger measurement reporting.

[0323] When one or more configured DL L1 measurement values ​​are below or above the configured threshold (depending on the configured conditions), the WTRU may report measurements containing one or more of the following: related DL beam / resource ID, measurement value, related panel, etc.

[0324] The WTRU may receive a configuration from the network that includes a set of serving antenna panels and candidate antenna panels.

[0325] The WTRU may update a set of serving antenna panels and candidate panels.

[0326] Follow the above method:

[0327] The WTRU may receive an updated DL measurement configuration from the network after sending the configured event triggered measurement report.

[0328] The WTRU may receive a CHO configuration from the network after sending a configured event-triggered measurement report: the CHO execution conditions may include reference signal information (e.g., reference signals to be measured, time-frequency resources, etc.), one or more antenna panels that may be used for measurements, and thresholds that may be applied to derive switching conditions based on measurements (e.g., measurements based on L1 / L3 events).

[0329] The WTRU may receive an updated TRP from the network after sending a configured event-triggered measurement report, either explicitly using the TRP ID or implicitly using an updated TCI frame.

[0330] Reference Fig.14 In an embodiment, a method for antenna panel selection / switching performed by a WTRU may include at least one of the following actions:

[0331] The WTRU may send WTRU capability information to the network, which may include the number of antenna panels supported, one or more of the following attributes of one or more panels: the number of beams supported by the antenna panel, the total angular coverage of the antenna panel, the beam width supported by the antenna panel, the type of antenna panel (DL / UL / both), the type of antenna panel (measurement / communication / control signaling), the number of layers or / and the number of different ports supported by the antenna panel, the panel layout, etc.

[0332] The WTRU may receive a TCI (eg, measurement) configuration from the network, which may contain DL signals / resources to be measured, quality thresholds, and conditions to trigger antenna panel switching.

[0333] The WTRU may update the antenna panel status (eg, serving / candidate / other) of one or more antenna panels based on configured measurements and conditions.

[0334] The WTRU may perform operations on one or more antenna panels based on the updated status.

[0335] Follow the above method:

[0336] Different conditions can be configured for DL ​​and UL serving / candidate antenna panels;

[0337] In case of a status update of at least one panel, the WTRU may send an indication to the network containing a set index indicating the status of the antenna panel;

[0338] In case of a status update of at least one panel, the WTRU may send an indication to the network containing an explicit indication with the panel ID or an implicit indication with the TCI configuration associated with the panel whose status is updated;

[0339] After sending the selection indication to the network, if the WTRU receives a confirmation (e.g., positive) from the network, the WTRU may use the antenna panel according to the most recently determined status:

[0340] The confirmation (eg, affirmative) message from the network may indicate the selected (eg, selected by the network) antenna panel (eg, which may be the same or a subset or different antenna panel as the panel indicated by the WTRU).

[0341] The WTRU may receive an updated DL measurement configuration from the network after sending the latest panel status indication;

[0342] The WTRU may receive a CHO configuration from the network, which includes a switching configuration for one or more non-serving gNBs / cells and a CHO evaluation condition, which may include DL measurements associated with the WTRU antenna panel: the CHO execution condition may include reference signal information (e.g., reference signals to be measured, time-frequency resources, etc.), one or more antenna panels that can be used for measurements, and thresholds that can be used to derive switching conditions based on measurements of one or more non-serving gNBs / cells (e.g., measurements based on L1 / L3 events); if the CHO execution condition is met based on the WTRU measurements: the WTRU may be separated from the serving / source gNB, and the WTRU may apply a given switching configuration for the selected candidate gNB / cell to synchronize and switch to the selected gNB / cell.

[0343] refer to Fig.15In an embodiment, a method 1500 performed by a WTRU for performing beam failure and detection recovery may include the step of sending 1510 to a network information indicating the capability for determining the WTRU's orientation associated with a receive beam. The information indicating the capability for determining the WTRU's orientation associated with a receive beam may include information including any of one or more parameters including the number of antenna panels, the angular coverage of at least one antenna panel, the maximum / minimum WTRU Tx / Rx beamwidth, and the location of the antenna panel on the WTRU.

[0344] The method 1500 may also include the step of receiving 1520 information indicating a plurality of parameter sets associated with a beam failure detection and recovery process, wherein the plurality of parameter sets are respectively associated with a plurality of receive beams, and wherein each parameter set in the plurality of parameter sets includes a criterion associated with a receive beam in the plurality of receive beams and one or more WTRU positions. The received criterion for each parameter set in the plurality of parameter sets may be based on any instance of a beam failure counter and a beam failure detection within a period of time.

[0345] The method 1500 may also include the step of determining 1530 a beam failure detection and recovery configuration corresponding to a second receive beam in the plurality of receive beams based on one or more measurements based on a first receive beam in the plurality of receive beams and based on a second WTRU position associated with a second receive beam in the plurality of receive beams. The measurement may include any of a rotation measurement and a channel quality measurement of the WTRU. In the event that the rotation measurement exceeds a rotation threshold, the WTRU may send information indicating a beam failure to the network.

[0346] The method 1500 may also include the step of performing 1540 a beam failure detection and recovery procedure on the second receive beam based on the received criteria associated with the second receive beam and based on the second WTRU position.

[0347] The method 1500 may also include the step of transmitting information indicative of the received criterion associated with the first receive beam.

[0348] Although the features and elements are described above in particular combinations, one of ordinary skill in the art will recognize that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware contained in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, caches, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use with a WTRU 102, a WTRU, a terminal, a base station, an RNC, or any host computer.

[0349] In addition, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, a variety of CPUs and memories may perform references to symbolic representations of actions and operations or instructions. These actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0350] Those of ordinary skill in the art will appreciate that these actions and symbolically represented operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation or reduction of electrical signals and the maintenance of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU, as well as other processing of signals. The memory location where the data bit is maintained is a physical location with specific electrical, magnetic, optical or organic properties corresponding to or representing the data bit. It should be understood that the exemplary embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0351] The data bits may also be stored on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems that can be read by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside entirely on the processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0352] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0353] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in certain circumstances) a design choice that represents a trade-off between cost and efficiency. There may be a variety of carriers (e.g., hardware, software, and / or firmware) to implement the processes and / or systems and / or other techniques described herein, and the preferred carrier may vary depending on the environment in which the processes and / or systems and / or other techniques are deployed. For example, if the implementer determines that speed and accuracy are critical, the implementer may choose a hardware and / or firmware-based carrier. If flexibility is critical, the implementer may choose a software-based implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0354] The foregoing detailed description has set forth various embodiments of the apparatus and / or process by using block diagrams, flow charts, and / or examples. As long as these block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be understood by those of ordinary skill in the art that each function and / or operation in these block diagrams, flow charts, or examples may be implemented individually and / or collectively by a variety of hardware, software, firmware, or nearly any combination thereof. Suitable processors include, for example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0355] Although features and elements are provided above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this application, which are intended to illustrate multiple aspects. It will be understood by those of ordinary skill in the art that many modifications and changes can be made without departing from its spirit and scope. Unless expressly provided, any element, action or instruction used in the description of this application should not be interpreted as being essential or indispensable to the present invention. In addition to those listed herein, those of ordinary skill in the art will understand from the foregoing description that functionally equivalent methods and devices within the scope of the present disclosure. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full range of equivalents enjoyed by such claims. It should be understood that the present disclosure is not limited to a particular method or system.

[0356] It should also be understood that the terms used herein are used only to describe specific embodiments and are not intended to be limiting. The terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" as used herein may refer to (i) a wireless transmit and / or receive unit (WTRU), as described below; (ii) any of the multiple embodiments of a WTRU, as described below; (iii) a wireless and / or wired (e.g., bondable) device configured with some or all of the structure and functionality of a WTRU, as described below; (iii) a wireless and / or wired device configured with less than all of the structure and functionality of a WTRU, as described below; or (iv) the like.

[0357] In certain representative embodiments, several portions of the subject matter described herein may be implemented by application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those of ordinary skill in the art will appreciate that certain aspects of the embodiments disclosed herein may be equivalently implemented in whole or in part in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as any combination thereof, and that designing circuits and / or writing software and / or firmware code is well within the skill of those of ordinary skill in the art in light of the present disclosure. Furthermore, those of ordinary skill in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as program products in a variety of forms, and that the illustrative embodiments of the subject matter described herein are applicable regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media, such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission type media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0358] The subject matter described herein sometimes illustrates other different components contained in different components or connected with different components.It should be understood that the described architecture is only an example, and many other architectures can actually be implemented to achieve the same function.In a conceptual sense, any component arrangement that realizes the same function is effectively "associated", so that the required function can be achieved.Therefore, any two components combined to realize a specific function herein can be regarded as "associated" to each other, so as to achieve the required function, regardless of the architecture or intermediate components.Similarly, any two components so associated can also be regarded as "operably connected" or "operably coupled" to each other to achieve the required function, and any two components that can be so associated can also be regarded as "operably coupled" to each other to achieve the required function.The specific example of operably coupling includes but is not limited to physically matchable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interacting components.

[0359] With respect to the use of almost any plural and / or singular terms herein, one of ordinary skill in the art can translate from the plural to the singular and / or from the singular to the plural, depending on the context and / or application. For clarity, various singular / plural arrangements may be expressly set forth herein.

[0360] One of ordinary skill in the art will understand that, in general, the terms used herein, especially in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). One of ordinary skill in the art will also understand that if an introduced claim item is intended to be a specific number, such intent will be expressly stated in the claim, and if no such statement is made, such intent does not exist. For example, when only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim items. However, the use of such phrases should not be construed as implying that the introduction of claim recitations by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitations to embodiments containing only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed as "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim recitations. Furthermore, even if a specific number of introduced claim recitations is explicitly recited, one of ordinary skill in the art will recognize that such recitation should be interpreted as indicating at least that number (e.g., the mere recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations). In addition, where a convention similar to "at least one of A, B, and C, etc." is used, such a convention is generally intended to be understood by a person of ordinary skill in the art (e.g., "a system having at least one of A, B, and C" would include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Where a convention similar to "at least one of A, B, or C, etc." is used, such a convention is generally intended to be understood by a person of ordinary skill in the art (e.g., "a system having at least one of A, B, or C" would include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). A person of ordinary skill in the art would further understand that virtually any disjunctive word and / or phrase representing two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, either, or both of the terms. For example, the phrase "A or B" would be understood to include the possibility of "A" or "B" or "A and B".Furthermore, as used herein, the term "any" followed by a listing of multiple items and / or multiple categories of items is intended to include "any," "any combination," "any plurality," and / or "any combination of plurality" of those items and / or categories of items, either alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the terms "set" or "group" are intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

[0361] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0362] It will be understood by those skilled in the art that for any purpose, such as in providing a written description, all ranges disclosed herein also encompass any possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily understood to fully describe and be able to decompose the same range into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be easily decomposed into a lower third, a middle third, and an upper third, etc. It will also be understood by those skilled in the art that all languages, such as "at most", "at least", "greater than", "less than", etc., include the numbers listed and refer to the ranges that can be subsequently decomposed into sub-ranges as described above. Finally, it will be understood by those skilled in the art that the range includes each individual member. A group with 1-3 units can refer to a group with 1, 2, or 3 units. Similarly, a group with 1-5 units can refer to a group with 1, 2, 3, 4, or 5 units, and so on.

[0363] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. § 112, or means-plus-function claim format, any claim not using the term “means for…” is not intended to have such an intent.

[0364] Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims without departing from the invention.

[0365] Throughout this disclosure, a skilled artisan will appreciate that certain representative embodiments may be substituted for or used in combination with other representative embodiments.

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

[0367] In addition, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices containing processors are indicated. These devices may include at least one central processing unit ("CPU") and a memory. According to the practice of those skilled in the art of computer programming, various CPUs and memories may perform references to actions and symbolic representations of operations or instructions. These actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0368] Those of ordinary skill in the art will appreciate that these actions and symbolically represented operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation or reduction of the electrical signals and the maintenance of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU, as well as other processing of the signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits.

[0369] The data bits may also be stored on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems that can be read by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside entirely on the processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0370] Unless explicitly described, any element, action or instruction used in the description of this application should not be interpreted as being essential or indispensable to the present invention. In addition, as used herein, the article "a" is intended to include one or more items. When only one item is intended, the term "one" or similar language is used. In addition, the term "any" used in this article is followed by a list of multiple items and / or multiple item categories, and is intended to include "any", "any combination", "any multiple" and / or "any multiple combination" of these items and / or item categories, either individually or in combination with other items and / or other item categories. In addition, the term "set" used in this article is intended to include any number of items, including zero. In addition, the term "quantity" used in this article is intended to include any number, including zero.

[0371] Suitable processors include, for example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0372] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC) or any host. The WTRU may be coupled to modules implemented in hardware and / or software, including software defined radio (SDR), and other components such as cameras, video camera modules, video phones, speaker phones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module).

[0373] Although the present invention has been described from the perspective of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more functions of the various components may be implemented in software controlling a general purpose computer.

[0374] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: sending information to a network indicating a capability for determining a WTRU position associated with a receive beam; receiving information indicating a plurality of parameter sets associated with a beam failure detection and recovery procedure, wherein the plurality of parameter sets are respectively associated with a plurality of receive beams, and wherein each of the plurality of parameter sets includes a criterion associated with a receive beam of the plurality of receive beams and one or more WTRU positions; determining, based on the one or more measurements, a beam failure detection and recovery configuration corresponding to a second receive beam in the plurality of receive beams and based on a second WTRU location associated with the second receive beam in the plurality of receive beams; as well as A beam failure detection and recovery procedure is performed on the second receive beam based on the received criteria associated with the second receive beam and based on the second WTRU position.

2. The method according to claim 1, comprising: Information indicative of the received standard associated with the second receive beam is transmitted.

3. The method according to any one of claims 1 and 2, wherein the WTRU includes an antenna panel, and wherein the WTRU orientation is associated with the receive beam formed by the antenna panel.

4. The method according to any one of claims 1 to 3, wherein the received criteria of each of the plurality of parameter sets is based on any one of an instance of a beam failure counter and a beam failure detection time period.

5. The method of any one of claims 1 to 4, wherein the one or more measurements include a rotation measurement of the WTRU.

6. The method of claim 5, comprising receiving information indicative of rotation measurements of the WTRU from network measurements and / or a gyro sensor.

7. The method of any one of claims 1 to 6, wherein the WTRU orientation comprises a plurality of angular ranges.

8. A method according to any one of claims 1 to claim 7, wherein indicating the ability to determine the WTRU orientation associated with a receive beam includes indicating information including any one of one or more parameters, wherein the one or more parameters include the number of antenna panels, the angular coverage of at least one antenna panel, the maximum / minimum WTRU transmit / receive beamwidth and the location of the antenna panel on the WTRU.

9. The method of claim 8, wherein the angular coverage comprises an azimuth dimension and an elevation dimension.

10. The method of any one of claims 8 and 9, wherein the location of the antenna panel on the WTRU is relative to an antenna panel used to send the information to the network.

11. The method of any one of claims 8 and 9, wherein the location of the antenna panel on the WTRU includes information indicating an absolute location relative to a center of the WTRU.

12. The method according to any one of claims 1 to 11, wherein the information indicative of the capability is sent using a radio resource control uplink message.

13. The method according to any one of claims 1 to claim 11, wherein the information indicating the capability is sent using uplink control information on a control channel.

14. The method of any one of claims 1 to 13, wherein each parameter set of the plurality of parameter sets comprises a configuration identifier.

15. The method according to any one of claims 1 to claim 14, comprising receiving information indicating a configuration for sending multiple SRSs and sending the indicated SRSs through different WTRU beams according to the received configuration.

16. A wireless transmit / receive unit (WTRU) comprising a processor, a transceiver unit and a memory unit and configured to: sending information to a network indicating a capability for determining a WTRU position associated with a receive beam; receiving information indicating a plurality of parameter sets associated with a beam failure detection and recovery procedure, wherein the plurality of parameter sets are respectively associated with a plurality of receive beams, and each of the plurality of parameter sets includes a criterion associated with a receive beam of the plurality of receive beams and one or more WTRU positions; determining, based on the one or more measurements, a beam failure detection and recovery configuration corresponding to a second receive beam in the plurality of receive beams and based on a second WTRU location associated with the second receive beam in the plurality of receive beams; as well as A beam failure detection and recovery procedure is performed on the second receive beam based on the received criteria associated with the second receive beam and based on the second WTRU position.

17. The WTRU of claim 16, configured to send information indicative of the received criterion associated with the second receive beam.

18. The WTRU of any one of claims 16 and 17, comprising an antenna panel, wherein the WTRU orientation is associated with a receive beam formed by the antenna panel.

19. The WTRU of any one of claims 16 to 18, wherein the received criteria for each of the plurality of parameter sets is based on any one of instances of a beam failure counter and a beam failure detection time period.

20. The WTRU of any one of claims 16 to 119, wherein the one or more measurements include rotational measurements.

21. The WTRU of claim 19, configured to receive information indicative of rotation measurements of the WTRU from network measurements and / or a gyro sensor.

22. The WTRU of any one of claims 16 to 21, wherein the WTRU orientation comprises a plurality of angular ranges.

23. A WTRU according to any one of claims 16 to claim 22, wherein the indication of the ability to determine the WTRU orientation associated with a receive beam includes indicating information including any one of one or more parameters, wherein the one or more parameters include the number of antenna panels, the angular coverage of at least one antenna panel, the maximum / minimum WTRU transmit / receive beamwidth and the location of the antenna panel on the WTRU.

24. The WTRU of claim 23, wherein the angular coverage comprises an azimuth dimension and an elevation dimension.

25. The WTRU of any one of claims 23 and 24, wherein the location of the antenna panel on the WTRU is relative to an antenna panel used to send the information to the network.

26. The WTRU of any one of claims 23 and 24, wherein the location of the antenna panel on the WTRU includes information indicating an absolute location relative to a center of the WTRU.

27. The WTRU of any one of claims 16 to 26, wherein the information indicative of the capability is sent using a radio resource control uplink message.

28. The WTRU of any one of claims 16 to 26, wherein the information indicative of the capability is sent using uplink control information on a control channel.

29. The WTRU of any one of claims 16 to 28, wherein each parameter set of the plurality of parameter sets comprises a configuration identifier.

30. The WTRU of any one of claims 16 to 29, configured to receive information indicating a configuration for transmitting a plurality of SRSs and to transmit the indicated SRSs through different WTRU beams according to the received configuration.

Images