Methods for RLF predictions and recovery

Abstract

A wireless transmit / receive unit (WTRU) may include a processor and a memory. The WTRU may be configured to send capability information related to radio link failure (RLF) predictions. The WTRU may be configured to receive a first configuration of RLF detection parameters. The first configuration may be based on one or more of a type of an out-of-synchronization (OOS) or in-synchronization (IS) measurement, and / or a number of measured OOS / IS measurements. The WTRU may be configured to receive a second configuration. The WTRU may be configured to perform the RLF prediction based on the first configuration, OOS / IS measurements, and / or predicted OOS or IS measurements over a period of time. Upon determining an RLF has been predicted within the period of time, the WTRU may be configured to perform the RLF recovery or the RLF reporting based on the second configuration and send an indication to a network.

Description

METHODS FOR RLF PREDICTIONSAND RECOVERYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No. 63 / 572,529 filed on April 1, 2024, the entire contents of which is incorporated herein by reference.BACKGROUND

[0002] While in RRC_CONNECTED state, the WTRU may perform Radio Link Monitoring (RLM) on the serving cell (e.g., primary cell in the case of multiple cells configured for carrier aggregation). The WTRU may be configured with timers and counters to use when detecting Radio Link Failure (RLF) and performing radio link recovery or re-establishment. The physical layer (PHY) may send out of sync (OOS) and in sync (IS) indications to the radio resource control (RRC), based on whether the serving cell’s signal-to-noise ratio (SINR) is below or above a configured SINR threshold. Upon the detection of N310 consecutive OOS indications from PHY, RRC may start a timer with a duration of T310. While T310 is running, the WTRU may attempt to recover the radio link on the serving cell. If N311 consecutive IS indications are received at RRC from PHY, the timer may be stopped and the WTRU may consider the radio link to have been recovered and resume normal operation and continue RLM on the serving cell. If T310 expires before the N311 consecutive IS indications are received, the WTRU may consider this as an RLF. Upon detection of RLF, a timer may be started with the duration of T311 , and the WTRU may perform a cell search in order to determine whether there is a suitable cell available on which the WTRU may perform RRC connection reestablishment. If the timer T311 expires before the WTRU finds a suitable cell, the WTRU may enter RRC J DLE mode with the cause “RRC Connection failure”. If the WTRU does find a suitable cell (which could be the original serving cell), this cell may be selected, T311 may be stopped, T301 may be started, and an RRC Connection re-establishment procedure may be started. If the timer T301 expires before the RRC Connection re-establishment is complete, the WTRU may enter idle mode with the cause “RRC Connection failure”.SUMMARY

[0003] A wireless transmit / receive unit (WTRU) may include a processor and a memory. The WTRU may be configured to send capability information related to radio link failure (RLF) predictions. The WTRU may be configured to receive a first configuration of RLF detection parameters. The first configuration of the RLF detection parameters may be based on one or more of a type of an out-of-synchronization (OOS) or in-synchronization (IS) measurement, and / or a number of measured OOS or IS measurements. The WTRU may be configured to receive a second configuration. The second configuration may include an action to be performed in response to the RLF prediction. The action may include an RLF recovery and / or an RLF reporting. The WTRU may be configured to perform the RLF prediction based on the first configuration, OOS or IS measurements, and / or predicted OOS or IS measurements over a period of time. Upon determining an RLF has been predicted within the period of time, the WTRU may be configured to perform the RLF recovery or the RLF reporting based on the second configuration and send an indication to a network.

[0004] The RLF detection parameters may include one or more of n310 values or scaling factors, n311 values or scaling factors, and / or t310 values or scaling factors. The n310 values or scaling factors may be associated with the measured or predicted OOSs. The n311 values or scaling factors may be associated with the measured or predicted ISs. The t310 values or scaling factors may be associated with a time duration for the WTRU to wait for the measured or predicted ISs. The time duration may be after the WTRU has measured or predicted the measured or predicted OOSs and before the WTRU determines the RLF has been predicted.

[0005] The first configuration of the RLF detection parameters may be based on a number or a confidence level of the predicted OOS or IS measurements. The measured OOS may be non-consecutive OOS. The second configuration may include an additional RLF-related logging configuration. The second configuration may include a pre-RLF indication configuration. The second configuration may include a L1 / L2 Triggered Mobility (LTM) configuration and / or a conditional handover (CHO) configuration for the RLF recovery. The period of time may be determined based on a preconfigured timer and / or an updated timer based on the measured OOS or IS measurements. The indication may be information indicating that the RLF recovery and / or the RLF reporting is being performed due to the RLF prediction.

[0006] The WTRU may be configured to perform the RLF recovery and / or the RLF reporting prior to identification of a predefined number of consecutive OOS measurements configured for determining an RLF.

[0007] The WTRU may be configured to perform the RLF recovery and / or the RLF reporting based on a prediction that a predefined number of consecutive IS measurements will not be received within a predefined period of time.

[0008] In addition to or instead of performing the RLF recovery upon the RLF prediction, the WTRU may be configured to send a pre-RLF indication, send a first indication indicating the RLF recovery has been finished, and / or send a second indication indicating additional RLF logging is available.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0010] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0011] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0012] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0013] FIG. 2 illustrates an example of the Radio Link Monitoring (RLM) and Radio Link Failure (RLF) detection procedures.DETAILED DESCRIPTION

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

[0015] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit,a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU. Further, any description herein that is described with reference to a UE may be equally applicable to a WTRU (or wee versa). For example, a WTRU may be configured to perform any of the processes or procedures described herein as being performed by a UE (or vice versa).

[0016] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the I nternet 110, and / or the 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, a NR NodeB, 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.

[0017] 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), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one 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 transmit and / or receive signals in desired spatial directions.

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

[0019] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

[0022] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0023] 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, CDMA20001X, 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), and the like.

[0024] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In 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 femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0025] 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] 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 the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide 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), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications 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.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A 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.

[0028] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include 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, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

[0034] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the 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, and the like.

[0035] 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 locationinformation over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0036] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

[0041] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0042] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. 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.

[0043] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

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

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

[0047] In representative embodiments, the other network 112 may be a WLAN.

[0048] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (I BSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0049] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every 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.

[0050] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0051] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0052] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0053] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest 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, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel isbusy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0054] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0055] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an 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.

[0056] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any numberof 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, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the 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, the 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).

[0057] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the 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 gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0058] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0059] 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 the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0060] The CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, differentnetwork slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. 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.

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

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

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

[0065] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one ormore, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0067] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g. , testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] A wireless transmit / receive unit (WTRU) may be configured to send capability information regarding Radio Link Failure (RLF) prediction. The WTRU may be configured with RLF detection parameters (e.g., n310 values or scaling factors, n311 values or scaling factors, T310 values or scaling factors, etc.,) that are dependent on one measured and predicted In Sync (IS) and Out of Sync (OOS), and confidence levels of the predictions. The WTRU may be configured to log (pre-)RLF related information (e.g., log info whenever even before OOS (e.g., predicted and / or measured) reaches the N310 count, etc.). The WTRU may be configured with L1 / L2 triggered mobility (LTM)Zconditional handover (CHO) configurations for recovery based on RLF type (e.g., predicted RLF or actual RLF, for example, different target cell thresholds for recovery based on actual RLF or predicted RLF). The WTRU may be configured to directly apply recovery without starting T310 if the prediction indicates less likelihood of getting the required consecutive N311 1S indications with T310 duration. The WTRU may predict RLF according to the received configuration and applying the recovery according to the received recovery configuration. The WTRU may send indication to the network whether the recovery is done due to actual RLF or predicted RLF. TheWTRU may be configured to send a pre-RLF indication to the network, indicating RLF is anticipated to occur within a certain time duration from now, at a certain confidence level.

[0069] The terms AI / ML and AIML may be used interchangeably.

