Methods, architectures, devices and systems for active non-radio measurement-based beam recovery procedures

Abstract

A process, method, architecture, apparatus, system, apparatus, and computer program product implemented by a wireless transmit / receive unit (WTRU) includes receiving first information indicative of a network coverage integrated area; receiving second information indicating a set of candidate beams and a configuration associated with the set of candidate beams; performing a first local sensor measurement; in response to detecting a beam fault, selecting a subset of candidate beams from the set of candidate beams based on the first local sensor measurements and the network coverage integration area; performing a second local sensor measurement and a radio measurement for each candidate beam; selecting a candidate beam based on a criterion associated with the second local sensor measurement and the radio measurement; determining at least one random access channel (RACH) parameter for the selected candidate beam; and transmitting the RACH transmission on the selected candidate beam using the at least one RACH parameter.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Patent Application No. 63 / 403,962, filed on September 6, 2022, which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to the fields of communications, software, and coding, including, for example, to methods, architectures, devices, and systems for beam failure recovery (BFR) based on active non-radio measurements. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, each of the figures in such drawings is an example. Therefore, the drawings (figures) and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("labels") in the various figures indicate the same elements, and wherein:

[0005] Figure 1A is a system diagram illustrating an example communication system;

[0006] Figure 1B It shows that it can be Figure 1A A system diagram of an exemplary WTRU for use within a communication system is shown;

[0007] Figure 1C It shows that it can be Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0008] Figure 1D It shows that it can be Figure 1A A system diagram of yet another example RAN and yet another example CN used within the communication system shown;

[0009] Figure 2 is a timing diagram of a WTRU (e.g., UE) attachment procedure;

[0010] Figure 3 shows a beam failure detection process at the medium access control (MAC) layer;

[0011] Figure 4 shows the parallel running process for beam / cell level mobility;

[0012] Figure 5 The beam span configuration is shown;

[0013] Figure 6A message sequence chart showing an example of active BFR, where a WTRU (e.g., UE) determines a beam through coverage ensemble and verification via radio measurements;

[0014] Figure 7 A message sequence diagram illustrating message exchanges between a WTRU (e.g., UE) and a network, wherein the WTRU (e.g., UE) is experiencing a beam failure;

[0015] Figure 8 A message sequence diagram illustrating message exchanges between a WTRU (e.g., UE) and a network during a beam failure recovery procedure;

[0016] Fig. 9 A flow chart showing an active beam restoration process with a single device / external mobility configuration;

[0017] Fig.10 A flow chart of active beam failure recovery with unified configuration is shown;

[0018] Fig.11 An embodiment of beam failure recovery in a translational motion scenario is shown;

[0019] Fig.12 A flow chart showing an active BFR process with coverage integration as WTRU (e.g., UE) dedicated signaling;

[0020] Fig.13 A flow chart showing an active BFR process with coverage integration as broadcast signaling;

[0021] Fig.14 is a flow chart illustrating a method implemented at a WTRU for beam failure recovery based on active non-radio measurements;

[0022] Fig.15 is a flow chart illustrating another method implemented at a WTRU for beam failure recovery based on active non-radio measurements; and

[0023] Fig.16 is a flow chart illustrating another method implemented at a WTRU for beam failure recovery based on active non-radio measurements. DETAILED DESCRIPTION

[0024] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, programs, components and circuits are not described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein can replace the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein to practice or practice in combination with them. Although various embodiments in which equipment, systems, devices, etc. and / or any of its elements perform operations, processes, algorithms, functions, etc. and / or any part thereof are described and / or claimed herein, it should be understood that any embodiment described and / or claimed herein assumes that any equipment, systems, devices, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0025] Example Communication System

[0026] The methods, devices, and systems provided herein are well suited for communications involving wired and wireless networks. Figures 1A to 1D An overview of various types of wireless devices and infrastructure is provided in which various elements of the network can utilize, perform, be arranged according to, and / or be adapted and / or configured for the methods, devices, and systems provided herein.

[0027] Figure 1A is a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources (including wireless broadband). 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 (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0028] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the 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 transmit and / or receive wireless signals and may include (or be) a 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 the context of an industrial and / or automated process chain), 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 WTRU (e.g., a UE).

[0029] 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 interface with at least one of the WTRUs 102a, 102b, 102c, 102d, for example, to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B (NB), an eNode-B (eNB), a Home Node-B (HNB), a Home eNode-B (HeNB), a gNode-B (gNB), a NR Node B (NR NB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0030] 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 transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area that may be relatively fixed or may vary over time. The cell may also be divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in an 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 utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0031] 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).

[0032] 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 use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0033] 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).

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

[0035] 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 jointly 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 sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0036] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), 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.

[0037] Figure 1AThe base station 114b in may be, for example, 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, and the like. In an 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0038] 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 high-level security functions, such as user authentication. Although Figure 1A Not shown, but 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 or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0039] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired 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 use the same RAT as the RAN 104 / 114 or a different RAT.

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

[0041] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other elements / 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.

[0042] 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 will be appreciated that the processor 118 and the transceiver 120 may be integrated together, such as in an electronic package or chip.

[0043] 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 an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, for example, the transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In an embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0044] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. For example, 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.

[0045] 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 for enabling the WTRU 102 to communicate via multiple RATs (e.g., such as NR and IEEE 802.11).

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

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

[0048] 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 receiving signals 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.

[0049] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), 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. Components / peripherals 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0051] 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, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0052] 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 an 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 receive wireless signals from, the WTRU 102a.

[0053] Each of the eNode-Bs 160a, 160b, and 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 uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

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

[0056] 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 or 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 DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0058] 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 communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) 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 owned and / or operated by other service providers.

[0059] Although the WTRU Figures 1A to 1D Although depicted as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communications interface utilizing a communications network.

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

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

[0062] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can send beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via 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-collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary signal is sensed / detected by a particular STA and / or is determined to be busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

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

[0064] 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. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as 80+80 configuration. For 80+80 configuration, data can be passed through a fragment parser after channel coding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream respectively. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operation of the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC) layer, entity, etc.

[0065] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those channel operating channels and carriers used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, limited capabilities, 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).

[0066] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth 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, for example, due to a STA (which only supports a 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0068] Figure 1D1 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.

[0069] 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 an 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 WTRUs 102a, 102b, 102c. 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 transmit 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 (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0070] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or the 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 various or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time) .

[0071] 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 also accessing other RANs (e.g., such as 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, such as 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, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

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

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

[0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve 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 protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing, for example, to customize CN support for the WTRU 102a, 102b, 102c based on the type of service the WTRU 102a, 102b, 102c is utilizing. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-APro) and / or non-3GPP access technologies (such as Wi-Fi).

[0075] 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 traffic 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.

[0076] The UPF 184a, 184b may be connected via the N3 interface to one or more of the gNBs 180a, 180b, 180c in the RAN 113, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, for example, 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.

[0077] 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) 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 via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b through the UPF 184a, 184b.

[0078] Given that Figures 1A to 1D and Figures 1A to 1D 102a to 102d, base stations 114a to 114b, eNode-Bs 160a to 160c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a to 180c, AMFs 182a to 182b, UPFs 184a to 184b, SMFs 183a to 183b, DNs 185a to 185b, and / or any other elements / devices described herein. A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0079] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly connected to another device for testing purposes, and / or can use over-the-air wireless communication to perform testing.

[0080] One or more simulation devices can perform one or more (including all) functions when not implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a 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 equipment. The simulation device can use direct RF connection and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0081] Overview

[0082] The following disclosure describes methods and processes for beam failure recovery based on active non-radio measurements, which methods and processes may include any of the following actions:

[0083] -WTRU) (e.g., User Equipment (UE)) can provide the network with assistance information regarding any of the following: (1) positioning, (2) location, (3) panel, (4) field of view (FoV), (5) application quality of service (QoS) from local sensors and measurement data.

[0084] - A network base station (e.g., gNode-B) may prepare an active beam restoration configuration, for example, in response to WTRU (e.g., UE) assistance information combined with its knowledge of the network deployment, and may transmit it to the WTRU (e.g., UE).

[0085] - Active beam recovery configuration may include a set of candidate beams for recovery and / or map these candidate beams to appropriate activity areas (positioning / location, angular span, WTRU (e.g., UE) panel) where these beams may be actively enabled.

[0086] -After a beam failure event, the WTRU (eg, UE) may extract information from local sensors and measurement data to calculate its updated geographic coordinates and orientation.

[0087] -The WTRU (e.g., UE) may identify suitable beam restoration candidates based on its determined coordinates / orientation.

[0088] -The WTRU (e.g., UE) may derive random access channel (RACH) parameters for the selected recovery candidate and may perform RACH transmissions as part of the beam recovery procedure on the selected candidate beam.

[0089] 5G NR – Beam-based process

[0090] A key feature of the 5G-New Radio (NR) design is its ability to operate in two different frequency ranges: below 6GHz, which is called Frequency Range 1 (FR1); and millimeter wave (mmWave), which is called Frequency Range 2 (FR2). As the availability of the sub-6GHz range becomes more limited, the wider bandwidth mmWave bands will become more dominant. This led to the extension of the FR2 range to 71GHz in 3GPP Release-17, and the extended range between 51.4Ghz and 71GHz is called FR2-2.

[0091] The 3GPP 5G NR standard defines new physical layer (PHY) and media access control (MAC) layer features to support directional communications. One of the important functions is beam management, which is used to acquire and maintain beams. It also defines a new initial access procedure to ensure successful directional transmission. Since transmission and reception are performed through narrow beams, there are procedures for detecting beam failures and recovering from beam failures.

[0092] Beam management

[0093] Beam management is a set of layer 1 (PHY) and layer 2 (MAC) procedures to establish and reserve the best beam pair for good connectivity. A beam pair may include a transmit beam and a corresponding receive beam in one link direction.

[0094] Before a WTRU (eg, UE) can communicate with the network, it may perform a cell search and selection procedure and obtain initial cell synchronization and system information. The first step in the process may be to acquire frame synchronization, find the cell identity, and decode the MIB and System Information Block Type 1 (SIB1).

[0095] In the case of a multi-antenna system that can transmit multiple beams, detecting beams from a network node (e.g., a gNB) can be part of the initial access procedure, where the WTRU (e.g., a UE) can detect (e.g., all) beams in a search space.

[0096] Figure 2A timing diagram of a WTRU (e.g., UE) attachment process is shown, which includes various aspects of beam management. The WTRU (e.g., UE) may (e.g., first) find a suitable beam, decode necessary system information through the beam, and then (e.g.) initiate an uplink (UL) connection using the received parameters.

[0097] Beam scanning and initial access

[0098] A network node (e.g., gNB) may transmit beams in all directions in bursts at regularly defined intervals. Whenever a WTRU (e.g., UE) synchronizes with the network, it may read the Synchronization Signal Block (SSB) and extract any of the following:

[0099] Primary Synchronization Signal (PSS):

[0100] ○One of three possible sequences.

[0101] ○ Provide timing estimates.

[0102] Secondary synchronization signal (SSS):

[0103] ○One of 336 possible sequences.

[0104] o Provide a cell ID (one of 3*336=1008).

[0105] Physical Broadcast Channel (PBCH) and Demodulation Reference Signal (DMRS):

[0106] ○Contains the Master Information Block (MIB).

[0107] ○ Includes basic information to take the next step (ie, decoding SIB1).

[0108] Beam measurement and determination

[0109] A WTRU (e.g., UE) may measure beam strength by measuring the signal power received via the beam. In idle mode, it may be based on synchronization signals, and in connected mode, it may be based on a channel state information reference signal (CSI-RS) in the downlink and a sounding reference signal (SRS) in the uplink. The WTRU (e.g., UE) may periodically search for the best beam, for example using a predefined threshold criterion defined by a network node (e.g., gNB), and / or may identify the beam with the highest reference signal received power (RSRP).

[0110] Beam Report

[0111] The best beam identified by the WTRU (e.g., UE) may be notified to the network node (e.g., gNB); this may be referred to as beam reporting. The Random Access Channel (RACH) may be an uplink channel used during initial access or when the WTRU (e.g., UE) may be unsynchronized with the network and may (e.g., need to) establish synchronization. In idle mode, after the WTRU (e.g., UE) selects a beam, the WTRU (e.g., UE) may have one or more RACH intervals with a specific time and frequency offset in which it may send a RACH preamble. The WTRU (e.g., UE) may send a physical RACH (PRACH) preamble corresponding to the SS block for which the best beam has been identified. There may be a one-to-one mapping between the received SS blocks and the transmitted RACH preamble. This may be a way for the WTRU (e.g., UE) to report the best beam to the network node (e.g., gNB) because the network node (e.g., gNB) may reversely calculate the best beam when receiving the RACH in a given interval, and the WTRU (e.g., UE) may receive the best synchronization signal through this best beam.

[0112] The network may configure the WTRU (e.g., UE) to perform certain measurements and report them at preconfigured intervals; this process may be referred to as measurement reporting. In connected mode, while the WTRU (e.g., UE) may be already connected to a network node (e.g., gNB) and may be performing active data transmission (e.g., when the WTRU (e.g., UE) may be already connected to a network node (e.g., gNB) and may be performing active data transmission), it may report the beams to the network node (e.g., gNB) via measurement reporting.

[0113] Beam switching

[0114] Switching from one beam to another may also be referred to as intra-cell mobility or beam-level mobility. Beam switching may be based on the triggering conditions of the beam and the configured beam switching algorithm. This may be applicable to situations where the WTRU (e.g., UE) may be in connected mode and may be done through L1 / L2 procedures (e.g., when the WTRU (e.g., UE) may be in connected mode and may be done through L1 / L2 procedures). On the other hand, switching may generally be used for inter-cell mobility and may be a L3 procedure.

[0115] Beam and link failures

[0116] In this section, the 3GPP procedures for detecting beam failure (recovery) and radio link failure are briefly described.

[0117] Beam Fault Detection and Restoration (BFDR)

[0118] In situations where a WTRU (e.g., UE) and a network node (e.g., gNB) may communicate via narrow beams, changes in WTRU (e.g., UE) mobility and / or the radio environment may result in degradation of the beam pair. Beam level measurements and continuous evaluation may be key processes to help maintain and switch to the best beam pair between the WTRU (e.g., UE) and the network node (e.g., gNB). These processes may be collectively referred to as beam failure detection and recovery (BFDR).

[0119] In the event of beam quality degradation (e.g., when beam quality degrades), the PHY layer of the WTRU (e.g., UE) may generate a "Beam Failure Instance (BFI)" when the measurement value from the configured reference signal for the beam drops below a configured threshold (e.g., when the measurement value from the configured reference signal for the beam drops below a configured threshold). The MAC layer may maintain a "Beam Failure Instance Counter". For each instance in which the PHY layer reports a BFI, the MAC layer may increment the BFI counter and / or may reset a "Beam Failure Detection Timer". If the BFI counter exceeds the configured value, a beam failure may be detected. For beam failure detection (BFD), this should occur within the beam failure detection timer.

[0120] Figure 3 Two exemplary cases of the beam failure process are shown. The upper sub-figure shows the case where the MAC layer receives a BFI from the PHY layer (e.g., when the MAC layer receives a BFI from the PHY layer), but the beam failure detection timer expires, and a beam failure may not be generated. The lower sub-figure shows the case where the PHY layer may report BFI at a rate that does not let the timer expire and the BFI counter reaches the BFD threshold, and the MAC layer will generate a BFD.

[0121] Upon detecting a beam failure event, the WTRU (e.g., UE) may initiate a beam failure recovery (BFR) procedure. In the event that a beam failure has been detected (e.g., once), the WTRU (e.g., UE) may attempt to recover from the beam failure if candidate recovery beams are configured. The WTRU (e.g., UE) may attempt to validate the configured candidates for a given serving cell based on configured / defined measurement quality criteria and thresholds. It may prepare a BFR MAC-CE or a truncated BFR MAC-CE based on defined conditions in which the cell and recovery beam may be indicated for the network to understand.

[0122] The actual beam recovery process may be different, whether the beam failure is detected on a specific cell (SpCell) (this can be the primary cell of the primary cell group. For dual connectivity operation, this can be the primary cell of the secondary cell group) or on a secondary cell (SCell). The 3GPP definition is adopted here for SpCell and SCell, as provided in TS38.331, for example. For the beam recovery process on SpCell, after verifying the configured candidate beams, the WTRU (e.g., UE) can select a suitable verified candidate beam for RACH transmission. A normal or truncated BFR MAC-CE can be sent as part of the RACH process. The RACH transmission can follow the parameters configured as part of the candidate beam configuration. A successful RACH can let the network know that the WTRU (e.g., UE) has recovered through this candidate beam. For the beam recovery process on SCell, after verifying the candidate beam, the WTRU (e.g., UE) can transmit a BFR MAC-CE or a truncated BFR MAC-CE to the network. The RACH process may not be initiated for beam failure recovery on SCell. Additional details on the beam failure recovery procedure and MAC CE contents can be found in TS 38.321.

[0123] Radio Link Failure (RLF)

[0124] A WTRU (e.g., UE) may perform radio link monitoring (RLM) based on a synchronization signal block (SSB) or / and a channel state information reference signal (CSI-RS) and / or a signal quality threshold configured by the network. The PHY layer at the WTRU (e.g., UE) may make measurements and pass them to the MAC and RRC layers. The MAC layer may be responsible for detecting beam failures, while the RRC layer may be responsible for detecting radio link failures (RLF). The network may configure the RLM reference signal (RLM-RS) and associated thresholds for the WTRU (e.g., UE) using RRC signaling. The RLM-RS may be an SSB, a CSI-RS, or a combination of both. The network may configure a timer for RLF detection / determination as part of the primary cell configuration. In the event that the radio link quality belonging to all monitored RSs may be worse than a configured threshold (e.g., when the radio link quality belonging to all monitored RSs may be worse than a configured threshold), the PHY layer may generate an "out of synchronization (OOS)" indication. In the event that the radio link quality belonging to at least one monitored RS may be better than the configured threshold (e.g., when the radio link quality belonging to at least one monitored RS may be better than the configured threshold), the PHY layer may generate an "in-sync" indication. In-sync and OOS indications may be passed to the RRC layer.

[0125] The criteria for declaring RLF can be listed in the 3GPP TS and reproduced here:

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

[0127] ● RLF based on T312: The WTRU (e.g., UE) may start a T312 timer when a measurement report is triggered, while the T310 timer may already be running for this. The T312 timer may allow the WTRU (e.g., UE) to distinguish between RLF caused by handover failure and RLF caused by coverage holes. The T312 timer may generally be shorter than the T310 timer. If the channel quality of the source network node (e.g., gNB) may be worse than a threshold, the shorter T312 timer may expire earlier and an RLF may be declared in a timely manner.

[0128] ● Random access procedure failure: RLF may be declared if multiple RACH attempts to connect to a network node (e.g. gNB) fail consecutively.

[0129] ●Beam failure recovery process failure: Failure to recover to a suitable beam after detecting a beam failure can result in an indication of a link failure.

[0130] • RLF due to reaching the maximum number of retransmissions from the Radio Link Control (RLC) layer.

[0131] In the case of beam and link degradation (e.g., when beam and link are degraded), BFDR, RLM and switching processes can run simultaneously, such as Figure 4 As shown. Each individual process can cause RLF. In the case where the WTRU (e.g., UE) is configured to use conventional handover (HO) (e.g., when the WTRU (e.g., UE) is configured to use conventional handover (HO)), link cutoff may interrupt measurement reporting and / or HO initiation. The HO operation may fail. The BFDR process may attempt to recover through BFR (e.g., in parallel). If the recovery attempt fails, the BFDR process may declare RLF. In the case where the WTRU (e.g., UE) is configured to use conditional handover (CHO) (e.g., when the WTRU (e.g., UE) is configured to use conditional handover (CHO)), in the case where the service link begins to degrade (e.g., once the service link begins to degrade), the WTRU (e.g., UE) may evaluate the execution conditions of the conditional handover and / or may switch to the target cell if the execution conditions are met.

[0132] Mobility issues in directional systems

[0133] At higher frequencies, such as the sub-THz and THz frequency ranges expected for 6G systems, due to high attenuation and path loss, larger antenna arrays (number of antenna elements ranging from tens to hundreds) can be used to form high-gain highly directional narrow beams, which can ensure the desired coverage level at such high frequencies. As we move to higher frequencies, the beams can become narrower. The highly directional links generated by narrow beams at both the WTRU (e.g., UE) and the network node (e.g., gNB) can be more sensitive to dynamic changes in the environment compared to conventional links. Another important aspect of such high-frequency systems can be network densification, where the coverage area for any (e.g., each) transmit receive point (TRP) is shorter.

