Method and apparatus for enhanced RLF processing in a wireless system

Abstract

A method implemented by a remote wireless transmit receive unit (WTRU) involves determining implementation of a radio link failure (RLF) and / or a recovery after deferring the RLF. The WTRU may receive configuration information from a network, the configuration information including a plurality of RLF-specific parameters for determining whether RLF has occurred. The WTRU may select a radio link management (RLF)-specific parameter of the plurality of RLF-specific parameters based on one or more determined or predicted channel conditions associated with the WTRU and a condition of the WTRU. The WTRU may determine that an RLF has occurred based on the selected RLF-specific parameters and the one or more conditions. The WTRU may transmit an indication to the network based on determining one or more of RLF detection or RLF recovery behavior.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 335,016, filed on April 26, 2022, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0003] A wireless transmit / receive unit (WTRU) that is in a radio resource control (RRC) connection (RRC_CONNECTED) needs to continuously monitor the radio link to ensure that the link is good / reliable enough for communication, a process known as radio link monitoring (RLM). The WTRU monitors the downlink (DL) quality based on a reference signal broadcast from the serving cell.

[0004] In case of dual connectivity (DC), the WTRU may be configured which RLM reference signals (RLM-RS) to monitor in order to determine the radio quality of the primary cell (PCell) and the secondary cell group (SCG), referred to as PSCell. The network may configure the WTRU to perform RLM based on SSB (synchronization signal block), CSI-RS (channel state information-reference signal), or a combination of both. Various timers and counters may be used to determine the reliability of the link. Upon expiration of these timers and counters, the RRC will consider the link to have failed and declare a radio link failure (RLF). Once RLF is declared, a reestablishment procedure may be implemented.

[0005] Due to the different operating conditions (activity levels, mobility states, trajectories, etc.) of multiple WTRUs connected to the network, it may be impractical for the network to individually track and individually handle the RLF detection and RLF recovery procedures. Summary of the invention

[0006] A wireless transmit / receive unit (WTRU) may be configured to modify RLF detection and RLF recovery behaviors based on current and predicted WTRU data activity (e.g., configured bearers, data activity, etc.), current and predicted mobility levels, location, and time. The WTRU may apply radio link failure (RLF) detection and recovery behaviors that depend on current / predicted WTRU traffic / trajectory in addition to network / radio conditions.

[0007] A remote WTRU may determine to postpone a radio link failure (RLF) and / or postpone implementation of recovery after RLF. The WTRU may receive configuration information from a network, the configuration information including a plurality of RLF-specific parameters for determining whether an RLF has occurred. The WTRU may detect (e.g., determine) one or more of the plurality of RLF-specific parameters based on one or more determined or predicted channel conditions associated with a radio link management (RLM) and a condition of the WTRU. The WTRU may determine that an RLF has occurred based on the detected RLF-specific parameters and the one or more conditions. The WTRU may transmit an indication to the network based on determining RLF detection and / or RLF recovery behavior.

[0008] The determined condition of the WTRU may include one or more of: configured radio bearers, quality of service (QoS) settings of the configured radio bearers, current data activity levels of the configured radio bearers, predicted data activity levels of the configured radio bearers, mobility state of the WTRU, speed of the WTRU, WTRU location, predicted WTRU location, WTRU trajectory, or predicted WTRU trajectory. The determination to defer transmission of the RLF indication or report may be based on the selected RLF specific parameters and / or the determined channel condition.

[0009] The WTRU may transmit RLF information to the network. The RLF information may include one or more of a deferral reason, a time taken to recover the RL, one or more measurements at the time of RLF, one or more measurements at the time of RL recovery, a WTRU location at the time of RLF, a WTRU location at the time of RL recovery, a time associated with RLF detection, or a time associated with RL recovery. The plurality of RLF specific parameters may include one or more of a RLF counter, a RLF constant, a RLF timer, or a RLF threshold. The detected RLF specific parameters may be modified based on one or more conditions of the WTRU.

[0010] One or more measured / determined channel conditions associated with RLM may include one or more of an RLM reference signal (RLM-RS) or an out-of-sync indication. The WTRU may determine to perform RLF recovery based on one or more of channel conditions associated with RLM, one or more conditions of the WTRU, predicted channel conditions, and / or predicted conditions of the WTRU. The WTRU's determination of whether to perform RLF recovery may include determining whether to postpone reestablishment based on one or more conditions of the network and the WTRU. The conditions may include one or more of channel conditions associated with RLM, conditions of the WTRU, predicted channel conditions, and / or predicted conditions of the WTRU. The WTRU may predict one or more of the channel conditions and the WTRU's conditions based on historical data associated with one or more channel conditions and / or conditions of one or more WTRUs operating within the network.

[0011] The WTRU may receive RLF configuration information from the network. The RLF configuration information may include one or more RLF specific parameters for determining whether RLF has occurred. The WTRU may determine one or more conditions of the WTRU and / or determine one or more RLF specific parameters based on the condition of the WTRU. The WTRU may determine one or more RLF specific parameters based on one or more channel conditions associated with radio link management (RLM). The WTRU may determine RLF detection and / or RLF recovery behavior based on the selected RLF specific parameters and / or channel conditions. The WTRU may transmit an indication to the network based on determining RLF detection or RLF recovery behavior. The condition of the WTRU may include one or more configured radio bearers, quality of service (QoS) settings of the radio bearers, current data activity levels of the configured radio bearers, predicted data activity levels of the configured radio bearers, mobility state of the WTRU, speed of the WTRU, WTRU location, predicted WTRU location, WTRU trajectory, and / or predicted WTRU trajectory. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system.

[0014] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0015] Figure 1D is an example of a method that can be used according to one embodiment. Figure 1A System diagram of another example RAN and another example core network (CN) for use within the illustrated communication system.

[0016] Figure 2 Various timers and counters used to determine the reliability of a link being monitored within the RLM and RLF detection mechanisms are illustrated.

[0017] Figure 3 A high-level overview of the re-establishment process after RLF is illustrated.

[0018] Figure 4 and Figure 5Examples of IE timers and constants used in detection of and recovery from radio link problems are illustrated.

[0019] Figure 6 An example of processing of RLF is illustrated.

[0020] Figure 7 A combination of various solutions for deferred RLF handling and modified RLF recovery is illustrated.

[0021] Figure 8 is a further illustration of the combination of solutions for RLF and recovery processing. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0066] 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, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

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

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

[0069] 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 traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU 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.

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

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

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

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

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

[0075] As discussed, a WTRU in RRC_CONNECTED needs to continuously monitor the radio link to ensure that the link is good / reliable enough for communication (RLM procedure).The WTRU monitors the DL quality based on a reference signal broadcast from the serving cell.

[0076] In the case where the WTRU operates with single connectivity, the WTRU will typically perform RLM on the PCell, and in the case where the WTRU operates with DC, the WTRU will typically perform RLM on both the PCell and the PSCell. The WTRU can be configured which RLM-RS to monitor in order to determine the radio quality of the PCell and the PSCell (in the case of DC). The network can also configure the WTRU to perform RLM based on SSB, CSI-RS, or a combination of both. The WTRU is configured with thresholds for determining whether the radio link being monitored is good / reliable enough, including Qout and Qin, where Qout is the level of the out-of-sync block error rate (BLERout) at which the DL cannot be reliably received and should correspond to a 10% block error rate assuming PDCCH transmission, and Qin is the level of the in-sync block error rate (BLERin) at which the DL can be received significantly more reliably than under Qout and should correspond to a 2% block error rate assuming PDCCH transmission.

[0077] The WTRU may also be configured with timers and counters that are used to determine the reliability of the link being monitored. Figure 2The RLM and RLF detection mechanisms and various timers are illustrated. OUT , link monitoring may begin (210). Counter N310 (212) is the number of consecutive out-of-sync indications that may be received at the RRC from lower layers (e.g., PHY) before the RRC begins to consider that the monitored link is experiencing reliability issues. Counter N311 (214) is the number of consecutive in-sync indications that may be received at the RRC from lower layers (e.g., PHY) before the RRC considers that the monitored link has become reliable again. RLF time T310 (216) is the duration of a timer that may start when N310 consecutive out-of-sync indications are received from lower layers and stop when N311 consecutive in-sync indications are received.