[0070] The terms “data”, “measurements”, “report” and “results” may be used interchangeably.

[0071] The terms indication, information and message may be used interchangeably.

[0072] The terms “serving cell” and “source cell” may be used interchangeably.

[0073] The terms “target cell”, “candidate cell”, and “neighbor cell” may be used interchangeably.

[0074] The terms “expected”, “predicted”, “anticipated”, and “estimated” may be used interchangeably.

[0075] The term “Ax” may be used to refer to any of the events A1, A2, A3, A4, A5, A6, where the events may be defined as event A1 (Serving becomes better than threshold), event A2 (Serving becomes worse than threshold), event A3 (Neighbor becomes offset better than SpCell, where SpCell is the Primary Cell, PCell or the Primary Secondary Cell, PSCell, in the case of dual connectivity), event A4 (Neighbor becomes better than threshold), event A5 (SpCell becomes worse than threshold 1 and neighbor becomes better than threshold2), and / or event A6 (Neighbor becomes offset better than SCell, where an SCell is a Secondary Cell in the case of carrier aggregation).

[0076] The term “Bx” may be used to refer to any of the events B1, B2, where the events are defined as event B1 (Inter radio access technology (RAT) neighbor becomes better than threshold), and / or event B2 (PCell becomes worse than thresholdl and inter RAT neighbor becomes better than threshold2).

[0077] The term “CHO” is used to refer to Conditional reconfiguration or conditional handover. For CHO, the WTRU may be provided with an RRC reconfiguration (e.g., a handover (HO) command) that is executed when certain measurement conditions are fulfilled (e.g., cond Ax / Bx events such as A3). That is, instead of the legacy way of the WTRU sending a measurement report and the network sending a HO command, the HO command may be already prepared and sent to the WTRU, and the WTRU may execute this already stored HO command when the measurement conditions are fulfilled.

[0078] The term “LTM” may be used to refer to “L1 / L2 triggered mobility”. LTM is like CHO in that the WTRU is pre-configured with the RRC reconfiguration (HO) command towards a target cell. However, the WTRU may not autonomously execute the RRC reconfiguration command based on the fulfillment of measurement events. The WTRU may be sending L1 measurement reports to the network, and the network may instruct the WTRU to execute the LTM to one of the target cells using an LTM MAC CE. Conditional LTM may be favored where the WTRU can execute the LTM autonomously upon the fulfillment of a measurement event(e.g., an event based on L1 filtered measurements, an event base on L3 filtered measurements as in legacy CHO, etc.).

[0079] The term “measurement event” may refer to any of the Ax / Bx events, or IS and OOS indications (e.g., an IS can be considered as a measurement event that is triggered when the serving cell’s SINR is lower than the Qout, etc.).

[0080] The terms “N310” and “N311” may be used to refer to the OOS / IS thresholds (e.g., configured parameters for RLM), while the terms “n310” and “n311” may be used to refer to the current number of consecutive OOS and IS indications received at the RRC from PHY.

[0081] The term “radio link problem detected” may be used to refer to the case when N310 consecutive OOS indications have been received.

[0082] The term “recovery monitoring” may be used to refer to the case and / or duration in which a radio link problem has been detected, the WTRU has started T310, and waiting for N311 consecutive IS indications.

[0083] The term “radio link recovered” may be used to refer to the case when N311 consecutive IS indications have been received after T310 has been started (which is started after radio link problem is detected).

[0084] The term “radio link failure detected” may be used to refer to the case where T310 has expired before the reception of N311 consecutive IS indications.

[0085] The term “predicted RLF” or “RLF is predicted” may be used to refer the case where / when the WTRU has determined an RLF based on current and predicted IS / OOS indications, according to any of the embodiments described below.

[0086] It should be noted that though the focus of the descriptions of embodiments here may include description of prediction based on artificial intelligence and machine learning (AIML) models, the proposed embodiments may be equally applicable to other form of prediction that doesn’t use AIML (e.g. time series forecasting, interpolation methods, etc.).

[0087] FIG. 2 illustrates an example procedure 200 of the RLM and RLF detection. While in RRC_CONNECTED state, the WTRU may perform Radio Link Monitoring (RLM) on the serving cell (e.g., primary cell in the case of multiple cells configured for carrier aggregation). The WTRU may be configured with timers and counters to use when detecting Radio Link Failure (RLF) and performing radio link recovery or re-establishment. The physical layer (PHY) may send out of sync (OOS) and in sync (IS) indications to the RRC, based on whether the serving cell’s signal-to-noise ratio (SINR) is below or above a configured SINR threshold. Upon the detection of N310 consecutive OOS indications from PHY, RRC may start a timer witha duration of T310 as shown in 202. While T310 is running, the WTRU may attempt to recover the radio link on the serving cell. If N311 consecutive IS indications are received at RRC from PHY, the timer may be stopped and the WTRU may consider the radio link to have been recovered, resume normal operation, and continue radio link monitoring (RLM) on the serving cell as shown in 204. If T310 expires before the N311 consecutive IS indications are received, the WTRU may consider this as an RLF as shown in 206. Upon detection of RLF, a timer may be started with the duration of T311 , and the WTRU may perform a cell search in order to determine whether there is a suitable cell available on which the WTRU may perform radio resource control (RRC) connection re-establishment. If the timer T311 expires before the WTRU finds a suitable cell, the WTRU may enter RRCJDLE mode with the cause “RRC Connection failure” as shown in 208. If the WTRU does find a suitable cell (which could be the original serving cell), this cell may be selected as shown in 210, T311 may stop, an RRC Connection re-establishment procedure may be started as shown in 212, and T301 may start when the RRC Connection re-establishment request is sent as shown in 214. If the timer T301 expires before the RRC Connection re-establishment is complete, the WTRU enter idle mode with the cause “RRC Connection failure”.

[0088] An RLF may occur, for example, when the WTRU goes out of coverage (e.g., entering a tunnel or moving to a rural area out of cellular coverage). An RLF may occur, for example, as a result of too late handover, whereby RLF is detected on the serving cell before a handover can be completed. The first part of the procedure (e.g., N310, T310, N311) may be intended to allow the WTRU a chance to recover the radio link in case of a temporary problem. The second part of the procedure after T310 expiry may be intended to allow the WTRU to attempt to re-establish the connection on the same or another cell without having to release the connection completely.

[0089] The legacy approach for RLM may be a reactive approach, where a recovery is attempted after an RLF is detected (e.g., only after an RLF is detected). One downside of this reactive approach may include that it may take a long time for recovery, as the WTRU has to wait for T310 before performing the cell selection. Another disadvantage is that RLF may be declared prematurely and WTRU may end up reestablishing to the same cell or temporarily reestablish to a neighbor but soon be handed over back to the cell where RLF was detected.

[0090] If a WTRU has a capability to do measurement prediction (e.g., based on an Al model), a more proactive approach may be taken to the detection and recovery of RLF. For example, the WTRU may postpone the declaring of RLF and initiating recovery and / or re-establishment if the serving cell measurements are expected to get better soon (e.g., if the RLF was due to a very narrow area of out ofcoverage). As another example, the WTRU may expediate the declaring of RLF and initiating recovery and / or re-establishment if the serving cell measurements are expected to get worse and there is a neighbor cell that already has a good signal level or / and expected to get better. Thus, unnecessary reestablishments may be prevented or recovery may be done faster without necessarily waiting for timer expiries.

[0091] Embodiments are described for leveraging the WTRU’s measurement prediction capability of serving and neighbor cell to enhance RLF detection and recovery (e.g., faster recovery, deferred RLF declaration, etc.). Described herein are embodiments for detecting RLF and performing recovery that utilizes the combination of actual measured In Sync (IS) and Out of Sync (OOS) indications as well as predicted IS / OOS indications. A WTRU may send capability information related to RLF predictions (e.g., based on AIML model). Capability may include details about the prediction. The details about the prediction may include one or more of type of prediction (e.g., whether actual prediction of radio signal levels, directly predicting of IS / OOS, directly predicting RLF, etc.), time duration of predictions, confidence level of prediction, area / cells / frequencies where the predictions may be made, and the like.

