Methods to support connectivity change reporting and recovery

Abstract

Methods, apparatuses, and systems are disclosed. In one example, a method performed by a WTRU may comprise receiving, from a first cell, configuration information associated with connectivity change prediction. The configuration information may indicate an artificial-intelligence or machine-learning (AI / ML) model to be used at the WTRU for connectivity change prediction. The method may further comprise determining, via the AI / ML model and based on one or more measurements, that a connectivity change event is predicted to occur within a time window. The method may further comprise sending a report via resources associated with a first cell. The report may comprise time-related information indicating the time window and / or information indicating at least one candidate cell for potential connection recovery.

Description

METHODS TO SUPPORT CONNECTIVITY CHANGE REPORTING AND RECOVERYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. provisional patent application no. 63 / 700,787, filed September 30, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] In existing layer-3 (L3) handover In existing layer-3 (L3) handover mechanisms, handover is triggered and executed based on reported historical measurement results and / or measurement events (e.g., this is a reactive scheme by its nature). It may work well among macro cells when wireless transmit / receive unit (WTRU) (e.g., user equipment (UE)) mobility is low for existing services, but it may be problematic when either a WTRU’s mobility is high or among micro cells of high density, or both for existing services or future services (e.g., extended reality (XR)), where such a reactive scheme may result in more unintended events (e.g., handover failure, radio link failure, Ping-Pong phenomenon, throughput loss, too early / late handover, etc.). To increase handover robustness, conditional handover is introduced in 3rd Generation Partnership Project (3GPP) Release 16 (Rel-16). And to reduce interruption time of frequent handover among small cells, Last Time Measurement (LTM) Handover (HO) is introduced in 3GPP Release 18 (Rel-18). Conditional handover and LTM-HO (L1 / L2 triggered mobility - handover) are not sufficient because they are reactive schemes by design.SUMMARY

[0003] Methods and apparatuses for operation by a wireless transmit / receive unit (WTRU) are provided.

[0004] In an example, a wireless transmit / receive unit (WTRU) may comprise a processor configured to receive, from a first cell, configuration information associated with connectivity change prediction. The configuration information may indicate an artificial-intelligence or machine-learning (AI / ML) model to be used at the WTRU for connectivity change prediction.

[0005] The processor may be further configured to determine, via the AI / ML model and based on one or more measurements, that a connectivity change event is predicted to occur within a time window; and send a report via resources associated with a first cell, the report comprising at least one of time-related information indicating the time window or information indicating at least one candidate cell for potential connection recovery.

[0006] The processor may be further configured to receive a downlink control channel transmission via resources associated with the at least one candidate cell, receive a reconfiguration message from the at least one candidate cell, and recover a connection based on the reconfiguration message.

[0007] The report may comprise the time-related information. The time-related information may comprise an indication of a time when the connectivity change event is predicted to occur. The time window may comprises the time. The time-related information may comprise an indication of a start time and an indication of an end time. The start time and the end time may indicate the time window.

[0008] The processor may be further configured to receive a response message from the first cell. The response message may comprise a recovery configuration for the at least one candidate cell.

[0009] The connectivity change event may comprises a radio link failure (RLF), a beam failure detection (BFD), a measurement event, a mobility event, excess transmissions of a radio link control (RLC) message, excess transmissions of a hybrid automatic repeat request (HARQ), excess transmissions of a random channel access (RACH) preamble, and / or a layer-2 (L2) failure.

[0010] The configuration information associated with connectivity change prediction may indicate one or more prediction evaluation criteria. The processor may be further configured to evaluate whether the one or more prediction evaluation criteria are satisfied based on the one or more measurements and the determination that the connectivity change event is predicted to occur. The processor may be further configured to send the report in response to a determination that the one or more prediction evaluation criteria are satisfied.

[0011] The one or more prediction evaluation criteria may comprise a criterion that is satisfied when a difference between an actual measurement and a predicted measurement does not exceed a threshold difference. The one or more prediction evaluation criteria may comprise a criterion that is satisfied when a number of predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of predicted measurements. The one or more prediction evaluation criteria may comprise a criterion that is satisfied when a number of consecutive predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of consecutive predicted measurements. The one or more prediction evaluation criteria may comprise a criterion that is satisfied when a percentage of predicted measurements that satisfyat least one other criterion of the prediction evaluation criteria is not less than a threshold percentage of predicted measurements.

[0012] The configuration information associated with connectivity change prediction may indicate one or more triggering conditions. The processor may be further configured to evaluate whether the one or more triggering conditions are satisfied and send the report in response to a determination that the one or more triggering conditions are satisfied.

[0013] The one or more triggering conditions may comprise a condition that is satisfied when a request for a connectivity change report is received. The one or more triggering conditions may comprise a condition that is satisfied when one or more connectivity change events are detected. The one or more triggering conditions may comprise a condition that is satisfied when one or more connectivity change events of a specific type are detected. The one or more triggering conditions may comprise a condition that is satisfied when a mobility event is detected. The one or more triggering conditions may comprise a condition that is satisfied when a connection to a recovery cell is established. The one or more triggering conditions may comprise a condition that is satisfied when a candidate cell is added to a set of candidate cells for potential connection recovery. The one or more triggering conditions may comprise a condition that is satisfied when a candidate cell is removed from a set of candidate cells for potential connection recovery. The one or more triggering conditions may comprise a condition that is satisfied when a prioritization for a candidate cell is changed. The one or more triggering conditions may comprise a condition that is satisfied when a determined confidence level associated with connectivity change prediction is not less than a threshold confidence level. The one or more triggering conditions may comprise a condition that is satisfied when a negative acknowledgment is received from a network.

[0014] The at least one candidate cell may comprises a plurality of candidate cells. The processor may be further configured to rank candidate cells in the plurality of candidate cells based on one or more signal quality values associated with the plurality of candidate cells, identify a highest-ranked candidate cell of the plurality of candidate cells, and / or synchronize and / or decode at least one downlink control channel using resources associated with the highest-ranked candidate cell.

[0015] The plurality of candidate cells may comprise one or more candidate cells that support a connection recovery procedure associated with the configuration information and one or more candidate cells that do not support the connection recovery procedure. The processor may be further configured to prioritize the one or more candidate cells that support the connectionrecovery procedure above the one or more candidate cells that do not support the connection recovery procedure.

[0016] The configuration information associated with connectivity change prediction may indicate a condition for including a cell in the report. The processor may be further configured to evaluate whether the condition is satisfied for the at least one candidate cell; and in response to a determination that the condition is satisfied for the at least one candidate cell, include the information indicating the at least one candidate cell in the report.

[0017] The condition for including a cell in the report may be satisfied when on one or more signal quality values are not less than a threshold signal quality value.

[0018] The processor may be further configured to, prior to reception of the configuration information, send a message indicating at least one capability of the WTRU. The at least one capability may be associated with connectivity change prediction, connectivity change detection, connectivity change reporting, and / or a connection recovery procedure associated with the configuration information.

[0019] The at least one capability may be based on a speed of the WTRU, an amount of remaining power for the WTRU, a location of the WTRU, a use of a type of service, and / or one or more channel quality indicators (CQIs).

[0020] The processor may be further configured to, prior to reception of the configuration information, receive, from the first cell, a message indicating at least one capability of a network associated with the first cell. The at least one capability may be associated with connectivity change reporting and / or a connection recovery procedure associated with the configuration information.

[0021] The message indicating the at least one capability of the network associated with the first cell may comprise a list of cells having the at least one capability within the network. The list of cells may include the first cell and the at least one candidate cell.

[0022] The processor may be further configured to, prior to the report, determine that a prohibit timer associated with the report is running and refrain from sending the report until the prohibit timer has expired.

[0023] The processor may be further configured to start a timer in response to the report being sent and monitor for the connectivity change event until the timer expires.

[0024] The processor may be further configured to, prior to recovery of the connection, evaluate whether one or more conditions for initiating connection recovery are satisfied and, in response to a determination that the one or more conditions for initiating connection recovery are satisfied, initiate a connection recovery procedure associated with the configuration information.

[0025] The processor may be further configured to start a timer upon initiation of the connection recovery procedure and recover the connection prior to expiration of the timer.

[0026] The one or more conditions for initiating connection recovery may comprise a condition that is satisfied by the determination that the connectivity change event is predicted. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied by detection of the connectivity change event. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied when the time window commences. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied by reception of an indication from a network associated with the first cell acknowledging reception of the report at the WTRU. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied by reception of an indication from a network associated with the first cell that the at least one candidate cell is suitable for recovery. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied when the connection is lost. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied when a measured signal quality value is less than a threshold signal quality value. The one or more conditions for initiating connection recovery may comprise a condition that is satisfied by reception of a recovery configuration for the at least one candidate cell at the WTRU.

[0027] The processor may be further configured to evaluate whether at least one selection condition is satisfied for the at least one candidate cell and, in response to a determination that the at least one selection condition is satisfied for the at least one candidate cell, select the at least one candidate cell for recovery of the connection.

[0028] The at least one selection condition may comprise a condition that is satisfied when the WTRU receives an acknowledgement that the at least one candidate cell is a valid recovery cell. The at least one selection condition may comprise a condition that is satisfied when one or more signal quality measurements associated with the at least one candidate cell are not less than a threshold signal quality measurement. The at least one selection condition may comprise a condition that is satisfied when the WTRU receives an indication that the at least one candidate cell supports a connection recovery procedure associated with the configuration information.

[0029] Mechanisms to support connectivity change reporting and / or recovery may be based on artificial intelligence (Al) and / or machine learning (ML). Mechanisms based on AI / ML algorithms may have the potential to enable proactive schemes. Mechanisms for connectivity change reporting may include connectivity reports. A connectivity report may include an indication of a predicted / detected change in connectivity, an indication of one or more alternative suitable cellsfor connection recovery and / or other additional information. Example mechanisms for supporting transmission of a connectivity change report may include triggering conditions for connectivity change report transmission, resources for transmission, validity conditions, transmission / retransmission and / or updating of an initial report, and / or prohibit conditions for report transmission. Mechanisms for supporting a network response to a connectivity change report may include additional WTRU monitoring and / or follow-up WTRU actions (e.g., depending on network (NW) response).

[0030] Mechanisms for supporting connectivity change validation and / or recovery may include follow-up monitoring and / or validation of a connectivity change event. Mechanisms to support connection recovery on a second (e.g., recovery) cell may include the initiation of connection recovery, downlink (DL) synchronization and / or WTRU identification on a second cell, and / or NW response on a second cell. Mechanisms to support connection recovery on a third / additional cell may include procedure initiation and / or additional cell selection.

[0031] Mechanisms for supporting early termination and / or procedure failure may include an early termination of a connectivity change reporting / recovery procedure, including initiation, WTRU actions upon early termination, and / or notification to the network. Mechanisms to support failure handling during a connectivity change reporting and / or recovery procedure may include failure conditions and / or follow-up WTRU actions.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] 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. 1A according to an embodiment.

[0034] FIG. 1C 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. 1A according to an embodiment.

[0035] 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. 1A according to an embodiment.

[0036] FIG. 2 is an example flow diagram depicting various procedural steps for supporting connectivity change reporting and recovery, and corresponding descriptions herein.

[0037] FIG. 3 is an example schematic diagram of various example descriptions regarding supporting connectivity change reporting and recovery described herein.DETAILED DESCRIPTION

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

[0039] 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, adevice 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 vice 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).

[0040] 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 Internet 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.

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

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

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

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

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

[0046] 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., an eNB and a gNB).

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

[0048] 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 wirelessconnectivity 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 cellularbased 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.

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

[0050] 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 anotherCN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0052] FIG. 1 B 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.

[0053] 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. 1 B 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.

[0054] 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 totransmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

[0059] 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 currentlocation of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information 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 location-determination method while remaining consistent with an embodiment.

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

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

[0062] FIG. 1C 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.

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

[0064] 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. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0065] The CN 106 shown in FIG. 1C 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.

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

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

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

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

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

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

[0072] 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 (IBSS) 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.

[0073] When using the 802.11ac 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, forexample 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.

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

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

[0076] 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.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11af 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.11ah 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).

[0077] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, 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 supportsthe smallest bandwidth operating mode. In the example of 802.11ah, 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 is busy, 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.

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

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

[0080] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment.The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, 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).

[0081] 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 / ordifferent 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).

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

[0083] 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. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

[0085] 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 AMF182a, 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, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, 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.

[0086] 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 U PF 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.

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