[0134] For these highly dense systems with highly directional narrow beams, mobility events (translations, rotations) or shadowing events can be expected to be more frequent. Since the beams are highly directional, beam quality may degrade faster and more frequently. Therefore, the time budget for making measurements, reporting measurement results (for example, in the case of network-controlled mobility), processing measurements, making mobility decisions, and executing mobility decisions may be very tight, making traditional mobility / beam management methods based on radio measurements impractical. This situation may be further exacerbated in the face of future applications that require even more stringent quality of service requirements. These mobility events can be the result of translational motion, rotational motion, or changes in the wireless medium. WTRU (e.g., UE) rotation can come from rotational movements of mobile phones / wearable devices (such as smartphones, game controllers, and VR / XR headsets). These movements can come from gestures, head movements, etc. WTRU (e.g., UE) rotation can cause channel changes between the serving network node (e.g., gNB) and the WTRU (e.g., UE), which can cause beam misalignment or even link / connection failures. Other types of dynamic changes can come from translational mobility. Another type of change may also occur when the service link / beam can be shielded by a mobile object or a mobile shield in the surrounding environment (e.g., when the service link / beam can be shielded by a mobile object or a mobile shield in the surrounding environment). Worse still, these changes may occur in any combination that results in degradation / failure of multiple beams / links. Regardless of the cause, future applications with strict QoS requirements may need to recover faster from this situation, otherwise there may be a risk of not being able to meet QoS requirements and impaired user experience. In such a highly directional system, the robustness and reliability of existing mobility / beam management processes that rely heavily on radio signal measurements may be challenged. New mobility / beam management methods that rely less on radio signal measurements may be used (e.g., required). It should be understood that the term "mobility process or method" may be used with reference to both traditional mobility processes (such as switching) and beam management processes.

[0135] Mobility may result in a sudden beam failure at the serving / source network node (e.g., gNB) and the WTRU (e.g., UE) may not discover nearby available neighboring beams from the same serving TRP, neighboring TRP, serving cell, or neighboring cell either as candidates to be measured and reported to the network or as candidates to be switched to as part of the beam failure recovery process. The reason for non-detection may be that the network did not have enough time to configure the measurements and gaps and the WTRU (e.g., UE) did not have enough time to make these measurements (if configured). Despite the availability of available beams / cells nearby from the same network node (e.g., gNB) or neighboring gNBs, the missing configuration to recover from a beam failure event may result in loss of connectivity and longer recovery delays. The new method may (e.g., needs to) be designed to avoid this problem of missing suitable configuration at the WTRU (e.g., UE).

[0136] Another (e.g., major) issue with operating in a dense network with a large number of narrow beams may be power consumption, which is generally used for transmit / receive purposes and in particular for making measurements on all such narrow beams from different TRPs. In such an environment, the device may (e.g., need to) make measurements on neighboring beams / cells, and due to directivity and path loss, the measurements may (e.g., need to) be made through a suitable receive beam. Therefore, the device may consume a lot of power in terms of reception and computation in order to make measurements on neighboring beams. In addition to the huge power disadvantage, beam steering for measurement purposes further increases the "cut-off" from the perspective of the serving beam / link. A streamlined procedure may (e.g., need to) be defined to reduce the power consumption of the WTRU (e.g., UE) for making beam / cell measurements on neighboring beams / cells.

[0137] The main focus of the present disclosure is to propose embodiments for beam failure detection, reporting and recovery that no longer use only radio measurements, but also use other non-radio based measurement information such as network deployment data, positioning, future device movement data and other sensor information.

[0138] Methods to minimize mobility disruption

[0139] Overview of Embodiments

[0140] Minimizing mobility disruption has always been a key topic in wireless communication systems. The evolution of wireless systems has led to more attention and activity on this topic as new applications require low latency, high reliability, and high availability. To this end, 3GPP has defined and standardized a number of mechanisms where mobility disruption can be minimized by faster switching of beams, cells, and network nodes.

[0141] The present disclosure proposes several embodiments to implement active mobility handling for beam-based systems. According to an embodiment, the proposed method may be to combine (i) the network deployment knowledge of its nodes / cells / beams with (ii) the ability of the WTRU (e.g., UE) to track its movement and / or determine an updated geographic location / position and / or orientation.

[0142] The ability of a WTRU (e.g., UE) to detect its geographic coordinates, position, and orientation in a highly timely manner can be used to (e.g., deterministically) select an appropriate node / cell / beam to which this WTRU (e.g., UE) should connect. Mobility decisions can be moved to the WTRU (e.g., UE) side. In order to make such decisions based on the latest WTRU (e.g., UE) location, orientation, and possible changes in the network environment, the network may share a suitable limited portion of its deployment / coverage integration with the WTRU (e.g., UE). Detailed information on the integration content, configuration, maintenance, signaling mechanisms, and post-processing of such integration by the WTRU (e.g., UE) may be provided in the following sections.

[0143] After acquiring network sharing deployment or coverage integration, the WTRU (e.g., UE) may use this information in combination with any of: its latest movement, location, orientation, and any changes in the network environment to minimize mobility interruptions and disconnections. The present disclosure proposes a framework that measures several newly defined non-radio measurement quantities, with a particular focus on location, positioning, and orientation detection. This allows the WTRU (e.g., UE) to combine traditional radio measurement quantities with the newly proposed non-radio measurement quantities to design special suitable events and triggers to handle mobility procedures, such as beam failure recovery. The measurement framework, measurement quantities, and combined events of radio measurement quantities and non-radio measurement quantities may be described below.

[0144] The embodiments presented in the present disclosure provide a system-level design for active beam failure recovery, which is built on the following framework and executes the proposed beam recovery process: (i) deployment / coverage areas that the network can indicate to the WTRU (e.g., UE) through appropriate signaling, and (ii) non-radio measurements and events combined with radio measurements estimated and evaluated at the WTRU (e.g., UE).

[0145] Deployment and coverage areas

[0146] A cellular network may be a planned network where an operator deploys network nodes at suitable locations to provide adequate coverage to its subscribers. A network operator may have very precise knowledge of the deployment of its cells, and the beams within these cells, with respect to coverage area attributes such as the location of the cell or TRP (reference location), potential spatial transmission directions defined, for example, by azimuth, elevation and position coordinates of the TRP, beamwidth information (such as 3-dimensional (3D) beamwidth information, for example in horizontal and vertical directions), transmission range information, coverage shape information (including, for example, the location coordinates of points constituting the coverage boundaries of a beam, cell or TRP).

[0147] Deploy the integration

[0148] Deployment integration may include any of the following: Information about the location of the TRP and the coverage / orientation of the beam. According to an embodiment, the location of the TRP may be represented by 2D coordinates, where an example of a 2D coordinate is a latitude and longitude coordinate. The location may be represented by 3D coordinates, where an altitude or height is added to the 2D coordinates. Both 2D or 3D representations may be in a global or local coordinate system.

[0149] A beam from a given TRP may be represented using azimuth and elevation. Appropriate references such as cardinal directions and apex may be used, or reference directions may be provided as part of the configuration. Appropriate refinement or quantization may be provided to these angles to meaningfully capture the mobility process and signal strength of a given beam in or out of coverage. In addition to the angle, the beamwidth in these directions may also be explicitly provided for the beam. Knowing the TRP location parameters and beam angle (plus width), the WTRU (e.g., UE) can prepare a local integration where it can see the coverage of different beams from different TRPs. Other attributes such as range / power may be added to the cell / beam to further refine the deployment integration.

[0150] Coverage Integration

[0151] Coverage integration can provide an indication of the geographic coverage of different TRPs from different beams. With appropriate representation, it can provide coverage boundaries for different TRPs and different beams. Coverage integration can combine any of the following: terrain properties, geological aspects, buildings and other geographical parameters on deployment integration to prepare appropriate areas and boundaries associated with coverage of different beams from different TRPs.

[0152] The representation of coverage integration may take the form of appropriate geometric shapes. To indicate the shapes that bound the cell / beam level coverage, different reference shapes may be defined. The reference shapes may be in the form of a circle, an oval, an ellipse, an ellipsoid with appropriate parameterization. Coverage integration may be indicated using these shapes with appropriate attributes. These attributes may provide a link to a cell / beam identity with which a given shape / area may be associated.

[0153] Configuration

[0154] This disclosure will use the terms deployment integration and overlay integration synonymously. When a distinction is required, it will be explicitly mentioned.

[0155] The coverage integration may be associated with an area, denoted herein as a coverage integration area. The coverage integration area may correspond to one or more cells, a RAN Notification Area (RNA), a Tracking Area (TA), a PLMN, and the like.

[0156] Coverage integration may be defined at different granularities. The granularity of coverage integration may be part of the coverage integration configuration. In one embodiment, coverage integration may be defined at a cell level and information about geographic coverage from different gNBs / TRPs may be indicated to the WTRU (e.g., UE) using appropriate signaling. Cell level coverage may be used for different handover and cell change procedures.

[0157] The coverage integration granularity may be reflected in the form of coverage areas. For cell level procedures, the coverage integration areas may have cell level granularity. For beam level procedures, where, for example, a WTRU (e.g., UE) may (e.g., needs to) track, maintain, or switch beams, the coverage integration granularity may be defined at the beam level, and areas in such coverage integration may be attributed to different beams.

[0158] A region can be attributed to a given beam from a given TRP. Further refined granularity can be achieved by defining regions and associating them with different directions from any (e.g., each) network node (e.g., gNB) or TRP. A region in a coverage integration can indicate a geographic area corresponding to a given set of reference signals. For beam-level regions, in one embodiment, any (e.g., each) region can indicate the coverage area of ​​an SSB beam. In another beam-level region design, any (e.g., each) region can indicate the coverage area of ​​an SSB beam or a CSI-RS beam, where the SSB / CSI-RS beam can be the coverage of the corresponding SSB / CSI-RS signal.

[0159] Any (e.g., each) region may be identified by an identifier that may be provided as part of the configuration. In another embodiment, any (e.g., each) region identifier may be a deterministic combination of the identifiers of the cell, TRP, and SSB / CSI-RS beam to which it may belong. The network and devices may know in advance the formula for calculating the region identifier, and they may use additional modulation parameters such as length, width, number of SSB beams, etc., which may be part of the system information or configuration.

[0160] The different granularities of the area can be at the gNB, TRP or cell level. For a cell level area, the area may indicate an area where this cell has sufficient coverage. A cell level area may group (e.g., all) SSB / CSI-RS areas associated with a given cell, and it may represent an area where any SSB / CSI-RS signal of this cell can be received with a known / configured quality. For coverage areas based on RNA, TA or PLMN, the area representation may be extended to a larger granularity. The cell level area identifier may be a cell identifier, or a deterministic modification of the cell identifier by combining the cell identifier with some other parameters. The same design may be used for areas to represent coverage of RNA, TA, PLMN, etc.

[0161] In an alternative embodiment, a region may be defined for any (e.g., each) location using its longitude and latitude values. The region length information may be provided as part of the configuration. The formula for calculating the region may be predefined, or may be signaled from a predefined set as part of the configuration. This embodiment may facilitate region identification calculations, for example, as standardized in the 3GPP NR side link work in Release-16. For this embodiment, the longitude and latitude values ​​may be geodesic distances from geographic coordinates (0, 0), for example, as used in the NR side link framework. Appropriate parameters may be provided as part of the configuration to select regional modularity along longitude and latitude directions. (e.g., only) a single parameter may be used to select the same modularity along longitude and latitude directions. The parameter may be a fixed value to simplify the configuration. In this embodiment, all devices may calculate the region of all devices and the region of the location for the longitude and latitude coordinates of any location.

[0162] Network deployment configuration

[0163] Deployment integration may include any of the following: Information about the location of the TRP and the coverage / orientation of the beam. In one example, the location of the TRP may be represented by 2D coordinates, where an example of a 2D coordinate is latitude and longitude coordinates. The location may be represented by 3D coordinates, where an altitude or height is added to the 2D coordinates. Both 2D or 3D representations may be in a global or local coordinate system. If the configuration of a region follows the sidelink design, the TRP location may be provided for the region instead of longitude and latitude coordinates.

[0164] A beam from a given TRP may be represented using azimuth and elevation angles. Appropriate references such as cardinal directions and apex may be used, or reference directions may be provided as part of the configuration. Appropriate refinement or quantization may be provided to these angles to meaningfully capture the mobility process and signal strength of a given beam in or out of coverage. In addition to the angle, the beamwidth in these directions may also be explicitly provided for the beam.

[0165] Network coverage configuration

[0166] The network can provide the configuration directly in the form of rich shapes that capture all the specific aspects of the local terrain, shadows from buildings and other objects. The advantage of this approach may be that the network not only knows the deployment of its cells / TRPs and beams accurately, but in addition it has access to geological data using navigation systems, cameras and continuous measurements of cells / beams from devices, allowing it to know very accurate coverage integration. An additional advantage may be the use of all historical data in the form of network measurements, cell / beam switches, etc., which can be used to update and refine this detailed coverage integration. This approach may have a large signaling overhead. The amount of information that can (e.g., needs to) be exchanged can be very large, because even the accurate coverage of a single beam can use (e.g., need to) be communicated to the WTRU (e.g., UE) a set of objects and their attributes. The large signaling overhead may use (e.g., need to) multiple message exchanges at the RRC level, which may also lead to increased configuration latency.

[0167] If the configuration of the area follows the sidelink design, the network can provide different cell and beam coverage indications, which provide the association of these cells and beams with the area.

[0168] Hybrid Configuration

[0169] The integrated configuration may be a hybrid of the two previous approaches, where some parts may be indicated in the form of network deployment based configuration and some parts may be indicated using overlay integration based configuration.

[0170] Deploy / overwrite the initial configuration of the integration

[0171] In one embodiment, the initial configuration of coverage integration may be communicated to the WTRU (e.g., UE) in the form of dedicated RRC signaling. The initial coverage integration configuration may be provided to a WTRU (e.g., UE) in an RRC active state with mobility. From the perspective of the WTRU (e.g., UE), the signaling may be dedicated, but the network may provide the same information to a group of WTRUs (e.g., UEs). These WTRUs (e.g., UEs) may be adjacent to each other and the same coverage integration may be associated with them.

[0172] In another approach, the network (e.g., base station) may broadcast coverage integration information. A new coverage integration system information block (SIB) may be specified. It will be appreciated that in this case, the coverage integration information broadcast by the cell or TRP may be configured to reflect the local deployment environment of the cell or TRP broadcasting coverage integration.

[0173] For many relevant cases, the initial configuration may provide a coarse coverage integration that may (e.g., needs to) be refined to an appropriate granularity and coverage extension in order to be fully useful. The coverage integration may be appropriately refined through dedicated signaling. Refinement may be network initiated in cases where certain application processes / flows may be configured with QoS constraints and active mobility is required (e.g., when certain application processes / flows may be configured with QoS constraints and active mobility is required). In a compatible embodiment, a WTRU (e.g., UE) may request refinement of its coverage integration.

[0174] WTRU (e.g., UE) processing to achieve effective coverage integration

[0175] The network deployment integration can be shared with the WTRU (e.g., UE) following configuration embodiments, for example, as described above, by adding additional attributes to the cell configuration or by introducing new configurations with these geographical attributes and providing links to these TRP / beam level configurations to the traditional cell configuration. In order to be used in mobility events and effective selection of beams, cells, TRPs, the WTRU (e.g., UE) can (e.g., needs to) have a detailed effective coverage integration, which we can call ground coverage integration. There may still be a question of how to make the deployment integration rich enough so that it can capture all geological and shadowing aspects. This coverage integration should not only take into account the TRP location and beam attributes, but also incorporate the physical properties of the surrounding environment, including the details of the terrain, buildings and all their physical properties that can shade, block or reflect the beam. An embodiment that enables the WTRU (e.g., UE) to obtain / manufacture ground coverage integration is presented below.

[0176] The WTRU (e.g., UE) integrates the coverage provided by the network to handle

[0177] In one embodiment, the deployment configuration provided by the network itself can become very rich and detailed and provided in the form of rich shapes that can capture all the specific aspects of the local terrain, shadows from buildings and other objects. In order to indicate the shapes that define the cell / beam level coverage, different reference shapes can be defined. The reference shapes can be in the form of circles, ovals, ellipses, ellipsoids with appropriate parameterization. The network can then indicate these shapes with appropriate attributes and provide their links to the cell / beam identification. The advantage of this solution is that the network knows exactly the deployment of its cells / TRPs and beams. It can access geological data using navigation systems, cameras and continuous measurements of cells / beams from devices, allowing it to know very accurate coverage integration. An additional advantage can be the use of all historical data in the form of network measurements, cell / beam switches, etc., which can be used to update and refine this detailed coverage integration. This approach can have a large signaling overhead. The amount of information that can (e.g., needs to) be exchanged can be very large, because even the accurate coverage of a single beam can use (e.g., need to) be communicated to the WTRU (e.g., UE) a set of objects and their attributes. Large signaling overhead may use (eg, require) multiple message exchanges at the RRC level, which may also result in increased configuration delays.

[0178] The WTRU (e.g., UE) is handled by the deployment integration provided by the network

[0179] In this design approach, the network can provide the WTRU (e.g., UE) with a snapshot of its node deployment and limited information about the beams it can transmit. Therefore, this approach can be mainly used in situations where the network can provide its deployment configuration (e.g., when the network can provide its deployment configuration). In this embodiment, the network can provide information about TRP locations, beam angles, and beam-specific parameters without using features of the local terrain to modulate coverage. Since the amount of information is less than that of methods where the network can provide detailed coverage integration, the signaling overhead and latency performance of this approach can be much better than the former.

[0180] In this embodiment, it is expected that the device obtains deployment characteristics / parameters of the TRP / beam and using local knowledge obtained through other technologies (locally stored terrain, positioning system, camera) a refined coverage integration can be prepared that can add geological aspects to the deployment configuration. In this embodiment, after local processing and manufacturing, the WTRU (e.g., UE) obtains an effective integration that can define different coverage areas associated with different beams and cells. This refined coverage integration can be used for beam and cell level mobility procedures at the WTRU (e.g., UE). This local physical coverage integration can be refined using mobility or additional information obtained from other sensors. When the device uses the deployment parameters provided by the network in combination with information from local sensors to prepare this effective integration, this can use (e.g., require) the availability of local sensors, additional storage and computing power to prepare the effective integration by combining the network deployment with information from local sensors.

[0181] Hybrid embodiments may be standardized to obtain refined coverage integration at the device. If some devices may not be equipped with the necessary local sensors, or they may not have the necessary computing power to process and make the integration themselves, the network may send the refined integration to such devices. In contrast, devices with the necessary local sensors and computing / storage capabilities may receive (e.g., only) limited deployment characteristics from the network and prepare effective integration locally. Hybrid embodiments may be used depending on the power consumption requirements of the WTRU (e.g., UE), battery quality, remaining battery, or depending on the active applications and their properties.

[0182] Deployment / maintenance of coverage integration

[0183] Upon detecting a change in the coverage integration area, the WTRU (e.g., UE) may reacquire the coverage integration for its current location. The reacquisition may take the form of dedicated RRC signaling. In another embodiment, this may be by reacquiring the coverage integration SIB. The detection of a change in the coverage integration area by the WTRU (e.g., UE) may include any of the following:

[0184] - Change of serving cell or (re)selection to a cell which may not belong to the current coverage integration area.

[0185] - (Re)selection to RNAs that may not belong to or may not correspond to the currently covered integration region.

[0186] -Execute RNA update process, or transmit RNA update message to the network (base station)

[0187] - (Re)selection to a TA that may not belong to the current coverage integration area, or may not correspond to the integration of the current coverage integration area.

[0188] -Perform the TA update procedure, or transmit a TA update message to the network (core network).

[0189] - (Re)selection to a PLMN which may not belong to the current coverage integration area, or which may not correspond to the integration of the current coverage integration area.

[0190] Deploy / override the release of the integration configuration

[0191] If the coverage integration configuration information expires, the WTRU (e.g., UE) may discard the information. An expiration indication may be derived if the WTRU (e.g., UE) changes its coverage area and may not be able to obtain an updated coverage integration. In another embodiment, the configuration may include (e.g., explicit) timers that, if expired, may cause the WTRU (e.g., UE) to release the configuration. These timers may be refreshed if the WTRU (e.g., UE) stays in an area associated with its current coverage integration. The coverage integration area may be defined based on RNA, TA, PLMN, or other suitable criteria.

[0192] The network may send an (eg, explicit) indication to the WTRU (eg, UE) to release its coverage integration configuration.

[0193] If the WTRU (eg, UE) exits the RRC active state, the WTRU (eg, UE) may release the coverage integration configuration.