[0078] like Figure 2 As also shown in , if the T310 timer expires before N311 consecutive synchronization indications are received from lower layers, the RRC may consider the link to have failed and declare RLF (radio link failure). The WTRU may employ another timer T312 (218) to detect RLF, which may be associated with a measurement report. The measurement report configuration may be associated with the timer T312 (218). When the reporting conditions are met and the measurement report may be transmitted, and if the measurement report configuration has been associated with T312, the WTRU will check whether T310 (216) is already running (i.e., the RLM has identified the problem and is waiting for recovery). If so, the WTRU starts the T312 timer (218), where the duration is set to the configured T312. If the problem is not resolved before the timer expires, the WTRU may declare RLF (220). Basically, T312 can be used to detect late holdover (HO), i.e., if the measurement report is transmitted earlier than the start of the radio link problem, the WTRU will most likely be handed over to the target cell in time.

[0079] The RRC may be considered to be RLF in various situations, such as one or more of the following: (1) upon a random access problem indication from the MAC (e.g., when the WTRU does not receive a random access response (RAR) after transmitting a random access preamble to the network a certain number of times); (2) upon an indication from the RLC that the maximum number of retransmissions has been reached; (3) if connected as an Integrated Access Backhaul (IAB) node, upon a Backhaul (BH) RLF indication received on the Backhaul Adaptation Protocol (BAP) entity (i.e., the link between the IAB node and the network has failed); or (4) when operating in unlicensed mode, upon a consistent uplink LBT (Listen Before Talk) failure indication from the MAC.

[0080] exist Figure 3A high-level overview of the reestablishment process is depicted in . When RLF (310) is detected due to any of the reasons described above, the WTRU (UE 312) performs RRC reestablishment to recover the radio link. In addition to RLF, there are several triggers for the WTRU to trigger reestablishment (314), such as one or more of the following: (1) when there is a reconfiguration with synchronization failure with the target cell during HO; (2) when the HO from NR to another RAT fails; (3) when the integrity check on CP data (e.g., data received via SRB1 or SRB2) fails; or (4) when the RRC connection reconfiguration fails (e.g., the WTRU is unable to compile / execute the received RRC reconfiguration file).

[0081] During the re-establishment process, the WTRU may perform several functions, such as a reset of the MAC; release of the WTRU configuration / context (including security configuration); perform cell reselection (i.e., select the cell with the best radio quality that the WTRU can measure at that time); or apply a default configuration and transmit an RRC re-establishment request message (316) to the network (target gNB, 318). The WTRU security verification (322) may be performed based on a message (324) between the target gNB (318) and the source gNB (320). The message (324) may include information such as the identity of the WTRU at the source cell where the re-establishment was triggered (e.g., C-RNTI), the PCI of the source cell, security integrity information that may be derived based on the security configuration used at the source cell, the reason for the re-establishment (e.g., RLF, integrity verification failure, reconfiguration failure, etc.).

[0082] The network (source gNB; 320) will use the security verification (322) included in the re-establishment request (326) to verify that the request is from a legitimate WTRU and use the provided WTRU identity and source cell identity to restore the latest WTRU context / configuration (e.g., if the WTRU is re-establishing at a target cell that is different from the source cell and the target cell is served by a gNB that may be different from the gNB serving the source cell, the target gNB may request the WTRU context / configuration information from the source). The network may transmit an RRC Re-establishment message to the WTRU, which includes information for the WTRU to update the security context. Signaling radio bearers are used for the transmission of RRC and NAS messages. SRB1 may now be up and running and the network may transmit an RRC Reconfiguration message (328) to the WTRU to complete the recovery (e.g., provide a new WTRU identity, set up bearers, configure measurements, etc.). The configuration of the WTRU identity, bearers, measurements, etc. may be the same as that used in the source cell before the reestablishment was triggered, or it may be different (for example, another WTRU at the target may already be using the identity, not all bearers may be permitted at the target, some measurement configurations may have to be modified due to the capabilities / configuration of the target, etc.).

[0083] In New Radio Release 16 (NR R16), the concept of conditional reconfiguration is introduced, where the WTRU may be provided with an RRC reconfiguration (e.g., HO command) that may be performed when certain measurement conditions are met (e.g., a neighboring cell becomes better than the serving cell by more than a certain threshold). That is, instead of the old way of the WTRU transmitting measurement reports and the network transmitting the HO command, the HO command may have been prepared and transmitted to the WTRU, and when the measurement conditions are met, the WTRU will execute this already stored HO command. The conditional reconfiguration generally associated with HO may be referred to as CHO (Conditional HO). In order to ensure that CHO works, the network may ensure that the target has been prepared (i.e., has been provided with the WTRU context / configuration, granted bearers, etc.). Furthermore, it should be noted that the actual HO command (i.e., the RRC reconfiguration message containing the reconfiguration with synchronization messages) may be prepared by the target and forwarded to the WTRU only via the source.

[0084] If the WTRU is configured with conditional reconfiguration, the WTRU performs a slightly enhanced re-establishment procedure. The WTRU may not release its context / configuration at the start of the re-establishment procedure, but may determine whether the cell reselection procedure results in the selection of a cell as a CHO target (i.e., the WTRU already has a CHO stored for that target and the target is already prepared for the WTRU). If so, the re-establishment procedure may not need to be continued, and the WTRU only executes the associated CHO command.

[0085] It is possible that the re-establishment process may not be successful due to several reasons. Potential examples include the WTRU being unable to perform cell reselection within a given time (e.g., timer T311, which may be started when the WTRU begins the cell reselection process, expiring before the WTRU has found a suitable cell to re-establish to); the WTRU being able to find a suitable cell, but before the re-establishment process can be completed, the cell becomes no longer suitable; or the WTRU not receiving a re-establishment message from the network within a given time after transmitting a re-establishment request (e.g., timer T301, which may be started when the WTRU transmits the re-establishment request, expiring before receiving a re-establishment command from the network).

[0086] In these cases, the WTRU may be forced into RRC_IDLE mode and recovery via connection setup from scratch may be triggered by the WTRU, which may be a more lengthy process than re-establishment as there may be no RAN level context acquisition and the CN may have to be involved in setting up / configuring the bearers. If the WTRU context is not correctly retrieved when the re-establishment request is received, a similar recovery from scratch (this time triggered by the network) may be performed.

[0087] As discussed herein, a WTRU may be configured with several timer values ​​and counters / constants used in the detection of and recovery from radio link problems. The timer and counter configuration may be provided to the WTRU in a dedicated (i.e., WTRU-specific) or broadcast manner (i.e., cell-specific) manner. The Information Element (IE) RLF-TimersAndConstants may be used to configure WTRU-specific timers and constants and may be included in the primary serving cell configuration for the PCell and, if the WTRU is operating in DC, also for the PSCell.

[0088] Figure 4 An example of information element and field descriptions for RLF timers and constants is shown in FIG. IE timers and constants included in SIB1 may be used by WTRUs in RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE (which may contain additional timers that may be used for other purposes). Figure 5 As illustrated, if the WTRU is configured with RLF timers and constants (and / or RLF thresholds), the timers / counters (and thresholds) configured therein will override the timers / counters broadcasted in SIB1 in UE-TimersAndConstants.