[0088] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.gr, 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 toa 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.

[0089] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, 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 or more, 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.

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

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

[0092] Various mechanisms for supporting connectivity change reporting and recovery are described herein. Regarding physical-layer-centric use cases including spatial and temporal beam prediction and / or temporal prediction within a serving cell may be used to predict the best or top-K beam(s) or beam pair(s) in the time domain in order to increase WTRU throughput. Predicting the best or top-K beam(s) or beam pair(s) among a set of beams by measuring a smaller set of beams may help reduce Reference Signal (RS) signaling overhead, measurementefforts, WTRU power consumption, etc. By extended L1 beam measurement from serving cell to neighboring cell, a majority of Radio Access Network Working Group 1 (RAN1) work may be reused (e.g., for LTM HO study). Since L3 measurement is based on filtering of L1 measurement, the study of AI / ML for air may be leveraged for mobility purposes (e.g., temporal prediction may also be used to predict when beam(s) / cell(s) will become worse so that an unintended event like radio link failure or short-stay handover may be avoided).

[0093] In these, Radio Access Network Working Group 3 (RAN3) normative work on mobility enhancement may be based on information available in the network side (e.g., handover and stay of time in history among cells to predict a WTRU’s trajectory in single hop and hence potential candidates). The WTRU’s predicted trajectory may be helpful for studying AI / ML mobility over an air interface to some extent.

[0094] Based on an assumption of a WTRU’s trajectory, it may be feasible to predict one or more radio resource management (RRM) measurements and / or an event and hence a candidate target cell on the WTRU side. On the network side, assistant information (e.g., if necessary) and / or statistics information based on one or more measurement reports from one or more WTRUs and / or neighboring nodes may also be used for prediction. If some prediction information can be known by the network, handover and / or RRM performance may be enhanced by proactive measures to make a better decision and / or to avoid an unintended event.

[0095] The use of AI / ML based prediction for RRM, including the inference of additional measurements (e.g., from a subset of beam measurements) may be extended to predict other changes in connectivity (e.g., a radio link failure (RLF) and / or beam failure detection). For instance, the WTRU may report if and / or when such future connection issues may arise. This may enable proactive recovery by the network, including preparation and / or recovery on an alternative and / or secondary cell prior to the connectivity change or loss of connection on a first and / or serving cell.

[0096] If a connectivity change occurs (e.g., an RLF), since currently defined procedures are reactive, the WTRU will have lost the connection with a serving cell prior to being able to receive DL recovery signaling (e.g., an HO command / RRC reconfiguration message). The WTRU may therefore initiate an RRC re-establishment procedure, introducing additional signaling overhead and / or service interruption. Herein described mechanisms address how to avoid the service interruption and / or signaling overhead of a radio link failure and / or reestablishment procedure if a connectivity change can be detected / predicted in advance.

[0097] FIG. 2 is an example flow diagram 200 depicting various procedural steps for supporting connectivity change reporting and / or recovery, and corresponding descriptions herein. A WTRU may report, to a first cell, a predicted RLF time and / or a second suitable candidate cell. The WTRU may monitor for a reconfiguration message from a second cell (e.g., the second suitable candidate cell) as a function of (e.g., based on) whether the predicted RLF occurs (e.g., the RLF predicted to occur at the predicted RLF time). As depicted in FIG. 2 at block 202, a WTRU may receive (e.g., from a first cell) configuration information associated with prediction, detection, reporting and / or recovery of a predicted connectivity change event. As indicated by block 204, a WTRU may determine and / or predict a connectivity change event (e.g., RLF, beam failure detection (BFD)), a change in a measurement / mobility event, and / or L2 failures (e.g., too many retransmissions of RLC (radio link control), hybrid automatic repeat request (HARQ), and / or random access channel (RACH) preamble) in a first cell and associated time-related (e.g., relative or absolute time, time window) information related to a possible change in the connectivity (e.g., a connectivity change event such as RLF, mobility event, L2 failures, etc.) (e.g., the predicted connectivity change event).

[0098] As indicated by block 206, the WTRU may transmit a report using a first set of resources associated with a first connection (e.g., in a first cell), wherein the report may include at least: (possibly predicted) time-related (e.g., relative or absolute time, time window) information related to the possible change in the connectivity (e.g., RLF, mobility event, L2 failures) and / or possibly also (possibly predicted) information about at least one suitable candidate cell. As indicated by block 208, the WTRU may receive a follow up network (NW) response from a first cell for (e.g., to) a connectivity change report (e.g., the report transmitted by the WTRU). The NW response may include one or more of: a recovery configuration for a second cell (e.g., a dedicated radio network temporary identifier (RNTI) / preamble / configured grant (CG) to identify the WTRU in the second cell) and / or an identifier of a recovery configuration for a second cell (e.g., index to a pre-configured second cell configuration (e.g., LTM candidate cells)). The second reported cell may comprise a second suitable candidate cell indicated in the report transmitted by the WTRU or may comprise a different cell. The WTRU may then synchronize and / or decode one or more downlink control channels using resources corresponding to a second reported cell (e.g., no earlier than starting from, or during, an associated period of a time corresponding to the reported time-related information, where the second reported cell may comprise a second suitable candidate cell indicated in the report transmitted by the WTRU or a different cell). For instance, as indicated by block 210, the WTRU may validate the connectivity change prediction (e.g., detect that the determined and / or predicted connectivity change eventhas occurred) and, as indicated by block 212, attempt to recover on the second reported cell. The WTRU may receive a downlink transmission that includes a reconfiguration message (e.g., with or without mobility control information). As indicated by block 214, if the WTRU is unsuccessful in receiving a downlink transmission from the second reported cell (e.g., within a time duration), the WTRU may attempt to synchronize and / or decode one or more downlink control channels using resources corresponding to a third reported cell (e.g., wherein the third reported cell may comprise a third suitable candidate cell indicated in the report transmitted by the WTRU or a different cell). The WTRU may first attempt to receive mobility information (e.g., a reconfiguration message) from a second cell (e.g., the second reported cell) prior to performing an RRC re-establishment procedure, which may reduce the connection interruption time and / or signaling overhead.

[0099] Mechanisms described herein support the prediction and / or detection of a connectivity change between a WTRU and the network, and corresponding recovery procedures (e.g., on an alternative candidate cell). The following terminology may be used within this document.

[0100] The term “connectivity change” may refer to a possible change in the WTRU-NW connection. Examples of connectivity change and / or connectivity change events may include, for example, a change in reference signal received power (RSRP), a change in reference signal received quality (RSRQ), radio link failure (RLF), a mobility / measurement event, and / or beam failure detection (BFD).

[0101] The terms “connectivity change detection” and / or “connectivity change prediction” may refer to the detection and / or prediction of a connectivity change and / or connectivity change event.

[0102] The terms “connectivity change procedure,” “connectivity change recovery procedure,” and / or similar terms may refer to one or more aspects of connectivity change detection, prediction, reporting, and / or recovery on a second, third, or other recovery cell.

[0103] The term “additional cell” may refer to a cell (e.g., other than a first, second, or third cell) on which the WTRU may attempt to recover a connection after a connectivity change event.

[0104] The term “cell” may refer to a cell and / or a specific beam on a cell. For example, where a measurement and / or a measurement event is described in terms of cell quality, this may refer to one or more individual beam qualities on a cell (e.g., the measurement according to a specific one or more measurement reference signals corresponding to a beam, such as asynchronization signal block (SSB) or a channel state information-reference signal (CSI-RS) resource).

[0105] The following principles and / or observations may apply. A connectivity change may be detected (e.g., via measurement) and / or predicted (e.g., via AI / ML inference). Solutions described herein may apply to both.

[0106] Regarding configuration and / or capability reporting, a WTRU may be provided with one or more configurations to support connectivity change prediction, detection, reporting, and / or recovery. Examples may include configurations to support one or more of: connectivity change reporting, connectivity change recovery procedures (e.g., procedure initiation, termination, failure handling), configurations for one or more secondary additional recovery cells, and / or one or more AI / ML models / functionalities (e.g., to predict a connectivity change).

[0107] Connectivity change prediction, detection, reporting, and / or recovery may (e.g., additionally) be initiated if supported by both the WTRU and the network (NW). A WTRU may indicate capability (e.g., of the WTRU) for one or more aspects of a connectivity change prediction, detection, reporting, and / or recovery procedure (e.g., prior to initiation of the procedure and / or reception of associated configurations). A NW may indicate support (e.g., per cell) for one or more aspects of the connectivity change prediction, detection, reporting, and / or recovery procedure. A WTRU may, for example, initiate a procedure and / or expect a configuration with cells which support the procedure.

[0108] Mechanisms described herein support indication of WTRU capability, NW support, and / or the reception of one or more configurations to enable / support connectivity change prediction, detection, reporting, and / or recovery.

[0109] Regarding the capability for connectivity change prediction / detection / recovery, a capability may be required for a connectivity change recovery procedure. The capability may be related to aspects (e.g., all aspects) of the connectivity change recovery procedure and / or one or more aspects thereof. Support for the connectivity change recovery procedure may be reported by the UE and / or indicated by the network (e.g., on a cell-specific basis). Regarding a WTRU’s capability reporting for connectivity change reporting and / or recovery, a WTRU may indicate capability and / or support for one or more aspects of connectivity change reporting and / or recovery. For example, the WTRU may indicate a single capability to indicate support for all aspects of the connectivity change recovery procedure (e.g., connectivity change prediction, detection, reporting and recovery). In another example, the WTRU may report support for eachaspect of the connectivity change recovery procedure (e.g., such that the WTRU may indicate support for one or more aspects of the connectivity change recovery procedure via one or more different parameters). For example, the WTRU may indicate support for one or more of the following: connectivity change prediction (e.g., at a particular time, or within a time window), connectivity change reporting (e.g., based on detection or prediction), and / or connectivity change recovery (e.g., on a second cell and / or on a third cell).

[0110] A WTRU may report the capability of one or more of the above aspects of a connectivity change recovery procedure, for example, via a WTRU capability transfer procedure. In another example, the WTRU may indicate capability and / or support via one or more of the following methods: random access (or use of one or more dedicated resources, use of random access preamble partitioning — e.g., a set of reserved preambles or random access occasions, radio network temporary identifiers (RNTIs) etc., upon RRC connection establishment / resumption — e.g., Msg3 or Msg5, upon request from the network — e.g., upon reception of the capability enquiry message), and / or WTRU assistance information.

[0111] The capability to support, perform, execute, and / or initiate one or more aspects of a connectivity change recovery procedure may be reliant on and / or linked to one or more other configurations. For example, the network may assume that a WTRU is capable of one or more aspects of the connectivity change recovery procedure based on, for example, an activation, state, and / or configuration of one or more of the following types: a configuration of an AI / ML model and / or functionality, an activation of an AI / ML model and / or functionality, an availability of an AI / ML model and / or functionality, and / or a configuration of resources for transmission of a connectivity change report.

[0112] The capability and / or support for initiation of one or more aspects of a connectivity change recovery procedure may be based (e.g., reliant) on one or more characteristics of the WTRU. For example, capability and / or support for initiation of one or more aspects of a connectivity change recovery procedure may be based (e.g., reliant) on one or more of the following characteristics: performance of an AI / ML model and / or functionality, WTRU speed, remaining WTRU power, WTRU processing ability, WTRU location (e.g., within a certain set of cells, use of one of a set of specific beams, GPS location, etc.), and / or when a particular type of service is in use (e.g., related to one or more specific network slices or channel quality indicators (QCIs).

[0113] If a WTRU is configured for a connectivity change recovery procedure and an associated configuration is not present and / or is not active and / or if the WTRU characteristics are notsuitable, the procedure may be temporarily disabled e.g., the WTRU may not initiate the procedure) and / or inactive. The WTRU may indicate (e.g., subject to configuration) to the network that the connectivity change recovery procedure is temporarily inactive (e.g., via a medium access control (MAC), control element (CE), uplink control information (UCI), and / or RRC signaling). The WTRU may also report a reason why the procedure is inactive (e.g., a reason such as a joint configuration being disabled or the WTRU characteristics not being suitable).

[0114] Regarding NW support for connectivity change report and recovery, a network may indicate support for a connectivity change report and / or recovery procedure. Support for the connectivity change recovery procedure may be indicated, for example, per cell, per public land mobile network (PLMN), per frequency, per tracking area (TA), and / or per RAN notification area (RNA). The indication of support may comprise, for example, a flag and / or a bit in system information which indicates support for the connectivity change report and / or recovery procedure. In another example, the NW may indicate support for an aspect of the procedure (e.g., indicate that the cell supports recovery, but not reporting etc.). In another example, the network may indicate (e.g., within system information and / or via RRC configuration) a list of one or more cells which support connectivity change report and / or recovery procedure.