[0194] Deployment / Overlay Integrated Network Instructions

[0195] The present disclosure proposes the following compatible embodiments, through which deployment integration can be provided to the WTRU (e.g., UE), and how to relate the cell / beam configuration and mobility configuration to the deployment configuration.

[0196] Integrated indication as part of cell / beam configuration

[0197] In a first embodiment, deployment integration may be part of a cell configuration. The cell configuration may be part of a conditional (re) configuration associated with a candidate cell, which may be part of a conditional switching or conditional PSCell change / addition process. Deployment integration may be associated with any serving cell configuration and may be used for any beam management process, i.e., beam switching, beam failure recovery, etc. New attributes may be added to the cell configuration that may define the TRPs to which this cell may be transmitted, the locations of these TRPs in a suitable global or local coordinate system, and the beam coverage attributes of the beams transmitted by these TRPs. The configuration may provide information about an SSB beam or a CSI-RS beam. The attributes of a beam may be in the form of an azimuth and elevation angle with a suitable reference direction. The reference direction may be taken from a base direction or may be indicated as part of the configuration itself. The range of a beam may be indicated in terms of a beam attribute or a single value that may indicate an unobstructed range in view of the transmit power. Beam attributes may define beam widths in the horizontal and vertical directions. Simpler deployments may specify a single beamwidth attribute for the horizontal direction and one beamwidth attribute for the vertical direction, which may be assumed to be the same for (e.g., all) configured beams. For deployments with varying beamwidth sizes, the network may provide a single value for the TRP and may provide incremental values ​​for any (e.g., each) beam. An alternative embodiment may provide the beamwidth as part of the beam configuration without any TRP or cell level indication. In yet another embodiment, the coverage of any (e.g., each) beam may be specified as an ellipsoid with appropriate parameterization.

[0198] Integrated indication as a stand-alone dedicated configuration

[0199] In this embodiment, the integration may be provided to the WTRU (e.g., UE) as a separate configuration. In this embodiment, the coverage integration configuration may not be part of the cell configuration or conditional (re)configuration. Coverage integration may depend on the geographical deployment and coverage, but its configuration and signaling may be provided by the network independently of the cell configuration or other conditional (re)configuration.

[0200] The coverage integrated configuration may be in the form of network node deployment and beam properties, or it may be in the form of detailed ground coverage incorporating geological and / or terrain specific features. The coverage / deployment integrated configuration may provide a link to the indicated TRP location and beam properties with the cell identity and cell configuration.

[0201] Integrate indication as broadcast signaling

[0202] In this embodiment, the deployment / coverage integration indication may be transmitted by the network in the form of broadcast signaling. The information may be broadcast by the network, and the relevant devices may be notified in advance or may know in advance how to obtain and decode the information. Control information for positioning the integrated related broadcast information may be broadcast, such as notifying all devices of the broadcast-based integrated information through specific paging or integrated downlink control information.

[0203] In a compatible embodiment, the integration indication may be considered as part of the system information. A new SIB may be designed that carries and communicates the deployment / coverage integration indication. The network may use periodic transmission of the integration SIB to keep the WTRU (e.g., UE) aware of the integration information. A WTRU (e.g., UE) that may be initiating related services that may (e.g., require) to minimize disconnection may be able to send (e.g., explicit) a request to the network to request the transmission of the integration SIB.

[0204] Measurement

[0205] A key part of the embodiments proposed in this disclosure may be radio measurements, non-radio measurements and combinations thereof, which may be used in an intelligent way to trigger certain events, which are combined with the provision of additional information from the network.

[0206] The device may be equipped with interfaces from non-3GPP RATs, local sensors, or may obtain environmental information and quantities from certain accumulation points. The use of these quantities and their integration with measurements on 3GPP standardized RATs may use (e.g., require) a coordinated framework where the WTRU (e.g., UE) may use data from non-3GPP RATs alone or in combination with data / measurements on 3GPP RATs. The following subsections are intended to provide a framework by which measurements or data quantities from non-3GPP RATs / sensors may be used for beam change and cell change procedures.

[0207] Configuration

[0208] From a 3GPP perspective, the measurement process and framework may be based on a measurement identifier. A measurement identifier may link a measurement object with a reporting configuration. A measurement object may constitute an object on which a WTRU (e.g., UE) may perform measurements and may indicate a combination of time, frequency, bandwidth, subcarrier spacing parameters related to a reference signal on which the WTRU (e.g., UE) may perform measurements. A reporting configuration may provide the reporting criteria, the nature of the report (whether periodic, event triggered, or cell global identifier reporting). For event triggered reporting, the reporting configuration may provide the triggering event and appropriate parameters related to the event.

[0209] The measurement object may provide a pointer to a quantity configuration. The quantity configuration may provide a measurement filter configuration that may be applied to the measurement prior to event evaluation and reporting.

[0210] In the current 3GPP measurement framework, a measurement identity may (e.g., always) link a measurement object and a reporting configuration. The current measurement object may belong to the same RAT over which the measurement may be configured, or inter-RAT measurements may be defined by other 3GPP technologies. For non-radio measurements from non-3GPP RATs, from local sensors, or from other sources, there may be, for example, embodiments as outlined in the following subsections.

[0211] Measurement identification of measurement objects with limited properties:

[0212] One embodiment may extend the 3GPP measurement framework so that the measurement identifier may provide a link to a report configuration to a virtual measurement object that may have very limited properties. For non-radio measurements, the report configuration may provide information about quantities where these events may (e.g., need to) be evaluated, reported, and used for decisions to perform beam switching, cell switching, or for general use (e.g., all) conditional reconfigurations. The virtual measurement objects may provide some parameters that may be used to select certain aspects of the non-measurement data. They may provide a selection of parameters to be used in situations where a non-3GPP interface or local sensor may be known to provide information in multiple forms and formats (e.g., when a non-3GPP interface or local sensor may be known to provide information in multiple forms and formats). These measurement objects may also indicate special filtering applied to these non-radio measurement quantities through updated quantity configurations.

[0213] Measurement ID without measurement object:

[0214] According to an embodiment, the 3GPP measurement framework is extended to span data from non-3GPP RATs, local sensors and other sources, and measurement identifiers may be defined that may (e.g., only) provide pointers to report configurations without any measurement objects. The report configurations may be extended with new events and related parameters that may provide information to handle non-radio measurements in an appropriate manner.

[0215] Post-processing and filtering of measurements

[0216] For some non-radio measurements, the measurement object may provide a selection of appropriate parameters that may be retained and used as part of the non-radio measurement framework. The quantity configuration may provide additional post-processing or filtering coefficients that may be applied to the non-radio measurements. The purpose of such filtering or post-processing may be to perform additional processing to make these measurement quantities suitable for 3GPP procedures, such as for mobility and conditional reconfiguration.

[0217] Measurement reporting, triggering and conditional (re)configuration

[0218] The reporting of non-radio measurements may work in much the same way as radio measurements. The same may be true for the role of non-radio measurements for triggering events and the use of these measurements and indicated events for mobility procedures and condition reconfiguration.

[0219] For the embodiments presented in the present disclosure, one of the (e.g., basic) topics may be an appropriate part of network sharing deployment integration, and the WTRU (e.g., UE) is able to make intelligent decisions, trigger changes in beams and cells, use local radio and non-radio measurements during mobility procedures such as beam recovery, conditional switching, conditional PSCell addition / change, etc.

[0220] The reporting configuration may be extended to include new non-measurement data based events where the WTRU (e.g., UE) may use data from local sensors. These events may use deployment properties of cells and beams, including both services (from the primary cell group or secondary cell group) and neighboring cells / beams obtained from the deployment configuration. Events may be created based on sensor non-measurement data. These events may be combined with measurement data events to, for example, verify whether a cell / beam is suitable for certain signal strengths, etc. In another compatible approach, composite events may be designed where conditions may be specified for non-measurement data quantities (such as position / angle) and measurement quantities (such as SSB / CSI-RS RSRP / RSRQ / SINR), and these composite events may be triggered where appropriate conditions from both groups may be specified (e.g., when appropriate conditions from both groups may be specified). The triggering of these composite events may result in the execution of conditional (re)configuration.

[0221] The current condition reconfiguration may have multiple (e.g., up to 2) measurement identifiers. In the case where (e.g., it is necessary) to use events based on non-measurement data in conjunction with events based on measurement data, the number of events may (e.g., it is necessary) to increase. In compatible embodiments, joint measurement and non-measurement events may be created.

[0222] The WTRU (e.g., UE) may evaluate events configured by appropriate combinations of radio and non-radio measurements. Details of how these events are used in specific procedures are explained in the related embodiments. Some example events for non-radio measurements are described in the following subsections.

[0223] Event V1 [Speed ​​becomes greater than a certain threshold]

[0224] The WTRU (e.g., UE) shall:

[0225] - consider the entry condition of this event satisfied if (e.g., when) the condition V1-1 specified below can be satisfied;

[0226] - consider the exit condition of this event satisfied if (e.g., when) the conditions V1-2 specified below can be satisfied;

[0227] Inequality V1-1 (entry condition 1):

[0228] Mv-Hys>Thresh1.

[0229] Inequality V1-2 (leaving condition 1):

[0230] Mv+Hys<Thresh2.

[0231] The variables in the formula can be defined as follows:

[0232] Mv may be the WTRU (eg, UE) speed estimated by the WTRU (eg, UE) through its local sensors without taking into account any offset.

[0233] Hys may be the hysteresis parameter for this event (ie, the hysteresis defined in the configuration for this event).

[0234] Thresh1 may be the threshold for this event, defined as the reference speed within the configuration of this event, and used as the speed threshold for entering this event.

[0235] Thresh2 may be the threshold of this event, defined as the reference speed within the configuration of this event, and used as the speed threshold for exiting this event.

[0236] Mv can be expressed in kilometers per hour.

[0237] Hys can be expressed in the same units as Mv.

[0238] Thresh1 and Thresh1 can be expressed in the same units as Mv.

[0239] The definition of Event V1 can also be applied to CondEvent V1.

[0240] Event R1 [The amount of device rotation is greater than a certain threshold]

[0241] The WTRU (e.g., UE) shall:

[0242] - consider the entry condition of this event satisfied if (e.g., when) the condition R1-1 specified below can be satisfied;

[0243] - consider the exit condition of this event satisfied if (e.g., when) the conditions R1-2 specified below can be satisfied;

[0244] Inequality R1-1 (entry condition 1):

[0245] Mr-Hys>Thresh1.

[0246] Inequality R1-2 (leaving condition 1):

[0247] Mr+Hys<Thresh2.

[0248] The variables in the formula can be defined as follows:

[0249] Mr may be the WTRU (eg, UE) rotation estimated by the WTRU (eg, UE) through its local sensors without taking into account any offset, where the duration of the rotation estimation may not exceed the duration Td configured as part of the configuration.

[0250] Hys may be the hysteresis parameter for this event (ie, the hysteresis defined in the configuration for this event).

[0251] Threshl may be the threshold for this event, defined as the amount of reference rotation within the configuration of this event, and used as the rotation threshold for entering this event.

[0252] Thresh2 may be the threshold for this event, defined as the amount of reference rotation within the configuration of this event, and used as the rotation threshold for leaving this event.

[0253] Mr may be expressed in degrees. In compatible embodiments, Mr may be expressed in radians. In a flexible approach, the units of Mr may be configured as part of the configuration.

[0254] Hys can be expressed in the same units as Mr.

[0255] Thresh1 and Thresh2 can be expressed in the same units as Mr.

[0256] The definition of Event R1 can also be applied to CondEvent R1.

[0257] Event O1 [Device orientation changed from service orientation greater than threshold]

[0258] The WTRU (e.g., UE) shall:

[0259] - consider the entry condition of this event to be satisfied if (eg, when) the condition O1-1 specified below can be satisfied;

[0260] - consider the exit condition of this event satisfied if (e.g., when) the conditions O1-2 specified below can be satisfied;

[0261] Inequality O1-1 (entry condition 1):

[0262] Mo-Hys>Thresh1.

[0263] Inequality O1-2 (leaving condition 1):

[0264] Mo+Hys<Thresh2.

[0265] The variables in the formula can be defined as follows:

[0266] Mr may be the WTRU (eg, UE) rotation estimated by the WTRU (eg, UE) through its local sensors without taking into account any offset, where the duration of the rotation estimation may not exceed the duration Td configured as part of the configuration.

[0267] Hys may be the hysteresis parameter for this event (ie, the hysteresis defined in the configuration for this event).

[0268] Threshl may be the threshold for this event, defined as the amount of reference rotation within the configuration of this event, and used as the rotation threshold for entering this event.

[0269] Thresh2 may be the threshold for this event, defined as the amount of reference rotation within the configuration of this event, and used as the rotation threshold for exiting this event.

[0270] Mr may be expressed in degrees. In compatible embodiments, Mr may be expressed in radians. In a flexible approach, the units of Mr may be configured as part of the configuration.

[0271] Hys can be expressed in the same units as Mr.

[0272] Thresh1 and Thresh2 can be expressed in the same units as Mr.

[0273] The definition of Event R1 can also be applied to CondEvent R1.

[0274] Event OD1 [Device orientation and distance matching a given TRP's location within a certain threshold]

[0275] The WTRU (e.g., UE) shall:

[0276] - consider the entry condition of this event to be satisfied when both the condition OD1-1 and the condition OD1-2 specified below are satisfied (e.g., when both the condition OD1-1 and the condition OD1-2 specified below are satisfied);

[0277] - consider the exit condition of this event satisfied if (e.g., when) the condition OD1-3 or the condition OD1-4 specified below can be satisfied;

[0278] Inequality OD1-1 (entry condition 1) [the device has an absolute orientation that matches the target cell beam]:

[0279] abs(Ou-Thresh1)<Hys1.

[0280] Inequality OD1-2 (entry condition 2) [device is within the appropriate distance from the target TRP]:

[0281] Ml+Hys2<Thresh2.

[0282] Inequality OD1-3 (leaving condition 1):

[0283] abs(Ou-Thresh1)>Hys1.

[0284] Inequality OD1-4 (leaving condition 2):

[0285] Ml-Hys2>Thresh2.

[0286] The variables in the formula can be defined as follows:

[0287] Ml can be the WTRU (e.g., UE) location, represented by the distance between the WTRU (e.g., UE) and the reference location parameter of this event (i.e., the reference location of the candidate TRP for this event), without considering any offset.

[0288] Ou may be the absolute orientation of the WTRU (eg, UE) estimated by the WTRU (eg, UE) through its local sensors, without taking into account any offset.

[0289] Hys1 may be a hysteresis parameter for the orientation condition for this event.

[0290] Threshl may be the threshold for this event, defined as the amount of reference orientation within the configuration of this event, and used as the rotation threshold for entering this event.

[0291] Thresh2 may be the threshold for this event, defined as the distance from the reference location configured in the configuration for this event.

[0292] Ou may be expressed in degrees relative to a configured measurement reference. In compatible embodiments, Ou may be expressed in radians. In a flexible approach, the units of Ou may be configured as part of the configuration.

[0293] Hys1 can be expressed in the same units as Ou.

[0294] Thresh1 can be expressed in the same units as Ou.

[0295] Ml can be expressed in meters.

[0296] Hys2 can be expressed in the same units as M1.

[0297] Thresh2 can be expressed in the same units as M1.

[0298] The definition of event OD1 can also be applied to CondEvent OD1.

[0299] Event OD2 [Device orientation and distance match the location of a given TRP better than the serving TRP based on configured thresholds]

[0300] The WTRU (e.g., UE) shall:

[0301] - consider the entry condition of this event to be satisfied when both the condition OD2-1 and the condition OD2-2 specified below are satisfied (e.g., when both the condition OD2-1 and the condition OD2-2 specified below are satisfied);

[0302] - consider the exit condition of this event satisfied if (e.g., when) the condition OD2-3 or the condition OD2-4 specified below can be satisfied;

[0303] Inequality OD2-1 (entry condition 1) [the device has an absolute orientation, and the degree of alignment with the target cell TRP is better than the serving cell orientation]:

[0304] abs(Ou-On)-Hys1<abs(Ou-Op).

[0305] Inequality OD2-2 (entry condition 2) [the device can be within a suitable distance from the target TRP]:

[0306] Dn-Hys2<Dp.

[0307] Inequality OD2-3 (leaving condition 1):

[0308] abs(Ou-On)+Hs1>abs(Ou-Op).

[0309] Inequality OD2-4 (leaving condition 2):

[0310] Dn+Hys2>Dp.

[0311] The variables in the formula can be defined as follows:

[0312] Ou may be the WTRU's (eg, UE's) reference orientation in absolute units estimated by the WTRU (eg, UE) through its local sensors, without taking into account any offset.

[0313] Op may be the orientation of the serving TRP relative to the WTRU (eg, UE) in absolute units, estimated by the WTRU (eg, UE) using the location of the serving TRP received in the configuration.

[0314] On may be the orientation of the neighboring TRP relative to the WTRU (eg, UE) in absolute units, estimated by the WTRU (eg, UE) using the position of the neighboring TRP received in the configuration.

[0315] Hys1 may be a hysteresis parameter for the orientation condition for this event.

[0316] Dp may be the distance between the WTRU (eg, UE) location and the location of the serving TRP, where the location of the serving TRP may be part of the configuration.

[0317] Dn may be the distance between the WTRU (eg, UE) location and the neighboring TRP location, where the location of the neighboring TRP may be part of the configuration.

[0318] Hys2 may be a hysteresis parameter for the distance condition for this event.

[0319] Ou may be expressed in degrees relative to a configured measurement reference. In compatible embodiments, Ou may be expressed in radians. In a flexible approach, the units of Ou may be configured as part of the configuration.

[0320] Op, On and Hys1 can be expressed in the same units as Ou.

[0321] Dn can be expressed in meters.

[0322] Dp and Hys2 can be expressed in the same units as Dn.

[0323] The definition of event OD2 can also be applied to CondEvent OD2.

[0324] Event CM1 [Device crosses the boundary of a specific area in the coverage integration]

[0325] The WTRU (e.g., UE) shall:

[0326] - consider the entry condition of this event to be satisfied if (eg, when) the condition CM1-1 specified below can be satisfied;

[0327] - consider the exit condition of this event satisfied if (e.g., when) the conditions CM1-2 specified below can be satisfied;

[0328] Inequality CM1-1 (entry condition) [device crosses the boundary in the covering integration]

[0329] Ml1-Hys>Thresh1

[0330] Inequality CM1-2 (leave condition)

[0331] Ml1+Hys<Thresh1

[0332] The variables in the formula can be defined as follows:

[0333] Ml1 may be the WTRU (e.g., UE) location, represented by the distance between the WTRU (e.g., UE) and the reference location parameter for this event, without taking into account any offset. The reference location parameter may be configured as the center of the area or a suitable reference point for the area. It may be configured as the location of the TRP serving this particular area.

[0334] Hys may be the hysteresis parameter for this event (ie, the hysteresis defined in reportConfigNR for this event).

[0335] Thresh1 may be the threshold for this event and is defined as the distance from a reference location (e.g., serving TRP) to the boundary of the coverage integration. The WTRU (e.g., UE) may derive Thresh1 from the coverage integration based on the configuration using information of its current location, serving TRP location, and boundary definition. The boundary definition may correspond to coverage of an RNA, TA, PLMN, or even TRP coverage. The configuration may provide information on whether Thresh1 may be the LOS distance (in which case Thresh1 may be the distance of the coverage boundary on the line connecting the serving TRP and the UE) or whether a different calculation may be used.

[0336] Ml1 can be expressed in meters.

[0337] Hys can be expressed in the same units as Ml1.

[0338] Thresh1 can be expressed in the same units as Ml1.

[0339] The definition of Event CM1 can also be applied to CondEvent CM1.

[0340] 3.3.4.7 Event CM2 [Device enters a specific area in the coverage integration]

[0341] The WTRU (e.g., UE) shall:

[0342] - consider the entry condition of this event to be satisfied if (eg, when) the condition CM2-1 specified below can be satisfied;

[0343] - consider the exit condition of this event satisfied if (e.g., when) the condition CM2-2 specified below can be satisfied;

[0344] Inequality CM2-1 (entry condition) [device enters a specific area in the coverage integration]:

[0345] Ml1-Hys<Thresh1.

[0346] Inequality CM1-2 (leave condition):

[0347] Ml1+Hys>Thresh1.

[0348] The variables in the formula can be defined as follows:

[0349] M11 may be the WTRU (eg, UE) location represented by the distance between the WTRU (eg, UE) and a reference location parameter for this event, without taking into account any offset. The reference location may be attributed to a specific area that may be associated with this event.

[0350] Hys may be the hysteresis parameter for this event (ie, the hysteresis defined in reportConfigNR for this event).