[0092] The WTRU may receive a first configuration of RLF detection parameters. The RLF detection parameters may include one or more of n310 values or scaling factors, n311 values or scaling factors, and / or t310 values or scaling factors. For example, the n310 values or scaling factors may be associated with the measured or predicted OOSs. The n311 values or scaling factors may be associated with the measured or predicted ISs. The t310 values or scaling factors may be associated with a time duration for the WTRU to wait for the measured or predicted ISs. The time duration may be after the WTRU has measured or predicted the measured or predicted OOSs and before the WTRU determines the RLF has been predicted. The first configuration of the RLF detection parameters may be based on one or more of a type of OOS and / or IS measurement (e.g., actually measured or predicted), or a number of actually measured OOS and / or IS measurements). In some embodiments, the measured OOS may be non-consecutive OOS. The first configuration of the RLF detection parameters may also be based on a number and / or a confidence level of OOS and / or IS predictions (e.g., consecutive IS / OOS, total number of IS / OOS within a configured duration, etc.).

[0093] The WTRU may receive a second configuration. The second configuration may include an action to be performed in response to the RLF prediction. The action may include an RLF recovery and / or RLF reporting. The second configuration may be regarding the RLF recovery / reporting. The second configuration may include an additional RLF-related logging configuration. For example, the additional RLF-related loggingconfiguration may include log information whenever a predicted and / or measured OOS is more than a certain value even if it doesn’t reach the n310 value, log information whenever N310 OOS has been reached even if T310 gets cancelled due to N311 IS, etc. The second configuration may include a pre-RLF indication configuration. For example, the pre-RLF indication configuration may include sending a pre-RLF indication upon RLF prediction instead of performing recovery. The second configuration may further include LTM / CHO configurations for recovery based on RLF type (e.g. , different target cell thresholds for recovery based on actual RLF or predicted RLF). The RLF type may include predicted RLF and / or actual RLF.

[0094] The WTRU may perform RLF detection and / or prediction based on the first configuration, OOS and / or IS measurements, and / or predicted OOS and / or IS measurements over a period of time. The period of time may be determined based on a preconfigured timer and / or an updated timer based on the measured OOS and / or IS measurements. The WTRU may perform RLF detection and / or prediction based on actual measurements and / or predicted measurements according to the received configuration.

[0095] Upon determining an RLF has been predicted within the period of time, the WTRU may perform the RLF recovery or the RLF reporting based on the second configuration and send an indication to a network. The RLF recovery may include reestablishment and / or executing LTM and / or CHO. The indication may include information indicating that the RLF recovery or the RLF reporting is being performed due to the RLF prediction. In various embodiments, the WTRU may perform the RLF recovery and / or the RLF reporting prior to identification of a predefined number of consecutive OOS measurements configured for determining an RLF. In various embodiments, the WTRU may perform the RLF recovery and / or the RLF reporting based on a prediction that a predefined number of consecutive IS measurements will not be received within a predefined period of time. In various embodiments, the WTRU may send a pre-RLF indication in addition to or instead of performing the RLF recovery upon the RLF prediction. In various embodiments, the WTRU may send a first indication to the network (e.g., during recovery, after recovery, etc.) to indicate that the RLF recovery has been finished due to predicted RLF (e.g., re-establishment cause value, additional flag in reconfiguration complete message if LTM / CHO is executed, etc.) in addition to or instead of performing the RLF recovery upon the RLF prediction. In various embodiments, the WTRU may send a second indication indicating additional RLF logging is available, in addition to or instead of performing the RLF recovery upon the RLF prediction.

[0096] Upon predicting an RLF, the WTRU may send a pre-RLF indication. The WTRU may perform recovery (e.g., re-establishment, execute LTM / CHO, etc.). The WTRU may send indication to the network (e.g., during recovery, after recovery, etc.,) to indicate that recovery was done due to predicted RLF (e.g., re-establishment cause value, additional flag in reconfiguration complete message if LTM / CHO is executed, etc.). The WTRU may send indication that additional RLF logging is available. This embodiment may enable pre-emptive recovery from RLF based on predicted radio conditions of serving and neighbor cells.

[0097] Each of the embodiments described herein may be agnostic to the kind of artificial intelligence and machine learning (AIML) model and / or technique used by the WTRU (e.g., the algorithm used, the mechanism such as neural network or what kind of neural network, for example, depth and parameters / weights of the network, etc.,), the origins of the model (e.g., WTRU vendor, operator, network vendor, etc.,), or how / where the training of the model is done (e.g., the input data used for the training, where the training is performed, if the training is performed offline or online, etc.). However, it can be assumed that the model may be trained based on historical observation of one or more WTRUs’ actual measurements in different WTRU and network conditions (e.g., during certain time durations of the day, during certain days of the week, at different locations, different WTRU mobility patterns / speeds, under different network conditions that are visible to the WTRU such as frequency / bandwidth, under different network configurations, which may be visible to the WTRU just as a network configuration index that is provided by the network at the time of training or data collection for the training, etc.).

[0098] There may be some WTRU capability communication between the WTRU and the network about AIML capability (e.g., where the WTRU can indicate to the network the supported AIML models / functions, confidence level of predictions, time horizon of predictions (e.g., how far along in the future are the prediction being made), etc.). The WTRU may support several AIML models for a certain functionality (e.g., with different prediction time horizons, prediction confidence levels, processing requirements, trained under / for operation in different freq uencies / cells / location / times of day, etc.). A given AIML model may operate in different modes (e.g., with different levels of prediction confidence levels at different prediction time horizons, at different locations, frequencies, WTRU mobility pattern / speed, etc.). The WTRU may choose the AIML model to use for a certain functionality (e.g., network may decide for which functionalities the WTRU can use AIML based operation, and the WTRU may choose the AIML model to use) or the network may explicitly control this (E.g., WTRU may provide details of AIML models and their capabilities, network determines which model to activate for a particular functionality). The AIML models can be available at the WTRU already trained, or the WTRU may be provided with an untrained AIML model and performs the training by itself. The AIML model may be available at the WTRU already trained, and the WTRU may be enabled and / or configured to perform further training (e.g., for different conditions such as freq uencies / cells / location / times of day, for the same conditions as the initial training but for increasing the level of confidence or / and the prediction time horizon, for differentWTRU speeds, etc.). The Al ML model may be available at the WTRU but not trained at all or trained (e.g., only trained) for certain WTRU / network conditions, and WTRU may be configured to train the model (e.g. for the conditions that it is not trained for). Network conditions may refer to conditions and / or configurations of the network that the WTRU can measure and / or detect (e.g., cells, frequencies, bandwidth, and any other network capabilities and / or configurations that are explicitly indicated to the WTRU or can be measured by the WTRU). Network conditions may refer to conditions and / or configurations of the network that the WTRU may not explicitly know. For example, during model training (or data collection for model training), the network may provide to the WTRU a network configuration index. After the training is done (e.g., at the WTRU, at the network, or another entity that uses the data collected by the WTRU), the metadata of the model may be updated to reflect that the model has been trained under the indicated network configuration index. When the model is to be used by the WTRU (e.g., at another location compared to where the training data was collected), the network configuration index communicated by the network (e.g., the current serving cell, neighbor cells, etc.) may be compared with the index that is associated with the model to determine if that model can be used at that location and / or time. The network configuration index may be used to determine if the model has been tested to work properly under a certain network configuration. Like the network configuration index, a model (e.g., in the metadata) may be associated with a dataset index / ID, which can be an index to the conditions under which the model was trained and / or performance tested. The dataset index may be associated not only with network configuration at the time of the testing or performance monitoring, but also with WTRU conditions (e.g., WTRU mobility state and / or pattern).