[0115] The WTRU may initiate a connectivity change recovery procedure or one or more aspects of a connectivity change procedure (e.g., prediction, detection, reporting and / or recovery) subject to the network supporting the procedure. For example, the WTRU may indicate a second cell as a recovery cell (e.g., within connectivity change report) if the cell (e.g., the second cell and / or a first cell to which the indication may be sent) has indicated support for the connectivity change recovery procedure.

[0116] Regarding configurations for connectivity change reporting and recovery, the WTRU may receive one or more configurations to support a connectivity change reporting and / or recovery procedure. Examples of configurations may include configurations for the connectivity change report contents / transmission and / or configurations for connectivity change recovery (e.g., initiation, termination, and / or failure handling).

[0117] Regarding configuration(s) for connectivity change reporting, the WTRU may receive a configuration to report a change in connectivity. A connectivity change reporting configuration may support, enable, and / or instruct the WTRU to report a change in connectivity. For example, a configuration for connectivity change reporting may include one or more pieces of information: an enable / disable indication for connectivity change reporting (e.g., a flag or bit), an indication ofwhether the reported connection change may be based on a prediction, an indication of an associated probability and / or confidence level with a connection change prediction, an indication of whether the WTRU may include a second cell and / or beam for recovery, an indication of whether the WTRU may include additional cell(s) and / or beam(s) for recovery, an indication of whether the WTRU includes measurements associated with the recovery cell(s) and / beam(s), an indication of whether the WTRU should monitor for a NW response after the connectivity change reporting, an indication of whether the WTRU may indicate multiple events within a report, and / or an indication of one or more connectivity events to prioritize in a report (e.g., in case multiple events are triggered concurrently and / or simultaneously).

[0118] Regarding configurations for recovery procedure initiation, the WTRU may receive a configuration to support initiation of a recovery procedure after a change in connectivity. For example, a configuration to initiate a post-connectivity change recovery procedure may indicate one or more of the following pieces of information: triggering conditions to initiate a recovery procedure and / or prohibit conditions to postpone recovery procedure initiation.

[0119] Regarding configurations for early termination of a recovery procedure, the WTRU may receive a configuration to support early termination of a connectivity change recovery procedure. For example, an early termination configuration may indicate whether the WTRU can report an early termination to the network.

[0120] Regarding configurations for failure handling of recovery procedure, the WTRU may receive a configuration to support handling of failures during a connectivity change recovery procedure. For example, a failure recovery configuration may indicate one or more of the following pieces of information: a number of cells or beams the WTRU may attempt recovery prior to declaring failure and / or one or more prohibit conditions (e.g., a backoff timer) for when the WTRU may re-attempt the procedure.

[0121] Regarding configurations for candidate recovery cells, the WTRU may receive one or more configurations to support recovery one or more cells. Examples may include configurations to support connection continuity (e.g., access, synchronization, WTRU identification, and / or DL monitoring) on a secondary cell and / or one or more additional cells and / or beams after connectivity change in a first cell.

[0122] Regarding configurations for secondary / recovery cell monitoring, the WTRU may receive a configuration to support recovery on a second cell during and / or on response to a connectivity change. For example, a secondary cell recovery configuration may include one or more of thefollowing pieces of information: an enable / disable indication (e.g., a flag / bit), monitoring configuration (e.g., time, duration, measurement RSs, etc.), an indication of which channel the WTRU may monitor for a response message (e.g., physical downlink control channel (PDCCH), physical downlink shared channel (PDSCH), etc.), an indication of dedicated resources to access the cell (e.g., RNTI, RACH occasions, preamble, configured grant), an indication of whether the WTRU is to resend the connectivity change report in the cell, and / or an indication of a time period (e.g., duration) during which the WTRU may monitor on a cell and / or beam.

[0123] Regarding configurations for prediction evaluation, the WTRU may receive a configuration to support recovery on a third or additional cell during and / or in response to a connectivity change. For example, a secondary cell recovery configuration may include one or more of the following pieces of information: an enable / disable indication (e.g., a flag or bit) to enable recovery on an additional cell and / or beam, an indication of a number of cells and / or beams the WTRU on which to try to attempt recovery (e.g., prior to declaring procedure failure), and / or an indication of whether the dedicated access resources are the same as those used to access the second cell.

[0124] Regarding configurations for connectivity change detection / prediction, the WTRU may receive configurations related to the detection and / or prediction of a connectivity change. Configurations may include, for example, configurations for AI / ML functionality / model activation and / or inference, and / or prediction performance evaluation.

[0125] Regarding configurations for prediction accuracy evaluation, the WTRU may receive a configuration indicating how to evaluate, for example, whether the AI / ML model / functionality predictions of a connectivity change event are valid / accurate. A prediction evaluation configuration (e.g., connectivity change event prediction) may include one or more of the following types of information: an indication (e.g., a flag and / or enable / disable indication) to perform prediction evaluation; an indication of whether the performance monitoring should occur before, after, or both before and after prediction of a connectivity change; an offset (e.g., time offset) to perform the prediction evaluation (e.g., before or after the connectivity change event is detected); a duration (e.g., time period) in which to perform the prediction evaluation; a number of performed and / or predicted measurement samples WTRU for the WTRU to compare; and / or one or more evaluation criteria for the prediction (for example, the WTRU may be provided with a threshold and / or value, e.g., signal quality difference between predicted and measured signal levels — if the comparison (e.g., difference) between the actual measurements and predicted measurements is below (e.g., less than) the threshold, the prediction may be consideredsatisfactory); an accuracy value (e.g., the measurement predictions are 95% accurate); the number of predicted measurements which have to satisfy a criterion (e.g., within a given time duration); whether these predictions that satisfy the criteria should be consecutive predictions; a ratio / percentage of measurements which have to satisfy a criterion, one or more criteria to trigger a prediction evaluation (e.g., signal quality of the serving cell and / or beam); and / or a periodicity to trigger a prediction evaluation.

[0126] Configurations for connectivity change reporting / recovery and / or for AI / ML model / functionalities may be independently configured (e.g., there may be no dependency between configurations, and the WTRU may independently apply / remove configurations) or jointly configured (e.g., the two configurations may be linked and both configurations may be jointly applied and / or removed, wherein the application / removal of one configuration may imply the application / removal of the other configuration).

[0127] Regarding configuration adaptation and / or management, methods to acquire, reacquire, adapt, and / or release connectivity change prediction / reporting / recovery configurations may be implemented to ensure the WTRU can continue / recover a connection on a second / additional cell.

[0128] Regarding signaling of connectivity change prediction / reporting / recovery configurations, the WTRU may be provided with connectivity change prediction / reporting / recovery configuration(s) upon establishment / resumption of an RRC connection (e.g., within the RRC Setup / Resume message) or upon handover to another cell (e.g., within a HO command / RRC reconfiguration message with a reconfiguration with sync) or at any time during an active RRC connection (E.g., RRC reconfiguration message without reconfiguration with sync). In some other solutions, configurations for connectivity change prediction / reporting / recovery may be indicated / configured / provided via one or more of the following signaling methods: SIB (e.g., a new SI block, or within another existing SIB), NAS, MAC CE, DCI, RACH (e.g., MSG2, MSG4, MSGB), RRC, and / or PDCCH / PUSCH.

[0129] A WTRU may receive different information and / or components of a connectivity change prediction / reporting / recovery configuration via different signaling methods. For example, the WTRU may receive some dedicated configuration aspects via RRC signaling (e.g., the DL coverage enhancements to apply, dedicated RNTIs), and some other configurations and / or information via system information (e.g., the resources to monitor access a second or additional recovery cell, whether the predicted connectivity change recovery is enabled for a given cell). If a WTRU is provided with a dedicated configuration / indication related to connectivity changeprediction / reporting / recovery, the WTRU may override other common configuration information (e.g., received via broadcast signaling) and / or may combine the dedicated configuration with one or more pieces of common configuration information. In another example, the WTRU may use the most recently received information in the configuration regardless of the signaling method.

[0130] The WTRU may receive one or more alternative configurations using a first signaling method (e.g., via system information or dedicated RRC signaling). Using another type of signaling — e.g., a second signaling method (e.g., via dedicated RRC signaling or MAC CE) — the network may select or indicate which of the one or more alternative configurations to apply.

[0131] Regarding handling of connectivity change prediction / reporting / recovery configuration(s), the WTRU may receive a configuration based on a NW decision (e.g., upon release to RRC IDLE and / or RRC INACTIVE). For example, the WTRU may receive a configuration based on a NW decision if the WTRU indicates the WTRU is capable of a connectivity change prediction / reporting / recovery. The WTRU may request to be configured with a connectivity change prediction / reporting / recovery configuration.

[0132] The WTRU may request a connectivity change prediction / reporting / recovery configuration, update an existing connectivity change prediction / reporting / recovery configuration, and / or apply a different connectivity change prediction / reporting / recovery configuration based on one or more of the following conditions being satisfied: if the WTRU detects that the DL coverage is degrading for the serving cell (e.g., signal quality measurements of the serving cell or beam have fallen below a threshold), and / or if the WTRU detects that the DL coverage is degrading for one or more neighboring cells) (e.g., if signal quality measurements of the serving cell or beam have fallen below a threshold).

[0133] The WTRU may release the configuration (e.g., all or one or more parts of a configuration), for example, upon (e.g., in response to detecting ) one or more of the following circumstances: the current serving cell does not supporting connectivity change prediction / reporting / recovery, the WTRU not having an active, available, configured, and / or supported AI / ML functionality / model to predict a connectivity change; an early termination of the procedure being triggered, and / or the WTRU declaring a procedure failure.

[0134] Regarding conditional configuration adaptation, a WTRU may adapt (e.g., change) one or more aspects of a configuration based on the WTRU characteristics of the WTRU. Examplesof WTRU characteristics may include: WTRU speed and / or position, WTRU power and / or battery level, and / or WTRU processing capability and / or load.

[0135] Upon detection of change in WTRU characteristics, the WTRU may modify one or more aspects of the current configuration and / or apply a new configuration. How the WTRU detects which aspects of the configuration to change may be based on conditions associated with the configuration and / or one or more aspects of the configuration. For example, the WTRU may be provided with one or more thresholds. If a threshold is exceeded by a value (or if a value has fallen below a threshold), the WTRU may apply an alternative configuration and / or value for the same configuration.

[0136] Regarding connectivity change reporting, a WTRU may report a detected and / or predicted change in the state of a WTRU-NW connection. Reporting a future detected and / or predicted change in connectivity may support network recovery actions if sufficient time is allowed to prepare recovery actions. For example, if the WTRU can predict a future radio link failure on a current serving cell, the network may prepare a handover to a future cell in advance to support recovery on a second cell (e.g., the future cell). This may also avoid the signaling and / or service interruption associated with connection re-establishment.

[0137] Solutions described herein may support connectivity change reporting — including report contents, initiation, transmission, retransmission, and / or prohibition — as well as the monitoring and / or WTRU actions to support a possible network response to the connectivity change report.

[0138] Regarding contents of a connectivity change report, a WTRU may provide a one-bit (e.g., flag) indication that a change in connectivity is expected. The WTRU may provide more detailed information regarding the change in connectivity, such as how the determination (e.g., prediction) is made, the confidence in the determination, and other useful information (e.g., WTRU characteristics) to support follow-up actions by the network and / or recovery actions by the WTRU.