[0351] Thresh1 may be a threshold for this event and is defined as the distance from a reference location (e.g., a reference gNB / TRP location of a reference area) to the boundary of the coverage integration. The WTRU (e.g., UE) may derive Thresh1 from the coverage integration based on the configuration using information of its current location, the reference gNB / TRP location, and the boundary definition. The boundary definition may correspond to coverage of an RNA, a TA, a PLMN, or even gNB / TRP coverage. The configuration may provide information on whether Thresh1 may be the LOS distance (in which case Thresh1 may be the distance of the coverage boundary on the line connecting the reference TRP and the UE) or whether a different calculation may be used.

[0352] Ml1 can be expressed in meters.

[0353] Hys can be expressed in the same units as Ml1.

[0354] Thresh1 can be expressed in the same units as Ml1.

[0355] The definition of Event CM2 can also be applied to CondEvent CM2.

[0356] 3.3.4.8 Joint event J1 [CM2&&A4] [Device enters a specific area in the coverage integration, and the reference cell in the area becomes better than the threshold]

[0357] The WTRU (e.g., UE) shall:

[0358] - consider the entry condition of this event to be satisfied in the case where the condition J1-1 and the condition J1-2 specified below can be satisfied (e.g., when the condition J1-1 and the condition J1-2 specified below can be satisfied);

[0359] - consider the exit condition of this event satisfied if the conditions J1-3 or J1-4 specified below can be satisfied (e.g., when the conditions J1-3 or J1-4 specified below can be satisfied);

[0360] Inequality J1-1 (entry condition) [device enters a specific region in the coverage integration]:

[0361] Ml-Hys1<Thresh1.

[0362] Inequality J1-2 (entry condition):

[0363] Mn+Ofn+Ocn–Hys2>Thresh2.

[0364] Inequality J1-3 (leave condition):

[0365] Ml+Hys1>Thresh1.

[0366] Inequality J1-4 (leave condition):

[0367] Mn+Ofn+Ocn+Hys2 <Thresh2。

[0368] The variables in the formula can be defined as follows:

[0369] M1 may be the WTRU (eg, UE) location represented by the distance between the WTRU (eg, UE) and a reference location parameter for this event, without taking into account any offset. The reference location may be attributed to a specific area that may be associated with this event.

[0370] Hys1 may be the hysteresis parameter to be used for this event for location conditions (ie, the hysteresis defined within reportConfigNR for this event).

[0371] Thresh1 may be a threshold for this event and is defined as the distance from a reference location (e.g., a reference gNB / TRP location of a reference area) to the boundary of the coverage integration. The WTRU (e.g., UE) may derive Thresh1 from the coverage integration based on the configuration using information of its current location, the reference gNB / TRP location, and the boundary definition. The boundary definition may correspond to coverage of an RNA, a TA, a PLMN, or even gNB / TRP coverage. The configuration may provide information on whether Thresh1 may be the LOS distance (in which case Thresh1 may be the distance of the coverage boundary on the line connecting the reference TRP and the UE) or whether a different calculation may be used.

[0372] Mn may be the measurement result of the neighboring cells without considering any offset.

[0373] Ofn may be the measurement object specific offset of the neighboring cell (ie, offsetMO defined in measObjectNR corresponding to the neighboring cell).

[0374] Ocn may be the measurement object specific offset of the neighboring cell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the neighboring cell) and is set to zero if not configured for the neighboring cell.

[0375] Hys2 may be the hysteresis parameter to be used for this event of the cell measurement condition (ie, the hysteresis defined within reportConfigNR for this event).

[0376] Thresh2 may be the threshold parameter for this event (ie, a4-threshold defined in reportConfigNR for this event).

[0377] Ml can be expressed in meters.

[0378] Hys1 can be expressed in the same units as Ml1.

[0379] Thresh1 can be expressed in the same units as Ml1.

[0380] Mn may be expressed in dBm in the case of RSRP, or in dB in the case of RSRQ and RS-SINR.

[0381] Ofn, Ocn, and Hys2 can be expressed in dB.

[0382] Thresh2 can be expressed in the same units as Mn.

[0383] The definition of Event J1 can also be applied to CondEvent J1.

[0384] Joint Event J2 [OD2&&A4] [Device orientation and distance match the location of a given TRP better than the serving TRP according to configured thresholds]

[0385] The WTRU (e.g., UE) shall:

[0386] - consider the entry condition of this event satisfied when the conditions J2-1, J2-2 and J2-3 specified below can be satisfied (e.g., when the conditions J2-1, J2-2 and J2-3 specified below can be satisfied);

[0387] - consider the departure condition of this event satisfied if any one of the conditions J2-4, J2-5 or J2-6 specified below can be satisfied (e.g., when any one of the conditions J2-4, J2-5 or J2-6 specified below can be satisfied);

[0388] Inequality J2-1 (entry condition 1) [the device has an absolute orientation, and the degree of alignment with the target cell TRP is better than the serving cell orientation]:

[0389] abs(Ou-On)-Hys1<abs(Ou-Op).

[0390] Inequality J2-2 (entry condition 2) [device can be within a suitable distance from the target TRP]:

[0391] Dn-Hys2<Dp.

[0392] Inequality J1-3 (entry condition):

[0393] Mn+Ofn+Ocn–Hys3>Thresh3.

[0394] Inequality J2-4 (leaving condition 1):

[0395] abs(Ou-On)+Hys1>abs(Ou-Op).

[0396] Inequality J2-5 (leaving condition 2):

[0397] Dn+Hys2>Dp

[0398] Inequality J2-6 (leaving condition 3):

[0399] Mn+Ofn+Ocn+Hys3 <Thresh3。

[0400] The variables in the formula can be defined as follows:

[0401] Ou may be the WTRU's (eg, UE's) reference orientation in absolute units estimated by the WTRU (eg, UE) through its local sensors, without taking into account any offset.

[0402] Op may be the orientation of the serving TRP relative to the WTRU (eg, UE) expressed in absolute units, estimated by the WTRU (eg, UE) using the position of the serving TRP received in the configuration.

[0403] On may be the orientation of the neighboring TRP relative to the WTRU (e.g., UE) expressed in absolute units, estimated by the WTRU (e.g., UE) using the position of the neighboring TRP received in the configuration.

[0404] Hys1 may be a hysteresis parameter for the orientation condition for this event.

[0405] Dp may be the distance between the WTRU (eg, UE) location and the location of the serving TRP, where the location of the serving TRP may be part of the configuration.

[0406] Dn may be the distance between the WTRU (eg, UE) location and the neighboring TRP location, where the location of the neighboring TRP may be part of the configuration.

[0407] Hys2 may be a hysteresis parameter for the distance condition for this event.

[0408] Mn may be the measurement result of the neighboring cells without considering any offset.

[0409] Ofn may be the measurement object specific offset of the neighboring cell (ie, offsetMO defined in measObjectNR corresponding to the neighboring cell).

[0410] Ocn may be the measurement object specific offset of the neighboring cell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the neighboring cell) and is set to zero if not configured for the neighboring cell.

[0411] Hys3 may be the hysteresis parameter to be used for this event of the cell measurement condition (ie, the hysteresis defined within reportConfigNR for this event).

[0412] Thresh3 may be the threshold parameter for this event (ie, a4-threshold defined in reportConfigNR for this event).

[0413] Ou may be expressed in degrees relative to a configured measurement reference. In compatible embodiments, Ou may be expressed in radians. In a flexible approach, the units of Ou may be configured as part of the configuration.

[0414] Op, On and Hys1 can be expressed in the same units as Ou.

[0415] Dn can be expressed in meters.

[0416] Dp and Hys2 can be expressed in the same units as Dn.

[0417] Mn may be expressed in dBm in the case of RSRP, or in dB in the case of RSRQ and RS-SINR.

[0418] Ofn, Ocn, and Hys3 can be expressed in dB.

[0419] Thresh3 can be expressed in the same unit as Mn.

[0420] The definition of Event J2 can also be applied to CondEvent J2.

[0421] Joint event J3 [CM2&&A3] [Device enters a specific area in the coverage integration, and the reference cell in this area becomes better than SpCell]

[0422] The WTRU (e.g., UE) shall:

[0423] - consider the entry condition of this event to be satisfied in the case where the condition J3-1 and the condition J3-2 specified below can be satisfied (e.g., when the condition J3-1 and the condition J3-2 specified below can be satisfied);

[0424] - consider the departure condition of this event satisfied if the condition J3-3 or J3-4 specified below can be satisfied (e.g., when the condition J3-3 or J3-4 specified below can be satisfied);

[0425] Inequality J3-1 (entry condition) [device enters a specific region in the coverage integration]:

[0426] Ml-Hys1<Thresh1.

[0427] Inequality J3-2 (entry condition):

[0428] Mn+Ofn+Ocn–Hys2>Mp+Ofp+Ocp+Off.

[0429] Inequality J3-3 (leaving condition):

[0430] Ml+Hys1>Thresh1.

[0431] Inequality J3-4 (leave condition):

[0432] Mn+Ofn+Ocn+Hys2 <Mp+Ofp+Ocp+Off。

[0433] The variables in the formula can be defined as follows:

[0434] M1 may be the WTRU (eg, UE) location represented by the distance between the WTRU (eg, UE) and a reference location parameter for this event, without taking into account any offset. The reference location may be attributed to a specific area that may be associated with this event.

[0435] Hys1 may be the hysteresis parameter to be used for this event for location conditions (ie, the hysteresis defined within reportConfigNR for this event).

[0436] Thresh1 may be a threshold for this event and is defined as the distance from a reference location (e.g., a reference gNB / TRP location of a reference area) to the boundary of the coverage integration. The WTRU (e.g., UE) may derive Thresh1 from the coverage integration based on the configuration using information of its current location, the reference gNB / TRP location, and the boundary definition. The boundary definition may correspond to coverage of an RNA, a TA, a PLMN, or even gNB / TRP coverage. The configuration may provide information on whether Thresh1 may be the LOS distance (in which case Thresh1 may be the distance of the coverage boundary on the line connecting the reference TRP and the UE) or whether a different calculation may be used.

[0437] Mn may be the measurement result of the neighboring cells without considering any offset.

[0438] Ofn may be the measurement object specific offset of the neighboring cell (ie, offsetMO defined in measObjectNR corresponding to the neighboring cell).

[0439] Ocn may be the measurement object specific offset of the neighboring cell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the neighboring cell) and is set to zero if not configured for the neighboring cell.

[0440] Mp can be the measurement result of SpCell without considering any offset.

[0441] Ofp may be a measurement object specific offset of the SpCell (ie, offsetMO defined within the measObjectNR corresponding to the SpCell).

[0442] Ocp may be a cell-specific offset for the SpCell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the SpCell) and may be set to zero if not configured for the SpCell.

[0443] Off may be the offset parameter of this event (ie, a3-offset defined in reportConfigNR for this event).

[0444] Hys2 may be the hysteresis parameter to be used for this event of the cell measurement condition (ie, the hysteresis defined within reportConfigNR for this event).

[0445] Ml can be expressed in meters.

[0446] Hys1 can be expressed in the same units as Ml1.

[0447] Thresh1 can be expressed in the same units as Ml1.

[0448] In the case of RSRP, Mn, Mp can be expressed in dBm, or in the case of RSRQ and RS-SINR, in dB.

[0449] Ofn, Ocn, Ofp, Ocp, Hys2, and Off can be expressed in dB.

[0450] The definition of Event J3 can also be applied to CondEvent J3.

[0451] Joint Event J4 [OD2&&A3] [Device orientation and distance match the location of a given TRP better than the serving TRP according to configured thresholds, and the reference cell in the area is better than SpCell]

[0452] The WTRU (e.g., UE) shall:

[0453] - consider the entry condition of this event satisfied when the conditions J4-1, J4-2 and J4-3 specified below can be satisfied (e.g., when the conditions J4-1, J4-2 and J4-3 specified below can be satisfied);

[0454] - consider the departure condition of this event satisfied if any one of the conditions J4-4, J4-5 or J4-6 specified below can be satisfied (e.g., when any one of the conditions J4-4, J4-5 or J4-6 specified below can be satisfied);

[0455] Inequality J4-1 (entry condition 1) [the device has an absolute orientation, and the degree of alignment with the target cell TRP is better than the serving cell orientation]:

[0456] abs(Ou-On)-Hys1<abs(Ou-Op).

[0457] Inequality J4-2 (entry condition 2) [device can be within a suitable distance from the target TRP]:

[0458] Dn-Hys2 <Dp。

[0459] Inequality J4-3 (entry condition):

[0460] Mn+Ofn+Ocn–Hys3>Mp+Ofp+Ocp+Off.

[0461] Inequality J4-4 (leaving condition 1):

[0462] abs(Ou-On)+Hys1>abs(Ou-Op).

[0463] Inequality J4-5 (leaving condition 2):

[0464] Dn+Hys2>Dp.

[0465] Inequality J4-6 (leaving condition 3):

[0466] Mn+Ofn+Ocn+Hys3 <Mp+Ofp+Ocp+Off。

[0467] The variables in the formula can be defined as follows:

[0468] Ou may be the WTRU's (eg, UE's) reference orientation in absolute units estimated by the WTRU (eg, UE) through its local sensors, without taking into account any offset.

[0469] Op may be the orientation of the serving TRP relative to the WTRU (eg, UE) expressed in absolute units, estimated by the WTRU (eg, UE) using the position of the serving TRP received in the configuration.

[0470] On may be the orientation of the neighboring TRP relative to the WTRU (e.g., UE) expressed in absolute units, estimated by the WTRU (e.g., UE) using the position of the neighboring TRP received in the configuration.

[0471] Hys1 may be a hysteresis parameter for the orientation condition for this event.

[0472] Dp may be the distance between the WTRU (eg, UE) location and the location of the serving TRP, where the location of the serving TRP may be part of the configuration.

[0473] Dn may be the distance between the WTRU (eg, UE) location and the neighboring TRP location, where the location of the neighboring TRP may be part of the configuration.

[0474] Hys2 may be a hysteresis parameter for the distance condition for this event.

[0475] Mn may be the measurement result of the neighboring cells without considering any offset.

[0476] Ofn may be the measurement object specific offset of the neighboring cell (ie, offsetMO defined in measObjectNR corresponding to the neighboring cell).

[0477] Ocn may be the measurement object specific offset of the neighboring cell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the neighboring cell) and is set to zero if not configured for the neighboring cell.

[0478] Mp can be the measurement result of SpCell without considering any offset.

[0479] Ofp may be a measurement object specific offset of the SpCell (ie, offsetMO defined within the measObjectNR corresponding to the SpCell).

[0480] Ocp may be a cell-specific offset for the SpCell (i.e., cellIndividualOffset defined within measObjectNR corresponding to the SpCell) and may be set to zero if not configured for the SpCell.

[0481] Off may be the offset parameter of this event (ie, a3-offset defined in reportConfigNR for this event).

[0482] Thresh3 may be the threshold parameter for this event (ie, a4-threshold defined in reportConfigNR for this event).

[0483] Ou may be expressed in degrees relative to a configured measurement reference. In compatible embodiments, Ou may be expressed in radians. In a flexible approach, the units of Ou may be configured as part of the configuration.

[0484] Op, On and Hys1 can be expressed in the same units as Ou.

[0485] Dn can be expressed in meters.

[0486] Dp and Hys2 can be expressed in the same units as Dn.

[0487] In the case of RSRP, Mn, Mp can be expressed in dBm, or in the case of RSRQ and RS-SINR, in dB.

[0488] Ofn, Ocn, Ofp, Ocp, Hys3, and Off can be expressed in dB.

[0489] The definition of Event J4 can also be applied to CondEvent J4.

[0490] Additional examples of joint events

[0491] The previous subsections have provided some key exemplary events that combine measurements from radio measurements and non-radio measurements into suitable events that can be used to achieve zero-interruption of mobility by triggering conditional (re)configuration (such as beam failure recovery, conditional handover, conditional PSCell change / addition, etc.). These examples can be used to jointly create additional events from radio measurements and non-radio measurements that can identify target scenarios in a very precise manner, and through these combinations, select the most appropriate beam / cell / TRP / network node (e.g., gNB) in a fast manner.

[0492] In the example of combined events, events A3 and A4 have been combined with non-radio measurements of orientation, distance or zone entry. Likewise, event A5 can be combined with non-radio measurements.

[0493] The examples of joint events J1, J2, J3 and J4 can be further combined with the speed / rate conditions used in event V1 to separate high-speed and low-speed scenarios and use appropriate beams / cells / TRPs accordingly.

[0494] For devices where only rotation is of interest, event R1 or event O1 can be combined with classical measured quantity events (A3, A4 and A5) etc. to create a conditional event focusing on rotation, which can then trigger an appropriate (re)configuration.

[0495] Reporting of non-radio measurements

[0496] If measurement objects are defined for non-radio measurements, the current 3GPP reporting framework may be fully adapted to the newly introduced non-radio measurements. Depending on the reporting configuration attributes (whether periodic or event triggered), the WTRU (e.g., UE) may provide non-radio measurements appropriately filtered according to the quantity configuration and / or provide the report to the network with an indication of the measurement identity, which is used as a reference for the report.

[0497] For alternative embodiments where the network may configure measurement identities without measurement objects, reporting of non-radio measurements may be based on the reporting configuration. In the absence of quantity configuration, no post-processing or filtering of non-radio measurements may be applied or predefined.

[0498] Active beam failure recovery based on non-radio measurements

[0499] According to an embodiment, a method is presented that may aim to recover from a beam failure event in a deterministic manner while minimizing cutouts and interruptions.

[0500] Since the cellular network may be a planned network, the network may have very precise knowledge of the deployment of its cells, and beams within these cells, with respect to coverage integration attributes such as the location (reference location) of the cell or transmit point (TRP), e.g., potential spatial transmit direction defined by the azimuth, elevation, and position coordinates of the TRP, beam width information (such as 3-dimensional (3D) beam width information, e.g., in the horizontal and vertical directions), transmit range information, coverage shape information (including, e.g., the location coordinates of the points constituting the coverage boundaries of the beam, cell, or TRP). What the network may not know in advance is the future movement (translation or rotation) of the device, e.g., how a particular WTRU (e.g., UE) may move from one cell / beam to another. In fact, the WTRU (e.g., UE) itself may not typically even be aware of this information. Similarly, in general, a WTRU (e.g., UE) may not have information about the network coverage integration as defined herein, or about the deployment of cells and beams and the geographical areas in which these cells / beams may be active. The terms "coverage integration" and "network deployment" may be used interchangeably hereinafter. The proposed method may provide a WTRU (e.g., UE) with a limited snapshot of the network deployment and suitable coordinates that bind the cell / beam to the geographic location and orientation for using a known cell / beam deployment from the network. The WTRU (e.g., UE) may use information from local sensors and interfaces to extract its current geographic parameters and mobility parameters. The WTRU (e.g., UE) geographic parameters may include any of the following, for example, WTRU (e.g., UE) location information such as absolute positioning, relative positioning relative to an object or other geographic marker, relative positioning relative to a reference location of a serving or neighboring cell / TRP. The WTRU (e.g., UE) mobility parameters may include any of the following, for example, WTRU (e.g., UE) mobility routing information, WTRU (e.g., UE) speed, direction, angular rotation, etc. The WTRU (e.g., UE) may use any of its geographic parameters, its mobility parameters, its capability information, and coverage integration information to determine a suitable candidate beam from the configuration provided by the network. This may ensure active restoration of the beam in the event of a beam failure.

[0501] According to an embodiment, a WTRU (e.g., UE) may provide assistance information (described in detail in the following paragraphs) to a network node (e.g., gNB). The network node (e.g., gNB) may use this information to prepare an active beam restoration configuration (including coverage integration information) and may provide it to the WTRU (e.g., UE). In case the quality of the serving beam is impaired, the WTRU (e.g., UE) may determine a suitable candidate beam, for example, based on any of: its current coverage integration configuration, its geographical parameters, its mobility parameters, its capabilities and other data available through its local sensors and possibly combined with other radio measurements, may verify the selected candidate and may perform beam restoration with the selected candidate. The assistance information may be a key element in the proposed method, which may first be transmitted to a network node (e.g., gNB) and may be used to prepare a suitable configuration for the target WTRU (e.g., UE). A new element of the configuration of the beams may be their association or mapping with the WTRU (e.g., UE) geographical coordinates or data from sensors plus other radio measurements. The network may provide this configuration to the WTRU (e.g., UE). The WTRU (e.g., UE) may use information from local sensors (which may be combined with radio measurements) to determine suitable candidate beams based on a configuration map from the network. Triggering criteria for determining suitable candidate beams, and triggering criteria for replacing a current serving beam by a suitable candidate beam may be described above. In the following, assistance information may be broadly defined, and (e.g., key) steps of the proposed active beam recovery procedure may be described.