[0099] Embodiments are described for the radio link failure detection and recovery. A WTRU that is in RRC_CONNECTED may continuously monitor the radio link for ensuring the link is good and / or reliable enough for communication, a process referred to as Radio Link Monitoring (RLM). The WTRU may monitor the downlink (DL) quality based on the reference signal (RS) that is being broadcasted from the serving cell.

[0100] In case the WTRU is operating in single connectivity, the WTRU may perform RLM on the Primary Cell (PCell). In case the WTRU is operating in dual connectivity (DC), the WTRU may perform RLM on both the PCell and the primary cell of the secondary cell group (SCG), which is referred to as Primary Secondary Cell (PSCell).

[0101] The WTRU may be configured which RLM reference signals (RLM-RS) to monitor to determine the radio quality of the PCell (and the PSCell in case of DC). The network may configure the WTRU to performthe radio link monitoring (RLM) based on Synchronization Signal Block (SSB), Channel State Information - Reference Signal (CSI-RS), or a combination of the two.

[0102] WTRUs may be configured with thresholds to determine whether the radio link being monitored is good and / or reliable enough. For example, Qout may be the level at which the DL cannot be reliably received and may correspond to out-of-sync block error rate (BLERout) which is the 10% block error rate of a hypothetical physical downlink control channel (PDCCH) transmission. For another example, Qin may be the level at which the DL can be significantly more reliably received than at Qout and may correspond to insync block error rate (BLERin), which is 2% block error rate of a hypothetical PDCCH transmission.

[0103] The WTRU may be configured with timers and counters that are used to determine the reliability of the link being monitored. For example, n310 may be the number of consecutive times that an out of sync indication is received at the RRC from the lower layers (e.g. PHY) before RRC starts considering the link being monitored as experiencing reliability problem. For example, n311 may be the number of consecutive times that an in-sync indication is received at the RRC from the lower layers (e.g., PHY) before RRC considers the link being monitored has become reliable again, For another example, t310 may be the duration of the timer that is started upon n310 consecutive out-of-sync indications received from lower layers and stopped upon n311 consecutive in-sync indications. If the T310 timer expires before the reception of n311 consecutive in-sync indications from lower layers, RRC may consider the link has failed and declares an RLF (Radio Link Failure).

[0104] Upon RLF detection, the WTRU may initiate the RRC re-establishment procedure. As the first step of the re-establishment procedure, the WTRU may perform cell selection (e.g., select the best / strongest suitable cell). If the WTRU has no CHO or LTM configuration associated with the selected cell, it may proceed with the legacy re-establishment procedure (e.g., releasing the WTRU context, sending the RRC Re-establishment message, etc.). On the other hand, if the WTRU has a CHO or LTM configuration associated with the selected cell, the WTRU may not release its context and / or configuration and instead execute the concerned CHO and / or LTM configuration.

[0105] Embodiments are described for the WTRU indicating capability related to RLF prediction. The WTRU may indicate to the network that is has capabilities related to RLF prediction. The WTRU may indicate that it can predict the occurrence of an OOS event in one or more future time instances. The WTRU may indicate that it can predict the occurrence of an IS event in one or more future time instances. The WTRU may indicate that it can predict the occurrence of a certain number of OOS events within a given time duration from now. The WTRU may indicate that it can predict the occurrence of a certainnumber of consecutive OOS events within a given time duration from now. The WTRU may indicate that it can predict the occurrence of a certain number of IS events within a given time duration from now. The WTRU may indicate that it can predict the occurrence of a certain number of consecutive IS events within a given time duration from now. The WTRU may indicate that it can predict the occurrence of an RLF within a given time duration from now.

[0106] The WTRU’s capability to predict RLF may be implicit, based on another capability indication related to measurements. For example, the WTRU may have indicated it can predict the radio signal level of cells, and based on that WTRU may be configured with the information it needs to translate that prediction into an OOS prediction, an IS prediction, an RLF, etc. (e.g., Qin threshold, Qout threshod, N310 / N311 counter values, T311 timer values, etc.).

[0107] The WTRU may indicate different confidence levels or confidence level ranges for the predication, e.g., depending on the length of a time duration of prediction. For example, a WTRU may indicate that can predict an OOS event happening within t1 duration with a confidence level of x%, within t2 duration (e.g., where t2 is longer than t1) with a confidence level of y% (e.g., y > x), etc.

[0108] The confidence levels indicated in the capability may be average and / or expected confidence level of predictions. When the WTRU makes a specific predication at a given time instance, the prediction confidence may be different (e.g., higher, or lower) from the one indicated in the capability.

[0109] The WTRU may indicate in the capability detailed information under which conditions its Al M L model (s) that has been trained on. This may include WTRU or network conditions (E.g., WTRU mobility conditions such as WTRU speed, WTRU location, cells, frequencies, time of day, network configurations and / or setting that are directly visible to the WTRU such as frequency and bandwidth, network configuration indexes, training data set ID that is known to both the WTRU and network, internal WTRU conditions such as processing power, battery level, memory, etc.))

[0110] The WTRU may indicate in the capability detailed information under which conditions its Al M L model (s) have been tested on. This may be the same information as the training conditions or different (e.g., a model that is trained under one condition may still perform well in another condition). In one variant of this embodiment, the WTRU may indicate different performance levels for the different conditions (e.g., RLF prediction can be more accurate at a certain WTRU mobility state as compared to another mobility state, etc.).

[0111] The WTRU may be configured to provide capability at a functionality level (e.g., WTRU not explicitly indicating the number / identity of the models it is using, but simply providing the overall capability of the oneor more models for RLF prediction) or it may be model level (e. g. , WTRU providing explicit information about each model it has for the RLF prediction and associated capability information for each model).

[0112] The capability information may be provided autonomously by the WTRU (e.g., upon connection setup / resume, upon handover, upon detecting that the WTRU has entered a new cell / region / RAT where the capability regarding beam prediction is different from previously reported capability, etc.) or based on an explicit request from the network.

[0113] If capability information is requested from the network, the request may be a generic request (in which case WTRU may provide it capabilities (e.g., all its capabilities)) or it may be a more granular request. For example, the WTRU may receive a request from the network it is supports RLF prediction at a certain frequency layer, and the WTRU may respond with indication that it doesn’t support that, and / or indication that it supports that or / and detailed information about the capability regarding prediction of RLF at that frequency layer (e.g., summarized information at functionality level, detailed information for each RLF prediction AIML model at that frequency layer, etc.).

[0114] The WTRU may be configured to detect radio link problem based on current and predicted measurements / events. In legacy communication systems (e.g., NR and / or LTE), the RRC may consider the serving cell as having a radio link problem if N310 consecutive OOS are detected from the PHY regarding that cell.

[0115] The WTRU may be configured to consider a radio link problem has been detected depending on the number of actual consecutive OOS currently detected and the number of consecutive OOSs that are predicted within. That is, the WTRU may be configured with one n310 value, as in legacy, and may consider both measured and predicted OOS equally. For example, if n310 was configured to be 10, the WTRU may consider a radio link problem is detected in each of the following cases: 10 consecutive OOS are actually detected; 5 consecutive OOS are detected and 5 consecutive OOS are predicted; and / or 1 OOS detected and 9 consecutive OOS are predicted.

[0116] The WTRU may be configured to use the same or different Qout thresholds for the determination of actual OOSs and predicted OOSs. For example, the Quot threshold to be used for prediction (e.g., QouLprediction) may be configured to be larger than the Qout to be used for actual OOS determination. In another example, the QouLprediction may be configured to be smaller than the Qout to be used for actual OOS determination.

[0117] The QouLprediction may be a scaled version of the Qout For example, WTRU may not be configured with 2 Qout values, but the legacy Qout and a scaling factor may be applied to determine the QouLprediction.