[0139] Regarding indication of a predicted / detected change in connectivity, a WTRU may indicate that a change in connectivity with the network will / may (e.g., is predicted to) occur. The change in connectivity may be related to a current serving cell and / or to one or more neighboring cells. If the connectivity change event is related to a neighboring cell and / or a beam / measurement resource on a neighboring cell, the WTRU may include an identifier (e.g., a PCI (physical cell identity), resource index) to associate the connectivity change event with the relevant cell and / or beam. Examples of a change in connectivity (e.g., a connectivity changeevent) may include one or more of the following: a radio link failure (RLF), beam failure detection (BFD), a cell quality or beam quality measurement quantity (e.g., RSRP / RSRQ / SINR (signal interference plus noise ratio) dropping below a threshold, a cell quality or beam quality measurement quantity (e.g., RSRP / RSRQ / SINR) increasing above a threshold, and / or a mobility and / or measurement event (e.g., A1 / A2 / A3 / A4 / A5, LTM2,3,4,5, etc.).

[0140] A WTRU may be configured to report one type of event (e.g., an RLF). Upon detection and / or prediction of the configured event, the WTRU may report (e.g., via a 1 -bit indication / flag) that the event has occurred or is predicted to occur. In another example, the WTRU may be configured to report among multiple (e.g., more than one) connectivity change events (e.g., wherein each event may be associated with an event ID). The WTRU may then indicate which event (e.g., RLF, BFD, change in measurement) has occurred (e.g., including the individual event IDs and / or including a bitmap indicating the events predicted to be fulfilled). If multiple events occur for the same report (e.g., RLF and BFD), the WTRU may include all events within the report. In another solution, the WTRU may prioritize between events and indicate a single event (or fewer than the total number of detected connectivity change events) within a report. For example, the WTRU may simultaneously detect RLF and a measurement quantity dropping below a threshold, and in the connectivity change report the WTRU may prioritize the reporting of the RLF. How the WTRU prioritizes which connectivity change events to include within a report may be based on network configuration, specification, and / or WTRU implementation.

[0141] A connectivity change event may be associated with a (e.g., future) time, for example, when the event is expected and / or predicted to occur. The WTRU may include the associated time within the connectivity change report. In some solutions, possible ways the WTRU may report the future time associated with a connectivity change event may include, for example, one or more of the following types of times and / or time duration: a time that the change in connectivity is predicted to occur (e.g., 10:23:40 UTC), a start time and / or a time duration in which the change in connectivity is predicted to occur, and / or pair of times comprising a start time and end time (e.g., wherein the event may be predicted occur anytime within the duration between the start time and the end time).

[0142] The WTRU may include a single time and / or time range for a connectivity change report, for example, if only one connectivity change event is included within the report. If multiple connectivity change events are included within the report, the WTRU may include different times and / or time ranges associated with each connectivity change event. In another solution, the WTRU may report a single time and / or time range associated with multiple events, wherein it allreported events may be predicted to occur at that time and / or within that time range. The single time and / or time range associated with multiple events may comprise the earliest time when one of the reported events is expected to occur.

[0143] The expected time occurrence of an event (e.g., a connectivity change event ) may be part of (e.g., indicated by) the event prediction configuration and may, in some examples, not be explicitly signaled by the WTRU. For example, the WTRU may have been configured with RLF prediction reporting configuration that may indicate a time duration / window for the prediction. That is, by receiving an RLF prediction report that does not include a time information, the network may implicitly know (e.g., infer) that the RLF is expected to occur after and / or within the configured time duration / window for the RLF prediction reporting.

[0144] The manner in which an associated time may be reported and / or expressed (e.g., indicated) may be based on, for example, a network configuration, a manner in which the connectivity change (e.g., with which the associated time is associated) was determined (e.g., based on detection and / or prediction), how far in advance the connectivity change event is expected, a prediction confidence, an AI / ML model / functionality used to make the prediction, and / or a type of connectivity change event that is predicted to occur.

[0145] Regarding indication of one or more alternative suitable cells for connection recovery, a WTRU may indicate one or more cells (e.g., via PCI or list of PCIs) and / or beams (e.g., via SSB or CSI-RS index) in a connectivity change report. The cells and / or beams within the report may be used to recover and / or continue the connection (e.g., if the connectivity change event occurs).

[0146] The WTRU may additionally (e.g., subject to configuration) include measurement results (e.g., RSRP, RSRQ, SI NR) associated with each potential recovery cell (e.g., candidate recovery cell) included within the connectivity change report. The measurement results may be explicitly provided within the connectivity change report and / or associated with a cell and / or may be provided via another method (e.g., via a measurement report). In one example, upon transmission (or triggering of transmission) of a connectivity change report, the WTRU may trigger transmission of a measurement report (e.g., including measurement results for cells indicated within the connectivity change report). The WTRU may include measurement results for cells indicated within the connectivity change report if those cells are not already included within a measurement report (e.g., a measurement report that was triggered before the connectivity change report).

[0147] If the WTRU includes more than one cell and / or beam in a report (e.g., connectivity change report), the WTRU may explicitly rank cells and / or beams in order of priority for recovery. For example, in case of recovery from a connectivity change event, the WTRU may attempt recovery on a highest ranked cell (e.g., the cell with the highest measured signal quality) first. If connection recovery was unsuccessful, the WTRU may then attempt connection on a second highest ranked cell, and so on. In another solution, the cells (e.g., potential recover cells and / or candidate recovery sales) may be implicitly ranked in order of priority for recovery. For example, the cells may be accompanied by an associated measurement quantity (e.g., RSRP / RSRQ / SINR) value. The WTRU may attempt recovery on the cell with the highest measurement value. If recovery on the cell with the highest measurement value is unsuccessful, the WTRU may attempt recovery on the cell with the second highest value cell, and so on. Whether the connectivity change report may include one or more cells may be based on configuration. How may cells the WTRU may include may be based on a configured maximum number of cells. In another solution, the network may configure a condition for including (e.g., indicating) a cell in a connectivity change report, and the WTRU may include all cells which satisfy this condition in the connectivity change report. For example, the WTRU may be configured with a measurement threshold, wherein the WTRU may report all neighboring cells which have a measured value (e.g., RSRP / RSRQ / SINR) above the configured threshold.

[0148] The network may support connectivity change recovery procedure on a subset of cells. The WTRU may include within a connectivity change report only cells which have indicated support for connection recovery (e g., as indicated within SIB). The WTRU may include both cells which support connection recovery and cells that do not support connection recovery, but may prioritize the cells in which connection recovery is supported. If there are no suitable cells which support connection recovery, the WTRU may within a connectivity change report only cells which do not support connection recovery.

[0149] Regarding additional information within a connectivity change report (e.g., if the change in connectivity is based on a prediction), a WTRU may include one or more pieces of additional information in the connectivity change report related to the connectivity change prediction (e.g., how the prediction was made and / or a level of confidence in the prediction to support). Such information may support, for example, network decisions on how to handle the connectivity change event and / or assess the priority of the connectivity change. Examples of additional information related to the prediction of the connectivity change event which may be included within the connectivity change report may include, for example, one or more of the following: anindication that the connectivity change event is based on prediction, a confidence of the connectivity change event (e.g., the event will occur with certain probability, such as 95%, in the indicated time window), the AI / ML model and / or functionality that was used to perform the prediction, and / or currently applied AI / ML configurations (e.g., data collection and / or inference configurations, associated ID).

[0150] Other examples of additional information a WTRU may report regarding the connectivity change may include information related to a WTRU status and / or additional details regarding the connectivity change event. For example, the WTRU may include one or more of the following additional pieces of information: current WTRU conditions (e.g., WTRU speed, processing load, battery status), measurements (e.g., the predicted RSRP, RSRQ, SINR) associated with the connectivity change event, and / or measurement values for one or more additional (e.g., additional to those used for determining to trigger the report) neighbor cells and / or beams (e.g., which measurements may be predicted and / or based on real measurement). The additional information that may be included in the connectivity change report may be based on satisfaction of one or more conditions. The one or more conditions may be based on, for example, the type of connectivity change, whether the connectivity change was based on prediction, a level of confidence of the prediction, and / or network configuration.

[0151] Whether the WTRU transmits additional information may be based on a follow-up request from the network. The WTRU may monitor and / or respond to a follow-up request from the network as further described herein.

[0152] Regarding transmission of a connectivity change report, (e.g., where the WTRU is configured to report a change in connectivity), how and when the WTRU transmits a connectivity change report at some point prior to the connectivity change event (e.g., based on WTRU implementation) may be controlled by the network. For instance, transmission of the connectivity change report may be controlled by the network (e.g., via the configuration of triggering conditions, prohibit conditions, and / or resources for transmission) as described herein.

[0153] Regarding triggering conditions for connectivity change report transmission, the WTRU may initiate transmission of a connectivity change report upon satisfaction of a triggering condition. A connectivity change report may be triggered, for example, based on one or more of the following conditions: upon reception of a network request for a connectivity change report, at periodic intervals (e.g., periodically), upon detection of a connectivity change event, upon prediction of a connectivity change event, upon detection / prediction of a specific type of changein connectivity (e.g., RLF), upon detection of an upcoming mobility event (e.g., A3 / A5 event), upon connection to a recovery cell (e.g., completion of RRC setup / resume / re-establishment), during DL synchronization to a recovery cell (e.g., within RACH), upon expiry of a timer (e.g., a prohibit timer), upon addition and / or removal of a recovery cell, upon change of prioritization for one or more recovery cells, upon additional and / or removal of additional information, and / or upon reception of a negative acknowledgement (NACK) from a network.

[0154] If a triggering condition is satisfied, the WTRU may transmit the connectivity change report. If multiple triggering conditions are satisfied prior to transmission of a connectivity change report and / or acknowledgment of an initial transmission of a connectivity change report, the WTRU may, for example, transmit a single report (e.g., connectivity change report). If a second report contains additional information and / or updated information not included within an initially transmitted report, the WTRU may trigger a second report containing the additional and / or updated information (e.g., as described further herein regarding retransmission / update of a connectivity change report).

[0155] Regarding transmission of a connectivity change report, a WTRU may transmit a connectivity change report via dedicated resources. For example, the WTRU may be provided with a dedicated UL resource (PUSCH, UCI (uplink control information)) to transmit the connectivity change report. The WTRU may be provided with a configured grant configuration. The WTRU may be provided with dedicated resources, for example, within the connectivity change report configuration. The WTRU may be provided with a dedicated (scheduling request) configuration to request resources to transmit a connectivity change report.

[0156] A WTRU may transmit a connectivity change report via, for example, one or more of the following signaling methods: UCI, PUSCH, PUCCH, MAC CE, RRC signaling, NAS, and / or RACH (MS3, MS5, MGSA).

[0157] A WTRU may transmit a connectivity change report to a first cell (e.g., the current serving cell). The WTRU may transmit the connectivity change report to a second and / or additional cell (e g., a recovery cell indicated within the connectivity change report). The cell to which the WTRU transmits the connectivity change report may depend on, for example, where the WTRU has detected and / or predicted the connectivity change. The WTRU may transmit the connectivity change report on a second and / or additional cell if the WTRU cannot transmit and / or complete transmission of the connectivity change report on the first cell (e.g., due to the connection being lost due to the detected connectivity change event occurring). The transmission method the WTRU selects may depend on to which cell the WTRU transmits theconnectivity change report. For example, the WTRU may transmit the connectivity report to a first cell (e.g., the cell in which the connectivity change was detected / predicted) via RRC or MAC CE. However if transmission was unsuccessful ,the WTRU may transmit the connectivity change report to a second and / or additional cell via RACH signaling (e.g., MSG3, MSG5, MSGA). The WTRU may select a different transmission method if the WTRU is sending an initial report as compared to a retransmission and / or updated / delta / partial connectivity change report.

[0158] Regarding validity of the connectivity change report, the connectivity change report may be associated with validity conditions (e.g., to ensure that the network is not operating on outdated information). Examples of validity conditions for a connectivity change report may include, for example, one or more of the following: an AI / ML model / functionality being deactivated and / or reconfigured (e.g., the model / functionality which was used to predict the connectivity change no longer bring applicable), the prediction confidence falling below a threshold, the WTRU characteristics having changed past a threshold (e.g., the WTRU having increased or decreased speed), and / or other early termination and / or failure conditions being satisfied (e.g., such as those further described herein).

[0159] Upon expiry of one or more validity conditions, the WTRU may consider the connectivity change report as no longer valid. In some examples, if the validity condition has expired prior to transmission of the connectivity change report, the WTRU may cancel transmission of a connectivity change report. In other examples, the validity conditions for a connectivity change report may have expired after the WTRU has already transmitted a report (e.g., connectivity change report). The WTRU may then, for example, transmit an indication to the network that a previous report is no longer valid and / or transmit an updated connectivity change report.

[0160] Regarding retransmission / update of a connectivity change report, the WTRU may update one or more aspects of the connectivity change report after the initial transmission of a connectivity change report. For example, if one or more of the aspects of an initial connectivity change report have changed, the WTRU may update one or more aspects of the connectivity change report. The types of updates that may trigger the WTRU to update one or more aspects of the report may include, for example, an updated connectivity change event, an updated time of a connectivity change event, an addition and / or removal of one or more recovery cells and / or priority of one or more recovery cells, a change in prediction accuracy and / or other additional information included within the initial connectivity change report (e.g., as described previously herein).

[0161] If one or more aspects of a connectivity change have been updated, a WTRU may transmit a full connectivity change report incorporating the revised information. The WTRU may transmit a partial connectivity change report (e.g., including only the values which have changed). The WTRU may transmit a delta report, where the WTRU may report a delta difference from a previous report. Whether the WTRU transmits a full report, delta report, or partial report may depend on whether the previous report (e.g., the report that is being used as a reference) was successfully acknowledged by the network.

[0162] Whether the WTRU may retransmit the report may be based on, for example, network configuration, network request, and / or an indication (e.g., implicit or explicit) that an earlier report was not successfully received (e.g., HARQ NACK (negative acknowledgment), RLC / PDCP (packet data convergence protocol) STATUS PDU (packet data unit)).

[0163] Regarding prohibit conditions for transmission of a connectivity change report, a WTRU may be prohibited from transmitting a connectivity change report (e.g., to avoid excessive reporting and / or use of resources). While the WTRU is prohibited from sending a connectivity change report, the WTRU may not initiate transmission of a connectivity change report even if, for example, the WTRU has currently dedicated and / or available resources for transmission of a connectivity change report.

[0164] A WTRU may be prevented from transmitting a connectivity change report indefinitely while a condition is satisfied and / or subject to a time period. The manner in which the WTRU suspends the reporting may be based on a reason for prohibiting the transmission of a report. For example, the WTRU may not transmit (e.g., may suspend) a connectivity change report based on one or more of the following reasons: the prediction quality of a model / functionality dropping below a threshold, reception of an indication from the network that disables the connectivity change reporting (e.g., based on configuration or a dynamic indication), the network not supporting a connectivity (e.g., which may be indicated via an indication in a system information block (SIB)), and / or a prohibit timer currently running for a connectivity change report.

[0165] Regarding NW response to a connectivity change report, a WTRU may perform an initial transmission of the connectivity change report and not expect and / or monitor for a response from the network. The WTRU may monitor to receive an acknowledgment from the network. The WTRU may monitor to receive additional messaging from the network, which may involve follow-up communication and / or actions.

[0166] Regarding WTRU monitoring for a follow-up NW response, a WTRU may perform additional DL monitoring (e.g., PDCCH, PDSCH) for a network response (e.g., for a time window) after transmitting a connectivity change report. The WTRU may monitor, for example, for a fixed duration (e.g., subject to a timer duration), on dedicated occasions and / or channels, at a fixed offset from transmission of the connectivity change report, and / or via a dedicated RNTI provided within the connectivity change reporting configuration. The WTRU may monitor for a follow-up response on a first cell (e.g., the serving cell and / or the cell on which the connectivity change is detected / predicted to occur) and / or on a second / additional recovery cell.

[0167] Whether the WTRU initiates monitoring for a follow-up action could be based on a configuration and / or an indication. Whether the WTRU initiates monitoring for a follow-up action may be based on a condition. For example, the WTRU may initiate monitoring for a follow up action based on one or more of the following: the type of connectivity change (e.g., the WTRU may expect a follow up message from the network if the RSRP is predicted to reduce), the confidence of the connectivity change prediction, and / or the priority of buffered data / connection.

[0168] The WTRU may monitor for a follow-up response on a first and / or second / additional cell based on a duration of time (e.g., from a current time) until a predicted event is predicted to occur. For example, if a duration of time until a connectivity change is predicted to occur is large (e.g., above a threshold amount of time, such that the predicted time of the connectivity change is far in the future), then the WTRU may monitor for an NW response on the first cell (e.g., the serving cell). If the duration of time until a connectivity change is small (e.g., below a threshold amount of time, such that the predicted time of the connectivity change is near in the future) (for example, if the connectivity event is expected to occur prior to a possible response from a first cell), the WTRU may monitor for a response on a second and / or additional recovery cell (e.g., a recovery cell indicated within the connectivity change report).

[0169] Regarding possible NW response(s) to a connectivity change report, a WTRU may receive a follow-up response to a connectivity change report. The network response (e.g., the follow-up response ) may be received from a first cell (e.g., the serving cell), the cell on which the initial connectivity change report was transmitted, and / or a second / additional cell. The NW response may be received during a dedicated monitoring period (e.g., as previously described), or may be transmitted in another occasion (e.g., while the WTRU is monitoring a PDSCH / PDCCH for other reasons). Possible responses to the connectivity change report by the network may include, for example, one or more of the following: an ACK (e.g., transmitted using RRC, PDCP, RLC, MAC CE, HARQ ACK) to the connectivity change report, a rejection to theconnectivity change report (e.g., RRC reject message), one or more additional configurations)for recovery (e.g., dedicated RNTIs, preambles WTRU identifiers etc. to use in a recovery cell), a reconfiguration message (e.g., RRC Reconfiguration) such as a conditional reconfiguration message (e.g., CHO), an LTM configuration, an indication that the WTRU should directly monitor a PDCCH (e.g., on one or more neighboring cells), an indication that the WTRU should monitor a RACH, and / or an indication that the WTRU should monitor on an another cell (e.g., a cell not indicated within the connectivity change report).