[0502] The auxiliary information from the WTRU (e.g., UE) can be roughly divided into two groups, referred to as data based on radio signal measurements and data based on non-radio signal measurements. In the present disclosure, data based on radio signal measurements can be simply represented as measurement-based data, and data based on non-radio signal measurements can be represented as non-measurement-based data. A group may include (e.g., all) information that can be estimated, measured, determined with or without post-processing of signals received from the radio interface with or without considering mobility. The group may be referred to as measurement-based (e.g., radio measurement-based) data. This may include any of the following: receiving, measuring and processing reference signals on the physical layer, MAC information elements, RRC messages received from the network, or information received at a higher layer. The corresponding measurement quantity may be in the form of RSRP, RSSI, RSRQ, SNR, or SINR.

[0503] The second group may include (e.g., all) information that may not be extracted from network signaling. This group may be referred to as non-measurement-based data. A subgroup in the non-measurement-based data may include WTRU (e.g., UE) capabilities and implementation details, covering any of the following: its antenna panels, the respective fields of view of these panels, transceiver and power characteristics, switching delays, simultaneous operation of panels, etc. The second subgroup in the non-measurement-based data may include (e.g., all) information extracted or measured by local sensors and interfaces other than the radio interface, such as WTRU (e.g., UE) geographic parameters, such as WTRU (e.g., UE) location information, such as absolute position, relative position relative to an object or other geographic marker, reference position of a serving or neighboring cell / TRP, in the case where mobility may be considered. Examples of local sensors may be positioning sensors, gyroscopes, accelerometers, speed monitoring sensors, etc. Interfaces other than the radio interface under consideration may be wired interfaces (e.g., Ethernet), wireless interfaces (e.g., Bluetooth, WiFi), or any other proprietary wired or wireless interfaces. Another subgroup in the non-measurement-based data may include mobility indicators and configuration triggers. Examples of mobility indicators may be, for example, speed (translation or / and rotation), direction (translation or / and rotation), velocity, trajectory or / and mobility history. Relevant configuration triggers that facilitate mobility management and provide appropriate configuration may come from situational or contextual information, for example, a vehicle-mounted device (or in-vehicle device) starts its trajectory to a destination, where both the starting point and the trajectory may be very important from a configuration perspective. Another example may be starting an online game from an AR / VR device that potentially contains a user profile that may contain or provide user behavior in terms of rotation during the game. Such parameters may be updated by the WTRU (e.g., UE) upon receiving some BFR configuration from a network node (e.g., gNB). The network node (e.g., gNB) may update the BFR configuration after receiving updated assistance information from the WTRU (e.g., UE) or other factors.

[0504] In some cases, overlap may occur, i.e., similar information may be used in both the measurement-based and non-measurement-based groups. An example may be positioning, where the network may provide some positioning information (based on measurements), while the WTRU (e.g., UE) may be equipped with a local positioning sensor that may extract positioning information from any satellite system. In such cases, one or the other may be used, or both information sets may be combined to achieve better accuracy, granularity, or information quality.

[0505] Having defined the auxiliary information, the (e.g., key) steps of the proposed method can be summarized here and explained in detail later:

[0506] - A WTRU (e.g., UE) may provide assistance information to a network node (e.g., gNB). This assistance information consolidates and simplifies potential information that the WTRU (e.g., UE) may measure and obtain through signals received from the network, or it may obtain through other interfaces or extract from its local sensors. The WTRU (e.g., UE) may update its assistance information for certain parameters, at least under certain conditions.

[0507] - A network node (e.g., gNB) may provide an active beam restoration configuration in response to WTRU (e.g., UE) assistance information. This configuration may be based on the network deployment of cells, TRPs, beams, and assistance information provided by the WTRU (e.g., UE). The configuration preparation may take into account any historical data about WTRU (e.g., UE) parameters, application usage, WTRU (e.g., UE) subscription status, etc. The configuration preparation may use artificial intelligence and machine learning algorithms in order to use (e.g., all) network and WTRU (e.g., UE) data in a predictive manner to prepare a configuration suitable for the WTRU (e.g., UE).

[0508] - The active beam recovery configuration may include a set of candidate beams for recovery and map these candidate beams to appropriate parameters containing measurement-based data and non-measurement-based data. For example, the candidate beams may be mapped to the active area (in terms of positioning / location) and the WTRU orientation (in terms of WTRU antenna panel characteristics, such as angular span, etc.).

[0509] -After a mobility event (caused by device mobility or environmental mobility) leading to beam quality impairment or beam failure, the WTRU (e.g., UE) may use relevant information from radio measurements, non-radio measurements, or a combination, and process it according to configured thresholds. It identifies a suitable beam / cell from the network configured mapping and may perform a beam failure recovery procedure using the derived candidate beam. In an alternative embodiment, the WTRU (e.g., UE) may evaluate the triggering criteria for evaluating a suitable beam replacement in the event that the triggering criteria for evaluating a suitable beam replacement (i.e., the beam failure detection criteria as defined above) may be met (e.g., when the triggering criteria for evaluating a suitable beam replacement may be met). The WTRU (e.g., UE) may identify one (i.e., one or more) suitable beams according to the criteria for a candidate beam to be considered a suitable beam as defined above. The beam failure detection criteria of the proposed embodiment may be relaxed, i.e., the threshold may be set to a higher value so that a beam failure may be declared sooner and the proposed recovery mechanism may initiate replacement of a degraded beam sooner. This may allow active beam recovery to declare a beam failure sooner and recover to a known-good beam in a faster manner, thereby minimizing cutouts.

[0510] - The WTRU (e.g., UE) may evaluate the triggering criteria to evaluate the candidate beams defined above. In the event that the criteria for beam failure recovery defined above may be met (e.g., when the criteria for beam failure recovery may be met), the WTRU (e.g., UE) may identify one or more candidate beams as recovery beams. The WTRU (e.g., UE) may notify the network of the selected one or more candidate beams. The recovery process may involve transmitting a RACH on the selected beam.

[0511] - In a fully network controlled scheme, the WTRU (e.g., UE) may report to the network the measurement results of one or more suitable candidate beams and zero or more serving beams for replacement. The network may confirm to the WTRU (e.g., UE) the new serving beam to be used.

[0512] This section may divide WTRU (e.g., UE) assistance information into two groups: one group is referred to as measurement-based data and the other group is referred to as non-measurement-based data. The assistance information may be grouped in different ways. An embodiment compatible with the proposed method may classify the assistance information into data based on radio measurement quantities and data based on non-radio measurement quantities. The first group of data based on radio measurement quantities may include (e.g., all) radio measurements that can be configured by the radio network. This may include (e.g., all) measurements for NR, E-UTRAN, UTRAN, and WiFi, etc. Measurements related to different RATs may be existing measurement quantities, or support for new measurement quantities may be introduced. The second group of data based on non-radio measurement quantities groups (e.g., all) the remaining assistance information, which may help minimize interruptions in the beam failure recovery process. The information elements in this group may include parameters and quantities that the WTRU (e.g., UE) may be able to provide based on other local interfaces, local sensors, etc. A subset of this non-radio measurement based data may include a set of parameters and quantities related to WTRU (e.g., UE) capabilities and specific implementation details (including but not limited to antennas, panels, detailed implementations on antenna panels, such as field of view, power characteristics, radiation patterns, architectural details of how transceivers are linked to different panels, beam steering capabilities (including digital, analog / phase shift and hybrid based transition times for beam steering and panel switching delays, etc.)). Mobility-related triggers that facilitate mobility management from situational or contextual information, such as a vehicle-mounted device (or in-vehicle device) starting its trajectory to a destination, or a trigger regarding the start of an online game from an AR / VR device (which may include a user profile) may also be part of the non-radio measurement based data.

[0513] In different but compatible groupings of assistance information, three groups may be defined as data based on radio measurement quantities, data based on non-radio measurement quantities, and data based on UE capabilities and implementation. In this classification, data based on radio measurement quantities may be as defined previously. Data based on non-radio measurement quantities may include (e.g., all) measurements that may not be part of the first group and may be made through local interfaces and local sensors, and also mobility triggers that provide situation and context information. The third group may include a set of parameters and quantities related to WTRU (e.g., UE) capabilities and specific implementation details.

[0514] According to an embodiment, a network (e.g., a base station) may broadcast coverage integration information. A new coverage integration system information block (SIB) may be specified. It will be appreciated that in this case, the coverage integration information broadcast by a cell or TRP may be configured to reflect the local deployment environment of the cell or TRP broadcasting the coverage integration. For example, a PLMN may be subdivided into more than one coverage integration, which may overlap or may not be connected. A coverage integration may be associated with an area represented herein as a coverage integration area. A coverage integration area may correspond to one or more cells, a RAN notification area (RNA), a tracking area (TA), a PLMN, and the like. A WTRU (e.g., a UE) may receive coverage integration area configuration information in a coverage integration SIB, or through a new SIB dedicated to coverage integration area signaling (which may be represented herein as a coverage integration area SIB). A WTRU (e.g., a UE) may receive coverage integration area information through dedicated RRC signaling (e.g., an RRC reconfiguration message). Upon detecting a change in the coverage integration area, the WTRU (e.g., UE) may reacquire the coverage integration of its current location, for example, by reacquiring the coverage integration SIB, or by performing a dedicated RRC signaling exchange with the network (e.g., base station). The detection of a change in the coverage integration area by the WTRU (e.g., UE) may include any of the following:

[0515] - Change of serving cell or (re)selection to a cell which may not belong to the current coverage integration area.

[0516] - (Re)selection to RNAs that may not belong to or correspond to the currently covered integrated region.

[0517] -Execute the RNA update process, or transmit the RNA update message to the network (base station).

[0518] - (Re)selection to a TA that may not belong to the current coverage integration area, or may not correspond to the integration of the current coverage integration area.

[0519] -Perform the TA update procedure, or transmit a TA update message to the network (core network).

[0520] - (Re)selection to a PLMN which may not belong to the current coverage integration area, or which may not correspond to the integration of the current coverage integration area.

[0521] Coverage integration may be defined at different suitable granularities. The granularity of coverage integration may be part of the coverage integration configuration. In one embodiment, coverage integration may be defined at a cell level and information about geographic coverage from different gNBs / TRPs may be indicated to the WTRU (e.g., UE) using suitable signaling. Cell level coverage may be used for different handover and cell change procedures. Coverage integration granularity may be reflected in the form of areas representing the level of granularity. An area may be attributed to any (e.g., each) RNA, TA, or PLMN. For cell level procedures, the coverage integration area may have cell level granularity. For beam level procedures, where, for example, a WTRU (e.g., UE) may (e.g., need to) track, maintain, or switch beams, the coverage integration granularity may be at a beam level and areas in such coverage integration may be attributed to different beams.

[0522] A region in a coverage integration may indicate a geographic area that may correspond to a set of reference signals. For beam-level regions, in one embodiment, any (e.g., each) region may indicate a coverage area of ​​an SSB beam. In another beam-level region design, any (e.g., each) region may indicate a coverage area of ​​an SSB beam or a CSI-RS beam, where the SSB / CSI-RS beam may be coverage of a corresponding SSB / CSI-RS signal. For cell-level regions, a region may indicate an area in which this cell has sufficient coverage. A cell-level region may group all SSB / CSI-RS regions associated with a given cell, and it may represent an area in which any SSB / CSI-RS signal of this cell may be received with a known / configured quality. For coverage areas based on RNA, TA, or PLMN, the region representation may be extended to a larger granularity.

[0523] Any (e.g., each) area can have an identifier, where the identifier can be (e.g., explicitly) indicated as part of the area configuration. In another embodiment, the area identifier can be a deterministic combination of certain parameters according to the area granularity. These identifiers can be modulated with some configuration parameters. As an example, a beam-level area identifier can be a combination of a cell identifier and a beam identifier (SSB or CSI-RS). The cell-level area identifier can be a cell identifier, or a deterministic modification of the cell identifier in combination with certain other parameters. It can also be used for mapping to represent the coverage area of ​​RNA, TA, PLMN, etc.

[0524] A WTRU (e.g., UE) may derive information from radio measurements and non-radio measurements to assist in the mobility process. As an example, information derived from non-radio measurements containing geographic coordinates and orientation may enable a WTRU (e.g., UE) to derive its current area. More specifically, a WTRU (e.g., UE) may be configured by the network with a measurement configuration in which conditional events, event CM1 or event CM2 (as described in detail in Section 3.3) may be configured. In the event that the relevant conditions for these events may be satisfied (e.g., when the relevant conditions may be satisfied), the WTRU (e.g., UE) may determine a change in its current area. The WTRU (e.g., UE) may determine its new area, which may allow it to derive a suitable beam from the coverage integration corresponding to the updated area, verify the beam from the radio signal measurements, and initiate a beam recovery procedure. The same purpose may be achieved by configuring the WTRU (e.g., UE) by the network with events having conditions compounded by radio and non-radio measurements. These events may be defined as J1, J2, J3, and J4 in Section 3.3.4.

[0525] Active beam recovery process details

[0526] For various reasons, a WTRU (e.g., UE) may have limited discovery of neighboring beams around it, and it may find itself in a situation at any time where it is unable to pre-discover nearby detectable beams. This situation may result if the WTRU (e.g., UE) performs rapid translational movement, or performs a large rotation, or a combination of the two. This may also be due to a limited number of antennas, antenna panels, transceivers, or strict requirements on power consumption. These situations and / or aspects result in the WTRU (e.g., UE) discovering and reporting limited neighboring beams to the network. Using traditional beam management and beam recovery procedures, this may limit the configuration from the network, where the network can configure surrounding beams for potential recovery in the event of a failure of the current serving beam. The lack of beam recovery configuration for nearby detectable beams discovered by the WTRU (e.g., UE) may result in the beam failure process being unable to allow the WTRU (e.g., UE) to recover to these beams. This may ultimately result in a radio link failure, as both beam management and radio link monitoring may run in parallel at the WTRU (e.g., UE). The radio link failure may (eg, then) cause the WTRU (eg, UE) to perform a cell search and RRC configuration procedure from scratch, which may be very time consuming and detrimental to ongoing traffic flows.

[0527] Network Configuration:

[0528] According to an embodiment, a WTRU (e.g., UE) may provide assistance information to a network node (e.g., gNB). The information may include measurement-based data and non-measurement-based data as described above. Based on the received assistance information, the base station may provide the WTRU (e.g., UE) with a set of candidate beams around the geographic coordinates of the UE and a mapping associating the candidate beams with the new geographic coordinates. The updated geographic coordinates may be any subset of parameters from the assistance information. These parameters may be considered as parameters outside of the assistance information, but the network node (e.g., gNB) knows that the WTRU (e.g., UE) may be able to understand these parameters through its local sensors or other interfaces. In a simple example, the mapping of candidate beams may be provided based on an orientation indication of the candidate beams. The orientation indication may be in the form of an angular coverage relative to a suitable reference beam. The angular coverage may be defined using azimuth, elevation, or a combination of both. The reference beam indication may be part of the configuration. The reference beam may be defined as an SSB beam or a CSI-RS beam. The reference beam may be the actual beam through which the network can serve the WTRU (e.g., UE). Instead of a reference beam, other methods may be used to specify a reference direction, such as geographic north or some other reference that both the network and the WTRU (e.g., UE) can understand. In one example, the orientation information may be given relative to one or more configured transmit configuration indication (TCI) states, where the TCI state may contain QCL reference information with a DL or UL beam / RS. In another example, a mapping of candidate beam pair positions and orientations may be provided, both recorded in suitable coordinates and in an appropriately quantized form.

[0529] For any (e.g., each) beam in a configuration set, in addition to its angular span around the WTRU (e.g., UE), the network node (e.g., gNB) may provide relevant parameters to enable contention-free RACH access within that beam. This may include RACH parameters such as RACH preamble sequence identity, RACH duration, power ramp parameters, parameters related to the RACH occasions associated with the indicated beam, etc. The configuration may provide RACH parameters for 4-step RACH, 2-step RACH, or both. Additionally, priority RACH access parameters may be specified as part of the configuration to speed up beam failure recovery.

[0530] Another optimization may be to design special search spaces for beam failure recovery. In one embodiment, these search spaces may have higher periodicity to enable fast network feedback. They may also be made simpler to reduce WTRU (e.g., UE) decoding complexity for BFR message exchange.

[0531] Another approach could be to provide configuration of UL and DL bandwidth portions which should be enabled and used for beam failure recovery procedure. These could be different from active BWP pre-BFD events.

[0532] The configuration may also include conditions under which the configuration remains valid. The configuration may have a timer and the validity may expire when this timer expires. Another configuration release condition may be associated with mobility, i.e., if the configured device moves away from its last known location / position by more than a configured threshold, it may release the active configuration. For this purpose, suitable areas may be created by the configuration. The WTRU (e.g., UE) may track its areas. The exit condition may specify under what circumstances (e.g., when) the configuration is released. An example may be whether the WTRU (e.g., UE) has just moved out of its current area. In another example, the configuration may be valid in the current area and in a direct neighboring area with overlapping boundaries. In this case, if the WTRU (e.g., UE) moves out of the direct neighboring area, it may release the active configuration. Another example is where the configuration release condition may be associated with the timing advance value of the device (e.g., with the serving gNB), for example, if the device moves and the change in timing advance may be above a configured threshold, the device may be configured to release the currently active active configuration. More generally, any suitable combination of parameters from the auxiliary information may be used to define the validity condition and the release condition.

[0533] In another embodiment, one or more active configurations may be given to the device. A mapping / association of configurations to regions, locations, or timing advance values / ranges may be given to the device. The device may select a configuration based on tracking of an associated metric (region, location, timing advance, etc.).

[0534] For future systems based on very large-scale MIMO, which are capable of deploying thousands of beams at each TRP, in order to control the overhead, the network deployment of beams can follow certain rules and can be provided in a compact form. In one example, the beam deployment can follow a pattern in the azimuth and elevation dimensions. A set of patterns can be known in a tabular form or through a formula. The network can select a suitable pattern for its deployment based on its requirements in a given geographical area. For such cell and beam deployments, the network can provide the deployment pattern in a compact form to the WTRU (e.g., UE) as part of the active beam recovery configuration. The configuration may include the positioning of the TRP in suitable coordinates. A WTRU (e.g., UE) receiving such a configuration can determine the nearest TRP at any location and can determine the beam integration using the pattern indication. The parameters of any (e.g., each) constituent beam, its identity, associated reference symbol parameters, RACH occasions, RACH preambles, and other parameters can also be transmitted to the WTRU (e.g., UE) as part of the configuration in a suitable compact form.

[0535] Figure 5 An exemplary configuration of a WTRU (eg, UE) in communication with TRP1 is shown in FIG. The figure shows a configuration including an indication of a reference direction of a current beam as well as neighboring beams and their angular spans.

[0536] In this example diagram, a beam from TRP 2 may be configured with a span labeled as a start angle (β2s) and an end angle (β2e) relative to a reference (beam) direction. Similarly, the diagram shows an example beam from TRP 3 with a start and end angle as β3s and β3e. For any (e.g., each) configured beam, the network node (e.g., gNB) may provide RACH related details to allow contention-free RACH access (CFRA) within that beam. The same configuration information may be provided by providing an angle from the reference direction / beam to the center of the candidate beam and additionally providing the beamwidth for any (e.g., each) beam. This process may be further simplified if the beamwidth is the same for any (e.g., each) beam and then a single beamwidth may be provided for any (e.g., each) candidate beam.

[0537] WTRU (e.g., UE) procedures:

[0538] In the event that the quality of the beam that the WTRU (e.g., UE) can associate with may exist (e.g., when the quality of the beam that the WTRU can associate with may exist), the PHY layer may report a beam failure indication (BFI) to the MAC layer. In the event that the reference symbol associated with the beam drops below a configured threshold (e.g., when the reference symbol associated with the beam drops below a configured threshold), the PHY layer may generate a BFI indication. These conditions may be defined on SSB, CSI-RS, or a combination of both. For very large-scale MIMO, there may be new reference symbol structures. One embodiment may be in the form of a layered architecture where narrow beams may be overlaid on wider beams. There may be multiple layers of such variable width beams. The beam failure condition may be appropriately defined and configured using existing reference symbols or new reference symbols defined for emerging networks with a large number of beams and appropriate thresholds to be evaluated based on these reference symbols.