[0118] There may be multiple QouLprediction (or multiple scaling factors to apply on top of the legacy Qout value). The different values (or scaling factors) may be associated with one or more of a confidence level of prediction (e.g., applying factor 1 if confidence level is below a certain threshold, and / or applying factor 2 if confidence level is above a threshold), a time duration of the prediction (e.g., applying factor 1 if the OOS is being predicted at time instance t1 from now, and / or applying factor 2 if the OOS is being predicted at a time instance t2 from now, etc.), and / or applying different factors depending on the number of consecutive or total OOS that are being predicted, and the like.

[0119] The WTRU may be configured to consider the predicted OOS if (e.g., only if) a certain number of actual OOS (or a percentage of the configured n310) have been detected. For example, the WTRU may be configured to consider the predicted ones if (e.g., only if) the number of actual consecutive OOS is at least half of the configured n310. Thus, in the example above with n 310 equal to 10, the last case with 1 detected OOS and 9 consecutive OOS predicted may not be considered as radio link problem detection while the case with 5 detected ones and 5 predicted will be considered as a radio link problem detection.

[0120] The WTRU may further be configured to consider not to perform the OOS prediction (inference) if the required number or percentage of actual OOS are not detected. For example, if the predicted OOS are not taken into consideration in the radio link problem determination, the WTRU may save some processing power by not performing a continuous prediction of OOS.

[0121] The WTRU may be configured with a weighting factor to apply on the predicted OOS while determining the OOS count to compare with the configured n310 value. For example, the WTRU may be configured with a weighting factor of 0.3, and may determine the current counter value for the N310 as: N310 = [number of currently detected consecutive OOS] + (0.3)* [number of predicted consecutive OOS]

[0122] The WTRU may be configured with one or more n310 values associated with predicted OOS (and corresponding n310 values associated with actual OOS). For example, a WTRU may be configured with the following settings (e.g., all the following settings): [n310_actual - 10, n310_predicted =0], [n310_actual = 9, n310_predicted =2], [n310_actual = 8, n310_predicted =3], [n310_actual = 7, n310_predicted =6]; and / or [n310_actual - 6, n310_predicted =8], etc.

[0123] The WTRU may consider a radio link problem has been detected if it detects 10 consecutive OOS or if it detects 9 consecutive OOS and predicts 2 consecutive OOS, or if it detects 8 consecutive OOS and predicts 3 consecutive OOS, etc.

[0124] The configuration may be provided as a formula and / or parameter instead of sets of different values as shown above. For example, the WTRU may consider a radio link problem has been detected if [Number of predicted consecutive OOS] is larger than and / or equal to w* (N310 - [Current number of detected consecutive OOSs]). W may be greater than 1.

[0125] For example, if current N310 is 8, n310 is 10, and w is set to 2, the WTRU may consider radio link failure problem has been detected if it predicts at least 4 consecutive OOS (e.g. , 2*(10-8)).

[0126] The detected OOS may not necessarily have to be consecutive. For example, the WTRU may be configured to account for non consecutive OOS in the calculation of the N310 value to compare with the configured n310, by considering the total number of OOS, consecutive or not, that are predicted to happen within a given configured time duration window.

[0127] A combination of consideration of consecutive as well as total predicted OOS within a given time duration may be possible. For example, the WTRU configured to consider radio link problem may be detected if n1 consecutive OOS have already occurred, n2 consecutive OOS are predicted, and at least n3 total OOS are predicted within the next x seconds, and the like.

[0128] The WTRU, upon detecting a radio link problem according to any of the embodiments herein, may be configured to start the recovery monitoring (e.g., start T310 timer and monitor the detected and predicted ISs, etc.).

[0129] The WTRU may be configured to immediately trigger the recovery procedure (according to legacy recovery procedure or any of the embodiments described below for recovery), without starting the T310 timer and waiting for recovery, depending on one or more of the conditions described herein. For example, the WTRU may be configured to immediately trigger the recovery procedure if the number of predicted consecutive OOSs at the time of radio link problem detection according to any of the embodiments above is greater than a certain configured threshold. The WTRU may be configured to immediately trigger the recovery procedure if the number of total predicted OOSs for a certain time duration (e.g., the T301 timer value or a value smaller than that) after the radio link problem detection according to any of the embodiments above is greater than a certain configured threshold.

[0130] In principle, the above embodiment may enable the WTRU to perform expediated recovery (e.g., not to start the T310 timer and wait for its expiry before performing recovery), if the prediction is indicating that the likelihood of getting N311 consecutive IS indications is low.

[0131] The WTRU may be configured to consider different T310 values based on current and predicted measurements and / or events. Once a radio link problem is detected (either based on legacy mechanisms or according to any of the embodiments proposed above), the WTRU may be configured to start the recovery timer T310, the value of which is dependent on current and predicted measurements and / or events.

[0132] The WTRU may be configured with different t310 values, each associated with the number of actual and predicted OOS that triggered the starting of the T310. For example, the WTRU may be configured with t310 to be Value 1, if T310 was started due to actual OOS (e.g., due to actual OOS only); and / or Value 2, if T310 was started due to a combination of actual OOS and detected OOS. Value 2 may be absolute value, or a delta value (positive or negative) from Value 1 (or Value 2 = w* Value 1 , where w may be smaller or greater than 1).

[0133] There may be different lists and / or sets of Value 2, each depending on several factors such as the number of predicted consecutive OOS; the number of predicted total OOS within a given duration; the percentage of the predicted vs the actual OOS; and / or the confidence level of the predictions. For example, assume for a particular case where the condition for detecting a radio link problem may be fulfilled upon predicting n1 consecutive OOS (according to any of the embodiments above). If the WTRU has predicted n2 consecutive OOS (where n2 is greater than n1), it may be configured to use a shorter t310 value (e.g., prediction indicates that the likelihood of recovery may be less as more than the required OOS indications to start the T310 timer have been predicted), as compared to the case where n1 consecutive OOS were predicted (and the shorter value for t310 may be just a scaled factor of the t310 value associated with n1, e.g., (n1 / n2)*t31 Ox, where t31 Ox may be the value associated with n1 predicted consecutive OOS, which could itself be a scaled version of the t310 that is associated with actual OOS (e.g., associated with actual OOS only), e.g., the legacy t310 value).

[0134] The described embodiments may be changing the WTRU behavior in one or more of the following scenarios described herein. For example, if the radio link problem is detected based on actual detected OOS, the WTRU may use legacy t310 value. If the radio link problem is detected based on actual detected and predicted OOS, the WTRU may use different t310 values (or scale the legacy t310 value). These values to use instead of t310 values may be smaller than the legacy t310. For example, if n310 was 10,and WTRU has detected 7 consecutive OOS and predicted 3 consecutive OOS, the t310 value used in this case may be smaller than the legacy t310 value, since the prediction is not likely to be a 100% accurate and as such the radio link problem detection may have occurred prematurely. These values to use instead of t310 values may be greater than the legacy t310. For example, if n310 was 10, WTRU has detected 7 consecutive OOS and predicted 8 consecutive OOS, the t310 value used in this case may be greater than the legacy t310 value, since the prediction is indicating the radio problem is going to persist for a while.

[0135] The WTRU may be configured to detect radio link recovery or failure based on current and predicted measurements and / or events. The WTRU may determine the N311 counter value to use for radio link recovery or failure determination depending on the how the predicted OOSs were considered in the detection of a radio link problem, according to any of the embodiments above.

[0136] The WTRU may be configured with one n311 value (e.g., n311_baseline), as in legacy, and a scaling factor depending on how the predicted OOSs were used in the radio link problem determination (according to any of the embodiments for determining N310 described above). For example, assume n310 was configured to be n1, and radio link problem was detected because the WTRU has detected n1_a consecutive OOSs and it has predicted n1_b consecutive OOSs (according to any of the embodiments above), the WTRU may be configured to use an n311 value that is equal to n311.legacy * (scaling factor), where scaling factor can be configured to be a function of n1_b / n1_a or n1_b / (n1), etc., e.g., on the relative contribution of the predicted OOSs as compared to the detected OOSs.