[0170] In response to a network action (e.g., an NW response), the WTRU may infer (e.g., assume) certain information and / or perform a corresponding follow-up action. For example, if the NW acknowledges the connectivity report (or the NW has not sent an explicit rejection to the request, e.g., within a certain time duration), the WTRU may infer that the network will prepare for a possible connection recovery on one or more indicated recovery cells within the connectivity report, and the WTRU may perform recovery actions on the indicated cells (e.g., immediately, within a given time duration from the sending of the report, at a certain time before the time the event is predicted to occur, when the predict event actually happens, etc.). If the WTRU receives a rejection from the network (or does not receive an ACK from the network, e.g., within a certain duration), the WTRU may infer that the WTRU cannot a perform recovery action on the indicated recovery cells indicated within the connectivity change report. If the WTRU indicates another cell (e.g., a cell not included within the connectivity change report), the WTRU may perform recovery actions on the indicated cell (e.g., instead of on a cell indicated within the connectivity change report). If a WTRU receives one or more additional configurations (e.g., for recovery on a cell), the WTRU may apply such configurations to access and / or synchronize with a recovery cell. If the network responds with an indication to access, DL synchronize (e.g., initiate RACH), and / or monitor a channel (e.g., PDCCH) of a second cell, the WTRU may immediately (or upon a time associated with the connectivity change indicated within the connectivity change report) start monitoring on an indicated cell.

[0171] Regarding connectivity change validation and / or recovery, upon prediction and / or detection of a connectivity change, a WTRU may perform additional verification to ensure the connectivity change has occurred. If the connectivity change does occur and the WTRU cannot maintain connection with a first (e.g., serving) cell, the WTRU may attempt recovery on a second (or possible third / additional) cell.

[0172] Mechanisms described herein support connectivity change validation and / or connectivity recovery, including monitoring and / or validation of a connectivity change event, criteria to initiateconnection recovery and / or synchronization via a secondary recovery cell, and / or criteria to initiate connection recovery and / or synchronization on a third / additional cell.

[0173] Regarding validation of connectivity change (e.g., upon prediction of a connectivity change and / or connectivity change event), a WTRU may validate that the connectivity change and / or connectivity change event actually occurs. Whether the WTRU validates the connectivity change may be based on, for example, whether the WTRU has previously reported a connectivity change to the network (e.g., via a connectivity change report). Whether the WTRU validates the connectivity change may also be independent of whether the WTRU has transmitted a connectivity change report.

[0174] Regarding follow-up monitoring for connectivity change, a WTRU may not monitor to validate the connectivity change event. The WTRU may directly trigger recovery actions (e.g., upon detection and / or prediction of a connectivity change event). The WTRU may monitor for a connectivity change subject to a time duration. For example, upon transmission of a connectivity change report (or alternatively upon detection of a connectivity change event), the WTRU may start a timer. The WTRU may monitor for a connectivity change event during this time duration until timer expiry. The WTRU may trigger monitoring for a connectivity change event based on satisfaction of one or more conditions. For example, the one or more conditions may be based on (e.g., satisfied upon) one or more of the following: a prediction that the connectivity change event occur (e.g., an inference that a connectivity change will occur), a transmission of a connectivity change report, a predicted time of a connectivity change, an offset from the predicted time of a connectivity change, an offset from the start of a time duration (e.g., a time window) where the predicted connectivity change is predicted to occur, a start (e.g., commencement) of a predicted time duration (e.g., the start of a time window) where a connectivity change may occur, and / or, a time within a prediction time duration (e.g., within a time window) in which a connectivity change may occur.

[0175] While a WTRU is monitoring for a connectivity change, the WTRU may perform measurements on one or more resources (e.g., SSB, CSI-RS). The WTRU may be configured with dedicated resources for validation of a connectivity change (e.g., within the connectivity change configuration). The WTRU may terminate monitoring for a connectivity change event, for example, based on one or more of the following: reception of a handover command / mobility to another cell, mobility to another cell (e.g., application of an RRC reconfiguration), an indication from the network (e.g., to terminate monitoring for a connectivity change), the RSRP of the cell increasing above a threshold, a current time being past a predicted time of the connectivitychange, a current time being past the end of a time duration (e.g., time window) in which the connectivity change was predicted to occur, activation of an AI / ML functionality / model, and / or deactivation of an AI / ML functionality / model.

[0176] If a WTRU cannot validate a connectivity change and / or has terminated monitoring prior to validating the connectivity change, the WTRU may declare failure to validate the connection (follow-up actions for failure to validate connectivity change are further described herein).

[0177] Regarding validation of connectivity change (e.g., based on the outcome of the connectivity change validation monitoring), a WTRU may declare and / or detect that the reported connectivity change is valid, for example, based on one or more of the following: the predicted / detected connectivity change occurring (e.g., during validation monitoring), the predicted / detected connectivity change or connectivity change event has occurring at a predicted time, and / or the predicted / detected connectivity change or connectivity change event occurring within a predicted time period (e.g., a time window).

[0178] Upon validation of a connectivity change event, the WTRU may perform one or more actions. For instance, the WTRU may report to the network that the connectivity change has occurred, initiate a recovery procedure on a second cell (e.g., attempt RACH, monitor PDCCH, or perform other actions as described herein), attempt connection re-establishment, apply a reconfiguration and / or stored configuration (e.g., a recovery configuration for a recovery cell, RRC reconfiguration), trigger conditional handover (CHO) and / or layer1 / 2 triggered mobility (LTM), change an RRC state (e.g., fall back to RRC INACTIVE / IDLE), and / or initiate a cellsearch procedure.

[0179] The WTRU may determine which of the above actions to performs based on (e.g., dependent on), for example, the configuration (e.g., recovery configuration) of the WTRU, whether the network has approved the connectivity change report (e.g., whether one or more cells indicated within a connectivity change report are suitable for recovery), and / or whether the WTRU has a stored reconfiguration message (e.g., whether the WTRU has a suitable CHO or LTM candidate configuration). The one or more actions the WTRU may perform may depend on the connectivity change event. For example, if the WTRU is predicting a drop in a measurement (e.g., RSRP, RSRQ, SINR), the WTRU may attempt to notify the first (e.g., serving) cell. If the WTRU is predicting / detecting an RLF, the WTRU may instead skip attempting to notify the first cell and instead directly attempt recovery on a second cell.

[0180] Regarding connection recovery on second cell, a WTRU may initiate a recovery procedure on a second cell (e.g., after the detection and / or reporting of a connectivity change). Initiating recovery on a second cell may be defined as attempting to recover, synchronize, and / or continue a connection on a second cell, including transmitting a UL message (e.g., RACH) and expecting a DL response message (e.g., a HO command or RRC reconfiguration message).

[0181] Regarding initiation of connection recovery to a second recovery cell, a WTRU may initiate connection recovery on a second cell, for example, upon prediction and / or validation of a connectivity change on a first (e.g., serving) cell. Whether the WTRU may initiate connection recovery on a second cell may depend on one or more conditions. Conditions for initiating a connection recovery may include (e.g., be satisfied upon), for example, one or more of the following: prior transmission of a connectivity change report (e.g., to a first cell), reaching the time of a predicted connectivity change event, reaching the start of a time period of a connectivity change event, validation of a connectivity change event, reception of a NW indication acknowledging the connectivity change report, acknowledgment from the network that a second cell is suitable for recovery, loss of connection with a first (e.g., serving) cell, one or more measurement quantities (e.g., RSRP / RSRQ / SINR) dropping below a configured threshold, the WTRU not having a suitable stored reconfiguration (e.g., CHO or LTM) and / or triggering conditions associated with a store reconfiguration not being met, the WTRU having a recovery configuration for a second cell, and / or the connectivity change report remaining valid.