[0539] If a WTRU (e.g., UE) experiences a beam failure (e.g., due to a rapid rotation), the WTRU (e.g., UE) may obtain locally available rotation information from local sensors and / or gyroscopes. It may use the rotation information and the reference beam / direction indicated by the network to calculate its new orientation. The network configuration may indicate various beams and their angular coverage. The WTRU (e.g., UE) may determine the appropriate beam for its locally determined orientation after the rotation event. This allows the WTRU (e.g., UE) to know exactly which beam it should have line-of-sight connectivity with respect to its new orientation. Therefore, the WTRU (e.g., UE) may not need to perform blind decoding and cell search to find an SSB beam and then perform a lengthy beam refinement process to achieve a suitable active connection.

[0540] For example, after establishing a suitable beam from the configuration provided by the network node (e.g., gNB), the WTRU (e.g., UE) may use the configured parameters for beam recovery for its newly determined beam. It may send a contention-free RACH with the configured RACH parameters via the configured RACH resources linked to the determined suitable beam.

[0541] Message sequence diagram for Active BFR - Radio Measurement Events

[0542] Figure 6 A message sequence diagram of message exchanges between a WTRU (e.g., UE) and a network is shown, where the WTRU (e.g., UE) may be experiencing a beam failure. The WTRU (e.g., UE) may send assistance information to the network (S611). The assistance information may help the network prepare a suitable active beam recovery configuration. The WTRU (e.g., UE) may receive an active beam recovery configuration provided by the network (S612). In the event that the WTRU (e.g., UE) experiences a beam failure (S613) (e.g., when the WTRU experiences a beam failure), it may estimate its current position and orientation through local sensors (S614). Such information may be combined with radio measurements. The WTRU (e.g., UE) may determine a suitable recovery beam from the configuration it receives, which may correspond to its estimated position / orientation (S615). For example, after validating the beam through an appropriately configured threshold (S616), the WTRU (e.g., UE) may initiate a beam recovery procedure through the validated beam (S617).

[0543] While the network may use assistance information to prepare a suitable active beam restoration configuration, this may not be mandatory. The network may prepare the configuration without receiving any assistance information, relying primarily on its knowledge of the deployed network. The configuration may be further refined using network statistics, artificial intelligence, and machine learning algorithms applied to historical data.

[0544] Message sequence diagram for active BFR – joint events for radio and non-radio quantities

[0545] Figure 7 1 shows a message sequence diagram of message exchanges between a WTRU (e.g., UE) and a network, where the WTRU (e.g., UE) may be experiencing a beam failure. Most of the message exchanges (S711 to S713) in this sequence diagram may be related to Figure 6 Similar to the previous examples described in . A (e.g., critical) change may be a joint event using radio and non-radio measurement quantities, which may be used to trigger a beam recovery procedure on a suitable candidate beam. The network may provide the configuration of the joint radio and non-radio measurement triggers and events to the WTRU (e.g., UE) as part of the active beam recovery configuration. Examples of these joint events may be J1, J2, J3, and J4, as described in detail in Section 3.3.4. Upon experiencing a beam failure, the WTRU (e.g., UE) may evaluate the configured conditions (or joint events) (S714), and if the conditions for the candidate beam are met, the WTRU (e.g., UE) may initiate an active beam recovery procedure using a successful candidate beam (S715).

[0546] Message sequence chart for active BFR – Broadcast coverage integration and joint events for radio and non-radio traffic

[0547] Figure 8 A message sequence diagram of message exchanges between a WTRU (e.g., UE) and a network is shown, wherein the WTRU (e.g., UE) may perform the proposed active beam failure recovery process after experiencing a beam failure. The sequence diagram shows an embodiment in which the network may transmit a coverage integration as broadcast information. The broadcast coverage integration may be transmitted by a specific SIB. The WTRU (e.g., UE) may receive and may (e.g., locally) store the coverage integration (S811). The WTRU (e.g., UE) may receive an active beam recovery configuration provided by the network (S812). In the event that the WTRU (e.g., UE) experiences a beam failure (S813) (e.g., when the WTRU experiences a beam failure), it may estimate its current position and orientation through local sensors. Such information may be combined with radio measurements. The WTRU (e.g., UE) may evaluate trigger conditions and events to determine a suitable recovery beam from the configuration it receives, which may correspond to its estimated position / orientation. After validating the beam through a properly configured joint event combining radio measurement quantities and non-radio measurement quantities (S814), the WTRU (eg, UE) may initiate a beam recovery procedure with the validated candidate beam (S815).

[0548] Flowchart of the active beam recovery process

[0549] Fig. 9 A flow chart of the proposed active beam recovery process is shown.

[0550] For a WTRU (e.g., UE) in a connected (e.g., RRC_CONNECTED) state (S901), it may send high-level assistance information to the network / network node (e.g., gNB) (S902). This information from the WTRU (e.g., UE) may include measurement-based information and non-measurement-based information. Two broad categories of parameters and elements within the assistance information have been described in detail above. The assistance information may carry information from the WTRU (e.g., UE) situation / environment and running applications that may require unimpeded mobility. This may include some triggers that may indicate that a potential device may experience a mobility situation that may result in a cutoff. Examples of such triggers may be a car starting to move (which may result in high translational mobility), a head mounted display (HMD) device or other AR / VR gadget indicating the start of a virtual / mixed reality game (where rotational mobility and movement blockers may result in a cutoff), etc.

[0551] Based on the assistance information, the network node (e.g., gNB) may provide the WTRU (e.g., UE) with appropriate configurations for beam recovery (S903). The configuration may include candidate beams and appropriate mappings of these candidate beams to geographic coordinates (including but not limited to location / area / span, etc.). The network configuration may include parameters and thresholds that the WTRU (e.g., UE) applies to its updated geographic coordinates (e.g., area / location / positioning and span) using local sensors and interfaces, so as to select an appropriate beam from an appropriate TRP, for example, using a configured mapping table. The configuration may include at least two groups of configurations, one for handling device mobility, where the device may be undergoing translational and rotational movement, and another group of configurations focusing on external mobility, where the interruption may be caused by the environment rather than the result of direct device mobility. For example, external mobility caused by a mobile shield may provide beams / TRPs that may be able to provide coverage for a target device that has its known location / positioning at a network node (e.g., gNB) in the event that a serving beam may fail (e.g., when a serving beam may fail). In this step, the UE / device may be switched and enabled to a different panel and the network node (e.g. gNB) may provide an indication as part of the configuration. This indication in turn may be based on the WTRU (e.g. UE) providing its antenna panel, transceiver, switching delay and detailed feature set implementation and capabilities as part of its assistance information.

[0552] In compatible embodiments, a configuration may include multiple configurations. In one embodiment, two sub-configurations may be provided, where one sub-configuration may be applicable to translational mobility and the other sub-configuration may be applicable to rotational mobility and external mobility (including blocking events in the network). This may be useful because rotation of the device itself or shielding of a beam due to mobility in the network may require the device to select a beam with coverage for the same location but with a different orientation.

[0553] In a compatible approach, the network may provide a set of beam restoration configurations to the WTRU (e.g., UE). The network may provide associations of these configurations with different applications, different QoS (e.g., different reliability requirements), different power consumption targets at the WTRU (e.g., UE), WTRU (e.g., UE) active service subscription levels, etc. In the event of a beam failure event (e.g., when a beam failure event occurs), the WTRU (e.g., UE) may select an appropriate beam restoration configuration based on the configured criteria, based on the current situation. As previously described, multiple configurations may be associated with different physical parameters (e.g., external or device mobility), different service reliability targets (one configuration when higher reliability may be used (e.g., required), and one configuration for lower reliability), different subscription levels (one configuration in the case where the WTRU (e.g., UE) may be using paid content (e.g., when the WTRU (e.g., UE) may be using paid content), and one configuration for non-paid content), etc.

[0554] In the event that mobility causes the quality of the serving beam to be impaired according to the configured beam quality threshold, the WTRU (e.g., UE) may extract information from its local sensors (S904). The sensor information may be combined with radio measurements of existing or newly designed reference signals received from the network. An example may be combining local sensor data with measurements performed using downlink positioning reference signals.

[0555] The WTRU (eg, UE) may use this information to decide whether link failure may occur due to device mobility or external mobility (S905) and / or to select the correct candidate beam set from the device mobility (S907) or external mobility (S906) configuration.

[0556] The WTRU (e.g., UE) may provide information from local sensors in an appropriate format of location / area / orientation according to the configuration and may derive its location / orientation. Using this location / orientation, the WTRU (e.g., UE) may determine the appropriate beam (from the appropriate TRP) from the configured mapping (S908 to S909).

[0557] The entries in the mapping table may provide multiple candidate beams for a given location / orientation. In this case, the network node (e.g., gNB) may provide a priority order for the candidate beams and a priority order for the TRP. For example, the network may prioritize (e.g., bias) the beams and / or TRPs to optimize them for load balancing, energy saving, and / or deployment scenarios, etc. The WTRU (e.g., UE) may perform a beam recovery procedure on the determined beam using a configured set of recovery parameters. Beam recovery may typically be transmitting a contention-free RACH using configured parameters, such as indicating a RACH sequence number, RACH occasion, timing, and power ramp.

[0558] The WTRU (e.g., UE) may verify the selected TRP / beam combination according to the configured parameter settings (S910). Quality verification may be configured based on RSRP, RSRQ, or SINR using appropriately indicated measurement objects from the selected TRP / beam. If the selected configuration meets the quality criteria, the WTRU (e.g., UE) may select a RACH configuration associated with the selected TRP / beam (S911) and may transmit a RACH on the derived resources (S912).

[0559] In a compatible embodiment, to enable active beam failure recovery, the configuration of candidate beams may be provided as a unified configuration. In this unified configuration, (e.g., all) candidate beams and their priorities may be provided with their mapping to appropriate geographic coordinates, orientations, and associations with other parameters that the WTRU (e.g., UE) may extract and use to determine a suitable beam. This unified configuration may be coordinated by design so that candidates may be provided that the WTRU (e.g., UE) may use in the event of a beam failure, regardless of the cause of the beam failure (e.g., external mobility or device mobility).

[0560] Fig.10 A flow chart of active beam failure recovery with unified global configuration is shown.

[0561] For a WTRU (e.g., UE) in a connected (e.g., RRC_CONNECTED) state (S1001), it may send high-level assistance information to the network / network node (e.g., gNB) (S1002). This information from the WTRU (e.g., UE) may include measurement-based information and non-measurement-based information. The two broad categories of parameters and elements within the assistance information are described in detail above. The assistance information may carry information from the WTRU (e.g., UE) situation / environment and running applications that may require unimpeded mobility.

[0562] and Fig. 9In contrast, a (eg, key) change here may be that the network configuration of beam / TRP candidates may be provided in a unified manner, thereby covering candidates for both external mobility and device mobility (S1003).

[0563] In the event that mobility according to the configured beam quality threshold causes the quality of the serving beam to be impaired, the WTRU (e.g., UE) may extract information from its local sensors (S1004). The sensor information may be combined with radio measurements of existing or newly designed reference signals received from the network. An example may be combining local sensor data with measurements performed using downlink positioning reference signals.

[0564] Once the device may be experiencing beam failure, the WTRU (eg, UE) may obtain information from its local sensors to decide whether the link failure may occur due to device mobility or external mobility ( S1005 ).

[0565] Based on this information combined with information extracted from other interfaces and other sensors, the WTRU (e.g., UE) can pick / select the configuration most suitable for beam failure recovery, for example based on its geographic coordinates to select the correct set of candidate beams from the device mobility (S1007) or external mobility (S1006) configuration.

[0566] The most appropriate configuration may be derived directly from the network configuration priorities for any (e.g., each) candidate beam, such as for the geographic coordinates of the WTRU (e.g., UE). The WTRU (e.g., UE) may pick / select the configuration (S1008 to S1009), and it may (e.g., need to) enable different antenna panels (S1010) depending on the selected configuration. The flowchart illustrates (e.g., only) appropriate panel enabling for external mobility situations, where (e.g., of course) it may be more relevant, although enabling appropriate panels may also be used for (e.g., need to) device mobility situations. In one example, the network may configure a priority order for antenna panels of the WTRU (e.g., UE) based on WTRU (e.g., UE) assistance information about supported antenna panels sent to the network. The WTRU (e.g., UE) may select antenna panels according to the configured priority order.

[0567] With the appropriate antenna panel enabled (e.g., with the highest priority), the WTRU (e.g., UE) may verify the selected TRP / beam combination according to the configured parameter settings (S1011). Quality verification may be configured based on RSRP, RSRQ, or SINR using appropriately indicated measurement objects from the selected TRP / beam.

[0568] If the selected configuration meets the quality criteria, the WTRU (e.g., UE) may select\determine the RACH configuration associated with the selected TRP / beam and may transmit the RACH on the derived resources (S1012), and may transmit the RACH on the derived resources (S1013). Although not shown in the flowchart for clarity of design, if the selected TRP / beam does not meet the configured quality criteria, the WTRU (e.g., UE) may select the next higher priority beam from the provided configuration until it finds the highest priority beam that meets the quality criteria. In the case of a priority higher than the panel, if the WTRU (e.g., UE) does not find any suitable beam that meets the quality criteria using the first selected panel, the WTRU (e.g., UE) may select the next higher priority panel from the provided configuration and find a suitable beam according to the given priority order of the beams. To speed up the process, the WTRU (e.g., UE) may adopt multiple candidates indicated by the current geographic coordinates and may decide on the highest priority candidate that meets the quality criteria to trigger the recovery process for the candidate. If no configured candidate meets the quality criteria, the WTRU (e.g., UE) may resort to the traditional beam recovery process.

[0569] Design of the proposed active beam restoration configuration

[0570] This embodiment may suggest indicating coverage integration from the network with appropriate beam level granularity. This may provide the WTRU (e.g., UE) with knowledge of different cells / beams serving neighboring areas. In the event that the WTRU (e.g., UE) moves from an area served by one beam to another area served by another beam (e.g., when the WTRU moves from an area served by one beam to another area served by another beam), the location / orientation information from the local sensors may guide the WTRU (e.g., UE) to determine a target beam serving its most recently located area. The WTRU (e.g., UE) may extract the beam recovery configuration corresponding to the determined beam and may perform a beam failure recovery procedure.

[0571] In the following, two additional exemplary configurations may be presented for active beam recovery, which may provide an alternative to the use of deployment / coverage integration. In these embodiments, coverage-related information for a beam may be provided as part of the beam recovery configuration for any (e.g., each) candidate beam. The first embodiment presents an independent embodiment of active BFR. The second embodiment presents a joint embodiment of traditional and active BFR. To simplify the description, a limited set of mapping parameters for candidate beams (rotation / orientation aspects) may be shown in these embodiments. Additional parameters for candidate beams in terms of geographic coordinates, orientation, other subsets of auxiliary information, and priority aspects may be indicated in the same manner.

[0572] Independent design of active BFR

[0573] Embodiments may be proposed where an active BFR information element (IE) may be defined as a separate configuration element. An active beam failure recovery configuration IE may be introduced as part of the configuration where a new structure may associate any (e.g., each) SSB / CSI-RS resource with a reference position / location and an angular span.

[0574] Any (e.g., each) candidate beam (whether SSB or CSI-RS based) may be indicated relative to a suitable reference and its span may be indicated with respect to that reference. A new structure / template may be introduced where for any (e.g., each) candidate beam it may provide a reference position / location for the WTRU (e.g., UE) and its angular span.

[0575]

[0576]

[0577]

[0578] In this embodiment, any (e.g., each) candidate beam may have an indication of its active region, which may be an Active-BFR-Map type structure. This may be defined with an appropriate set of parameters from either a measurement-based information element or a non-measurement-based information element.

[0579] A compatible embodiment for providing beam mapping may be one in which any (e.g., each) beam may be defined as having a reference angle. An example may be the center of a beam. For any (e.g., each) candidate beam, its orientation may be specified relative to the reference beam / angle, and its beamwidth may be provided.

[0580]

[0581] The configuration may be further updated if (eg, all) SSB beams have a common beamwidth and / or (eg, all) CSI-RS beams have a common beamwidth.

[0582] The beam angles (whether defined as start and end angles relative to a reference, or as a reference beam orientation angle defined relative to a reference) can be defined as azimuth and vertical angles relative to a reference direction, where the reference direction can be defined as:

[0583] - In a global coordinate system (GCS), where estimated azimuths may be measured relative to geographic north and may be positive in a counterclockwise direction, and estimated vertical angles may be measured relative to a vertex and may be positive relative to the horizontal.

[0584] - In a local coordinate system (LCS), where the estimated azimuth angle may be measured relative to the x-axis of the LCS and may be positive in the counterclockwise direction, and the estimated vertical angle may be measured relative to the z-axis of the LCS and may be positive relative to the xy plane direction.

[0585] Although the active BFR process has an independent configuration, it can still run in parallel with the legacy BFR process. A WTRU (e.g., UE) may receive a configuration with a set of candidate beams suitable for active BFR mapping and may simultaneously receive a set of candidate beams for the legacy BFR process.

[0586] Unified design of active and traditional BFR

[0587] According to an embodiment, a unified configuration setting may be proposed that covers both active BFR and legacy BFR. In the case where the network decides to configure BFR candidates for a WTRU (e.g., UE) (e.g., when the network decides to configure BFR candidates for the WTRU), the configuration embodiment may be unique, which may be used to provide a set of candidate beams for legacy BFR and a set of candidate beams for the proposed active BFR. The two sets may have overlapping candidate beams.

[0588] BeamFailureRecoveryConfig

[0589] The IE BeamFailureRecoveryConfig may be used to configure RACH resources and candidate beams for a WTRU (eg, UE) for beam failure recovery in case of beam failure detection. See also TS 38.321, clause 5.1.1.

[0590]

[0591]

[0592]

[0593]

[0594] According to an embodiment, a single reference orientation may be provided for (e.g., all) beams (e.g., in contrast to previous embodiments where any (e.g., each) candidate beam may be configured with its own reference orientation). Similar techniques may be applied in this unified embodiment to specify beam-based references.

[0595] Both separate active BFR configurations and unified BFR configurations can be defined for beams derived based on SSB or CSI-RS signals. The conditions for these measurement objects using SSB or CSI-RS can be defined using specific metrics (such as RSRP, RSRQ and / or SINR, etc.). For ultra-large-scale MIMO, there may be a new reference symbol structure that is more suitable for generating thousands of beams. These beams and associated reference symbols can be transmitted from the network in a hierarchical manner. There may be multiple layers of such variable-width beams. These ultra-large-scale and holographic MIMO beams can be appropriately associated with suitable reference symbols of potential new designs to provide active BFR configurations to the WTRU (e.g., UE). These new reference symbols can follow the design and transmission of such holographic beams. New measurement metrics can be designed to capture the quality of a given beam in a more accurate and faster manner. For a hierarchical design, the quality of the beam can be derived based on measurements of potentially overlapping / superimposed beams. Beam failure and restoration conditions and thresholds may be appropriately defined and configured using existing reference symbols or new reference symbols defined for emerging networks with a large number of beams, using existing or new metrics and appropriate thresholds to be evaluated in view of these reference symbols and measurements.

[0596] Beam Failure Recovery Configuration for Translational Motion

[0597] The proposed embodiments for active BFR of a WTRU (e.g., UE) with limited neighboring beam snapshots configured through network sharing may not be limited to scenarios where the WTRU (e.g., UE) / device may be undergoing rotational movement. The proposal may be fully applicable to rotational movement, translational movement, beam / link being blocked by a mobile masker or beam / link failure due to other reasons, or any combination of the foregoing mobility / shielding events.

[0598] Fig.11 A WTRU (e.g., UE) arrangement is shown within a vehicle travelling on a road. The figure shows 3 TRPs, each providing 3 beams to cover a portion of the road. Although the WTRU (e.g., UE) cannot discover beams that are not yet covered, the network may provide beam configurations to the WTRU (e.g., UE). To cover translational motion, the beam recovery configuration may include beam identifications associated with the locations that it can serve. This information may be communicated to the WTRU (e.g., UE) using their location and relative distance, or in the form of absolute locations of these beams, which may be with respect to a suitable reference location and beam width or operating cone for any (e.g., each) beam.

[0599] The SSB and CSI-RS beams may be individually indicated with an active area, where a reference direction may be indicated, for which an angular span may be specified. In addition to the angular span, the translational coverage area may also be specified using suitable coordinates. These coordinates may be longitude and latitude, such as those obtained by a GPS system.

[0600] Appropriate quantization may be applied to the indicated values ​​to avoid excessive overhead.

[0601]

[0602]

[0603] In the Proactive-BFR-Mapping parameter structure, any (e.g., each) candidate beam (e.g., additionally) may indicate a reference position and an active span. This may enable a given beam to be mapped to a specific geographic region with a specific angular span. This configuration may be appropriate for many real-world situations we encounter today as a combination of high mobility, a large number of beams, and limited discovery / feedback opportunities. Further refinement of the beam geographic coordinates and regions may be added in the Proactive-BFR-Mapping structure to refine it to an appropriate degree and cover the required geospatial coordinates.