[0089] Figure 6 An example of the problem of handling RLF is illustrated. From an operational simplicity point of view, the easiest way for the network to operate would be to configure RLF-related timers and constants for all WTRUs via SIB1 broadcast. However, different WTRUs (e.g. Figure 6 The UE1 and UE2 in the WTRU may have different characteristics. For example, they may travel at different speeds, have different bearer configurations, etc. In addition, the network may decide to configure timer and counter values ​​that are compatible with the WTRU characteristics. However, the WTRU bearer configuration changes from time to time. Furthermore, the activity level of the bearers may not be constant (for example, intermittent behavior where bursts of heavy traffic may be followed by long periods of inactivity).

[0090] Taking into account the above discussion and Figure 6In the scenario illustrated in Figure 2, two WTRUs (UE1 and UE2) may experience a triggering condition (e.g., RLF) for re-establishment at locations A and B. At point A, one WTRU (UE1) may have very active bearers that have very low latency requirements, while the other WTRU (UE2) may not have such bearers (or may have bearers with similar requirements but that may not be active). Under the legacy RLF handling, both WTRUs would trigger a re-establishment and may become connected to cell 2 and switch back to cell 1 very quickly (as can be seen from the WTRU's traces). For one WTRU (UE1) with active bearers that may be latency sensitive, this may be the best action to take. However, for the other WTRU (UE2), the re-establishment to cell 2 and the subsequent HO back to cell 1 may not be necessary because the performance of the WTRU's bearers will not be affected if the WTRU does nothing until it has returned to proper coverage of cell 1. In location B, the situation may be the opposite, where the activity level of the bearers of one WTRU (UE1) has decreased, while the activity level of the bearers of the other WTRU (UE2) has increased.

[0091] It is impractical, if not impossible, for the network to track the different conditions of the WTRU bearer configuration, activity level, mobility state, trajectory, etc. and configure timers and counters that control the RLF detection and RLF recovery procedures. In the embodiments discussed herein, the WTRU may be configured to modify the detection of RLF based on the current WTRU bearer configuration, etc.

[0092] In an embodiment, the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values ​​depending on the type of bearers with which the WTRU may be configured. For example, if the WTRU has bearers with a QoS level of x or less (e.g., based on delay tolerance), the WTRU may use value set 1, if the WTRU has bearers with a QoS level between x and y, the WTRU may use value set 2, if the WTRU has bearers with a QoS level equal to or greater than y, the WTRU may use value set 3, etc.; if all bearers have a QoS level of x or less, the WTRU may use value set 1, otherwise use value set 2; a value set associated with the bearer with the most stringent QoS level may be used; a value set associated with the bearer with the least stringent QoS level may be used; or a value set that is an average of the bearers with the most stringent and least stringent QoS levels may be used.

[0093] The term QoS level refers to one or more parameters used to define the Quality of Service (QoS) of a bearer. For example, the QoS level may be the delay tolerance, minimum bit rate requirement, reliability (e.g., block error rate), priority level, etc. of the bearer, or a combination of all of these.

[0094] In an embodiment, the WTRU may be configured to have only one baseline set of n310 / n311 / t310 / t312 values, and the values ​​may be updated / scaled depending on the configuration type of the bearer. For example: if the WTRU has a bearer with a QoS level of x or less, the WTRU may be configured to use the baseline value, if the WTRU has a bearer with a QoS level between x and y, the WTRU may be configured to scale the value by a factor of n1, if the WTRU has a bearer with a QoS level greater than y, the WTRU may be configured to scale the value by a factor of n2, etc. In this example, n1 and n2 may be the same for each parameter (i.e., applicable to all n310 / n311 / t310 / t312), or there may be different scaling values ​​associated with each parameter.

[0095] In an embodiment, the WTRU may be configured to have only one set of n310 / n311 / t310 / t312 values ​​and update these values ​​by increasing / decreasing the increment value depending on the configuration of the bearer. For example, if the WTRU has a bearer with a QoS level of x or less, the WTRU may be configured to use the baseline value, if the WTRU has a bearer with a QoS level between x and y, the WTRU may be configured to add an increment value c1 for the counter and an increment value t1 for the timer, if the WTRU has a bearer with a QoS level greater than y, the WTRU may be configured to add an increment value c2 for the counter and an increment value t2 for the timer, and so on. In this example, c1 and c2 may be the same for each counter (i.e., applicable to both n310 and n311), or there may be different increment values ​​associated with each counter. Similarly, t1 and t2 may be the same for each timer value (i.e., applicable to both t310 and t312), or there may be different increment values ​​associated with each timer.

[0096] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the configuration of the bearers for the WTRU. For example, if the WTRU has only bearers with a QoS level of x or less, t3xx is set to 0; if the WTRU has at least one bearer with a QoS level between x and y, t3xx is set to t1; or if the WTRU has at least one bearer with a QoS level greater than y, t3xx is set to t2, etc.

[0097] A baseline t3xx value may be configured and the WTRU may scale it up / down or apply an incremental value on the baseline value depending on the QoS of the configured bearer (as described for other embodiments above).

[0098] In an embodiment, in addition to the type of bearer, the number of bearers may also be considered. For example, assume that the WTRU has two bearers with QoS level y and three bearers with QoS level z (z>y). Different value sets are specified for the two bearer types, and the WTRU uses a weighted average of the different values ​​associated with each bearer (e.g., a linear average or based on a weighting factor associated with each group). If the WTRU is configured with scaling factors n1 and n2 for bearers of type y and z, as discussed above, it may calculate the scaling factor to be applied as a weighted average of n1 and n2 associated with the two types of bearers (e.g., n=(n1*2+n2*3) / 5). In addition, if the WTRU is configured with the t3xx timer configuration discussed above, it may calculate the timer value to be applied as a weighted average of t1 and t2 associated with the two types of bearers (e.g., t3xx=(t1*2+t2*3) / 5).

[0099] In an embodiment, the WTRU may be configured to modify the detection of RLF based on the current overall WTRU data or activity level, and to defer RLF detection based on the current WTRU data activity.

[0100] For example, depending on the current total UL buffer level of all bearers, the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values. For example, if the total UL buffer level may be xMB or less, the WTRU may be configured to use value set 1, if the buffer level may be between xMB and yMB, the WTRU may be configured to use value set 2, if the buffer level may be equal to or greater than yMB, the WTRU may be configured to use value set 3, etc.

[0101] In an embodiment, the WTRU may be configured to have only one baseline set of n310 / n311 / t310 / t312 values, and update / scale these values ​​depending on the current total UL buffer level for all bearers. For example, if the total UL buffer level for all bearers may be xMB or less, the WTRU may be configured to use the baseline value, if the buffer level may be between xMB and yMB, the WTRU may be configured to scale the value by a factor of n1, if the buffer level may be above yMB, the WTRU may be configured to scale the value by a factor of n2, and so on. In another example, if the buffer level may be xMB or less, the WTRU may be configured to use the baseline value, and if the buffer level is greater than x, the WTRU may be configured to scale the value by a factor of n1*(current buffer level / x). In these examples, n1 and n2 may be the same for each parameter (i.e., applicable to all n310 / n311 / t310 / t312), or there may be different scaling values ​​associated with each parameter.

[0102] In an embodiment, the WTRU may be configured to have only one baseline set of n310 / n311 / t310 / t312 values, and update these values ​​by adding / subtracting increment values ​​depending on the current total UL buffer level. For example, if the total UL buffer level may be xMB or less, the WTRU may be configured to use the baseline value, if the buffer level may be between xMB and yMB, the WTRU may be configured to add increment value c1 for the counter and increment value t1 for the timer, if the buffer level may be above yMB, the WTRU may be configured to add increment value c2 for the counter and increment value t2 for the timer, etc. In this example, c1 and c2 may be the same for each counter (i.e., applicable to both n310 and n311), or there may be different increment values ​​associated with each counter. Similarly, t1 and t2 may be the same for each timer value (i.e., applicable to both t310 and t312), or there may be different increment values ​​associated with each timer. In another example, if the buffer level may be xMB or less, the WTRU may be configured to use the baseline value, and if the buffer level is above x, the WTRU may be configured to update the value by adding c*(current buffer level / x) for the counter and t*(current buffer level / x) for the timer. In this example, c may be the same or different for each counter. Similarly, t may be the same or different for each timer.

[0103] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the total UL buffer level. For example, if the total UL buffer level is less than xMB, t3xx may be set to 0; if the total UL buffer level is between xMB and yMB, t3xx may be set to t1; and if the total UL buffer level is greater than yMB, t3xx may be set to t2, etc.

[0104] The baseline t3xx value may be configured and the WTRU may scale it up / down or apply a delta value on the baseline value depending on the total UL buffer level (as described above for other embodiments).

[0105] Variations of all of the above embodiments are envisioned in which, instead of (or in addition to) the total UL buffer level, the total data rate of the bearer is taken into account. The data rate may be for UL only, DL only, or a combination of both (e.g., maximum, minimum, weighted average, sum, etc.). For example, depending on the current total data rate, the WTRU may be configured to use a different set of n310 / n311 / t310 / t312 values. For example, if the total data rate is x Mbps or less, the WTRU may be configured to use value set 1, if the data rate is between x Mbps and y Mbps, the WTRU may be configured to use value set 2, if the buffer level is equal to or greater than y Mbps, the WTRU may be configured to use value set 3, and so on. In addition, the WTRU may be configured with a baseline set of n310 / n311 / t310 / t312 values ​​and update / scale these values ​​depending on the current total data rate. For example, if the total data rate is x Mbps or less, the WTRU may be configured to use the baseline value, if the data rate is between x Mbps and y Mbps, the WTRU may be configured to scale the value by a factor of n1, if the data rate is above y Mbps, the WTRU may be configured to scale the value by a factor of n2, etc. In this example, if the total data rate is x Mbps or less, the WTRU may be configured to use the baseline value, if the data rate is above x Mbps, the WTRU may be configured to scale the value by a factor of n1*(current data rate / x), etc.

[0106] Variations of all of the above embodiments are envisioned in which, instead of (or in addition to) the buffer level and the data rate, the activity / inactivity level of the bearer is considered. The inactivity level may be considered in the UL, DL, or a combination (e.g., the minimum of UL and DL inactivity is considered the inactivity time, the average of UL and DL inactivity is considered the inactivity timer, etc.). For example, depending on the inactivity time, the WTRU may be configured to use a different set of n310 / n311 / t310 / t312 values. For example, if the WTRU has activity no more than xms ago, the WTRU may be configured to use value set 1, if there is no activity between xms and yms, the WTRU may be configured to use value set 2, if there is no activity for yms or longer, the WTRU may be configured to use value set 3, etc. In addition, the WTRU may be configured with a baseline set of n310 / n311 / n310 / n312 values ​​and these values ​​may be updated / scaled depending on the current total data rate. In this example, if the WTRU has no activity for no more than xms, the WTRU may be configured to use the baseline value, and if there is no activity between xms and yms, the WTRU may be configured to scale the value by a factor of n1, if there is no activity for yms or longer, the WTRU may be configured to scale the value by a factor of n2, etc. In another example, for inactivity levels exceeding xms, the WTRU may be configured to scale the value by a factor of n1*(current inactivity timer / x), etc.

[0107] In the above, activity may refer to only user plane data, only control plane data, or both (for example, if only user plane data is considered, the WTRU may not consider RRC messages / responses, ACK / NACK for DL / UL data, MAC / RLC / PDCP control PDUs from the WTRU / gNB, etc. when determining the inactivity level).

[0108] Variations of all the above embodiments are envisioned in which only a subset of bearers are considered when calculating the buffer level, data rate or inactivity level. The subset of bearers to be considered may be indicated to the WTRU either explicitly (e.g., bearer ID) or by category (e.g., WTRUs configured to consider only bearers of a certain QoS level / class, WTRUs configured not to consider bearers of a certain QoS level / class, etc.).

[0109] In an embodiment, the WTRU may be configured to modify the detection of RLF based on the current mobility level / state so as to postpone the detection of RLF based on the current WTRU mobility level. For example, depending on the current mobility state of the WTRU, the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values. In this example, if the WTRU is stationary, the WTRU may be configured to use value set 1, if the WTRU is moving between xm / s and ym / s, the WTRU may be configured to use value set 2, if the WTRU is moving at greater than zm / s, the WTRU may be configured to use value set 3, etc.

[0110] In an embodiment, the WTRU may be configured with only one baseline set of n310 / n311 / t310 / t312 values ​​and update / scale these values ​​depending on its current mobility state. For example, if the speed is less than xm / s, the WTRU may be configured to use the baseline values, if the speed may be between xm / s and ym / s, the WTRU may be configured to scale the values ​​by a factor of n1, if the speed may be above ym / s, the WTRU may be configured to scale the values ​​by a factor of n2, etc. In another example, if the speed may be xm / s or less, the WTRU may be configured to use the baseline values, if the speed is greater than x, the WTRU may be configured to scale the values ​​by a factor of n1*(x / current speed). In these examples, n1 and n2 may be the same for each parameter (i.e., applicable to all n310 / n311 / t310 / t312), or there may be different scaling values ​​associated with each parameter.

[0111] In an embodiment, the WTRU may be configured to have only one baseline set of n310 / n311 / t310 / t312 values, and update these values ​​by adding / deleting increment values ​​depending on its current mobility state. For example, if the WTRU's speed may be less than xm / s, the WTRU may be configured to use the baseline values, if the WTRU's speed may be between xm / s and ym / s, the WTRU may be configured to add increment values ​​c1 for the counters and t1 for the timers, if the WTRU's speed may be higher than ym / s, the WTRU may be configured to add increment values ​​c2 for the counters and t2 for the timers, and so on. In this example, c1 and c2 may be the same for each counter (i.e., applicable to both n310 and n311), or there may be different increment values ​​associated with each counter. Similarly, t1 and t2 may be the same for each timer value (i.e., applicable to both t310 and t312), or there may be different increment values ​​associated with each timer. In another example, if the speed of the WTRU may be x m / s or less, the WTRU may be configured to use the baseline value and update the value by adding c*(x / current speed) for the counter and t*(x / current speed) for the timer. In this example, c may be the same or different for each counter. Similarly, t may be the same or different for each timer.

[0112] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the WTRU mobility state. For example, if the WTRU speed is greater than ym / s, t3xx may be set to 0; if the WTRU speed is between xm / s and ym / s, t3xx may be set to t1; and if the WTRU speed is less than xm / s, t3xx may be set to t2, etc.

[0113] The baseline t3xx value may be configured and the WTRU may scale it up / down or apply a delta value on the baseline value depending on the current speed of the WTRU (as described above for other embodiments).

[0114] In an embodiment, the WTRU may be configured to modify the detection of RLF based on its current location and to defer RLF detection based thereon. For example, the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values ​​depending on the WTRU's current location. For example, if the WTRU is located between GNSS coordinates x and y, the WTRU may be configured to use value set 1, if the WTRU is located between coordinates y and z, the WTRU may be configured to use value set 2, and so on.

[0115] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the WTRU's current location. For example, if the WTRU is located within GNSS coordinates a and b, t3xx may be set to 0; if the WTRU is located within GNSS coordinates b and c, t3xx may be set to t1; and if the WTRU is located within GNSS coordinates c and d, t3xx may be set to t2, etc.

[0116] In an embodiment, the WTRU may be configured to modify the detection of RLF based on its current serving cell and / or neighboring cells and to defer RLF detection based thereon. For example, depending on the WTRU's current serving cell identity (e.g., PCI), the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values. In this example, if the WTRU is served by cell ID 1, the WTRU may be configured to use value set 1, if the WTRU is served by cell ID 2, the WTRU may be configured to use value set 2, and so on.

[0117] In an embodiment, in addition to or instead of cell identity, the configuration may be based on frequency; for example, value set 1 is used for any serving cell with freq 1, value set 2 is used for any serving cell with freq 2, and value set 1a is used for a serving cell with cell id 1 and freq a, value set 1b is used for a serving cell with cell id 1 and freq b, and so on.

[0118] In an embodiment, the WTRU may be configured to use different sets of n310 / n311 / t310 / t312 values ​​depending on the neighboring cells that the WTRU can detect. For example, if the WTRU can detect neighboring cells in neighboring cell ID list 1, the WTRU may be configured to use value set 1, if the WTRU is served by neighboring cells in neighboring cell ID list 2, the WTRU may be configured to use value set 2, and so on. Further criteria may be configured with respect to neighboring cells to apply corresponding value sets. In this example, one or more of the following may apply: (1) all cells in the neighboring cell list must be detected; (2) at least one cell in the neighboring list must be detected; (3) at least a certain number or percentage of the neighboring list must be detected; and so on.

[0119] In an embodiment, in addition to or instead of cell identity, configuration may be based on the frequency of neighboring cells; for example, value set 1 is used for neighboring cells with freq 1, and value set 2 is used for any serving cell with freq 2.

[0120] In an embodiment, the signal level thresholds may be specified together with the serving cell and the neighboring cell based on the above configuration; for example, the WTRU may apply different sets of values ​​for different signal level ranges of the serving cell with a specified identity (if no specific cell ID can be specified, the WTRU may apply similar behavior to all serving cells based solely on the signal level, i.e., regardless of which specific cell the WTRU is being served at). The WTRU may apply different sets of values ​​for different signal level ranges of neighboring cells within a specified neighboring cell list (e.g., for a given neighboring cell list, there may be different associated sets of values ​​corresponding to different minimum signal levels of neighboring cells). In addition, the WTRU may apply different sets of values ​​depending on a comparison of the signal levels of neighboring cells (or neighboring cell lists) and the serving cell, etc.

[0121] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the WTRU's current serving cell. For example, if the WTRU is being served by a cell with an ID in Cell ID List 1, t3xx may be set to 0; if the WTRU is being served by a cell with an ID in Cell ID List 2, t3xx may be set to t1, etc.

[0122] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the WTRU's current neighboring cells. For example, if the WTRU detects a neighboring cell with an ID in Neighbor Cell ID List 1, t3xx may be set to 0; and if the WTRU detects a neighboring cell with an ID in Neighbor Cell ID List 2, t3xx may be set to t1, etc.

[0123] Embodiments are envisioned in which the T3xx value may also depend on the signal level of the serving cell, neighboring cells, or a comparison therebetween, as described above for configurations that may be based on multiple value sets. Other embodiments are envisioned in which the T3xx value may be configured based on the frequency of the serving cell or neighboring cells in addition to or instead of the cell ID.

[0124] In an embodiment, the WTRU may be configured to modify the detection of RLF based on the current time (time of day) and to defer RLF detection based thereon. For example, depending on the current time, the WTRU may be configured to use a different set of n310 / n311 / t310 / t312 values. In this example, if the time of day is between t1 and t2 (where t1 and t2 are specified as, for example, HH:MM:SS:mmm, i.e., hours, minutes, seconds, milliseconds), the WTRU may be configured to use value set 1, if the time is between t2 and t3, the WTRU may be configured to use another set 2, and so on.

[0125] In an embodiment, the WTRU may be configured with a new timer T3xx (e.g., with an associated timer value t3xx), and the WTRU starts the timer after T310 or T312 has expired (the same value or separate values ​​may be specified to correspond to T310 and T312) and declares RLF only when T3xx expires. The timer value may be configured to depend on the current time. For example, if the current time is between t1 and t2, t3xx may be set to 0; if the current time is between t2 and t3, t3xx may be set to ta; and if the current time is between t3 and t4, t3xx may be set to tb, etc.

[0126] In an embodiment, the WTRU may be configured with different sets of values ​​(or different t3xx timers) corresponding to different days. For example, a different set of values ​​may be configured for weekends (or holidays) compared to weekdays.

[0127] In an embodiment, instead of (or in addition to) the current data activity level, the WTRU may be configured to consider and / or defer RLF based on predicted data activity levels (buffer size, data rate, data inactivity, etc.) to determine how to modify RLF detection. For example, the WTRU may be configured with different value sets or scaling factors or increment values ​​corresponding to the current data activity and predicted activity levels (e.g., if the current UL buffer size may be less than xMB and the predicted buffer size may not exceed yMB within a certain duration (e.g., t1ms), then value set 1 is used, if the current buffer size may be less than xMB and the predicted buffer size may be between yMB and zMB within a certain duration (e.g., t1ms), then value set 2 is used, etc.). Alternatively or in addition, the WTRU may be configured with weighting factors to apply to the current value and the predicted value (e.g., if the current buffer value may be yMB and a scaling factor n1 is associated with that buffer level, and the predicted buffer value may be zMB and a scaling factor n2 is associated with that buffer level, the WTRU may calculate the scaling factor as (1-a)*n1+a*n2, where a may be the scaling factor configured for the predicted value).

[0128] In an embodiment, instead of the current mobility level (or in addition to the current data activity level), the WTRU may be configured to consider and / or defer RLF based on the predicted mobility level to determine how to modify RLF detection. For example, the WTRU may be configured with different value sets or scaling factors or increment values ​​corresponding to the current mobility level and the predicted activity level (e.g., if the current speed may be less than xm / s and the predicted speed may not exceed ym / s within a specific duration (e.g., t1ms), then use value set 1, if the current speed may be less than xm / s and the predicted setting may be between ym / s and zm / s within a specific duration (e.g., t1ms), then use value set 2, etc.). Alternatively or in addition, the WTRU may be configured with weighting factors to apply to current values ​​and predicted values ​​(e.g., if the current speed may be ym / s and a scaling factor n1 is associated with that speed, and the predicted speed may be zm / s and a scaling factor n2 is associated with that speed, the WTRU may calculate the scaling factor as (1-a)*n1+a*n2, where a may be the scaling factor configured for the predicted value).

[0129] Combinations of any of the above embodiments are contemplated. For example, the WTRU may be configured to apply a set of values ​​(or scaling factors or increment values) at a specific location for a specific duration of time (e.g., when the current time may be t1, when the WTRU may be located in l1, the value set 1_l1_t1 is applicable, when the current time may be in t2, when the WTRU may be located in l1, the value set 1_l1_t2 is applicable, etc.). In addition, the WTRU may be configured to apply a set of values ​​(or scaling factors or increment values) for a specific data activity at a specific duration of time (e.g., when the WTRU UL data rate may be lower than d1 and the current time may be in t1, the value set 1_d1_t1 is applicable, when the WTRU UL data rate may be between d1 and d2 and the current time may be in t1, the value set 1_d2_t1 is applicable, etc.). The WTRU may also be configured to apply a set of values ​​(or scaling factors or incremental values) for specific data activities at specific time durations and mobility levels (e.g., when the WTRU UL data rate may be lower than d1, the current time may be within t1, and the WTRU may be moving at a speed of s1 or less, the value set 1_d1_t1_s1 is applicable; when the WTRU UL data rate may be lower than d1, the current time may be within t1, and the WTRU may be moving at a speed between s1 and s2, the value set 1_d1_t1_s2 is applicable, etc.).

[0130] Applications that also consider other WTRU and network conditions may be included. Examples of WTRU and network conditions may include one or more of the following: WTRU battery level (e.g., different sets of values ​​for different battery level thresholds); WTRU overheat level; RAT of the serving cell; and RAT of the neighboring cell.

[0131] In an embodiment, the WTRU may detect RLF as in the legacy manner (i.e., using the legacy timers and constants), but refrain from recovery (e.g., re-establishment) for a certain duration based on configuration taking into account any one or combination of the parameters discussed herein for deferring RLF detection. If, after the configured duration has elapsed, the WTRU has not returned to the coverage of the source cell where the RLF was detected, the WTRU may start recovery (e.g., start the re-establishment process).

[0132] As described herein, the duration for prohibiting the initiation of RLF recovery after RLF detection may depend on several parameters, such as one or more of the types of bearers. For example, if the WTRU has bearers with a QoS level of x, the WTRU may be configured to not delay the reestablishment, if the WTRU only has bearers with a QoS level between x and y, the WTRU may be configured to delay the reestablishment by t1, if the WTRU only has bearers with a QoS level between y and z, the WTRU may be configured to delay the reestablishment by t2, and so on; WTRU data activity (e.g., if the WTRU's UL data rate is lower than x, the WTRU may be configured to delay the reestablishment by t1, if the WTRU's UL data rate may be between x and y, the WTRU may be configured to delay the reestablishment by t2, and if the WTRU's UL data rate may be higher than y, the WTRU may be configured to not delay the reestablishment, and so on, and - as in the case of deferred RLF - the WTRU may also be configured to take into account predicted WTRU data activity); WTRU mobility level (e.g., if the WTRU's speed may be lower than x, the WTRU may be configured to delay the reestablishment by t1, if the WTRU's speed may be higher than y, the WTRU may be configured to not delay the reestablishment, and so on); degree may be between x and y, the WTRU may be configured to delay the reestablishment by t2, etc. - again, as in the case of deferred RLF - the WTRU may also be configured to take into account the predicted WTRU mobility level); WTRU location (e.g., if the WTRU is located within location coordinates L0 and L1, the WTRU may be configured to delay the reestablishment by t1, if the WTRU is located within location coordinates L1 and L2, the WTRU may be configured to delay the reestablishment by t2, etc.); serving / neighboring cell (e.g., if the WTRU is being served by a cell in cell ID list 1, the WTRU may be configured to delay the reestablishment by t1, if the WTRU is being served by a cell in cell ID list 2, the WTRU may be configured to delay the reestablishment by t2, etc.); current time (e.g., if the current time may be between T0 and T1, the WTRU may be configured to delay the reestablishment by t1, if the current time may be between T1 and T2, the WTRU may be configured to delay the reestablishment by t2, etc.); and any combination of all of the above.

[0133] In an embodiment, in addition to or in lieu of the configured duration, the WTRU may be configured to consider a predicted trajectory and outage duration to delay RLF recovery. For example, the WTRU may have an AI / ML model that has been trained to predict its trajectory and estimate (e.g., based on previous outages / RLFs at the current location) how long the outage will last (e.g., in terms of time duration or location coordinates of the coverage hole) based on channel conditions and / or historical data of the conditions of one or more WTRUs operating within the network, as well as other channel conditions and conditions of the WTRU. Based on the current mobility level, trajectory, and current location, the WTRU may determine how long it will take (e.g., t2) before it will return to the coverage of the source serving cell where the RLF was detected. If t2 is less than the configured duration for delaying RLF recovery, the WTRU may delay recovery for the specified duration (i.e., the time at which the delay duration has elapsed when the WTRU will most likely return to the coverage of the source cell). However, if t2 is greater than the configured duration for delaying RLF, this means that even after delaying recovery by the specified amount, the WTRU will not be back in coverage of the serving cell and delaying recovery will not be the best decision. Therefore, for this case, the WTRU may decide to perform RLF recovery immediately (e.g., reestablish to another cell).

[0134] Figure 7An example implementation of various embodiments as discussed above is shown. At 712, the WTRU 700 may determine one or more WTRU conditions. The one or more WTRU conditions may include configured radio bearers, quality of service (QoS) settings of configured radio bearers, current data activity levels of configured radio bearers, predicted data activity levels of configured radio bearers, mobility state of the WTRU, speed of the WTRU, WTRU location, predicted WTRU location, WTRU trajectory, or predicted WTRU trajectory. The WTRU 700 may be configured to receive configuration information 710. The configuration information 710 may include a plurality of RLF specific parameters. The plurality of RLF specific parameters may include a RLF counter, a RLF constant, a RLF timer, or a RLF threshold. The plurality of RLF specific parameters may be used to determine whether RLF has occurred. In general, in addition to the configuration information (710) received by the WTRU (700) from the network, the current WTRU condition and indication, the predicted WTRU condition, and the predicted WTRU trajectory (712) may be included in a decision process (714) performed by the WTRU to implement a particular RLF embodiment (716). The legacy behavior (a) of the WTRU may be applied. The WTRU 700 may determine one or more channel conditions associated with RLM. For example, the WTRU 700 may predict one or more of the channel conditions and / or the conditions of the WTRU based on historical data related to the one or more channel conditions and the conditions of one or more WTRUs operating within the network. At 714, the WTRU 700 may detect (e.g., determine) an RLF-specific parameter from a plurality of RLF-specific parameters, for example, based on the one or more conditions of the WTRU. At 714, the WTRU 700 may determine to defer RLF detection and / or defer RLF recovery. For example, the WTRU 700 may be configured to determine RLF detection and / or RLF recovery behavior based on the detected RLF-specific parameters and / or the one or more channel conditions.

[0135] The WTRU 700 may determine to perform RLF recovery based on one or more of one or more determined channel conditions associated with the RLM, one or more determined conditions of the WTRU, one or more predicted channel conditions, and / or one or more predicted conditions of the WTRU. Determining to perform RLF recovery may include determining whether to defer reestablishment of the radio link. The WTRU 700 may transmit an indication to the network based on determining RLF detection and / or RLF recovery behavior.

[0136] As a possible alternative, deferred RLF detection (b) may be implemented based on an updated timer / constant, or RLF may be declared upon expiration of a T3xx timer. Here, N310 / N311 / T310 / Y312 is scaled or T3xx is started after expiration of t310 / t312. Deferred RLF detection preferably depends on the bearer QoS, data activity level, mobility, location, time of day, etc. The WTRU defers detection of RLF based on an updated timer / constant or declares RLF upon expiration of T3xx. As another alternative, RLF recovery (c) may be deferred. Deferred RLF detection may be applied as above in (b) or (as shown) detect RLF based on legacy parameters (a). Depending on multiple factors (such as bearer QoS, data activity level, mobility, location, time of day, etc.), RLF recovery may not be triggered. If the WTRU returns to the source coverage again before the configured duration has elapsed, recovery will not be performed. Depending on the decision made, an indication of the reason for the deferral, the time taken to restore the link, measurements, and other data may be transmitted to the network (718). The WTRU 700 may transmit RLF information to the network. The RLF information may include the reason for the deferral, the time taken to restore the radio link (RL), one or more channel conditions at the time of RLF, one or more channel conditions at the time of RL recovery, the WTRU location at the time of RLF, the WTRU location at the time of RL recovery, a time associated with RLF detection, and / or a time associated with RL recovery.

[0137] Figure 8 It shows that Figure 6 The two WTRUs (UE1, UE2) in Figure 7 Specific implementation in . At 812, the first WTRU (UE1) may determine one or more conditions of the first WTRU. At 812, the second WTRU (UE2) may determine one or more conditions of the second WTRU. The one or more conditions (e.g., WTRU conditions) may include configured radio bearers, quality of service (QoS) settings of the configured radio bearers, current data activity levels of the configured radio bearers, predicted data activity levels of the configured radio bearers, mobility states of the WTRUs, speeds of the WTRUs, WTRU locations, predicted WTRU locations, WTRU trajectories, or predicted WTRU trajectories. The first WTRU and the second WTRU may be configured to receive configuration information 810 from the network. The configuration information 810 may include a plurality of RLF specific parameters. The plurality of RLF specific parameters may include a RLF counter, a RLF constant, a RLF timer, or a RLF threshold. The plurality of RLF specific parameters may be used to determine whether RLF has occurred.

[0138] Typically, in addition to the configuration information (810) received by the WTRU (UE1, UE2) from the network, separate conditions and indications of the two different WTRUs (UE1, UE2) and, for example, predicted WTRU conditions and predicted WTRU trajectories (812) are included in the decision process (814) performed by the WTRU. Depending on the WTRU, the specific RLF implementation (816) may be different. As shown, at 814, the second WTRU (e.g., UE2) may determine to implement the legacy behavior (a). At 814, the decision may be made based on delays in active traffic or tolerant traffic as the second WTRU moves along its trajectory path. The first WTRU (e.g., UE1) may not have active traffic or delay tolerant traffic as the first WTRU moves along its trajectory path. At 814, the first WTRU (UE1) may determine to implement deferred RLF detection (b) based on an updated timer / constant, or may declare RLF upon expiration of a T3xx timer. Alternatively, at 814, the first WTRU (UE1) may determine RLF based on the legacy parameters (a), while deferring RLF recovery depending on one or more factors. Again, if the first WTRU (UE1) is back in source coverage before the configured duration has elapsed, recovery will not be performed. Additionally, depending on the decision made, indications may be made to the network regarding the reason for deferral, the time taken to restore the link, measurements, and other data (818).

[0139] For example, the first WTRU may determine one or more channel conditions associated with the RLM. For example, the WTRU may predict one or more of the channel conditions and / or the conditions of the WTRU based on historical data related to the one or more channel conditions and the conditions of one or more WTRUs operating within the network (e.g., such as UE1 and UE2). At 814, the first WTRU may detect (e.g., determine) a RLF-specific parameter from a plurality of RLF-specific parameters, for example, based on one or more conditions of the first WTRU. At 814, the first WTRU may determine to postpone RLF detection and / or postpone RLF recovery. For example, the first WTRU may be configured to determine RLF detection and / or RLF recovery behavior based on the detected RLF-specific parameters and / or one or more channel conditions associated with the first WTRU. The first WTRU may determine to perform RLF recovery based on one or more of the one or more determined channel conditions associated with the RLM, one or more determined conditions of the WTRU, one or more predicted channel conditions, and / or one or more predicted conditions of the WTRU. Determining to perform RLF recovery may include determining whether to postpone reestablishment of the radio link. The first WTRU may transmit an indication to the network based on determining RLF detection and / or RLF recovery behavior.

[0140] In an embodiment, a WTRU is provided with a WTRU timer and a constant that control the deferral of RLF detection and / or RLF recovery in a variety of ways. Examples of ways to provide them to the WTRU include one or more of the following: in a dedicated manner (e.g., RRC signaling, MAC signaling, etc.); system information broadcast (e.g., SIB1); and an indication (via SIB or dedicated signaling) of a WTRU potential configuration and the configuration (e.g., configured index) applied thereto that is transmitted to the WTRU.

[0141] In an embodiment, the network may transmit an indication (e.g., via SIB signaling, MAC CE, etc.) that enables / disables the deferral of RLF detection or recovery. As an example, the network may transmit to the WTRU an indication of whether to apply RLF detection deferral or RLF recovery deferral or both.

[0142] In an embodiment, the WTRU may be configured to transmit an indication to the network regarding the deferred RLF. For example, if the WTRU is configured to defer the RLF by t1 ms compared to legacy (based on any combination of the embodiments related to deferred RLF detection described herein) and the radio link to the source is restored at t2 ms (t2 < t1), the WTRU may transmit to the network an indication that the RLF was deferred and the link was restored in time (e.g., an RRC message, MAC CE, etc.). Additional information may also be included in the indication (e.g., measurements of the serving cell and neighboring cells at the time of failure and / or recovery, the time taken to restore the link, location information, etc.). Alternatively, the WTRU may only transmit an indication of the deferred RLF, and the network may later transmit a request for details, such as a measurement report and the time of WTRU failure (e.g., via a WTRU information response upon receipt of a WTRU information request).

[0143] In an embodiment, the WTRU may be configured to maintain storage of information regarding the deferred RLF and associated details (such as a measurement report) and may provide them upon request from the network (e.g., via a WTRU information request). Additionally, if the WTRU defers the RLF and still does not restore the link in time and declares an RLF, at a subsequent recovery (e.g., re-establishment), the WTRU may indicate to the network that an RLF report is available and that the RLF is a deferred RLF.

[0144] In an embodiment, the WTRU may be configured to convey to the network an indication regarding a postponed RLF recovery. For example, if the WTRU is configured to postpone RLF recovery by t1 ms compared to legacy (based on any combination of embodiments described herein related to postponed RLF handling) and the radio link with the source is restored at t2 ms (t2 < t1), the WTRU may convey to the network an indication that the RLF recovery was postponed and the link was restored in time (e.g., an RRC message, a MAC CE, etc.). Additional information may also be included in the indication (e.g., measurements of the serving cell and neighboring cells at the time of failure and / or recovery, the time taken to restore the link, location information, etc.). Alternatively, the WTRU may only convey an indication of the postponed RLF, and the network may later convey a request for details, such as a measurement report and the time of WTRU failure (e.g., via a WTRU information request).

[0145] In an embodiment, the WTRU may be configured to maintain storage of postponed RLF recovery information and associated details (such as a measurement report) and may provide them upon request from the network (e.g., via a WTRU information response, upon receipt of a WTRU information request).

[0146] In an embodiment, if the WTRU postpones RLF recovery and still does not restore the link in time and a recovery (e.g., a reconstruction) is performed, the WTRU may indicate to the network that an RLF report is available and that the RLF is related to the postponed RLF recovery.

[0147] In an embodiment, the WTRU may indicate to the network (in an indication regarding a postponed RLF, a postponed RLF recovery, or in the conveyance of details regarding a postponed RLF or RLF recovery) the reason for postponing RLF detection or recovery (e.g., RLF detection postponed due to meeting a condition related to data rate, RLF detection postponed due to meeting a condition related to mobility level, etc.). The WTRU may also include further information, such as how much RLF detection or recovery was postponed and whether the configuration from the network was modified based on WTRU predictions related to mobility level, data rate, trajectory, etc. (as discussed in Sections 5.2 and 5.3).

[0148] In other embodiments, the WTRU may be configured with a maximum time duration for storing information regarding postponed RLF detection or RLF recovery.

[0149] In an embodiment, the WTRU may be configured with a maximum size (e.g., xMB) to be used for storing information about deferred RLF detection and / or RLF recovery. Then, if the size of the stored information becomes larger than a specified threshold, the WTRU may delete older entries in the information about deferred RLF detection and recovery to make room for newer information.

[0150] A working example for implementing deferred RLF detection may require the WTRU to receive configurations from the network regarding radio link management (RLM) and associated radio link failure (RLF) detection. The configuration information may indicate behaviors that depend on one or more of the following: the quality of the radio link (RL) of the serving cell, the configured radio bearers and their corresponding QoS settings; the current and predicted data activity levels of the radio bearers (e.g., UL buffer occupancy, data rate, inactivity level, etc.), the mobility / speed of the WTRU, the current time, and the current and predicted WTRU location. The WTRU will also monitor WTRU conditions, such as current and predicted traffic, trajectory, etc. Based on measured or otherwise determined information and settings, the WTRU may modify RLF detection parameters (e.g., timer values, counters / constants, etc.) based on the received configuration and the current / predicted WTRU and network conditions. The predicted conditions may be based on historical data related to one or more channel conditions and the conditions of one or more WTRUs operating within the network. The WTRU may also perform radio link monitoring based on the modified parameters. During the detection deferral, upon recovery from a link failure before declaring RLF, the WTRU may transmit an indication to the network indicating that the RLF is deferred. Based on a request from the network or included with the indication of the deferred RLF, the WTRU may transmit details about the deferred RLF (e.g., reason for deferral, time taken to restore the link, measurements at the time of failure / recovery, WTRU location at the time of failure / recovery, current time at the time of failure / recovery, etc.).

[0151] In another working example for implementing deferred RLF recovery, a WTRU may receive a configuration regarding radio link management (RLM) and associated radio link failure (RLF) recovery, wherein the configuration specifies a duration for how long RLF recovery should be deferred, and the duration is configured to depend on one or more of the radio link quality of the serving cell, the configured radio bearers and their corresponding QoS settings, the current and predicted data activity levels of the radio bearers (e.g., UL buffer occupancy, data rate, inactivity level, etc.), the mobility / speed of the WTRU, the current time, and the current and predicted WTRU location. The WTRU may monitor its operating conditions (e.g., current and predicted traffic, trajectory, etc.) and monitor the radio link itself. The WTRU may determine a duration for delaying RLF recovery based on the received configuration and current / predicted WTRU and network conditions. Upon RLF detection, the WTRU may refrain from starting RLF recovery (e.g., reestablishment) for the determined delay duration. Upon recovery from a link failure before the duration delay has elapsed, the WTRU may transmit an indication to the network indicating that RLF recovery is deferred. Based on a request from the network or included with the indication about the deferred RLF recovery, the WTRU may transmit details about the deferred RLF recovery (e.g., reason for the deferred, time taken to restore the link, measurements at the time of failure / recovery, WTRU location at the time of failure / recovery, current time at the time of failure / recovery, predicted conditions, etc.).

[0152] In an embodiment, a method and corresponding apparatus for postponing RLF detection are contemplated, wherein the WTRU may receive a configuration regarding RLM and associated RLF detection from the network. The configuration information may indicate behavior that depends on one or more of: the RL quality of the serving cell, the configured radio bearers and their corresponding QoS settings; the current and predicted data activity levels of the radio bearers, the mobility / speed of the WTRU, the current time, and the current and predicted WTRU locations. The WTRU will also monitor WTRU conditions, such as current and predicted traffic, trajectory, etc. Based on measured or otherwise determined information and settings, the WTRU may modify RLF detection parameters (including timer values, counters / constants, and other parameters) based on the received configuration and the current / predicted WTRU and network conditions. The predicted channel conditions and / or the conditions of the WTRU may be based on historical data related to the channel conditions and other WTRUs operating within the network. The WTRU may also perform RLM based on the modified parameters.

[0153] In an embodiment, during the deferral of RLF detection, upon recovery from a link failure prior to declaring RLF, the WTRU may transmit an indication to the network indicating that the RLF is deferred. Based on a request from the network, or included with the indication of the deferred RLF, the WTRU may transmit details regarding the deferred RLF. The deferred details may include the reason for the deferral, the time taken to restore the link, measurements at the time of failure / recovery, the WTRU location at the time of failure / recovery, the current time at the time of failure / recovery, and other operational details. In an embodiment, during the deferral of RLF recovery, the WTRU may receive configuration information regarding RLM and associated RLF recovery from the network.

[0154] In an embodiment, the configuration information may specify a duration for how long RLF recovery may be postponed. The configuration details may depend on one or more of the following: the RL quality of the serving cell, the configured radio bearers and their corresponding QoS settings, the current and predicted data activity levels of the radio bearers, the mobility / speed of the WTRU, the current time, and the current and predicted WTRU location. The WTRU may monitor its operating conditions (including current and predicted traffic, trajectory, and other conditions) and monitor the radio link itself. The WTRU may determine the duration for delaying RLF recovery based on the received configuration and the current / predicted WTRU and network conditions. When RLF is detected, the WTRU may refrain from starting RLF recovery (e.g., reestablishment) for the determined delay duration.

[0155] In an embodiment, during a deferred RLF recovery, upon recovery from a link failure before the elapsed delay has elapsed, the WTRU may transmit an indication to the network indicating that the RLF recovery is deferred. Based on a request from the network, or included with the indication regarding the deferred RLF recovery, the WTRU may transmit details regarding the deferred RLF recovery. The details may include the reason for the deferred, the time taken to restore the link, measurements at the time of failure / recovery, the WTRU location at the time of failure / recovery, the current time at the time of failure / recovery, and other details.

[0156] In an embodiment, the method discussed herein may be implemented in a WTRU, including monitoring of the RL quality of a serving cell of a network node serving the WTRU. The WTRU may receive configuration information from the network, including timer durations and counter values ​​for RL state determination of the serving cell, and dependency information of the timer durations and counter values ​​based on current and predicted WTRU and network conditions. The WTRU measures or otherwise determines the RL quality of the serving cell and the current WTRU operating conditions and determines the predicted conditions. Based on the configuration information and the measured or otherwise determined WTRU and network conditions, the WTRU modifies the timer durations and counter values, and performs RL state determination based on the modified timer durations and counter values.

[0157] In an embodiment, the configuration information may indicate the dependency of the timer duration and counter value on one or more of: the RL quality of the serving cell, the configured radio bearers of the WTRU and their corresponding QoS settings; the current and predicted data activity levels of the radio bearers of the WTRU, the mobility / speed of the WTRU, the current time, and the current and predicted WTRU location. In addition, when recovering from RLF before the expiration of the modified timers and counters, the WTRU may transmit an indication to the network indicating that the RLF is postponed.

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

Claims

1. A method implemented by a remote wireless transmit receive unit (WTRU), the method comprising: receiving radio link failure (RLF) configuration information from a network, the RLF configuration information comprising a plurality of RLF-specific parameters for determining whether an RLF has occurred; determining one or more conditions of the WTRU; detecting an RLF specific parameter from the plurality of RLF specific parameters based on the one or more conditions of the WTRU; determining one or more channel conditions associated with radio link management (RLM); determining one or both of RLF detection and RLF recovery behavior based on the detected RLF-specific parameters and the determined one or more channel conditions; and An indication is transmitted to the network based on determining the RLF detection or RLF recovery behavior.

2. The method of claim 1 , wherein the one or more conditions of the WTRU include one or more of: a configured radio bearer, a quality of service (QoS) setting of the configured radio bearer, a current data activity level of the configured radio bearer, a predicted data activity level of the configured radio bearer, a mobility state of the WTRU, a speed of the WTRU, a WTRU location, a predicted WTRU location, a WTRU trajectory, or a predicted WTRU trajectory.

3. The method of claim 1 or 2, further comprising determining to defer transmitting the indication to the network based on the detected RLF-specific parameter and the determined one or more channel conditions.

4. The method of claim 3, wherein the indication transmitted to the network indicates that the RLF recovery is deferred.

5. The method of claim 4, further comprising transmitting RLF information to the network, the RLF information comprising one or more of: a reason for deferral, a time taken to recover the radio link (RL), one or more channel conditions at the time of RLF, one or more channel conditions at the time of RL recovery, a WTRU location at the time of the RLF, a WTRU location at the time of RL recovery, a time associated with RLF detection, or a time associated with RL recovery.

6. The method according to any one of claims 1 to 5, wherein the plurality of RLF specific parameters comprises one or more of a RLF counter, a RLF constant, a RLF timer or a RLF threshold.

7. The method of claim 6, further comprising modifying the detected RLF-specific parameters based on the one or more conditions of the WTRU.

8. The method of any one of claims 1 to 7, wherein the determined one or more channel conditions associated with the RLM include one or more of an RLM reference signal (RLM-RS) or an out-of-sync indication.

9. The method according to any one of claims 1 to 8 also includes determining to perform RLF recovery based on one or more of the determined one or more channel conditions associated with the RLM, the determined one or more conditions of the WTRU, one or more predicted channel conditions, and one or more predicted conditions of the WTRU.

10. The method of claim 9, wherein determining to perform RLF recovery comprises determining whether to defer reestablishment of the radio link.

11. The method according to any one of claims 1 to 10 further includes predicting one or more of the channel conditions and the conditions of the WTRU based on historical data related to one or more channel conditions and the conditions of one or more WTRUs operating within the network.

12. A wireless transmit receive unit (WTRU), the wireless transmit receive unit (WTRU) comprising: A processor, the processor being configured to: receiving radio link failure (RLF) configuration information from a network, the RLF configuration information comprising a plurality of RLF-specific parameters for determining whether an RLF has occurred; determining one or more conditions of the WTRU; detecting an RLF specific parameter from the plurality of RLF specific parameters based on the determined one or more conditions of the WTRU; determining one or more channel conditions associated with radio link management (RLM); determining one or both of RLF detection and RLF recovery behavior based on the detected RLF-specific parameters and the determined one or more channel conditions; and An indication is transmitted to the network based on determining the RLF detection or RLF recovery behavior.

13. A WTRU according to claim 12, wherein the one or more conditions of the WTRU include one or more of the following: a configured radio bearer, a quality of service (QoS) setting of the configured radio bearer, a current data activity level of the configured radio bearer, a predicted data activity level of the configured radio bearer, a mobility state of the WTRU, a speed of the WTRU, a WTRU location, a predicted WTRU location, a WTRU trajectory, or a predicted WTRU trajectory.

14. The WTRU of claim 11 or 13, wherein the processor is further configured to determine to defer transmitting the indication to the network based on the selected RLF specific parameter and the determined one or more channel conditions.

15. The WTRU of claim 14, wherein the indication transmitted to the network indicates that the RLF recovery is deferred.

16. The WTRU of claim 15, wherein the processor is further configured to transmit RLF information to the network, the RLF information comprising one or more of: a reason for deferral, a time taken to recover the radio link (RL), one or more channel conditions at the time of RLF, one or more channel conditions at the time of RL recovery, a location of the WTRU at the time of the RLF, a location of the WTRU at the time of RL recovery, a time associated with RLF detection, or a time associated with RL recovery.

17. The WTRU of any one of claims 12 to 16, wherein the plurality of RLF specific parameters include one or more of a RLF counter, a RLF constant, a RLF timer, or a RLF threshold.

18. The WTRU of claim 17, wherein the processor is further configured to modify the detected RLF specific parameters based on the one or more conditions of the WTRU.

19. The WTRU of any one of claims 12 to 18, wherein the determined one or more channel conditions associated with the RLM include one or more of an RLM reference signal (RLM-RS) or an out-of-sync indication.

20. The WTRU of any one of claims 12 to 19, wherein the processor is further configured to determine to perform RLF recovery based on one or more of the determined one or more channel conditions associated with the RLM, the determined one or more conditions of the WTRU, one or more predicted channel conditions, and one or more predicted conditions of the WTRU.

21. The WTRU of claim 20, wherein upon determining to perform RLF recovery, the processor is configured to determine whether to defer radio link reestablishment.

22. The method according to any one of claims 12 to 21 further includes predicting one or more of the channel conditions and the conditions of the WTRU based on historical data related to one or more channel conditions and the conditions of one or more WTRUs operating within the network.

Images