[0182] The WTRU may select a second cell on which to perform recovery based on a recovery cell previously indicated within a connectivity change report. In some examples, the WTRU may select this cell, for example, based on one or more conditions. For example, the WTRU may select the second cell based on the network has acknowledging the second cell as a valid recovery cell, the second cell still being suitable for recovery (e.g., measurements for the second cell being above a threshold), and / or the second cell supporting connection recovery (e.g., based on NW indication).

[0183] If a previously indicated second cell is no longer valid as a recovery cell, the WTRU may select a different (e.g., third and / or additional) cell. In one example, the network may provide (e.g., indicate) another recovery cell (e.g., in response to a connectivity change report) and the WTRU may attempt recovery on the provided (e.g., indicated) recover cell. The WTRU may select a different cell indicated within the connectivity change report (e.g., as further describedherein). If no additional cell is available for connection recovery, the WTRU may declare connection recovery failure and / or perform one or more actions as further described herein.

[0184] Regarding DL synchronization and / or WTRU identification, a WTRU may attempt to receive DL signaling from a second recovery cell (e.g., to continue and / or recover the connection lost from the first cell). The WTRU may be provided with configurations, identifiers, and / or resources to identify that the WTRU is attempting recovery on the second cell. The WTRU may be identified as a WTRU initiating the recovery based on use of a dedicated identifier. For example, the WTRU may be configured to access a cell via one or more of the following: a dedicated RACH preamble, a dedicated RNTI, dedicated RACH occasions, a resume and / or establishment cause, and / or dedicated resources (e.g., time period(s), frequency(s)).

[0185] Whether a WTRU may use such resources may be subject to a time period. For example, upon initiation of a connection recovery to a second cell, the WTRU may start a timer. The WTRU may apply one or more related recovery configurations and attempt to synchronize and / or access the second cell while the timer is running. The WTRU may attempt to access the cell for a configured number of attempts. If the WTRU cannot complete DL synchronization and / or receive the DL messaging that may be necessary to continue the connection on the second cell within the number of connection attempts prior to timer expiry, the WTRU may attempt to recovery on a different cell indicated within the connectivity change report (e.g., as further described herein). If no additional cell is available for connection recovery, the WTRU may declare connection recovery failure and perform one or more actions as further described herein.

[0186] Regarding NW response on a second recovery cell, (e.g., upon successful DL synchronization and / or access with a second cell), a WTRU may receive a DL response message on a second cell (e.g., related to the recovery procedure). A WTRU may receive a response via one or more of the following signaling methods: SIB (e.g., a new SI block, or within another existing SIB), NAS, MAC CE, DCI, RACH (e.g., MSG2, MSG4, MSGB), RRC, and / or PDCCH / PUSCH. In an example, the WTRU may first attempt RACH to access and / or DL synchronize with the second cell, and then monitor for a DL response message (e.g., via use of a dedicated RNTI). In another example (e.g., if the WTRU has a valid timing advance (TA) based on estimation and / or pre-provided), the WTRU may directly monitor a PDCCH on the second cell for the DL response message. The WTRU may use a dedicated RNTI to receive such messaging.

[0187] The WTRU may receive one or more of the messages from the second cell. The one or more messages that the WTRU receives from the second cell may include, for example, an HO command (e.g., reconfiguration message) on the second cell, a redirect command to a third cell (e.g., wherein the redirect command may be included in the HO command), and / or a rejection message.

[0188] Depending on which of the or more messages the WTRU receives from the second cell, the WTRU may perform one or more corresponding actions. For example, if the WTRU receives an HO command (e.g., an RRC reconfiguration message), the WTRU may apply the reconfiguration and continue the connection on a second cell. In another example, if the WTRU receives a redirection to a third cell, the WTRU may attempt access (e.g., RACH) and / or DL synchronization with the third cell and may apply the reconfiguration message upon successful access. In another example, if the WTRU receives a rejection message from the third cell, the WTRU may, for example, attempt to recovery on a different cell indicated within the connectivity change report (e.g., as further described herein). If no additional cell is available for connection recovery, the WTRU may declare connection recovery failure and / or perform one or more actions as further described herein.

[0189] Regarding connection recovery on a third / additional cell, a WTRU may attempt connection recovery on a third cell (e.g., if recovery on a second cell was unsuccessful) and / or one or more additional cells. The additional cells may have been identified by the WTRU during the connectivity change report and / or may have been approved and / or acknowledged by the network as possible candidate cells for recovery.

[0190] Regarding initiation of connection recovery on a third / additional cell, a WTRU may initiate a recovery on a third / additional cell. Whether the WTRU may attempt recovery on one or more additional / third cells may depend on, for example, whether the WTRU is configured to support connectivity attempt on an additional cell, whether a cell (e.g., of the one or more additional / third cells) has been previously reported within a connectivity change report as a potential recovery candidate, whether the WTRU has one or more configurations (e.g., one or more resources and / or identifiers) to access and / or synchronize with the cell (e.g., of the one or more additional / third cells), and / or whether the cell (e.g., of the one or more additional / third cells) is still considered a valid and / or suitable cell (e.g., whether the cell supports connection recovery, whether measurement conditions are above a threshold, etc.).

[0191] The WTRU may attempt recovery on a third cell if the WTRU has first failed to recover (e.g., receive a DL recovery message) on a second cell. The WTRU may detect a failure torecover on a second cell, for example, upon expiry of a timer associated with recovery on the second cell.

[0192] Regarding selection of a third / additional cell, the WTRU may be provided (e.g., by the network) with a third and / or additional cell on which to attempt connection recovery. In another example, the WTRU may select a third cell from among a candidate list of cells (e.g., a list of candidate cells). In one example, the WTRU may select a next-highest ranked (e.g., second highest ranked) cell indicated within the connectivity change report. If the WTRU was unable to recover the connection on this cell, the WTRU may then select the next-highest ranked (e.g., third highest ranked) cell indicated within the connectivity change report. In some examples, the WTRU may continue attempting recovery on one or more cells, for example, until one or more of the following conditions are met: recovery has been attempted on a maximum number of cells, the WTRU has received a rejection message from the network, no more additional cells are indicated within the connectivity change report, and / or no more suitable cells are available (e.g., the measurements of one or more cells have fallen below a threshold).

[0193] Upon meeting one or more of the above conditions, the WTRU may declare a connection recovery failure and / or perform one or more of the actions further described herein.

[0194] Regarding synchronization and / or connection recovery on an additional recovery cell, a WTRU may re-use the same dedicated resources and / or identifiers (e.g., provided for accessing the second cell) to access a third / additional cell. For instance, the WTRU may re-use the same dedicated resources and / or identifiers subject to one or more conditions. For example, such conditions may comprise: a condition that is satisfied if the cell has been approved / indicated / acknowledged by the network, a condition that if satisfied if the network has indicated the resources are valid for use on multiple cells, a condition that validity conditions (e.g., associated timer) for use of the recovery resources are still valid, and / or a condition that the cell is part of a same tracking area, PLMN, and / or RAN notification area.

[0195] The WTRU may have a different configuration (e.g., set of configurations / resources / identifiers) to access a third or additional cell. In this case, the resources and / or the WTRU identifier may be associated with a cell ID (e.g., a physical cell identity (PCI)).

[0196] Regarding early termination and / or procedure failure, during a connectivity change report and / or recovery procedure, a WTRU may terminate the connectivity change report and / or recovery procedure prior to completion. In some examples, the WTRU may terminate the procedure because the quality of the connection has changed enough to sufficient to avoid forconnection recovery not to be necessary or because a level of confidence in the prediction is no longer sufficient to be considered reliable. In other examples, the procedure may fail entirely (e.g., if the connectivity change occurs earlier than expected, if recovery actions are not ready etc.). In either case, WTRU synchronization with the network and / or WTRU actions may be used to support connection continuity and recovery.

[0197] Mechanisms described herein may support the early termination and / or failure recovery for a connectivity change prediction / report / recovery procedure, including a declaration of termination / failure, an indication to a network, and / or recovery actions. Regarding early termination of a recovery procedure, a WTRU may terminate a connectivity change reporting and recovery procedure without performing mobility to a second cell. Termination of the connectivity change reporting and / or recovery procedure may occur at any point during the procedure, including prior to reporting, after reporting, and / or during an attempted recovery on a second and / or additional cell.

[0198] Regarding initiation of early termination of a connectivity change and / or reporting procedure, a WTRU may terminate the connectivity change recovery procedure. Termination may occur at any step within the procedure, including prior to prediction / detection of a connectivity change, prior to transmission of a connectivity change report, after transmission of a connectivity change report, and / or during recovery to a second and / or third / additional cell.

[0199] Early termination of a connectivity change procedure may be caused by one or more events, reception of one or more DL messages, and / or a change and / or expiry of validity conditions. Examples of conditions which may cause early termination of the recovery procedure may include, for example, conditions that may be satisfied when one or more of following are true: the RSRP of a serving cell increases, the likelihood of a connectivity change event falls below a threshold, an HO command is received at the WTRU (e.g., an RRC reconfiguration message), and / or an AI / ML model / functionality is deactivated. Upon satisfaction of one or more of the above, the WTRU may declare early termination and / or suspension of the connectivity change recovery procedure.

[0200] Regarding WTRU actions upon early termination of a connectivity change and / reporting procedure, upon declaration of early termination of the connectivity change recovery procedure, a WTRU may perform one or more of the following actions: stopping and / or resetting ongoing timers (e.g., monitoring for validation of connectivity change), releasing one or more resources associated with monitoring for a connectivity change, releasing one or more configurations associated with connectivity change reporting and / or recovery, canceling transmission of aconnectivity change report, and / or aborting a RACH attempt (e.g., to a second and / or third recovery cell).

[0201] The actions which the WTRU may perform upon termination of the procedure may depend on at which step the procedure was terminated. For example, if the WTRU has yet to transmit a connectivity change report, the WTRU may cancel transmission of the connectivity change report. In another example, if the WTRU has transmitted a connectivity change report but has not yet validated the connectivity change event, the WTRU may terminate monitoring for connectivity event validation. In another example, if the WTRU has validated the connectivity change event and is attempting DL synchronization to a recovery cell, the WTRU may abort the RACH attempt on the recovery cell.

[0202] Regarding an indication to the NW that the procedure has been terminated, the WTRU may report that the connectivity change prediction / report / recovery procedure has been terminated. Within the indication, the WTRU may include, for example, one or more of the following pieces of information: an indication (e.g., a flag and / or bit) that the procedure is terminated, a cause for termination (e.g., the RSRP has increased, the prediction accuracy has fallen below a threshold), and / or a level of confidence that a connectivity change will not occur (e g., % likelihood of the change not happening).

[0203] In response to the notification, the network may release configurations associated with the connectivity change report. In another example, the network may instruct the WTRU (or the WTRU may implicitly decide without instruction from the network) to maintain the connectivity change configuration and / or continue monitoring for a connectivity change. In another example, the WTRU may suspend monitoring for a connectivity change until a cause for early termination is addressed (e.g., the AI / ML functionality is activated and / or reactivated, the RSRP drops below a threshold, and / or the probability of a connectivity change event increases above a threshold). In another example, the network may still request the connectivity change report (e.g., with revised prediction probability). In another example, if the WTRU has already initiated the recovery procedure on a second cell, the network may allow the WTRU to continue the connection with the second cell.

[0204] Depending on in which stage of the connectivity recovery procedure the WTRU is, the WTRU may transmit the indication (e.g., that the recovery procedure has been terminated) to the first (e.g., serving) and / or second (e.g., recovery) cell. For example, if the WTRU has not yet initiated a recovery procedure on a second cell, the WTRU may transmit the early termination indication to the first cell. In another example, if the WTRU has already initiated connectionrecovery on a second cell, the WTRU may transmit the early termination indication (e.g., the indication that the recovery procedure has been terminated) to the second cell.

[0205] Regarding failure to complete connectivity change prediction / report / recovery, a WTRU may fail to complete a connectivity change prediction / report / recovery procedure. For instance, the WTRU may fail to complete the connectivity change prediction / report / recovery procedure to ensure that the connection may continue and / or further recovery actions may be triggered to avoid further service interruption. Additional procedures may be defined to address procedure failure.