[0604] Reference selection for angular span and translational valid area indication

[0605] In accordance with an embodiment in which a network node (e.g., a gNB) may configure a WTRU (e.g., a UE) with candidate beams for a beam recovery process, different suitable reference points may be used to indicate the angular span of the candidate beams and to indicate a valid translation region.

[0606] To indicate the angular span of the candidate beams, the reference direction may be considered as the serving beam of a network node (e.g., gNB). In another embodiment, the reference direction may be considered as one of the directions from the base directions. The configuration of the reference beam may be given based on the TCI state containing the reference DL / UL beam or the associated RS.

[0607] To indicate the active translation area for a candidate beam, the area may be indicated based on (e.g., absolute) GPS coordinates. According to an embodiment, the active translation area may be specified relative to a suitable reference position / location. The reference may be the location of the gNB or it may be indicated as part of the configuration. The current location of the WTRU (e.g., UE) may serve as a reference point. According to an embodiment, in cases where different beams may originate from different TRPs (e.g., when different beams may originate from different TRPs), the network may configure the location of the source TRP along with the candidate beams. Using this information, the WTRU (e.g., UE) may determine the strongest beam (assuming line of sight), which is quite reasonable for high frequency communications.

[0608] Determine suitable candidate beams and trigger criteria for current serving beam replacement

[0609] The WTRU (e.g., UE) may monitor suitable measurement quantities for radio and non-radio measurements. Configured thresholds and events for these quantities may allow the WTRU (e.g., UE) to determine a suitable candidate beam that should be used to replace the current serving beam and initiate beam failure recovery.

[0610] According to an embodiment, the network may provide a coverage integrated configuration and / or the area determination threshold and / or the event to be triggered may be provided as part of the beam restoration configuration.

[0611] According to an embodiment, the area determination threshold may be part of the deployment / coverage integration configuration, and events on radio measurements and non-radio measurements triggering the beam recovery process on the candidate beams may be indicated as part of the beam recovery configuration.

[0612] According to an embodiment, the beam restoration configuration may include (e.g., explicitly) defined execution conditions. The network may provide the beam restoration configuration with appropriate triggers and execution conditions to the WTRU (e.g., UE). The execution conditions point to appropriate measurement identifiers, wherein the measurement configuration of the indicated measurement identifier may provide appropriate events for radio and non-radio measurement quantities with (e.g., all) (e.g., necessary) conditions and thresholds for evaluation.

[0613] Beam Failure Recovery for SpCell and SCell

[0614] Most of the steps of the proposed embodiment, involving providing WTRU (e.g., UE) assistance information, network configuration of candidate beams, and evaluation of the configured beams by the WTRU (e.g., UE) using network-provided geographic coordinates, can remain valid for the beam failure recovery process triggered after beam failure detection of the SpCell or SCell. Since the WTRU (e.g., UE) may not need to transmit RACH for BFR on the SCell, the active BFR configuration provided for the SCell may not include the RACH preamble and related parameters. From the perspective of WTRU (e.g., UE) actions, in the case where the WTRU (e.g., UE) identifies the candidate beam that is most suitable for BFR (e.g., once the WTRU identifies the candidate beam that is most suitable for BFR), the WTRU (e.g., UE) may prepare a set of verified candidate beams and prepare a MAC CE, which may be BFR or truncated BFR.

[0615] For the beam recovery procedure on the SpCell, the WTRU (e.g., UE) may transmit a RACH according to the configured parameters and may send a MAC CE as part of the RACH transmission.

[0616] For the beam recovery procedure on the SCell, the WTRU (e.g., UE) may transmit a BFR or truncated BFR MAC CE to the network on a specific cell, which may be the primary cell of the relevant cell group. Due to the proposed embodiment, the WTRU (e.g., UE) is able to quickly determine the best beam, so the process can obtain significant latency benefits, where a mapping of candidate beams can be provided for suitable geographic coordinates and can be enriched and refined using information from local sensors combined with radio measurements. An active BFR configuration for the SCell may be specified, similar to the above section, which may provide a configuration example for the SpCell. In a normal embodiment of the BFR configuration of the SCell, RACH related details may not be provided. In the proposed method, the SCell may be configured for RACH transmission, and the BFR configuration of such SCell may include relevant RACH parameters.

[0617] To make BFR faster for both SpCell and SCell, in cases where the WTRU (e.g., UE) may be configured with active beam failure recovery candidates (e.g., when the WTRU may be configured with active beam failure recovery candidates), beam failure detection may be declared earlier or a larger threshold may be used compared to traditional beam failure detection parameters. Two sets of thresholds may be indicated for beam failure detection. One set may be the traditional beam failure detection thresholds, and a new set of stricter thresholds, which may be applied (e.g., only) in cases where the WTRU (e.g., UE) has an active configuration available (e.g., when the WTRU has an active configuration available). In addition to the thresholds, new conditions or new events may be defined as being more relevant to active BFR.

[0618] Exemplary Embodiments

[0619] Proactive BFR procedure with coverage integration indication as WTRU (e.g., UE) dedicated signaling

[0620] Fig.12 An exemplary embodiment detailing a process for a WTRU (eg, UE) to perform active beam recovery when experiencing beam failure is shown in FIG.

[0621] The active beam failure recovery method may include any of the following steps:

[0622] -(S1201) The WTRU (e.g., UE) sends assistance information to a network node (e.g., gNB), the assistance information including any one of the following information groups:

[0623] ○ Data based on radio measurement quantities;

[0624] ○ Data based on non-radio measurements; and

[0625] ○UE capabilities and implementation details.

[0626] -The network node (e.g., gNB) transmits beam-level coverage integration via dedicated signaling to the WTRU (e.g., UE).

[0627] -(S1202) The WTRU (e.g., UE) may receive a local beam-level coverage integration transmitted by the network, the integration including any of the following:

[0628] ○ Taking local snapshots of different regions at beam-level granularity and identifying coverage of different regions; and

[0629] o A beam associated with any (eg, each) region.

[0630] -The network node (e.g., gNB) prepares a suitable active BFR configuration based on the assistance information received from the WTRU (e.g., UE) and its network deployment of TRP, cells and beams, and transmits the configuration to the WTRU (e.g., UE).

[0631] -(S1203) The WTRU (e.g., UE) receives a configuration for active BFR from a network node (e.g., gNB), the configuration including any of the following:

[0632] ○ A configuration containing different beam candidates to be used for beam failure recovery, including the following parameters;

[0633] ○ A set of candidate beams;

[0634] ○ Candidate beams associated with appropriate SSB, CSI-RS or newly designed reference signals;

[0635] o RACH parameters associated with any (e.g., each) candidate beam; and

[0636] ○ Providing measurement identifiers for events that trigger beam recovery that combines radio quantity measurements with non-radio quantity measurements (for example, these conditions and events can be specified based on the events described previously, in particular joint events J1, J2, J3 and J4, etc.).

[0637] -In the event that the WTRU (e.g., UE) detects a beam failure (the configured reference signal of the serving beam drops below the configured threshold or other conditions of BFD are met) (e.g., under the conditions when the WTRU detects a beam failure), the WTRU (e.g., UE) may initiate an active beam failure recovery procedure.

[0638] -(S1204) The WTRU (eg, UE) may obtain information from local sensors (GPS, accelerometer, gyroscope, etc.), possibly combined with radio measurements, and may determine the current value of its position / orientation parameter.

[0639] -(S1205) The WTRU (eg, UE) may determine its area based on the network signal coverage integrated configuration using its geographic coordinates (including at least its location, position, orientation, etc.).

[0640] -(S1206) The WTRU (eg, UE) may determine the beam associated with its determined area from the coverage provided by the network.

[0641] -(S1207) The WTRU (eg, UE) shortlists the determined beam candidates for which it has received active BFR configuration.

[0642] -(S1208) The WTRU (eg, UE) may measure and evaluate the radio measurement quantities and non-radio measurement quantities jointly configured as execution conditions of the listed BFR candidate beams using the configured signals and the configured thresholds.

[0643] -SpCell beam failure recovery:

[0644] ○(S1209) In the event that the selected candidate passes the joint radio and non-radio quality criteria (e.g., under the condition that the selected candidate passes the joint radio and non-radio quality criteria), the WTRU (e.g., UE) may extract its associated RACH configuration parameters (S1210).

[0645] ○(S1211) The WTRU (eg, UE) may transmit RACH for the BFR candidates using the derived RACH parameters. The WTRU (eg, UE) may prepare and transmit a BFR MAC-CE to provide the network with information of suitable candidate beams.

[0646] -Beam failure recovery on SCell:

[0647] o In the event that the selected candidate passes the joint radio and non-radio quality criteria (eg, under the condition that the selected candidate passes the joint radio and non-radio quality criteria), the WTRU (eg, UE) may prepare a BFR MAC-CE.

[0648] o The WTRU (eg, UE) may transmit a BFR MAC-CE to the network.

[0649] The above exemplary embodiment, wherein:

[0650] - A WTRU (eg, UE) may be configured with multiple sets of active BFR configurations, which may be associated with different parameters / situations.

[0651] -The WTRU may be configured with two sets of active BFR configurations, which may be associated with device mobility and external mobility, and the WTRU (e.g., UE) may determine the appropriate configuration to use by determining from measurements from local sensors whether the cause of the mobility is device mobility or external mobility.

[0652] - A set of BFR configurations may be indicated to be associated with different QoS requirements of specific application processes / services running at a WTRU (eg, UE) device.

[0653] - A set of BFR configurations may be indicated to be associated with different levels of WTRU (eg, UE) power consumption requirements.

[0654] -It may be indicated that a set of BFR configurations are associated with a WTRU (eg, UE) active subscription.

[0655] - A set of BFR configurations may be associated with different levels of WTRU (eg, UE) speed / rate values.

[0656] -The integration provided by the network may include its deployment parameters for cells, TRP and beam related parameters.

[0657] - The WTRU (eg, UE) may perform post-processing on the deployment package received from the network to construct a valid coverage package.

[0658] - Post-processing of the deployment integration by the WTRU (eg, UE) may use information from its local sensors to construct an effective coverage integration.

[0659] - Post-processing of the deployment integration by the WTRU (eg, UE) may use the locally stored information to construct an effective coverage integration. An example may be the use of geological and topographic related integration that may be available in local storage or through some other source.

[0660] - Active BFR configuration may instruct the WTRU (eg, UE) to enable specific panels among its available antenna panels.

[0661] - A WTRU (eg, UE) may determine a suitable antenna panel for a given BFR candidate based on its location, orientation, and coverage integration properties.

[0662] - The WTRU (eg, UE) verifies the execution conditions of a given BFR candidate through its associated determined / indicated WTRU (eg, UE) antenna panel.

[0663] - The WTRU (eg, UE) initiates a RACH procedure with the successful configuration / candidate using the determined / indicated antenna panel.

[0664] Active BFR process with coverage integration indication as broadcast signaling

[0665] Fig.13 An exemplary embodiment detailing a process for a WTRU (eg, UE) to perform active beam recovery when experiencing beam failure is shown in FIG.

[0666] The active beam failure recovery method may include any of the following steps:

[0667] -(S1301) The WTRU (e.g., UE) may receive a local beam level coverage integration transmitted by the network as part of a system information broadcast, the integration including any of the following:

[0668] ○ Take local snapshots of different areas at beam-level granularity and identify the coverage of different areas.

[0669] o A beam associated with any (eg, each) region.

[0670] -(S1302) The WTRU (e.g., UE) receives a configuration for active BFR from a network node (e.g., gNB), the configuration including any of the following:

[0671] ○ Contains the configuration of different beam candidates to be used for beam failure recovery, including the following parameters.

[0672] ○A set of candidate beams.

[0673] ○ Candidate beams associated with suitable SSB, CSI-RS or newly designed reference signals.

[0674] o RACH parameters associated with any (eg, each) candidate beam.

[0675] o Provides measurement identification of events that trigger beam recovery combining radio metrics and non-radio metrics.

[0676] -In the event that the WTRU (e.g., UE) detects a beam failure (the configured reference signal of the serving beam drops below the configured threshold or satisfies the BFD condition) (e.g., under the condition when the WTRU detects a beam failure), the WTRU (e.g., UE) may initiate an active beam failure recovery procedure.

[0677] -(S1303) The WTRU (eg, UE) may obtain information from local sensors (GPS, accelerometer, gyroscope, etc.), possibly combined with radio measurements, and may determine the current value of its position / orientation parameter.

[0678] -(S1304) The WTRU (eg, UE) may determine its area based on the network broadcast coverage integration using its geographic coordinates (position / location and orientation, etc.).

[0679] -(S1305) The WTRU (eg, UE) may determine the beam associated with its determined area from the network broadcast coverage integration.

[0680] -(S1306) The WTRU (eg, UE) may shortlist the determined beam candidates for which it has received active BFR configuration.

[0681] -(S1307) The WTRU (eg, UE) may measure and evaluate the radio and non-radio measurement quantities jointly configured as execution conditions for the listed BFR candidate beams using the configured signals and the configured thresholds.

[0682] -SpCell beam failure recovery:

[0683] ○(S1308) In the event that the selected candidate passes the quality criteria of the joint radio and non-radio quantities (e.g., under the condition that the selected candidate passes the quality criteria of the joint radio and non-radio quantities), the WTRU (e.g., UE) may extract its associated RACH configuration parameters (S1309).

[0684] o (S1310) The WTRU (eg, UE) may transmit RACH for the BFR candidate using the derived RACH parameters. The WTRU (eg, UE) may prepare and transmit a BFR MAC-CE to provide the network with information of suitable candidate beams.

[0685] -Beam failure recovery on SCell:

[0686] o In the event that the selected candidate passes the quality criteria for the joint radio and non-radio quantities (eg, under the condition that the selected candidate passes the quality criteria for the joint radio and non-radio quantities), the WTRU (eg, UE) may prepare a BFR MAC-CE.

[0687] o The WTRU (eg, UE) may transmit a BFR MAC-CE to the network.

[0688] The above exemplary embodiment, wherein:

[0689] - A WTRU (eg, UE) may be configured with multiple sets of active BFR configurations, which may be associated with different parameters / situations.

[0690] -The WTRU may be configured with at least two sets of active BFR configurations, which may be associated with device mobility and external mobility, and the WTRU (e.g., UE) may determine the appropriate configuration to use by determining from measurements from local sensors whether the cause of the mobility is device mobility or external mobility.

[0691] - A set of BFR configurations may be indicated to be associated with different levels of QoS requirements for specific application processes / services running at a WTRU (eg, UE) device.

[0692] - A set of BFR configurations may be indicated to be associated with different levels of WTRU (eg, UE) power consumption requirements.

[0693] -It may be indicated that a set of BFR configurations are associated with a WTRU (eg, UE) active subscription.

[0694] - A set of BFR configurations may be associated with different values ​​of WTRU (eg, UE) speed / rate.

[0695] -The integration provided by the network may include deployment parameters of its cells, TRP and / or beam related parameters.

[0696] - The WTRU (eg, UE) may perform post-processing on the deployment package received from the network to construct a valid coverage package.

[0697] - Post-processing of the deployment integration by the WTRU (eg, UE) may use information from its local sensors to construct an effective coverage integration.

[0698] - Post-processing of the deployment integration by the WTRU (eg, UE) may use the locally stored information to construct an effective coverage integration. An example may be the use of geological and topographic related integration that may be available in local storage or through some other source.

[0699] - Active BFR configuration may instruct the WTRU (eg, UE) to enable specific panels among its available antenna panels.

[0700] - A WTRU (eg, UE) may determine a suitable antenna panel for a given BFR candidate based on its location, orientation, and / or coverage integration properties.

[0701] - The WTRU (eg, UE) verifies the execution conditions of a given BFR candidate through its associated determined / indicated antenna panel.

[0702] - The WTRU (eg, UE) initiates a RACH procedure with the successful configuration / candidate using the determined / indicated antenna panel.

[0703] Active BFR with a single BFR configuration providing geographic coverage

[0704] An exemplary embodiment of a process for specifying a WTRU (e.g., UE) with an active beam failure recovery process may include any of the following steps:

[0705] The WTRU (e.g., UE) sends assistance information to a network node (e.g., gNB), the assistance information including any of the following information groups:

[0706] ○ Data based on radio measurement quantities;

[0707] ○ Data based on non-radio measurements; and

[0708] ○UE capabilities and implementation details.

[0709] -The network node (e.g., gNB) prepares an appropriate unified active BFR configuration based on the assistance information received from the WTRU (e.g., UE) and its network deployment of TRP, cells and beams, and transmits the configuration to the UE.

[0710] The WTRU (e.g., UE) receives a configuration for active BFR from a network node (e.g., gNB), the configuration including any of the following:

[0711] ○ A single configuration covering both device mobility and external mobility includes the following parameters;

[0712] ○ A set of candidate beams;

[0713] ○ Candidate beams associated with appropriate SSB, CSI-RS or newly designed reference signals;

[0714] o RACH parameters associated with any (e.g., each) candidate beam;

[0715] o Mapping of candidate beams to appropriate geographic coordinates (position, location, orientation) to accommodate device mobility and external mobility; and

[0716] o An indication of candidate beam priority in the event that multiple candidate beams may have at least partially overlapping coverage (eg, when multiple candidate beams may have at least partially overlapping coverage).

[0717] -In the event that the WTRU (e.g., UE) detects a beam failure (the configured reference signal of the serving beam drops below the configured threshold or other conditions of BFD are met) (e.g., under the conditions when the WTRU detects a beam failure), the WTRU (e.g., UE) may initiate an active beam failure recovery procedure.

[0718] - The WTRU (eg, UE) may obtain information from local sensors (GPS, accelerometer, gyroscope, etc.), possibly combined with radio measurements.

[0719] - A WTRU (e.g., UE) may evaluate changes in local sensor data and configured conditions to determine device mobility or external mobility to determine device mobility or external mobility based on the configuration,

[0720] - If device mobility is determined:

[0721] o The WTRU (eg, UE) uses its determined geographic coordinates (position / location and orientation, etc.) and radio measurements to determine candidate beams as recovery candidates from a configured mapping table.

[0722] - If external mobility is determined:

[0723] o The WTRU (eg, UE) uses its determined geographic coordinates (position / location and orientation, etc.) to determine a candidate beam from a configured mapping table as a recovery candidate. This may include removing the beam on which the beam failure detection occurred in case of external mobility.

[0724] -The WTRU (e.g., UE) may select the highest priority beam among the determined candidates.

[0725] -The WTRU (eg, UE) may enable the antenna panel associated with the selected BFR candidate.

[0726] -The WTRU (eg, UE) may measure the quality of the selected BFR candidate beams using the configured measurement signal and the configured threshold.

[0727] -SpCell beam failure recovery:

[0728] o In the event that the selected candidate passes the quality criteria (eg, under the condition that the selected candidate passes the quality criteria), the WTRU (eg, UE) may extract its associated RACH configuration parameters.

[0729] o The WTRU (eg, UE) may transmit RACH for the BFR candidates using the derived RACH parameters. The WTRU (eg, UE) may prepare and transmit a BFR MAC-CE, providing the network with information of suitable candidate beams.

[0730] -Beam failure recovery on SCell:

[0731] o In case the selected candidate passes the quality criteria (eg, under the conditions when this occurs), the WTRU (eg, UE) may prepare a BFR MAC-CE.

[0732] o The WTRU (eg, UE) may transmit a BFR MAC-CE to the network.

[0733] Active BFR with multiple BFR configurations providing geographic coverage

[0734] Example embodiments specifying a process for a WTRU (e.g., UE) to be proactive in performing beam failure recovery procedures:

[0735] The WTRU (e.g., UE) sends assistance information to a network node (e.g., gNB), the assistance information including any of the following information groups:

[0736] ○ Data based on radio measurement quantities;

[0737] ○ Data based on non-radio measurement quantities; and

[0738] ○UE capabilities and implementation details.

[0739] -The network node (e.g., gNB) prepares multiple suitable active BFR configurations based on the assistance information received from the WTRU (e.g., UE), the WTRU (e.g., UE) profile, and the network deployment of its TRP, cells, and beams, and transmits the configurations to the UE.

[0740] The WTRU (e.g., UE) receives a configuration set for active BFR from a network node (e.g., gNB), the configuration set including any of the following:

[0741] o Two configurations of device mobility and external mobility, where any (e.g., each) configuration may include any of the following parameters:

[0742] ■The set of candidate beams / TRPs;

[0743] ■Candidate beams associated with appropriate SSB, CSI-RS or newly designed reference signals;