[0137] Instead of or in addition to the scaling factors, the WTRU may be provided with multiple n311 values that correspond to the relative level of contribution of the predicted OOSs as compared to the actual detected OOSs.

[0138] Each of the described embodiments for determining the N310 counter value based on the actual and predicted OOSs may be applied also for determining the N311 counter value based on the actual and predicted ISs.

[0139] The WTRU may be configured to consider that the radio link has been recovered depending on the number of actual consecutive ISs currently detected after the start of T310 and the number of consecutive ISs that are predicted. That is, the WTRU may be configured with one n311 value, as in legacy, but may consider both measured and predicted ISs equally. For example, if n311 was configured to be 10, the WTRU may consider a radio link has recovered in each of the following cases: 10 consecutive ISs are actually detected; 5 consecutive ISs are detected and 5 consecutive ISs are predicted; and / or 1 1S is detected and 9 consecutive ISs are predicted.

[0140] The WTRU may be configured with different Qin threshold (e.g., Qin_prediction) to be used for the prediction of an IS. For example, the Qi n_prediction may be configured to be larger than the Qin to be used for actual IS determination. In another example, the Qin_prediction may be configured to be smaller than the Qin to be used for actual IS determination.

[0141] The Qin_prediction may be a scaled version of the Qin. For example, the WTRU may not be configured with 2 Qin values, but the legacy Qin and a scaling factor may be applied to determine the Qin_prediction.

[0142] There may be multiple Qin_prediction (or multiple scaling factors to apply on top of the legacy Qin value). The different values (or scaling factors) may be associated with a confidence level of prediction (e.g., applying factorl if confidence level is below a certain threshold, applying factor 2 if confidence level is above a threshold). The different values (or scaling factors) may be associated with a time duration of the prediction (e.g., applying factor 1 if the IS is being predicted at time instance t1 from now, applying factor 2 if the IS is being predicted at a time instance t2 from now, etc.). The different values (or scaling factors) may be associated with applying different factors depending on the number of consecutive or total ISs that are being predicted.

[0143] The WTRU may be configured with multiple Qin_prediction thresholds (or scaling factors) that is associated with the multiple QouLprediction thresholds. That is, if the WTRU started the T310 timer based on a prediction of a radio link problem that used Qout_prediction_x, the WTRU may use a Qi n_prediction_y that is configured to be associated with the Qout_prediction_x.

[0144] The WTRU may be configured to consider the predicted ISs if (e.g., only if) a certain number of actual ISs (or a percentage of the configured n311) have been detected. For example, the WTRU may be configured to consider the predicted ones if (e.g., only if) the number of actual consecutive ISs is at least half of the configured n311. Thus, in the example above with n311 equal to 10, the last case with 1 detected IS and 9 consecutive ISs predicted may not be considered as the detection of radio link recovery, while the case with 5 detected ones and 5 predicted may be considered as a radio link recovery.

[0145] The WTRU may further be configured to consider not to perform the IS prediction (inference) if the required number or percentage of actual ISs are detected. For example, if the predicted ISs are not going to be taken into consideration in the radio link recovery determination, the WTRU may save some processing power by not performing a continuous prediction of ISs.

[0146] The WTRU may be configured with a weighting factor to apply on the predicted IS while determining the IS count to compare with the configured n310 value. For example, the WTRU may be configured with a weighting factor of 0.3, and may determine the current counter value for the N311 as: N311 = [number of currently detected consecutive ISs] + (0.3)* [number of predicted consecutive ISs]

[0147] The WTRU may be configured with one ore more n311 values associated with predicted ISs (and corresponding n311 values associated with actual ISs). For example, a WTRU may be configured with the following conditions (e.g., all the following conditions): [n311_actual - 10, n311_predicted =0], [n311_actual = 9, n311_predicted =2], [n311_actual = 8, n311_predicted =3], [n311_actual = 7, n311_predicted =6]; and / or [n311_actual = 6, n311_predicted =8], and the like.

[0148] The WTRU may consider that the radio link has been recovered if it detects 10 consecutive ISs or if it detects 9 consecutive ISs and predicts 2 consecutive ISs, or if it detects 8 consecutive ISs and predicts 3 consecutive ISs, and the like.

[0149] The configuration may be provided as a formula and / or parameter instead of sets of different values as shown above. For example, the WTRU may consider a radio link problem has been recovered if [Number of predicted consecutive ISs] >= w* (n311 - [Current number of detected consecutive ISs ]). W may be greater than 1.

[0150] For example, if current N311 is 8, n311 is 10, and w is set to 2, the WTRU may consider radio link has been recovered if it predicts at least 4 consecutive ISs (e.g., 2*(10-8)).

[0151] The detected ISs may not necessarily have to be consecutive. For example, the WTRU may be configured to account for non consecutive ISs in the calculation of the N311 value to compare with the configured n311, by considering the total number of ISs, consecutive or not, that are predicted to happen within a given configured time duration window.

[0152] A combination of consideration of consecutive as well as total predicted ISs within a given time duration may also be possible. For example, the WTRU may be configured to consider radio link is recovered if n1 consecutive ISs have already occurred, n2 consecutive ISs are predicted, and at least n3 total ISs are predicted within the next x seconds, and the like.

[0153] The WTRU, upon determining a radio link has not recovered according to any of the embodiments above before the T310 expires, may be configured to initiate a radio link failure recovery procedure.

[0154] The WTRU may be configured to perform recovery based on predicted RLF. The WTRU may be configured with an LTM / CHO configuration. The LTM / CHO may be executed if (e.g., only if) the RLF was a predicted RLF according to any of the embodiments above. For example, the WTRU may be configuredwith the following CHO / LTM configurations: Configuration #1 (including target A, A3 threshold.!, RRC reconfiguration_1), Configuration #2 (including target B, A3 threshold_2, RRC reconfiguration_2), and / or Configuration #3 (including target C, A3 thresholds, RRC reconfiguration^).

[0155] The WTRU may be further configured such that targets A and B are to be considered for RLF recovery if RLF is detected according to legacy counters and / or timers without considering predicted IS / OS, and target C is to be considered if the RLF was a predicted RLF. Upon detecting actual RLF and performing cell selection, if the selected cell is A or B, the WTRU may execute the CHO / LTM associated with the cell. Otherwise, if the selected cell is C or another cell, the WTRU may proceed with legacy reestablishment. One the other hand, if the RLF was a predicted RLF, and the cell that was selected after the RLF was cell C, the WTRU may execute the CHO / LTM towards cell C. Otherwise (e.g., the selected cell was cell A, B or another cell), the WTRU may proceed with the re-establishment procedure.

[0156] The association between which target cells are to be considered for legacy RLF vs which cells to be considered for predicted RLF may be configured in an lE / flag within each configuration, or a separate mapping configuration / table may be provided the association. A certain target may be associated to be considered for both actual RLF and predicted RLF recovery.

[0157] The WTRU may be configured to perform a recovery towards a given CHO / LTM target cell after a predicted RLF if the target cell fulfills a certain radio conditions (e.g., target cell has radio signal level above a certain configured threshold, target cell has radio signal level not lower than a certain configured threshold than the best / strongest cell, and the like), even if the target cell is not the best cell at that time.For example, if the WTRU performs legacy cell selection in preparation to the re-establishment, it may have selected a different cell than the concerned target cell.

[0158] The WTRU may be configured with two thresholds: one threshold may be used for recovery due to actual RLF while another threshold may be used during recovery due to predicted RLF (e.g., two separate thresholds, one threshold and a scaling factor to determine the other threshold, etc.).