[0206] Regarding failure to complete connectivity change reporting and / or recovery procedure, a WTRU may fail to complete the connectivity change report and / or recovery procedure. Possible failure cases may include, for example: an RLF happening prior to reporting the RLF report to the network, an RLF report no being received successfully by that network (e.g., HARQ failure), that WTRU not receiving a response on a neighboring cell, the NW not being prepared for the WTRU on a neighboring cell, the WTRU not being able to validate the connectivity change event (e.g., as previously described) the WTRU declaring a failure to validate the connectivity change, no neighbor cells supporting connectivity change prediction / reporting / recovery, and / or there being no suitable neighboring cells. Upon detection of one or more of the above, the WTRU may declare that the connectivity change reporting and / or recovery procedure has failed and / or perform one or more recovery actions.

[0207] A WTRU may perform other actions upon failure to complete connectivity change prediction / reporting / recovery. For instance, the WTRU may perform one or more actions upon declaration of a failure in connectivity change prediction / reporting / recovery. For example, the WTRU may perform one or more of the following actions: releasing one or more configurations associated with connectivity change prediction / reporting / recovery, stopping or suspending timers associated with the connectivity change recovery procedure, terminating ongoing RACH procedures (e.g., on cells associated with the connectivity change reporting and / or recovery procedure), discarding pending connectivity change reports, releasing resources associated with the connectivity change recovery procedure, releasing dedicated RNTI and / or RACH preambles and / or other identifiers associated with the connectivity change recovery procedure, initiating an RRC connection re-establishment procedure, initiating a beam failure recovery procedure, and / or indicating to the network that the connectivity change recovery procedure has failed (e.g., via resume cause and / or dedicated preamble).

[0208] Connection recovery may be accomplished on a second cell based on a predicted connectivity change in a first cell. For example, a WTRU may receive, from a first cell, configuration information associated with the prediction, detection, reporting and / or recovery of a predicted connectivity change event The WTRU may determine (and / or predict) a connectivity change event (e.g., RLF, BFD, a change in a measurement / mobility event) in the first cell and associated time-related (e.g., relative or absolute time, time window) information related to a possible change in the connectivity (e.g., RLF, mobility event). The WTRU may transmit a report using a first set of resources associated with a first connection (e.g., in a first cell), wherein the report may include time-related (e.g., relative and / or absolute time, time window) information related to a possible change in the connectivity (e.g., RLF, mobility event) and / or also information about at least one suitable candidate cell. The time-related information and / or information about the at least one suitable candidate cell may, in some examples, be predicted. The WTRU may receive a follow-up NW response from a first cell for a connectivity change report which may include a recovery configuration for a second cell (e.g., a dedicated RNTI / preamble to identify the WTRU in the second cell). The WTRU may then synchronize and / or decode one or more downlink control channels using resources corresponding to a second reported cell (e.g., no earlier than starting from, or during an associated period of, a time corresponding to the reported time-related information). The WTRU may receive a downlink transmission that may include a reconfiguration message (e.g., with or without mobility control information). In some examples, if the WTRU is unsuccessful in receiving a downlink transmission from a second reported cell (e.g., within a time duration), the WTRU may attempt to synchronize and / or decode one or more downlink control channels using resources corresponding to a third reported cell.

[0209] A predicted RLF may be reported and / or pre-emptive recovery may be accomplished. For example, a WTRU may inform a network regarding the WTRU’s capability to predict RLF (e.g., within a certain time window, within a certain confidence level, etc.). There may be multiple capabilities (e.g., sets of confidence levels and / or prediction windows, e.g., 90% confidence to predict RLF within the next five hundred millisecond, 95% confidence to predict RLF within the next one second, etc.). The WTRU may receive a configuration from the network that contains one or more of the following: a configuration regarding the predictions and / or prediction reports, a configuration regarding cells for recovery, a configuration regarding what to include in the report, a configuration regarding when to start performing the recovery, and / or a configuration regarding on how recovery is performed.

[0210] Regarding a configuration regarding the predictions and / or prediction reports, the configuration may include details such as which WTRU capability to use and when the reporting is to be triggered (e.g., the WTRU may be configured to inform the network when the WTRU predicts an RLF is expected to happen within a certain time duration with a confidence level greater than a certain confidence threshold).

[0211] A configuration regarding cells for recovery may include the best N cells (e.g., top N best cells according to actual measurements available when the RLF prediction report is sent, top N best cells according to predicted measurements of the cells for a time when the RLF is expected to happen, and / or a combination of both — e.g., cells that are in the top N in both actual measurements and predicted measurements). A configuration regarding cells for recovery may include an explicit list of cells for recovery (e.g., as part of the measurement configuration for neighbor cells, e.g., in a way similar to legacy-allowed list configuration in measurement objects). In another example, the WTRU may be configured with information about cells that cannot be used for recovery (e.g., in a way similar to how legacy approaches block list configuration in measurement objects). A configuration regarding cells for recovery may include recovery frequencies (e.g., cells at that frequency layer may be used for recovery), an indication of whether there is more than one recovery cell, and / or an indication of whether to attempt the recovery in parallel, in sequence, or in a combination of in parallel and in sequence. For instance the WTRU may attempt recovery one cell and, if the attempt does not succeed within a given time, may attempt recovery on another cell. If this second attempt at recovery does not succeed within a given time, the WTRU may attempt recovery on yet another cell, and so on. A configuration regarding cells for recovery may include resources on cells to use for recovery, such as a set of preambles to use, a random access channel configuration, and / or a configured grant.

[0212] A configuration regarding what to include in the report may include: a time when an RLF is expected to happen (e.g., an absolute time value, a relative time value, a time value and / or a range index according to a pre-configured index), a confidence interval (e.g., a % confidence, a confidence level index according to a pre-configured confidence level / range index), a list of top N recovery cells (e.g., according to current measurements at the time of an RLF prediction report, predicted measurements at the time when an RLF is expected to happen, etc.,), and / or measurements of the recovery cells indicated in the report (e.g., actual measurements, predicted measurements at the time when RLF is anticipated to happen, etc.).

[0213] Configuration regarding when to start performing the recovery may include an indication to start immediately after the sending of the RLF prediction report, an indication to start after an acknowledgement of the reception of the recovery report (e.g., lower layer ACK indicating the report is received by the network, an indication to start after an explicit message indicating the reception of the report from the network, etc.), an indication to start after a certain time duration from the sending of the report and / or the reception of the acknowledgement from the network elapses, an indication to start upon arrival of a time that is a certain time duration before the anticipated time of the RLF (e.g., X milliseconds before the RLF is predicted to happen), and / or an indication to start when RLF is detected.

[0214] A configuration regarding how recovery may be performed may include an indication to monitor a PDCCH of one or more of the recovery cells. The monitoring may involve using a C- RNTI that was used in the serving cell and / or an RNTI different from the C-RNTI that was used in the serving cell (e.g., if WTRU was configured with an RNTI to use on recovery for each recovery cell and / or a common RNTI to use on recovery for all recovery cells, etc.). A configuration regarding how recovery may be performed may include an indication that the monitoring may be WTRU-specific and / or common. Common monitoring may involve using a common CORSET configuration (e.g., in the MIB of the recovery cell). In WTRU-specific monitoring, the WTRU may be provided with a CORSET configuration to use on the recovery cell. A configuration regarding how recovery may be performed may include an indication that a recovery message received in a paging message (e.g., when a common PDCCH monitoring is used) and / or in a WTRU-specific message (e g., an RRC reconfiguration message).

[0215] The WTRU may perform the RLF prediction and / or send the report when (e.g., upon satisfaction of a condition that) the reporting conditions are fulfilled. The WTRU may perform recovery according to the received recovery message at one of the recovery cells.

[0216] Some of the configurations discussed above (e.g., on how recovery is performed, when recovery is initiated, etc.,) may be part of a specification instead of a WTRU-specific configuration. In some examples, the behavior may be standardized, but there may be a WTRU- specific (parameter) configuration (e.g., a specification indicating that the WTRU initiates the recovery a certain time duration before the anticipated time of the RLF, but the time duration may be configured on a per-WTRU basis).

[0217] In one example, a WTRU may be configured to resort to legacy RLF recovery (e.g., RRC re-establishment) if recovery was not achieved via one of the recovery cells (e.g., within acertain duration after the sending of the RLF prediction report, when the RLF is detected, a certain time duration after the RLF has actually been detected, etc.).

[0218] In one example, a WTRU may be configured to wait for a certain time duration for a response (e.g., reconfiguration) from the network via the source cell after the sending of the RLF prediction report, and may attempt recovery via one of the recovery cells if the WTRU has not received such a response within that time duration (and / or if the predicted RLF actually happens before the WTRU has received a message from the network via the source cell).

[0219] In one example, if a WTRU has started performing a recovery (e.g., monitoring the PDCCH of one of the recovery cells) and the RLF does not occur at the anticipated time (or within a certain time duration after the anticipated time), the WTRU may stop performing the recovery and / or send an indication to the network instead to indicate that the anticipated RLF did not occur.

[0220] In one example, a WTRU may keep performing RLM monitoring and / or RLF detection on a source cell even after the WTRU has finished the recovery via one of the recovery cells, and if the RLF is not detected at the anticipated time (or within a certain time duration after the anticipated time), the WTRU may send an indication to the network to indicate that the anticipated RLF did not occur.

[0221] In one example, a WTRU may perform an early UL synchronization to one or more of the recovery cells upon sending an RLF prediction report (e.g., immediately upon sending the report, a certain time duration after sending the report, etc.). The WTRU may be pre-configured with the configuration for the UL synchronization (e.g., RACH preambles, RACH occasions, etc.).

[0222] In one example, a WTRU may be configured with an RRC configuration (e.g., CHO (conditional handover), LTM-like configurations) associated with one or more of the recovery cells, but these configurations may initially be dormant and / or inactive (e.g., the WTRU may store the configurations, but may refrain from monitoring triggering conditions for the CHO / LTM). Upon sending an RLF report (e.g., predicted RLF report), the WTRU may activate these CHO / LTM configurations. The WTRU may be configured to execute the CHO / LTM configuration upon fulfillment of radio conditions (e.g., as in legacy CHO / LTM) and / or if additional conditions are fulfilled (e.g., reception of a message from the source cell indicating a recovery cell, a reception of an indication from one of the recovery cells — e.g., a paging message, a MAC CE, DCI, etc.)

[0223] In one example, a WTRU may receive an indication from one of the recovery cells indicating the WTRU may perform the recovery in the recovery cell that sent the indication (e.g., an RRC reconfiguration message that is not encrypted / integrity protected containing an indication, a MAC CE message, DCI, a paging message, etc.) and the WTRU may apply and / or execute an RRC reconfiguration that is associated with that recovery cell (e.g., the WTRU may have been pre-configured with a CHO-like configuration and / or LTM-like configuration for one or more of the recovery cells).

[0224] In one example, a WTRU may keep using a current security context to decrypt and / or integrity verify an RRC reconfiguration message received from a target cell. In that RRC reconfiguration, there may be a security update (e.g., in a reconfiguration WithSync information element (IE)) indicating to the WTRU that a security key update is to be performed. The WTRU may apply the security update according to that configuration. The WTRU may use the newly derived security keys (e.g., indicated by and / or resulting from the security key update) for future communications with the target cell (including an RRC reconfiguration complete message to be sent as a response to the received RRC reconfiguration message).

[0225] In one example, the WTRU, upon performing a recovery towards a certain recovery cell, may already update the security context and / or use the updated security keys to decrypt and / or integrity verify the RRC reconfiguration message received from the target cell. For example, the WTRU may be pre-configured with some parameters (e.g., next hop chaining count, key set change indicator, etc.) and perform the security update using these parameters before decoding the RRC reconfiguration message from the recovery cell (e.g., target cell). In one example, these parameters may be specific to each recovery cell (e.g., in RRC reconfiguration messages that are specific to each recovery cell). In another example, the WTRU may be provided with a single set of parameters and use that single set of parameters regardless of from which recovery cell the message is received.

[0226] FIG. 3 provides an example schematic diagram 300 of various example descriptions regarding supporting connectivity change reporting and / or recovery described herein. The WTRU capability communication 302 is shown in dotted lines because the network may receive the WTRU capability information from the core network or the WTRU capability information may be transferred to the source cell 312 during a handover (e.g., the WTRU 310 may not have directly sent the WTRU capability information to the source cell). Some further explanation of the messages exchanged during the recovery process 320 are provided below.