[0744] ■ RACH parameters associated with any (e.g., each) candidate beam;

[0745] ■ Mapping of candidate TRPs / beams to positions / locations, orientations for device mobility;

[0746] ■ Mapping of candidate TRPs / beams for external mobility; and

[0747] ■ An indication of candidate beam priorities in cases where multiple candidate beams may have at least partial overlap for certain geographic coordinates (eg, when multiple candidate beams may have at least partial overlap for certain geographic coordinates).

[0748] -In the event that the WTRU (e.g., UE) detects a beam failure (the configured reference signal of the serving beam drops below the configured threshold or satisfies the BFD condition) (e.g., under the condition when the WTRU detects a beam failure), the WTRU (e.g., UE) may initiate a beam failure recovery procedure.

[0749] - The WTRU (eg, UE) may obtain information from local sensors (GPS, accelerometer, gyroscope, etc.), possibly combined with radio measurements.

[0750] - The WTRU (eg, UE) may evaluate changes in local sensor data and configured conditions to determine device mobility or external mobility depending on the configuration.

[0751] If the WTRU (e.g., UE) determines device mobility:

[0752] o A WTRU (eg, UE) may select a device mobility BFR configuration.

[0753] o The WTRU (eg, UE) uses its determined geographic coordinates (position / location and orientation, etc.) and radio measurements to determine candidate beams from the selected configuration mapping table as recovery candidates.

[0754] If the WTRU (e.g., UE) determines external mobility:

[0755] o A WTRU (eg, UE) may select an external mobility BFR configuration.

[0756] o The WTRU (eg, UE) determines a candidate beam from the selected configuration map as a recovery candidate using its determined geographic coordinates (position / location and orientation, etc.) This may include removing the beam on which the beam failure detection occurred in case of external mobility.

[0757] -The WTRU (e.g., UE) may select the highest priority beam among the determined candidates.

[0758] -The WTRU (eg, UE) may enable the antenna panel associated with the selected BFR candidate.

[0759] -The WTRU (eg, UE) may measure the quality of the selected BFR candidate beams using the configured measurement signal and the configured threshold.

[0760] -SpCell beam failure recovery:

[0761] o In the event that the selected candidate passes the quality criteria (eg, under the condition that the selected candidate passes the quality criteria), the WTRU (eg, UE) may extract its associated RACH configuration parameters.

[0762] o The WTRU (eg, UE) may transmit RACH for the BFR candidates using the derived RACH parameters. The WTRU (eg, UE) may prepare and transmit a BFR MAC-CE, providing the network with information of suitable candidate beams.

[0763] -Beam failure recovery on SCell:

[0764] o In case (eg, under the condition that) the selected candidate passes the quality criteria, the WTRU (eg, UE) may prepare a BFR MAC-CE.

[0765] o The WTRU (eg, UE) may transmit a BFR MAC-CE to the network.

[0766] In one embodiment, a method implemented by a WTRU includes: sending first information including data from local sensors and radio measurements. The method may also include: receiving second information indicating network deployment. The method may also include: receiving third information indicating a configuration associated with a set of candidate beams. The method may also include: in response to detecting a beam failure, selecting a subset of candidate beams from the set of candidate beams based on the current position and / or orientation of the WTRU. The method may also include: selecting a candidate beam from the subset of candidate beams, wherein the candidate beam can meet the configured radio trigger conditions and non-radio trigger conditions. The method may also include: determining RACH parameters from the configuration received for the selected candidate beam. The method may also include: sending a RACH transmission on the selected candidate beam using the RACH parameters.

[0767] In certain representative embodiments, the data from the local sensors may include any of the following: location of the WTRU, position of the WTRU.

[0768] In certain representative embodiments, the first information may also indicate any one of the following: field of view, application service quality.

[0769] In certain representative embodiments, the second information may be transmitted by the network node via a system information broadcast.

[0770] In certain representative embodiments, the second information may be transmitted by the network node via dedicated signaling.

[0771] In certain representative embodiments, the method may also include determining the current position and / or orientation of the WTRU from local sensors.

[0772] In certain representative embodiments, the method may also include determining the current position and / or orientation of the WTRU using radio measurements.

[0773] In certain representative embodiments, a network deployment may indicate any of the following: a local snapshot of different regions at a beam-level granularity, identifying coverage of different regions, and beams associated with any (eg, each) region.

[0774] Exemplary Embodiments

[0775] It is contemplated that the methods previously described herein may be combined in various ways. Fig.14 , a wireless communication method 1400 implemented by WTRU 102.

[0776] According to an embodiment, the WTRU 102 may be configured to send first information including data from local sensors and radio measurements (S1410).

[0777] According to an embodiment, the WTRU 102 may be configured to receive second information indicating network deployment (S1420).

[0778] According to an embodiment, the WTRU 102 may be configured to receive third information indicating a configuration associated with a set of candidate beams (S1430).

[0779] According to an embodiment, the WTRU 102 may be configured to select a subset of candidate beams from a set of candidate beams in response to detecting a beam failure, for example based on the current position and / or orientation of the WTRU (S1440).

[0780] According to an embodiment, the WTRU 102 may be configured to select a candidate beam from a subset of candidate beams, for example, where the candidate beam satisfies configured radio trigger conditions and non-radio trigger conditions (S1450).

[0781] According to an embodiment, the WTRU 102 may be configured to determine RACH parameters according to the configuration for the selected candidate beam reception (S1460).

[0782] According to an embodiment, the WTRU 102 may be configured to send a RACH transmission on the selected candidate beam using the RACH parameters (S1470).

[0783] According to an embodiment, the data from the local sensors may include any of the following: the location of the WTRU, the position of the WTRU.

[0784] According to an embodiment, the first information may indicate any one of the following: field of view, application service quality.

[0785] According to an embodiment, the second information may be transmitted by the network node through system information broadcast.

[0786] According to an embodiment, the second information may be transmitted by the network node through dedicated signaling.

[0787] According to an embodiment, the WTRU 102 may be configured to determine the current position and / or orientation of the WTRU from local sensors.

[0788] According to an embodiment, the WTRU 102 may be configured to determine the current position and / or orientation of the WTRU using radio measurements.

[0789] According to an embodiment, the network deployment may indicate any of the following: a local snapshot of different areas at a beam level granularity, where the coverage of different areas is identified, and the beams associated with any (e.g., each) area.

[0790] refer to Fig.15, a wireless communication method 1500 implemented by the WTRU 102 is shown.

[0791] According to an embodiment, the WTRU 102 may be configured to receive first information indicating a network coverage integration area (eg, a plurality of network coverage areas) from a network node (S1510).

[0792] According to an embodiment, the WTRU 102 may be configured to receive second information indicating a set of candidate beams and a configuration associated with the set of candidate beams from a network node (S1520).

[0793] According to an embodiment, the WTRU 102 may be configured to perform a first local sensor measurement from at least one local sensor of the WTRU (S1530).

[0794] According to an embodiment, the WTRU 102 may be configured to select a subset of candidate beams from the set of candidate beams based on the first local sensor measurement and the network coverage integration area in response to detecting a beam failure (S1540).

[0795] According to an embodiment, the WTRU 102 may be configured to perform second local sensor measurements and radio measurements from at least one local sensor of the WTRU for each candidate beam in the subset of candidate beams (S1550).

[0796] According to an embodiment, the WTRU 102 may be configured to select a candidate beam from the subset of candidate beams based on criteria associated with the second local sensor measurements and the radio measurements (S1560).

[0797] According to an embodiment, the WTRU 102 may be configured to determine at least one random access channel (RACH) parameter for the selected candidate beam based on the received configuration (S1570).

[0798] According to an embodiment, the WTRU 102 may be configured to send a RACH transmission on the selected candidate beam using at least one RACH parameter (S1580).

[0799] According to an embodiment, the configuration indicates at least one RACH parameter associated with each candidate beam in the set of candidate beams.

[0800] According to an embodiment, the configuration indicates at least one local sensor measurement threshold and at least one radio measurement threshold.

[0801] According to an embodiment, the criterion is based on a comparison of the second local sensor measurement with at least one local sensor measurement threshold and a comparison of the radio measurement with at least one radio measurement threshold.

[0802] According to an embodiment, the first information indicates a plurality of coverage areas, and wherein each area of ​​the plurality of coverage areas is associated with at least one beam of the set of candidate beams.

[0803] According to an embodiment, selecting a subset of candidate beams includes the WTRU being configured to: determine a current position and / or orientation of the WTRU based on a first local sensor measurement; and / or select a coverage area from a plurality of coverage areas based on the current position and / or orientation of the WTRU, and wherein the coverage area is associated with a subset of candidate beams.

[0804] According to an embodiment, determining the current position and / or orientation of the WTRU is based on a second radio measurement.

[0805] According to an embodiment, the second information is broadcasted via system information and / or received from the network node via dedicated signaling.

[0806] According to an embodiment, receiving first information indicating a network coverage integration area comprises the WTRU being configured to: send third information comprising data from local sensors and further radio measurements to a network node, and wherein the network coverage integration area is based on the third information.

[0807] refer to Fig.16 , a wireless communication method 1600 implemented by the WTRU 102 is shown.

[0808] According to an embodiment, the WTRU 102 may be configured to receive first information indicating a network coverage integration area (eg, a plurality of network coverage areas) from a network node (S1610).

[0809] According to an embodiment, the WTRU 102 may be configured to receive second information from a network node, the second information indicating a first set of candidate beams, a first configuration associated with the first set of candidate beams, a second set of candidate beams, and a second configuration associated with the first set of candidate beams (S1620).

[0810] According to an embodiment, the WTRU 102 may be configured to perform a first local sensor measurement from at least one local sensor of the WTRU (S1630).

[0811] According to an embodiment, the WTRU 102 may be configured to determine whether the cause of the WTRU's mobility is device mobility or external mobility based on the first local sensor measurement (S1640).

[0812] According to an embodiment, the WTRU 102 may be configured to select a configuration between the first configuration and the second configuration based on mobility reasons (S1650).

[0813] According to an embodiment, the WTRU 102 may be configured to, in response to detecting a beam failure, select a subset of candidate beams from the set of candidate beams based on a first local sensor measurement and a network coverage integration area (S1660);

[0814] According to an embodiment, the WTRU 102 may be configured to perform second local sensor measurements and radio measurements from at least one local sensor of the WTRU for each candidate beam in the subset of candidate beams (S1670).

[0815] According to an embodiment, the WTRU 102 may be configured to select a candidate beam from the subset of candidate beams based on criteria associated with the second local sensor measurements and the radio measurements (S1680).

[0816] According to an embodiment, the WTRU 102 may be configured to determine at least one random access channel (RACH) parameter for the selected candidate beam based on the selected configuration (S1690).

[0817] According to an embodiment, the WTRU 102 may be configured to send a RACH transmission on the selected candidate beam using at least one RACH parameter (S1695).

[0818] According to an embodiment, the selected configuration indicates at least one RACH parameter associated with each candidate beam in the set of candidate beams.

[0819] According to an embodiment, the selected configuration indicates at least one local sensor measurement threshold and at least one radio measurement threshold.

[0820] According to an embodiment, the criterion is based on a comparison of the second local sensor measurement with at least one local sensor measurement threshold and a comparison of the radio measurement with at least one radio measurement threshold.

[0821] According to an embodiment, the WTRU is configured to select a candidate beam from a subset of candidate beams based on a priority criterion; enable an antenna panel of the WTRU, wherein the antenna panel is associated with the selected candidate beam; measure a quality of the selected candidate beam, for example using at least one configured measurement signal; and / or

[0822] Determination of at least one RACH parameter and / or transmission of at least one RACH parameter is performed based on a comparison of the measured quality with a quality threshold.

[0823] According to an embodiment, the first information indicates a plurality of coverage areas, and wherein each area of ​​the plurality of coverage areas is associated with at least one beam of the set of candidate beams.

[0824] According to an embodiment, selecting a subset of candidate beams includes the WTRU being configured to: determine a current position and / or orientation of the WTRU based on a first local sensor measurement; and / or select a coverage area from a plurality of coverage areas based on the current position and / or orientation of the WTRU, and wherein the coverage area is associated with a subset of candidate beams.

[0825] According to an embodiment, determining the current position and / or orientation of the WTRU is based on a second radio measurement.

[0826] According to an embodiment, the second information is broadcasted via system information and / or received from the network node via dedicated signaling.

[0827] According to an embodiment, receiving first information indicating a network coverage integration area comprises the WTRU being configured to: send third information comprising data from local sensors and further radio measurements to a network node, and wherein the network coverage integration area is based on the third information.

[0828] in conclusion

[0829] Although features and elements are provided above in a specific combination, it will be understood by those skilled 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 in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of the present application should not be interpreted as being critical or necessary to the present invention, unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art according to the preceding description. 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 scope of equivalents given by such claims. It should be understood that the present disclosure is not limited to specific methods or systems herein.

[0830] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0831] It will also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed over a certain time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities (e.g., wearable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of a WTRU; or (iv) a similar device. References herein to Figures 1A to 1D Details of an example WTRU are provided, which may be representative of any WTRU set forth herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than a head mounted display may be utilized, and some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0832] In addition, the methods provided herein can be implemented in a computer program, software or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs), processors associated with software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC or any host computer.

[0833] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the embodiments shown are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0834] In addition, in the embodiments provided above, 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, references to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0835] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may cause the final conversion or reduction of electrical signals and maintain the data bits in memory locations in the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of 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. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0836] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside only on a 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.

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

[0838] There is little difference between hardware and software implementations of various aspects of the system. The use of hardware or software is usually (but not always, as in some cases, the choice of hardware or software may become important) a design choice that represents a cost-efficiency trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) with which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred vehicle may change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may select a primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may select a primary software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0839] The foregoing detailed description has been described various embodiments of the apparatus and / or process by using block diagrams, flow charts and / or examples. Insofar as such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or indeed any combination thereof. In an embodiment, several parts of the subject matter described herein may be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein may be equivalently implemented 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 almost as any combination thereof, and according to the present disclosure, designing circuit systems and / or writing codes for software and / or firmware will be completely within the skill range of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative examples of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0840] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system by a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application, one or more interactive devices such as a touch pad or screen, and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or velocity; a control motor for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as components typically found in data computing / communication and / or network computing / communication systems.

[0841] The subject matter described herein sometimes illustrates different parts that are included in different other parts or connected with different other parts.It should be understood that the architecture of such depiction is only an example, and many other architectures that realize the same function can actually be implemented.In a conceptual sense, any arrangement of parts for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two parts that are combined to realize a specific function in this article can be regarded as "associated" with each other so that the desired function is realized regardless of the architecture or the intermediate parts.Similarly, any two parts that are so associated can also be regarded as "operably connected" or "operably connected" to realize the desired function, and any two parts that can be so associated can also be regarded as "operably connected" to realize the desired function.The specific example of operably connectable includes (but is not limited to) parts that can be matched physically and / or physically interact, and / or parts that can be wirelessly interacted and / or wirelessly interacted, and / or parts that can be logically interacted and / or parts that can be logically interacted.

[0842] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural where appropriate to the context and / or application. For clarity, the various singular / plural arrangements may be expressly set forth herein.

[0843] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim statement is intended, such intent will be expressly stated in the claim, and in the absence of such a statement, no such intent is present. For example, where 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 multiple claim statements. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to embodiments including 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 interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., merely reciting "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those cases where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent the convention that one skilled in the art would understand (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those cases where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such meaning is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). One skilled in the art would further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternatives should be understood to contemplate the possibility of including one of the items, either of the items, or both of the items. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B."Furthermore, as used herein, the term "any" followed by a plurality of items and / or a listing of items in a plurality of categories is intended to include "any," "any combination," "any plurality," and / or "any combination of plurality," either alone or in combination with other items and / or items in other categories. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And as used herein, the term "plurality" is intended to be synonymous with "multiple."

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

[0845] As will be understood by those skilled in the art, for any and all purposes, such as in providing a written description, all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily identified as fully describing and capable of decomposing the same range into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, 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. As will be understood by those skilled in the art, all languages ​​such as "at most", "at least", "greater than", "less than", etc. include the enumerated numbers, and refer to the ranges that can be subsequently subdivided into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, the range includes each individual member. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, and so on.

[0846] 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 refer to or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving first information indicating a network coverage integration area from a network node; receiving, from the network node, second information indicating a set of candidate beams and a configuration associated with the set of candidate beams; performing a first local sensor measurement from at least one local sensor of the WTRU; In response to detecting a beam failure, selecting a subset of candidate beams from the set of candidate beams based on the first local sensor measurement and the network coverage integration area; performing, for each candidate beam in the subset of candidate beams, second local sensor measurements and radio measurements from the at least one local sensor of the WTRU; selecting a candidate beam from the subset of candidate beams based on criteria associated with the second local sensor measurements and the radio measurements; determining at least one random access channel (RACH) parameter for the selected candidate beam based on the received configuration; as well as A RACH transmission is sent on the selected candidate beam using the at least one RACH parameter.

2. The method of claim 1, wherein the configuration indicates at least one RACH parameter associated with each candidate beam in the set of candidate beams.

3. The method according to any one of claims 1 to 2, wherein the configuration indicates at least one local sensor measurement threshold and at least one radio measurement threshold. 4 . The method of claim 3 , wherein the criterion is based on a comparison of the second local sensor measurement with the at least one local sensor measurement threshold and a comparison of the radio measurement with the at least one radio measurement threshold.

5. The method according to any one of claims 1 to 4, wherein the first information indicates a plurality of coverage areas, and each of the plurality of coverage areas is associated with at least one beam in the set of candidate beams.

6. The method according to any one of claims 1 to 5, wherein selecting the subset of candidate beams comprises: determining a current position and / or orientation of the WTRU based on the first local sensor measurements; A coverage area is selected from the plurality of coverage areas based on the current location and / or orientation of the WTRU, and wherein the coverage area is associated with a subset of the candidate beams.

7. The method of claim 6, wherein determining the current position and / or orientation of the WTRU is based on a second radio measurement.

8. The method according to any one of claims 1 to 7, wherein the second information is received from the network node through system information broadcast and / or through dedicated signaling.

9. The method according to any one of claims 1 to 8, wherein receiving first information indicating a network coverage integration area comprises: Third information comprising data from local sensors and further radio measurements is sent to the network node, and wherein the network coverage integration area is based on the third information.

10. A wireless transmit / receive unit (WTRU), comprising a processor, a transmitter, a receiver, and a memory, the WTRU being configured to: receiving first information indicating a network coverage integration area from a network node; receiving, from the network node, second information indicating a set of candidate beams and a configuration associated with the set of candidate beams; performing a first local sensor measurement from at least one local sensor of the WTRU; In response to detecting a beam failure, selecting a subset of candidate beams from the set of candidate beams based on the first local sensor measurement and the network coverage integration area; performing, for each candidate beam in the subset of candidate beams, second local sensor measurements and radio measurements from the at least one local sensor of the WTRU; selecting a candidate beam from the subset of candidate beams based on criteria associated with the second local sensor measurements and the radio measurements; determining at least one random access channel (RACH) parameter for the selected candidate beam based on the received configuration; as well as A RACH transmission is sent on the selected candidate beam using the at least one RACH parameter.

11. The WTRU of claim 10, wherein the configuration indicates at least one RACH parameter associated with each candidate beam in the set of candidate beams.

12. The WTRU of any one of claims 10 to 11, wherein the configuration indicates at least one local sensor measurement threshold and at least one radio measurement threshold.

13. The WTRU of claim 12, wherein the criterion is based on a comparison of the second local sensor measurement to the at least one local sensor measurement threshold and a comparison of the radio measurement to the at least one radio measurement threshold.

14. The WTRU according to any one of claims 10 to 13, wherein the first information indicates a plurality of coverage areas, and each of the plurality of coverage areas is associated with at least one beam in the set of candidate beams.

15. The WTRU of any one of claims 10 to 14, wherein selecting the subset of candidate beams comprises the WTRU being configured to: determining a current position and / or orientation of the WTRU based on the first local sensor measurements; A coverage area is selected from the plurality of coverage areas based on the current location and / or orientation of the WTRU, and wherein the coverage area is associated with a subset of the candidate beams.

16. The WTRU of claim 15, wherein determining the current position and / or orientation of the WTRU is based on a second radio measurement.

17. The WTRU of any one of claims 10 to 16, wherein the second information is received from the network node through system information broadcast and / or through dedicated signaling.

18. The WTRU of any one of claims 10 to 17, wherein receiving first information indicating a network coverage integration area comprises the WTRU being configured to: Third information comprising data from local sensors and further radio measurements is sent to the network node, and wherein the network coverage integration area is based on the third information.

Images