[0159] If the WTRU is configured to perform recovery even without starting T310 (e.g., if the prediction is indicating the likelihood of getting N311 within a time duration of T310 is very low), the decision to do so may be dependent on the availability of a suitable CHO / LTM candidate cell. In one example, the WTRU may be configured to perform the direct recovery without starting T310 if (e.g., only if) a suitable CHO / LTM candidate is available according to legacy constraints, for example, the best cell at that time is a CHO / LTM candidate. In another example, the WTRU may be configured to perform the direct recovery without starting T310 even if the CHO / LTM candidate is the not the best cell, but the signal level of the candidate fulfills acertain absolute / relative threshold (e. g . , greater than a first threshold, not lower than the best cell by more than a second threshold, etc.)

[0160] In the embodiments described herein regarding recovery due to predicted RLF, the WTRU may be configured to include an indication that the recovery was performed due to predicted RLF instead of actual RLF (e.g. in a flag / IE that is included in the RRC complete message associated with the executed CHO / LTM, in a re-establishment cause value if re-establishment was triggered due to the unavailability / unsuitability of a CHO / LTM candidate for recovery, etc.)

[0161] The WTRU may be configured to log measured IS / OOS information. In legacy operation, the WTRU may log RLF related information (e.g., only log RLF related information) after RLF occurs (e.g., N310 consecutive OOS indications received from PHY and T310 expired before receiving N311 consecutive IS indication from PHY).

[0162] The WTRU may be configured to log information prior to RLF detection depending on the number of consecutive OOSs detected, even if the number is lower than configured N310 to trigger the start of T310. For example, the WTRU may be configured to perform a logging of the occurrences of one or more of but not be limited to the following scenarios being described. For example, while T310 is not running, N1 consecutive OOSs may be detected (where N1 is smaller than N310) followed by an IS indication, and N2 total OOSs may be detected within a given configured time duration. While T310 is running, N3 consecutive OOSs may be detected, and N4 total OOSs may be detected. And / or whether T310 is running or not, N5 total OOSs may be detected within a given configured time duration, N6 total ISs may be detected within a given configured time duration, and when the ratio of total OOSs to total ISs within a given configured time duration becomes above or below a certain configured threshold.

[0163] The WTRU may be configured to include information such as time of day, WTRU location (e.g., cell, GNSS co-ordinates, if available, etc.) with each log entry. The WTRU may be configured statical / summarized information instead of (or in addition to) the raw information (e.g., average number of IS indications during a given time duration, average number of OOS indications during a given time duration, the relative number / ratio / distribution of ISs / OOSs within a given duration or during a stay at a given cell, the distribution information of consecutive ISs and OOS, etc.).

[0164] Such logged information may be very useful in training AIML models for predicting RLFs (e.g., data used by the WTRU itself to train a model, logged data collected from several WTRUs used by the network or external entity such as an over-the-top (OTT) server used to train a model, etc.). The WTRU may beconfigured to send an indication that such logged information is available. The WTRU may be configured to send the logged information upon explicit request from the network.

[0165] The WTRU may be configured to send the logged information upon the fulfillment of certain conditions. For example, the conditions may include when a certain amount of measurement is logged is above a certain threshold, e.g., actual data size or number of logged entries, depending on the content of the logged information such as the absolute / relative distribution of the OOSs and ISs, etc.

[0166] The WTRU may be configured to send pre-RLF indication. The WTRU may be configured to perform RLF prediction and upon predicting an RLF (e.g., according to any of the embodiments above). Instead of starting an RLF recovery procedure, it may be configured to send an indication (e.g., pre-RLF indication) to the network (e.g. indicating to the network that an RLF is anticipated to happen).

[0167] The WTRU may be configured to determine whether to send a pre-RLF indication or perform RLF recovery, depending on the confidence level of the prediction and / or the time duration when the RLF is predicted to happen. For example, the WTRU may be configured to send the pre-RLF indication if the time duration window / instance the RLF is expected to happen is longer / later than a certain configured duration or delta time from now, but trigger recovery otherwise. In another example, the WTRU may be configured to send the pre-RLF indication if the confidence level of the prediction is below a certain confidence threshold, but perform the recovery if the confidence level is greater than or above that threshold.

[0168] The WTRU may be configured to include the time duration / window where RLF is expected to happen. The WTRU may be configured to include the confidence level of the pre-RLF indication. The WTRU may be configured with and / or to include multiple time duration and confidence level indications (e.g., RLF expected to happen with a confidence level 1 within time duration 1, RLF expected to happen with a confidence level 2 within time duration 2, etc.).

[0169] The WTRU may be configured to include cell / beam level measurements of neighbor cells in the pre-RLF indication (e.g., current cell / beam level measurements, predicted cell / beam level measurements at the time when RLF is expected to happen, etc.).

[0170] The WTRU may be configured to send the pre-RLF indication if (e.g., only if) the confidence level is above a certain threshold and / or if the RLF is expected to happen in less than a given time duration. The pre-RLF indication may be sent via an RRC message, a MAC control element (MAC CE), unified configuration interface (UCI), etc.

[0171] The WTRU may be configured to send the pre-RLF indication via a cell different from the PCell. For example, if the WTRU is configured with carrier aggregation, it may send the pre-RLF indicationregarding the PCell via an SCell. In another example, if the WTRU is configured with DC, it may send the pre-RLF indication regarding the PCell via the PSCell (e.g. , using SRB3 that is associated with the PSCell instead of SRB1 / SRB2 associated with the PCell). Sending the pre-RLF indication to / via a cell or node other than the PCell (or the master node, in case the indication was sent to the PSCell) may increase the likelihood of the pre-RLF indication to be received (e.g., preventing the case where the pre-RLF indication can not be sent due to the pre-RLF indications being very accurate and UE actually ends up detecting the RLF soon).

[0172] The WTRU may be configured to log the information instead of sending it in a pre-RLF indication (e.g. along with other information like time of day, current WTRU location, etc.), and report it later (e.g., WTRU indicating it has such information, network requesting it, etc., like the way legacy RLF report availability is indicated by the WTRU in RRC complete messages and network explicitly requesting it via WTRU information request message, etc.).

[0173] The WTRU may be configured to send pre-RLF indication based on explicit network request. For example, the WTRU may receive a message from the network if an RLF is expected to happen within a given duration, and WTRU may respond with the information based on its current prediction (e.g., RLF not expected to happen, RLF expected to happen with a certain confidence level, RLF expected to happen at a time duration later than the one indicated in the received request message, etc.).

[0174] After the sending of the pre-RLF indication, the WTRU may receive an indication / message from the network instructing it to perform certain mobility decisions (e.g., HO command, indication to execute a CHO / LTM configuration available at the WTRU, etc.), thereby enabling quicker recovery than the legacy way of waiting for T310 expiry and then do re-establishment or recovery via LTM / CHO after that.

[0175] The WTRU may be configured to consider confidence of predictions. The WTRU may be configured to consider the confidence of the predictions when detecting the radio link problem has been recovered and detecting radio link failure.

[0176] The WTRU may be configured with different parameters, according to any of the embodiments above, that also considers the prediction confidence. For example, the WTRU may be configured to consider predicted ISs / OOSs, if (e.g., only if) the confidence level of the IS / OOS prediction is above a certain confidence threshold. In another example, different / several parameter configurations may be provided, according to any of the embodiments above, where the different parameter val ues / configurations are associated with different level of confidence (this can be explicit values or scaling factors from a baseline confidence level). For example, for the embodiment above where a weighting factor was appliedon considering the predicted OOS, the WTRU may be provided with a set of weighting factors, e.g., [w1, w2, ..., wn], each corresponding to different confidence levels or range of confidence level of the OOS prediction.