[0227] The message 322 (Msg x.0) may comprise one or more of the following types of messages: a paging message, an RRC message (e.g., RRC setup, RRC Resume, RRC reestablishment, RRC reconfiguration, etc.), a MAC CE, and / or a DCI.

[0228] The message 324 (Msg x.1) may be sent in response to the reception of the message 322 (Msg x.0) (e.g., only if paging is received, only if an RRC message is received, etc.) or the message 324 (Msg x.1) may be sent even without the reception of the message 322 (Msg x.0). The message 324 (Msg x.1) may comprise any of the following: a random access preamble (if the WTRU 310 was not in UL sync with the recovery cell, for example) and / or an RRC message (e.g., RRC setup request, RRC reestablishment request, RRC resume request, etc.). If the message 322 (msg x.0) was not received or if the message 322 (msg x.0) was not an RRC message, the message 324 (Msg x.1) may comprise an RRC complete message (RRC setup complete, RRC resume complete, RRC re-establishment complete, RRC reconfiguration complete, etc.,), if message 322 (msg x.0) was an RRC message, the message 324 (Msg x.1) may comprise an MAC CE and / or UCI.

[0229] If the WTRU 310 already has a UL sync with the recovery cell 314 (e.g., the WTRU 310 has performed early sync according to some of the examples above, the network has indicated the source cell 312 and recovery cell 314 are co-located, for example, by configuring them with the same timing advance group, etc.), a RACH procedure may not be required.

[0230] The message 326 (Msg x.2) may be a response from the network to the message 324 (Msg x.1). The message 326 (Msg x.2) may comprise any of the types of messages in the following examples. For instance, if the message 324 (Msg x.1) comprised a random access preamble, the message 326 (Msg x.2) may comprise a random access response. If the message 324 (Msg x.1) comprised an RRC (Request) message, the message 326 (Msg x.2) may comprise an RRC message (e.g., RRC resume if the message 324 comprised an RRC resume request message, etc.). If the message 324 (Msg x.1) comprised an RRC complete message, the message 326 (Msg x.2) may not have to be sent or may comprise a further reconfiguration message, a MAC CE, and / or DCI.

[0231] The message 328 (Msg x.3) may comprise a response from the WTRU 310 to the message 326 (Msg x.2). The message 328 (Msg x.3) may comprise any of the types of messages in the following examples. If the message 326 (Msg x.2) comprised a random access response message 328 (Msg x.3) may comprise an RRC (request) message (e.g., RRC resume request). If the message 326 (Msg x.2) comprised an RRC message, the message 328 (Msg x.3) may comprise an RRC complete message, MAC CE, and / or UCI.

[0232] The message 330 (Msg x.4) may comprise a response from the network to the message 328 (Msg x.3). The message 330 (Msg x.4) may comprise any of the types of messages in the following examples. If the message 328 (Msg x.3) comprised an RRC (Request) message, the message 330 (Msg x.4) may comprise an RRC message (e.g., RRC resume). If the message 328 (Msg x.3) comprised an RRC complete message, the message 330 (Msg x.4) may not have to be sent or may comprise a further RRC message (e.g., RRC reconfiguration message), MAC CE, and / or DCI.

[0233] The message 332 (Msg x.5) may comprise a response from the WTRU 310 to the message 330 (Msg x.4). The message 332 (Msg x.5) may comprise any of the types of messages in the following examples. If the message 330 (Msg x.4) comprised an RRC message (e.g., RRC resume, RRC reconfiguration, etc.), the message 332 (Msg x.5) may comprise an RRC complete message (e.g., RRC resume complete, RRC reconfiguration complete, etc.). If the message 330 (Msg x.4) did not comprise an RRC complete message, the message 332 (Msg x.5) may not have to be sent (e.g., if the message 328 (Msg x.3) comprised an RRC reconfiguration complete message) or the message 332 (Msg x.5) may comprise an MAC CE and / or UCI.

[0234] In some cases, a further message may be used after the message 332 (Msg x.5) for further reconfiguration of the WTRU before the WTRU may fully function in the recovery cell 314 (e.g., configuration of security, bearers, etc.).

[0235] It should be noted that, unlike in legacy approaches, it may be possible for the WTRU 310 to send a certain RRC request message, but receive an RRC message different from the RRC message that was requested. For example, the WTRU 310 may send an RRC reestablishment request message (e.g., as in legacy approaches) upon RLF detection and / or earlier before the RLF occurrence based on the prediction according to any of the examples above. However, in response to that RRC re-establishment request message, the recovery cell 314 may respond with an RRC resume and / or RRC reconfiguration message (e.g., if the recovery cell 314 already has the WTRU context information). Similarly, the WTRU 310 may send an RRC resume request message, but may receive an RRC re-establishment message instead.

[0236] Also, as shown above, unlike in the legacy approach, the WTRU 310 may not have to send a request message (e.g., RRC Setup Request, RRC Resume Request, RRC reestablishment Request, etc.) before the WTRU 310 may receive the corresponding RRC message (e.g., RRC Setup, RRC Resume, RRC re-establishment, etc.).

Claims

CLAIMS:

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive, from a first cell, configuration information associated with connectivity change prediction, the configuration information indicating an artificial-intelligence or machine-learning (AI / ML) model to be used at the WTRU for connectivity change prediction; determine, via the AI / ML model and based on one or more measurements, that a connectivity change event is predicted to occur within a time window; and send a report via resources associated with a first cell, the report comprising at least one of time-related information indicating the time window or information indicating at least one candidate cell for potential connection recovery.

2. The WTRU of claim 1 , wherein the processor is configured to: receive a downlink control channel transmission via resources associated with the at least one candidate cell; receive a reconfiguration message from the at least one candidate cell; and recover a connection based on the reconfiguration message.

3. The WTRU of claim 1 , wherein the report comprises the time-related information, and wherein the time-related information comprises at least one of: an indication of a time when the connectivity change event is predicted to occur, wherein the time window comprises the time; or an indication of a start time and an indication of an end time, wherein the start time and the end time indicate the time window.

4. The WTRU of claim 1 , wherein the processor is further configured to: receive a response message from the first cell, wherein the response message comprises a recovery configuration for the at least one candidate cell.

5. The WTRU of claim 1 , wherein the connectivity change event comprises at least one of a radio link failure (RLF), a beam failure detection (BFD), a measurement event, a mobility event, excess transmissions of a radio link control (RLC) message, excess transmissions of a hybrid automatic repeat request (HARQ), excess transmissions of a random channel access (RACH) preamble, or a layer-2 (L2) failure.

6. The WTRU of claim 1, wherein the configuration information associated with connectivity change prediction indicates one or more prediction evaluation criteria, and wherein the processor is further configured to: evaluate whether the one or more prediction evaluation criteria are satisfied based on the one or more measurements and the determination that the connectivity change event is predicted to occur; and send the report in response to a determination that the one or more prediction evaluation criteria are satisfied.

7. The WTRU of claim 6, wherein the one or more prediction evaluation criteria comprise at least one of: a criterion that is satisfied when a difference between an actual measurement and a predicted measurement does not exceed a threshold difference; a criterion that is satisfied when a number of predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of predicted measurements; a criterion that is satisfied when a number of consecutive predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of consecutive predicted measurements; or a criterion that is satisfied when a percentage of predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold percentage of predicted measurements.

8. The WTRU of claim 1, wherein the configuration information associated with connectivity change prediction indicates one or more triggering conditions, and wherein the processor is further configured to: evaluate whether the one or more triggering conditions are satisfied; and send the report in response to a determination that the one or more triggering conditions are satisfied.

9. The WTRU of claim 8, wherein the one or more triggering conditions comprise at least one of: a condition that is satisfied when a request for a connectivity change report is received;a condition that is satisfied when one or more connectivity change events are detected; a condition that is satisfied when one or more connectivity change events of a specific type are detected; a condition that is satisfied when a mobility event is detected; a condition that is satisfied when a connection to a recovery cell is established; a condition that is satisfied when a candidate cell is added to a set of candidate cells for potential connection recovery; a condition that is satisfied when a candidate cell is removed from a set of candidate cells for potential connection recovery; a condition that is satisfied when a prioritization for a candidate cell is changed; a condition that is satisfied when a determined confidence level associated with connectivity change prediction is not less than a threshold confidence level; or a condition that is satisfied when a negative acknowledgment is received from a network.

10. The WTRU of claim 1 , wherein the at least one candidate cell comprises a plurality of candidate cells, and wherein the processor is further configured to: rank candidate cells in the plurality of candidate cells based on one or more signal quality values associated with the plurality of candidate cells; identify a highest-ranked candidate cell of the plurality of candidate cells; and synchronize and decode at least one downlink control channel using resources associated with the highest-ranked candidate cell.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a first cell, configuration information associated with connectivity change prediction, the configuration information indicating an artificial-intelligence or machine-learning (AI / ML) model to be used at the WTRU for connectivity change prediction; determining, via the AI / ML model and based on one or more measurements, that a connectivity change event is predicted to occur within a time window; and sending a report via resources associated with a first cell, the report comprising at least one of time-related information indicating the time window or information indicating at least one candidate cell for potential connection recovery.

12. The method of claim 11, further comprising:receiving a downlink control channel transmission via resources associated with the at least one candidate cell; receiving a reconfiguration message from the at least one candidate cell; and recovering a connection based on the reconfiguration message.

13. The method of claim 11 , wherein the report comprises the time-related information, and wherein the time-related information comprises at least one of: an indication of a time when the connectivity change event is predicted to occur, wherein the time window comprises the time; or an indication of a start time and an indication of an end time, wherein the start time and the end time indicate the time window.

14. The method of claim 11 , further comprising: receiving a response message from the first cell, wherein the response message comprises a recovery configuration for the at least one candidate cell.

15. The method of claim 11, wherein the connectivity change event comprises at least one of a radio link failure (RLF), a beam failure detection (BFD), a measurement event, a mobility event, excess transmissions of a radio link control (RLC) message, excess transmissions of a hybrid automatic repeat request (HARQ), excess transmissions of a random channel access (RACH) preamble, or a layer-2 (L2) failure.

16. The method of claim 11 , wherein the configuration information associated with connectivity change prediction indicates one or more prediction evaluation criteria, and wherein the method further comprises: evaluating whether the one or more prediction evaluation criteria are satisfied based on the one or more measurements and the determination that the connectivity change event is predicted to occur; and sending the report in response to a determination that the one or more prediction evaluation criteria are satisfied.

17. The method of claim 16, wherein the one or more prediction evaluation criteria comprise at least one of:a criterion that is satisfied when a difference between an actual measurement and a predicted measurement does not exceed a threshold difference; a criterion that is satisfied when a number of predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of predicted measurements; a criterion that is satisfied when a number of consecutive predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold number of consecutive predicted measurements; or a criterion that is satisfied when a percentage of predicted measurements that satisfy at least one other criterion of the prediction evaluation criteria is not less than a threshold percentage of predicted measurements.

18. The method of claim 11 , wherein the configuration information associated with connectivity change prediction indicates one or more triggering conditions, and wherein the method further comprises: evaluating whether the one or more triggering conditions are satisfied; and sending the report in response to a determination that the one or more triggering conditions are satisfied.

19. The method of claim 18, wherein the one or more triggering conditions comprise at least one of: a condition that is satisfied when a request for a connectivity change report is received; a condition that is satisfied when one or more connectivity change events are detected; a condition that is satisfied when one or more connectivity change events of a specific type are detected; a condition that is satisfied when a mobility event is detected; a condition that is satisfied when a connection to a recovery cell is established; a condition that is satisfied when a candidate cell is added to a set of candidate cells for potential connection recovery; a condition that is satisfied when a candidate cell is removed from a set of candidate cells for potential connection recovery; a condition that is satisfied when a prioritization for a candidate cell is changed; a condition that is satisfied when a determined confidence level associated with connectivity change prediction is not less than a threshold confidence level; ora condition that is satisfied when a negative acknowledgment is received from a network.

20. The method of claim 11 , wherein the at least one candidate cell comprises a plurality of candidate cells, and wherein the method further comprises: ranking candidate cells in the plurality of candidate cells based on one or more signal quality values associated with the plurality of candidate cells; identifying a highest-ranked candidate cell of the plurality of candidate cells; and synchronizing and decoding at least one downlink control channel using resources associated with the highest-ranked candidate cell.

Images