[0177] The confidence level may vary depending on the number of consecutive OOS / IS being predicted and / or the time duration in which the OOS / IS are being predicted (e.g., if the total number of OOSs / ISs is also being considered instead or / and in addition to the number of consecutive OOSs / ISs). For example, at time TO, the WTRU may predict 2 consecutive OOSs with confidence level 1, 3 consecutive OOSs with confidence level 2, and so on. In another example, the WTRU may predict that 10 OOSs will occur within duration 1 with a confidence level 1, within duration 2 with a confidence level 2, etc. In another example, the WTRU may predict that 10 OOSs will occur within duration 1 with confidence level 1 , 5 OOSs will occur within duration 1 with confidence level 2, etc. Described herein are embodiments for detecting RLF and performing recovery that utilizes the combination of actual measured In Sync (IS) and Out of Sync (OOS) indications as well as predicted IS / OOS indications. The WTRU may send capability information related to RLF predictions (e.g., based on AIML model). Capability may include details about the prediction (e.g., type of prediction, e.g., whether actual prediction of radio signal levels, directly predicting of IS / OOS, directly predicting RLF, etc., time duration of predictions, confidence level of prediction, area / cells / frequencies where the predictions can be made, etc.).

[0178] The WTRU may receive a configuration of RLF detection parameters (e.g., n310 values or scaling factors, n311 values or scaling factors, T310 values or scaling factors, etc.) that are dependent on one or more of the type of OOS and / or IS measurement (e.g., actually measured of predicted), the number of actually measured OOS and / or IS measurements, and / or the number and / or confidence level of OOS and / or IS predictions (e.g., consecutive IS / OOS, total number of IS / OOS within a configured duration, etc.).

[0179] The WTRU may receive a configuration regarding the RLF recovery / reporting. The configuration information may contain additional RLF related logging configuration (e.g., log information whenever OOS (predicted and / or measured) is more than a certain value even if it doesn’t reach the N310 value, log information whenever N310 OOS has been reached even if T310 gets cancelled due to N311 IS, etc.). The configuration information may contain pre-RLF indication configuration (e.g., send a pre-RLF indication upon RLF prediction instead of performing recovery). The configuration information may contain LTM / CHO configurations for recovery based on RLF type (predicted RLF or actual RLF) (e.g., different target cell thresholds for recovery based on actual RLF or predicted RLF).

[0180] The WTRU may perform RLF detection / prediction based on actual measurements and / or predicted measurements according to the received configuration.

[0181] Upon predicting an RLF, the WTRU may send a pre-RLF indication. The WTRU may perform recovery (re-establishment, execute LTM / CHO, etc.). The WTRU may send indication to the network (e.g., during recovery, after recovery, etc.,), indicating that recovery was done due to predicted RLF (e.g., reestablishment cause value, additional flag in reconfiguration complete message if LTM / CHO is executed, etc.). And / or the WTRU may send indication that additional RLF logging is available.

[0182] The above-mentioned embodiment may enable pre-emptive recovery from RLF based on predicted radio conditions of serving and neighbor cells.

Claims

CLAIMS:

1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, wherein the processor and the memory are configured to: send capability information related to radio link failure (RLF) predictions; receive a first configuration of RLF detection parameters, wherein the first configuration of the RLF detection parameters is based on one or more of a type of an out-of-synchronization (OOS) or insynchronization (IS) measurement, or a number of measured OOS or IS measurements; receive a second configuration, wherein the second configuration comprises an action to be performed in response to the RLF prediction, wherein the action comprises an RLF recovery or an RLF reporting; perform the RLF prediction based on the first configuration, OOS or IS measurements, and predicted OOS or IS measurements over a period of time; and upon determining an RLF has been predicted within the period of time, perform the RLF recovery or the RLF reporting based on the second configuration and send an indication to a network.

2. The WTRU of claim 1 , wherein the RLF detection parameters comprise one or more of n310 values or scaling factors associated with the measured or predicted OOSs, n311 values or scaling factors associated with the measured or predicted ISs, or t310 values or scaling factors, wherein the t310 values or scaling factors are associated with a time duration for the WTRU to wait for the measured or predicted ISs, wherein the time duration is after the WTRU has measured or predicted the measured or predicted OOSs and before the WTRU determines the RLF has been predicted.

3. The WTRU of claim 1 , wherein the first configuration of the RLF detection parameters is further based on a number or a confidence level of the predicted OOS or IS measurements.

4. The WTRU of claim 1 , wherein the second configuration comprises an additional RLF-related logging configuration or a pre-RLF indication configuration.

5. The WTRU of claim 1, wherein the second configuration comprises a L1 / L2 Triggered Mobility (LTM) configuration or a conditional handover (CHO) configuration for the RLF recovery.

6. The WTRU of claim 1 , wherein the period of time is determined based on a preconfigured timer or an updated timer based on the measured OOS or IS measurements.

7. The WTRU of claim 1 , wherein the indication is information indicating that the RLF recovery or the RLF reporting is being performed due to the RLF prediction.

8. The WTRU of claim 1 , wherein the processor and memory are further configured to perform the RLF recovery or the RLF reporting prior to identification of a predefined number of consecutive OOS measurements configured for determining an RLF.

9. The WTRU of claim 1 , wherein the processor and memory are further configured to perform the RLF recovery or the RLF reporting based on a prediction that a predefined number of consecutive IS measurements will not be received within a predefined period of time.

10. The WTRU of claim 1 , wherein the processor and memory are further configured to, in addition to or instead of performing the RLF recovery upon the RLF prediction: send a pre-RLF indication, send a first indication indicating the RLF recovery has been finished, or send a second indication indicating additional RLF logging is available.

11. A method comprising: sending capability information related to radio link failure (RLF) predictions; receiving a first configuration of RLF detection parameters, wherein the first configuration of the RLF detection parameters is based on one or more of a type of an out-of-synchronization (OOS) or insynchronization (IS) measurement, or a number of measured OOS or IS measurements; receiving a second configuration, wherein the second configuration comprises an action to be performed in response to the RLF prediction, wherein the action comprises an RLF recovery or an RLF reporting; performing the RLF prediction based on the first configuration, OOS or IS measurements, and predicted OOS or IS measurements over a period of time; and upon determining an RLF has been predicted within the period of time, performing the RLF recovery or the RLF reporting based on the second configuration and sending an indication to a network.

12. The method of claim 11 , wherein the RLF detection parameters comprise one or more of n 310 values or scaling factors associated with the measured or predicted OOSs, n311 values or scaling factors associated with the measured or predicted ISs, or t310 values or scaling factors, wherein the t310 values or scaling factors are associated with a time duration for the WTRU to wait for the measured or predicted ISs, wherein the time duration is after the WTRU has measured or predicted the measured or predicted OOSs and before the WTRU determines the RLF has been predicted.

13. The method of claim 11 , wherein the first configuration of the RLF detection parameters is further based on a number or a confidence level of the predicted OOS or IS measurements.

14. The method of claim 11, wherein the second configuration comprises an additional RLF-related logging configuration, or a pre-RLF indication configuration.

15. The method of claim 11, wherein the second configuration comprises a L1 / L2 Triggered Mobility (LTM) configuration or a conditional handover (CHO) configuration for the RLF recovery.

16. The method of claim 11, wherein the period of time is determined based on a preconfigured timer or an updated timer based on the measured OOS or IS measurements.

17. The method of claim 11, wherein the indication is information indicating that the RLF recovery or the RLF reporting is being performed due to the RLF prediction.

18. The method of claim 11 , further comprising: performing the RLF recovery or the RLF reporting prior to identification of a predefined number of consecutive OOS measurements configured for determining an RLF.

19. The method of claim 11 , further comprising: performing the RLF recovery or the RLF reporting based on a prediction that a predefined number of consecutive IS measurements will not be received within a predefined period of time.

20. The method of claim 11, in addition to or instead of performing the RLF recovery upon the RLF prediction, further comprising: sending a pre-RLF indication, sending a first indication indicating the RLF recovery has been finished, or sending a second indication indicating additional RLF logging is available.

Images