Preventing RRC reestablishment via RRC recovery

Abstract

The present system and method provides mobility enhancement, network energy saving, RRC re-establishment, and RRC recovery. For example, a WTRU in a connected state is configured to perform an RRC recovery procedure (e.g., provided with a recovery identity, next hop link count, etc. For example, the WTRU is configured to perform a recovery procedure if there is a cell within a certain configured group of cells (e.g., alternative / equivalent cells) that satisfies a condition (e.g., signal level above a certain threshold). For example, a WTRU is provided with parameters (e.g., a new recovery identity, next hop link count, etc.) for subsequent recovery and / or candidate cells (e.g., a new / updated list of alternative / equivalent cells) that may be used for recovery when performing an RRC recovery procedure in connected mode. For example, the WTRU performs an RRC recovery procedure at the alternative / equivalent cell using small data transmission (SDT) resources.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 410,962, filed on September 28, 2022, which is incorporated herein by reference in its entirety as if fully set forth. Background of the Invention

[0003] As described herein, NES is performed by controlling the power level of a serving cell or even turning it off. However, this may have an adverse effect on the performance of the WTRU. For example, if a cell is turned off, multiple WTRUs may detect an RLF and initiate an RRC reconstruction. From the perspective of both the WTRU and the network, this behavior is highly undesirable. For the WTRU, the reconstruction may result in a significant service interruption because most of the WTRU context is released, PDCP / RLC is reconstructed, MAC is reset, etc. For the network, the reconstruction - especially when several WTRUs trigger the reconstruction - may result in high signaling overhead (on the air interface for full re - configuration, and in possible X2 interactions between the source and the target if the WTRU context is to be retrieved to avoid involving the CN). Additionally, when several WTRUs attempt to reconstruct simultaneously, RACH conflicts during the initial access attempt of multiple WTRUs to the (one or more) target cells may further delay the reconstruction and exacerbate the service interruption. Summary of the Invention

[0004] The present system and method provide mobility enhancement, network energy saving, RRC reconstruction, and RRC recovery. For example, a WTRU in a connected state is configured to perform an RRC recovery process (e.g., provided with a recovery identity, a next - hop link count, etc.) when detecting that a trigger condition (such as RLF) is met. For example, the WTRU is configured to perform the recovery process if there is a cell within a certain configured cell group (e.g., an alternative / equivalent cell) that meets a condition (e.g., signal level above a certain threshold). For example, the WTRU is provided with parameters for subsequent recovery (e.g., a new recovery identity, a next - hop link count, etc.) and / or candidate cells (e.g., a new / updated list of alternative / equivalent cells) that can be used for recovery when performing the RRC recovery process in the connected mode. For example, the WTRU uses small data transfer (SDT) resources to perform the RRC recovery process at the alternative / equivalent cell. Brief Description of the Drawings

[0005] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0006] Figure 1Ais a system diagram of an example communication system in which one or more of the disclosed embodiments may be implemented;

[0007] Figure 1B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0008] Figure 1C is a system diagram of an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0009] Figure 1D is a system diagram of an additional example RAN and an additional example CN that may be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0010] Figure 2 illustrates the basic handover process in NR;

[0011] Figure 3 illustrates the configuration and execution of conditional handover;

[0012] Figure 4 illustrates the RLM and RLF detection mechanisms;

[0013] Figure 5 illustrates a high-level overview of the reconstruction process;

[0014] Figure 6 illustrates an example of L1 / 2 inter-cell mobility operation, where the candidate cell group is configured by RRC, and the dynamic transition of the PCell and SCell is implemented using L1 / 2 signaling;

[0015] Figure 7 illustrates an example RRC connection setup process;

[0016] Figure 8 illustrates an example RRC connection setup process;

[0017] Figure 9 illustrates different RRC states and possible transitions;

[0018] Figure 10 illustrates a signaling diagram of a WTRU in the connected state, which is configured to perform an RRC recovery process (e.g., providing a recovery identity, a next-hop link count, etc.) when detecting that a trigger condition (such as RLF) is met;

[0019] Figure 11A signaling diagram of a WTRU in a connected state is shown, the WTRU being configured to perform an RRC recovery procedure (e.g., provided with a recovery identity, a next-hop link count, etc.) when detecting that a triggering condition (such as RLF) is met;

[0020] Figure 12 A signaling diagram of a WTRU in a connected state is shown, the WTRU being configured to perform an RRC recovery procedure (e.g., provided with a recovery identity, a next-hop link count, etc.) when detecting that a triggering condition (such as RLF) is met; and

[0021] Figure 13 A method for performing an RRC recovery procedure according to one aspect is shown. Detailed Description

[0022] A system, method, and apparatus for preventing RRC re - establishment via RRC recovery are described.

[0023] A method performed in a wireless transmit - receive unit (WTRU) includes: receiving configuration information for performing connection recovery when detecting a radio link failure (RLF), the configuration information including at least a candidate cell list and an acceptable threshold signal level of a cell to be used; and when detecting RLF, performing cell selection on candidate cells having a radio condition meeting the threshold among candidate cells included in the candidate cell list, and initiating a connection recovery procedure by sending a connection recovery request message to the network. The method may include receiving in a "connected" state. The information may further include one or more of a WTRU identity to be used during the connection recovery procedure and a security configuration to be applied during the connection recovery procedure. The method may include using a cause value in the connection recovery request, the cause value indicating at least one cause for triggering the connection recovery. The method may include receiving a connection recovery message from the network, the connection recovery message including configuration information. The method may include applying the configuration information. The method may include restoring a connection with the network via a selected candidate cell. The method may include sending a connection recovery complete message to the network. The connection recovery complete message indicates that the WTRU has restored the connection. The method may include performing a re - establishment procedure if no cell meeting the threshold is included in the candidate cell list. The method may include determining that a radio condition of one of the candidate cells from the candidate cell list meets the threshold.

[0024] A wireless transmit / receive unit (WTRU) includes a processor and a transceiver communicatively coupled to the processor. The processor and the transceiver operate to: receive configuration information for performing connection recovery upon detection of a radio link failure (RLF), the configuration information including at least a list of candidate cells and an acceptable threshold signal level for a cell to be used; and upon detection of an RLF, perform cell selection to a candidate cell having a radio condition meeting the threshold among candidate cells included in the candidate cell list, and initiate a connection recovery procedure by sending a connection recovery request message to the network. The reception can be in a "connected" state. The information can further include one or more of a WTRU identity to be used during the connection recovery procedure and a security configuration to be applied during the connection recovery procedure. The processor and the transceiver can further operate to include a cause value in the connection recovery request, the cause value indicating at least one cause that triggered the connection recovery. The processor and the transceiver further operate to: receive a connection recovery message from the network, the connection recovery message including configuration information; apply the configuration information; and restore connection with the network via the selected candidate cell. The processor and the transceiver can further operate to send a connection recovery complete message to the network. The connection recovery complete message indicates that the WTRU has restored the connection. If no cell meeting the threshold is included in the candidate cell list, the processor and the transceiver can further operate to perform a re-establishment procedure. The processor and the transceiver can further operate to determine that a radio condition of one of the candidate cells from the candidate cell list meets the threshold.

[0025] Figure 1A FIG. is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to a plurality of wireless users. The communication system 100 may enable the plurality of wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and the like.

[0026] As Figure 1AAs shown in FIG. 0, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d—any one of which may be referred to as a station (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 phone, a personal digital assistant (PDA), a smartphone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, and the like. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0027] The communication system 100 may further include base stations 114a and / or base stations 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, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a home Node B, a home eNode B, a next-generation NodeB (such as a gNode B (gNB)), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. Although 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.

[0028] Base station 114a may be part of RAN 104, and RAN 104 may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base station 114a and / or 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 cells (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 wireless services to a specific geographical area, which may be relatively fixed or may vary over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0029] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, and air interface 116 may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

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

[0031] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA) which may establish an air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro.

[0032] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access which may establish an air interface 116 using NR.

[0033] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface used 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., eNBs and gNBs).

[0034] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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.

[0035] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as a commercial premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0036] The RAN 104 can communicate with the CN 106, which can 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 can have different quality of service (QoS) requirements such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although not shown in Figure 1A the figure, it will be appreciated that the RAN 104 and / or the CN 106 can communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that may utilize the NR radio technology, the CN 106 can also communicate with another RAN (not shown) employing a GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0039] Figure 1B is a system diagram of an illustrative example of the WTRU 102. As Figure 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0040] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it will be appreciated that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0043] The transceiver 120 can be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs (such as NR and IEEE802.11), for example.

[0044] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from: the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in: any type of suitable memory (such as non-removable memory 130 and / or 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: a memory that is not physically located on the WTRU 102 (such as a server or a home computer (not shown)).

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

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

[0047] The processor 118 can be further coupled to other peripheral devices 138, which can include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 can include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, a frequency modulation (FM) radio unit, a digital music player, a media player, an electronic game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral devices 138 can include one or more sensors. The sensors can be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, an attitude sensor, a biosensor, a humidity sensor, and the like.

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

[0049] Figure 1C is a system diagram of an illustrative RAN 104 and CN 106 according to one embodiment. As described above, the RAN 104 can communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 can also communicate with the CN 106.

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

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

[0052] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although 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.

[0053] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via the S1 interface and may act 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 the initial attachment of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide control plane functions for interworking between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

[0055] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0056] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 can include or communicate with the following: 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 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0058] In a representative embodiment, another network 112 can be a WLAN.

[0059] In an infrastructure basic service set (BSS) mode, a WLAN can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access to or interface with a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic destined for an STA from outside the BSS can reach the STA through the AP and can be delivered to the STA. Traffic originating from an STA to a destination outside the BSS can be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within the BSS can be sent through the AP, where the source STA can send the traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between the source STA and the destination STA using direct link setup (DLS) (e.g., directly between the source STA and the destination STA). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "ad hoc" communication mode in this document.

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

[0061] High throughput (HT) STAs can communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0062] A very high throughput (VHT) STA can support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non - adjacent 80 MHz channels - which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser, which can split the data into two streams. The inverse fast Fourier transform (IFFT) processing and time - domain processing can be performed separately on each stream. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0063] 802.11af and 802.11ah support operation modes below 1 GHz. Relative to the operation modes used in 802.11n and 802.11ac, the channel operation bandwidth and carrier are reduced in 802.11af and 802.11ah. 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 can support metering - type control / machine - type communication (MTC), such as MTC devices in a macro - coverage area. MTC devices can have certain capabilities (e.g., limited capabilities), which include supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices can include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0064] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In an example of 802.11ah, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC type device), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy, for example, due to an STA (which only supports the 1MHz operating mode) transmitting to the AP, then all available frequency bands can be considered busy, even if most of the available frequency bands remain idle.

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

[0066] Figure 1D is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

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

[0068] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may use subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., which contain different numbers of OFDM symbols and / or last for different lengths of absolute time) to communicate with the gNBs 180a, 180b, 180c.

[0069] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in stand-alone configuration and / or non-stand-alone configuration. In stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also being connected to another RAN (e.g., such as eNode-Bs 160a, 160b, 160c). In stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor. In stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate / connect with gNBs 180a, 180b, 180c while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In non-stand-alone configuration, eNode-Bs 160a, 160b, 160c can act as the mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

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

[0071] Figure 1DThe CN 106 shown in the figure 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 data networks (DN) 185a, 185b. Although 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.

[0072] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may be used as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing in order to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service the WTRUs 102a, 102b, 102c are utilizing. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and the like. The AMF 182a, 182b may provide control plane functions for interworking between the RAN 104 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.

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

[0074] UPF 184a and 184b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface, which can provide access to a packet switched network (such as the Internet 110) for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPFs 184a and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0075] CN 106 can facilitate communication with other networks. For example, CN 106 can include or communicate with the following: an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and the PSTN 108. Additionally, CN 106 can provide access to other networks 112 for WTRUs 102a, 102b, and 102c, where the other networks 112 can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0076] In view of Figures 1A - 1D and Figures 1A - 1D the corresponding descriptions, one or more or all of the functions described herein with respect to one or more of WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). The emulation device(s) can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device(s) can be used to test other devices and / or simulate network and / or WTRU functions.

[0077] A simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For the purpose of testing and / or performing tests using over-the-air wireless communication, the simulation device can be directly coupled to another device.

[0078] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in test scenarios in a test laboratory and / or a non-deployed (e.g., test) wired and / or wireless communication network in order to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas).

[0079] Figure 2 Illustrated is a basic handover process 200 in NR. In process 200, a WTRU 205, a base station such as a source gNB 215, a base station such as a target gNB 225, an AMF 235, and one or more UPFs 245 communicate. Process 200 includes three main parts, which include handover preparation 210, handover execution 250, and handover completion 290.

[0080] Handover preparation 210 includes mobility control information provided by the AMF 235 at 202. The mobility control information can be provided to the source gNB 215 and the target gNB 225. The WTRU 205 connection within the source gNB 215 contains information regarding roaming and access restrictions, which is provided at connection establishment or at the last TA (Timing Advance) update.

[0081] Measurement and control reports are provided at 204 between the WTRU 205 and the source gNB 215. The source gNB 215 configures the WTRU 205 measurement process, and the WTRU 205 reports according to the measurement configuration.

[0082] At 206, a handover decision is made. The source gNB 215 decides to hand over the WTRU 205 based on the measurement results received at 204.

[0083] At 208, a handover is requested. The source gNB 215 sends a handover request message to the target gNB 225 at 208. The handover request message may carry a transparent RRC container with the necessary information to prepare the handover on the target side. The necessary information may at least include the target cell ID, KgNB*, the C-RNTI of the WTRU 205 in the source gNB 215, the RRM configuration including the WTRU inactive time, the basic AS configuration including antenna information and DL carrier frequency, the current QoS flow to DRB mapping rules applied to the WTRU 205, the SIB1 from the source gNB 215, the capabilities of the WTRU 205 for different RATs, PDU session related information, and may include the measurement information reported by the WTRU 205 (including beam related information if available).

[0084] Admission control is provided at 212. For example, the admission control may be performed by the target gNB 225.

[0085] At 214, the handover request is confirmed from the target gNB 225 to the source gNB 215. If the WTRU 205 can be admitted, the target gNB 225 prepares the handover with L1 / L2 and sends a "Handover Request Acknowledge" 214 to the source gNB 215, which includes a transparent container to be sent to the WTRU 205 as an RRC message to perform the handover.

[0086] The handover execution 250 includes the RAN initiating the handover at 216. The source gNB 215 may trigger the Uu handover by sending an RRC reconfiguration message to the WTRU 205. The RRC reconfiguration message may contain the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifier for the selected security algorithm. The RRC reconfiguration message may include a set of dedicated RACH resources, the association between the RACH resources and one or more SSBs, the association between the RACH resources and one or more UE-specific CSI-RS configurations, common RACH resources, and the system information of the target cell, etc. Essentially, the source gNB 215 delivers buffered data and new data from the first UPF, and the WTRU 205 detaches from the old cell (source gNB 215) and synchronizes to the new cell (target gNB 225). At 218, an early state transfer occurs.

[0087] The source gNB 215 sends a "SN Status Transfer" message to the target gNB 225 at 222 to convey the uplink PDCP SN receiver state and the downlink PDCP SN transmitter state of the DRB (i.e., RLC AM) to which the PDCP state retention applies.

[0088] At 224, the handover is complete and handover complete 290 occurs. At 226, the WTRU 205 synchronizes with the target gNB 225 and completes the RRC handover procedure by sending an RRC reconfiguration complete message to the target gNB 225. At 228, an SN status transfer occurs.

[0089] The target gNB 225 sends a "Path Switch Request" message to the AMF 235 at 232 to trigger the 5GC to switch the DL data path towards the target gNB 225 and establish an NG-C interface instance towards the target gNB 225 at 234.

[0090] The 5GC switches the DL data path towards the target gNB 225. The UPF 245 sends one or more "End Marker" packets on the old path to the source gNB 215 for each PDU session / tunnel and then releases any U-plane / TNL resources to the source gNB 215.

[0091] The AMF 235 acknowledges the "Path Switch Request" message at 232 with a "Path Switch Request Acknowledge" message at 236.

[0092] Upon receiving the "Path Switch Request Acknowledge" message from the AMF 235, the target gNB 225 sends a "WTRU Context Release" at 238 to notify the source gNB 215 that the handover was successful. The source gNB 215 may release radio and C-plane related resources associated with the WTRU 205. Any ongoing data forwarding may continue.

[0093] In NR, there are conditional HO and CPC. Conditional handover (CHO) and conditional PSCell addition / change (CPA / CPC, or collectively CPAC) are designed to reduce the likelihood of radio link failure (RLF) and handover failure (HOF). Traditional LTE / NR handovers are typically triggered by measurement reports, even if nothing prevents the network from sending a HO command to the WTRU 205, even in the absence of a received measurement report. For example, the WTRU 205 is configured with an A3 event, and in the case of dual connectivity (DC), when the radio signal level / quality (RSRP, RSRQ, etc.) of an adjacent cell becomes better than that of the primary serving cell (PCell) or also the primary-secondary serving cell (PSCell), this A3 event triggers the sending of a measurement report. The WTRU 205 monitors the serving cell and adjacent cells and sends a measurement report when the conditions are met. When such a report is received, the network (current serving node / cell) prepares a HO command (basically an RRC reconfiguration message with reconfiguration WithSync) and sends it to the WTRU 205. The WTRU 205 executes the HO command, which causes the WTRU 205 to connect to the target gNB 225.

[0094] CHO differs from traditional handovers in two main aspects. First, multiple handover targets are prepared (as compared to only one target in the traditional case), and second, the WTRU 205 does not execute the CHO immediately as in the case of traditional handovers. Instead, the WTRU 205 can be configured with trigger conditions for a set of radio conditions, and the WTRU 205 can perform a handover to one of the targets only when / only if the trigger conditions are met.

[0095] When the radio conditions towards the current serving cell are still favorable, a CHO command can be sent, thus reducing the two main failure points in traditional handovers, namely, the risk of not being able to send a measurement report (e.g., if the link quality to the current serving cell is below an acceptable level when a measurement report is triggered in a normal handover) and the risk of not being able to receive a handover command (e.g., if the link quality to the current serving cell is below an acceptable level after the WTRU 205 has sent a measurement report but before it has received a HO command).

[0096] The triggering conditions for CHO can be based on the radio quality of the serving cell and neighboring cells, such as the conditions used to trigger measurement reports in traditional NR / LTE. For example, the WTRU 205 can be configured with a CHO having an A3 class triggering condition and an associated HO command. The WTRU 205 can monitor when the current cell and serving cell and the A3 triggering condition are met. The WTRU 205 can execute the associated HO command and transition its connection towards the target gNB 225 instead of sending a measurement report.

[0097] Another advantage of CHO is that it helps prevent unnecessary reconstructions in the case of radio link failure. For example, assume that the WTRU is configured with multiple CHO targets and the WTRU experiences an RLF before the triggering conditions for any of the targets are met. Traditional operation would have caused an RRC reconstruction procedure, which would have caused a relatively long interruption time for the WTRU bearers. However, in the case of CHO, if the WTRU ends its cell with an associated CHO after detecting the RLF (i.e., the target cell is ready for it), the WTRU can directly execute the HO command associated with that target cell instead of proceeding with the full reconstruction procedure.

[0098] Figure 3 Illustrated is conditional handover configuration and execution 300. Conditional handover configuration and execution 300 includes a WTRU 305, a source node 315, and a potential target node 325. At 302, the source node 315 provides a CHO request to the potential target node 325. At 304, the potential target node 325 provides a CHO request ACK to the source node 315. The CHO request ACK can be in the form of an RRC reconfiguration as described herein.

[0099] The source node 315 can provide a CHO configuration to the WTRU 305 at 306. The CHO configuration can include conditions such as A3 / A5 events plus the RRC reconfiguration described herein. At 308, the WTRU 305 can monitor the CHO conditions for target cell 325 candidates. At 312, if the conditions are met, the WTRU 305 executes the HO. The WTRU 305 provides a CHO confirmation to the target node 325 at 314. At 316, path transition and WTRU context release can occur to complete the handover.

[0100] CPC and CPA are just extensions of CHO, but in the DC scenario. The WTRU 305 can be configured with triggering conditions for PSCell change or addition, and when the triggering conditions are met, the WTRU 305 can execute the associated PSCell change or PSCell addition command.

[0101] Radio link monitoring and radio link failure detection can be performed. A WTRU in RRC_CONNECTED can continuously monitor the radio link to ensure that the link is good / reliable enough for communication, and this process is called radio link monitoring (RLM). The WTRU can monitor the downlink (DL) quality based on the reference signals being broadcast from the serving cell. In the case where the WTRU is operating in single connection, the WTRU can perform RLM on the primary cell (PCell). In the case where the WTRU is operating in dual connection (DC), the WTRU can perform RLM on both the PCell and the primary cell of the secondary cell group (SCG) (which is referred to as the PSCell).

[0102] The WTRU can be configured with RLM reference signals (RLM-RS) for monitoring in order to determine the radio quality of the PCell (and PSCell, in the case of DC). The network can configure the WTRU to perform RLM based on SSB (synchronization signal block), CSI-RS (channel state information-reference signal), or a combination of both.

[0103] Figure 4 The following RLM and RLF detection mechanism 400 is illustrated. The WTRU can be configured with thresholds to determine whether the monitored radio link is good / reliable enough. Specifically: Qout and Qin. Qout is the level at which the DL cannot be received reliably and should correspond to the out-of-sync block error rate (BLERout), which is a 10% block error rate for an assumed PDCCH transmission. Qin is the level at which the DL can be received significantly more reliably than Qout and should correspond to the in-sync block error rate (BLERin), which is a 2% block error rate for an assumed PDCCH transmission.

[0104] The WTRU may be configured with timers and counters for determining the reliability of a monitored link, specifically: n310, n311, t310, and t311. n310 refers to the consecutive number of out-of-sync indications received by the RRC from a lower layer (e.g., the PHY) before the RRC starts to consider that the monitored link is experiencing reliability problems. n311 refers to the consecutive number of in-sync indications received by the RRC from a lower layer (e.g., the PHY) before the RRC considers that the monitored link has become reliable again. t310 is the duration of a timer that starts when the RRC receives n310 consecutive out-of-sync indications from a lower layer and stops when the RRC receives n311 consecutive in-sync indications. The timer defines how long the WTRU should attempt to recover (re-acquire synchronization) of the radio link on the current cell (after detecting out-of-sync). t311 refers to the duration of a timer that starts when t310 expires and stops when the WTRU selects a suitable cell. The timer defines how long the WTRU should attempt to search for another cell to re-establish an RRC connection after a radio link failure and before declaring an RRC connection failure. If the T310 timer expires before the RRC receives n311 consecutive in-sync indications from a lower layer, the RRC may consider the link to have failed and declare an RLF (Radio Link Failure).

[0105] The WTRU may use another timer (T312) to detect RLF, which is associated with a measurement report. The measurement report configuration may be associated with t312. When the reporting conditions are met and a measurement report is to be sent, and if the measurement report configuration has been associated with t312, the WTRU may check whether t310 is already running (i.e., RLM has identified a problem and is waiting for recovery). If so, the WTRU starts the t312 timer with the duration set to the configured t312, and if the problem is not resolved before the timer expires, the WTRU also declares an RLF. Basically, t312 is used to detect late HO (i.e., a measurement report has been sent earlier than the start of the radio link problem and the WTRU will likely switch to the target cell in time).

[0106] Specifically, in Figure 4 RLM 410 may include normal operation 415. Normal operation 415 may occur until the SINR < Qout (420), at which point a radio problem is detected at 425. When the SINR < Qout N310 times (430), the RLF timer T310 is initiated at 435. When the SINR > Qin less than N311 times (440), reconstruction and MCG failure recovery occur at 445.

[0107] In Figure 4In [the figure], RRM 450 may include measurements 455 that occur before the measurement report condition (460) is satisfied. When the measurement report condition is satisfied (46), a TTT occurs at 465 until the measurement report is triggered at 470 while T310 is running. At this point, the short RLF timer T312 starts at 475. When SINR > Qin is less than N311 times (440), reconstruction and MCG failure recovery occur at 485.

[0108] In addition to the described RLM and RLF detection mechanisms, there are other situations where RRC considers an RLF. In one example, RRC considers an RLF when there is a random access problem indication from the MAC (e.g., when the WTRU does not receive a random access response (RAR) after transmitting a random access preamble to the network a specific number of times). In one example, when an indication from the RLC indicates that the maximum retransmission count has been reached, RRC considers an RLF. In one example, when a backhaul (BH) RLF indication is received on a backhaul adaptation protocol (BAP) entity (i.e., the link between the IAB node and the network has failed), RRC considers the RLF (if connected) for an integrated access backhaul (IAB) node. In one example, when operating in unlicensed mode, RRC considers an RLF when there is a coherent uplink LBT (listen before talk) failure indication from the MAC.

[0109] Figure 5 The figure illustrates a high-level overview of the reconstruction process 500. The WTRU 505, source gNB 515, and target gNB 525 are included. When an RLF is detected, for any of the reasons described above, at 502, the WTRU 505 may perform an RRC reconstruction to recover the radio link. In addition to RLF, there are several triggers for the WTRU 505 to trigger a reconstruction, such as when reconfiguring in case of a synchronization failure with the target cell during HO, when there is an HO failure from NR to another RAT, when there is an integrity check failure of CP data (e.g., data received via SRB1 or SRB2), and when there is an RRC connection reconfiguration failure (e.g., the WTRU is unable to compile / execute the received RRC reconfiguration file).

[0110] During the reconstruction process, the WTRU 505 may perform several functions at 504. One function is to reset the MAC. Another function is to release the WTRU configuration / context (including security configuration). The WTRU 505 may perform cell reselection (i.e., select the cell with the best radio quality that the WTRU 505 can measure at that time). The WTRU 505 may apply the default configuration and send an RRC reconstruction request message to the network at 506. This message may be sent to the target gNB 525. The message may include information such as the identity of the WTRU 505 (e.g., C-RNTI) at the source cell where the reconstruction was triggered, the PCI of the source cell, security integrity information derived from the security configuration used at the source cell, the reason for the reconstruction (e.g., RLF, integrity verification failure, reconfiguration failure, etc.).

[0111] The target gNB 525 may perform WTRU security verification at 512. The target gNB 525 (via the network) may use the security information included in the reconstruction request to verify that the request is from a legitimate WTRU and use the provided WTRU identity and source cell identity to restore the most recent WTRU context / configuration (e.g., if the WTRU is reconstructing at a target cell different from the source cell and the target cell is served by a gNB different from the gNB serving the source cell, the target gNB may request WTRU context / configuration information from the source). Once the target gNB 525 performs this security verification at 512, the target gNB 525 may send an RRC reconstruction message to the WTRU 505 at 514. The RRC reconstruction message may include information for the WTRU 505 to update the security context. The WTRU 505 may send an RRC reconstruction complete message at 516. At 518, the connection may be restored (e.g., security has been updated, SRB1 is operational, etc.).

[0112] SRB1 may be operational, and the target gNB 525 may send an RRC reconfiguration message to the WTRU 505 at 522 to complete the restoration (e.g., provide a new WTRU identity, set up bearers, configure measurements, etc.). The configuration of the WTRU identity, bearers, measurements, etc. may be the same as the configuration used in the source cell before the reconstruction was triggered, or it may be different (e.g., another WTRU at the target is already using that identity, not all bearers may be admissible at the target, some measurement configurations may have to be modified due to the capabilities / configurations of the target). Once complete, the WTRU 505 may be fully operational at 526, where the bearers and measurements are configured as described.

[0113] If the WTRU 505 is configured with conditional reconfiguration, the WTRU 505 may perform a slightly enhanced reconstruction process. The WTRU 505 may not release its context / configuration at the start of the reconstruction process, but may determine whether the cell reselection process has resulted in the selection of a cell that is the target of a CHO (i.e., the WTRU has stored a CHO for that target and the target has been prepared for the UE). If so, there is no need to continue the reconstruction process, and the WTRU 505 only performs the associated CHO command.

[0114] It should be noted that the reconstruction process may not be successful for several reasons. For example, if the WTRU 505 is unable to perform cell reselection within a given time (e.g., the timer T311 that starts when the WTRU 505 begins the cell reselection process expires before the WTRU 505 has found a suitable cell to reconstruct to), the WTRU 505 may be able to find a suitable cell, but the cell becomes unsuitable before the reconstruction process is complete, or the WTRU 505 does not receive a reconstruction message from the network within a given time after sending a reconstruction request (e.g., the timer T301, which starts when the WTRU 505 sends a reconstruction request and expires before receiving a reconstruction order from the network). In these cases, the WTRU 505 may be forced into the RRC_IDLE mode and may trigger a recovery from scratch via connection setup by the WTRU 505, which is an even longer process than reconstruction because there is no RAN-level context acquisition and the CN must be involved in setting / configuring the bearers. If the WTRU context is not retrieved correctly when receiving a reconstruction request, a similar recovery from scratch is performed (this time triggered by the network).

[0115] As discussed herein, the WTRU 505 may be configured with several timer values and counters that are used in the detection and recovery of radio link problems. The WTRU 505 may be provided with timer and counter configurations in a dedicated (i.e., WTRU-specific) or broadcast manner (i.e., cell-specific). The information element (IE) RLF-TimersAndConstants may be used to configure WTRU-specific timers and constants and may be included in the primary serving cell configuration (for the PCell and, if the WTRU is operating in DC, also for the PSCell). The RLF-TimersAndConstants information element and the RLF-TimersAndConstants fields are described below.

[0116]

[0117]

[0118] The IE WTRU-TimersAndConstants is included in SIB1 and contains timers and constants used by the WTRU in RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE (which includes additional timers for other purposes). The WTRU TimersAndConstants information element is provided below.

[0119]

[0120] If the WTRU 505 is equipped with RLF-TimersAndConstants, the timers / counters configured therein may override the timers / counters broadcast in SIB1 in WTRU-TimersAndConstants.

[0121] Figure 6 An example of L1 / 2 inter-cell mobility operation is illustrated, where the candidate cell group is configured by RRC, and the dynamic transition of the PCell and SCell is implemented using L1 / 2 signaling. In the CA case, inter-cell L1 / 2 mobility can be used to manage beams, but cell change / addition is not supported. The objective of WI "Additional NR Mobility Enhancements" is to specify the mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency.

[0122] To specify the mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency: configuration and maintenance of multiple candidate cells to allow for rapid application of candidate cell configurations [RAN2, RAN3]; dynamic transition mechanism between candidate serving cells (including SpCell and SCell) for potential applicable scenarios based on L1 / L2 signaling [RAN2, RAN1]; L1 enhancements for inter-cell beam management, including L1 measurement and reporting, and beam indication [RAN1, RAN2], where early RAN2 participation is necessary, including the possibility of further clarifying the interaction between this bullet point and the previous bullet point; timing advance management [RAN1, RAN2]; and CU-DU interface signaling to support L1 / L2 mobility if needed [RAN3]. FR2-specific enhancements are not excluded if any. The procedures for L1 / L2-based inter-cell mobility apply to the following scenarios: stand-alone, CA, and NR-DC cases where the serving cell changes within a CG; intra-DU cases and inter-DU cases within the CU (applicable to stand-alone and CA: no new RAN interfaces are expected); both intra-frequency and inter-frequency; both FR1 and FR2; the source and target cells can be synchronous or asynchronous; and inter-CU cases are not included.

[0123] L1 / L2-based mobility provides and inter-cell beam management addresses scenarios within a DU and within a frequency. In this case, the serving cell remains the same (i.e., it is not possible to use L1 / 2-based mobility to change the serving cell). In FR2 deployments, CA is typically used to utilize the available bandwidth, e.g., to aggregate multiple CCs in one frequency band. These CCs are typically transmitted using the same analog beam pair (gNB beam and WTRU beam). The WTRU is configured with TCI states (which can be a fairly large number, e.g., 64) for receiving PDCCH and PDSCH. Each TCI state includes an RS or an SSB, and the WTRU sets its beam with reference to it. For R17, the SSB can be associated with a non-serving PCI. MAC signaling (“TCI state indication for WTRU-specific PDCCH MAC CE”) activates the TCI state for the core set / PDCCH. The MAC CE indicating the TCI state associated with the non-serving PCI enables the reception of PDCCH from the non-serving cell. MAC signaling (“TCI state activation / deactivation for UE-specific PDSCH”) activates (at most) a subset of 8 TCI states for PDSCH reception. The DCI indicates which one of the 8 TCI states. R17 also supports “unified TCI states” with (DCI-based) different update mechanisms, but without multi-TRP. R18 will support unified TCI states with multi-TRP.

[0124] The overall objective of L1 / 2 inter-cell mobility is to improve handover latency; for traditional L3 handovers or conditional handovers, the WTRU can typically first send a measurement report using RRC signaling. In response to this, the network can provide additional measurement configurations and potentially conditional handover configurations. For traditional handovers, after the WTRU reports using RRC signaling that a cell meets the configured radio quality criteria, the network provides the configuration for the target cell. For conditional handovers, in order to reduce the handover failure rate due to the delay in sending the measurement report and then receiving the RRC reconfiguration, the network pre-provides the target cell configuration and the measurement criteria for determining when the WTRU can trigger the CHO configuration. However, due to the sending of the measurement report and the reception of the target configuration, both of these L3 methods can suffer a certain amount of delay, especially in the case of regular (unconditional) handovers.

[0125] In particular, the objective of L1 / 2-based inter-cell mobility is to allow for the rapid application of the configuration of candidate cells, including dynamic transitions between SCell and role transitions of the PCell (e.g., switching roles between SCell and PCell), without performing RRC signaling. The case between CUs may require repositioning the PDCP anchor. Therefore, at least an RRC-based method is required to support inter-CU handovers. One of the purposes of L1 / 2 may be to allow for the immediate enabling of CA operations when the serving cell changes.

[0126] Figure 6 An example L1 / 2 inter-cell mobility 600 using CA is illustrated. Specifically, in the example L1 / 2 inter-cell mobility 600, cell 16101 operates at 3.5 GHz, cell 26102 operates at 2.1 GHz, cell 36103 operates at 26 GHz, and cell 46104 operates at 26 GHz (collectively referred to as cells 610). The WTRU 605 is moving through cells 610. During the movement of the WTRU 605, L1 / 2 signaling (within the CU) for Scell activation / deactivation that may change can occur. A CHO (within the CU or between CUs) for PCell handover can occur. Updates can be provided for a set of L1 / 2 candidates.

[0127] For example, at the first location of the WTRU 605, Pcell 16101 and SCell 26102 can be configured instead of cell 36103 and cell 46104. The RRC initially configures cells 1 - 4 as candidates and activates Pcell 16101 and SCell 26102. At the second location of the WTRU 605, Pcell 16101 and SCell 36103 can be configured instead of cell 26102 and cell 46104. When the WTRU 605 moves to the third location, a dynamic SCell handover may occur between cell 26102 and cell 36103, leaving the connection as Pcell 16101 and SCell 26102 instead of cell 36103 and cell 46104. When the WTRU 605 moves to the fourth location, a dynamic handover may occur where the PCell hands over to cell 26102 and the SCell hands over to cell 46104.

[0128] Network energy consumption can be significant and in some cases unnecessary (e.g., during quiet periods). The network can turn off small cells and rely on macro cells for coverage during quiet periods, completely turn off some sectors or gNBs, reduce PA power consumption, and / or enable the gNB - side sleep mode without significantly sacrificing WTRU performance. The gNB combines information including WTRU measurements, WTRU - assisted information, interference status, load information, and proprietary information to make this decision.

[0129] One enhancement is the introduction of the NES state (also known as the network availability state). The WTRU can determine whether it can transmit or receive on certain resources depending on the network availability state, which implies a power saving state of the gNB. The availability state can be determined by the WTRU or indicated by the network. The availability state can be, for example, "on", "off", "sleep", "microsleep", or "deep sleep". This state can be abstracted by NW configuration parameters and / or values. The "off" availability state may mean that the baseband hardware of the gNB is completely turned off. The "sleep" availability state may mean that the gNB wakes up periodically to transmit certain signals (e.g., presence signals) or receive certain UL signals. In some availability states, some DL or UL resources are unavailable during a specific time period, and this enables the network to turn off baseband processing and other activities. Some measurement resources (e.g., SSB or CSI-RS) may be available only in certain availability states.

[0130] Under certain conditions, the WTRU can further transmit a request (wake-up request) to the network to modify the availability state to a state where resources that will satisfy the WTRU requirements are available. Such a wake-up request can include a transmission that can be decoded by a low-complexity receiver at the gNB, for which the energy consumption requirements are minimal. In this document, wake-up request, wake-on request, or wake-on WTRU assistance information can be used interchangeably. In certain availability states (e.g., "microsleep" or "deep sleep"), the wake-up request can be specifically used and can refer to a physical uplink signal transmitted by the WTRU to request a change in the availability state. The physical layer design of the wake-up request signal is elaborated. Additionally, the wake-on request can be a physical layer or L2 indication from the WTRU to the network, which can be delivered as MAC CE, UCI, RRC signaling, PUCCH, or RACH indication, and can include wake-on WTRU assistance information and / or positioning reports.

[0131] The WTRU can determine the availability state by receiving an availability state indication from, for example, L1 / L2 signaling, or can implicitly determine the availability state by receiving periodic DL signaling (or aperiodic DL signaling). If the resources are applicable for the active availability state, the WTRU can determine whether the resources are available for transmission / reception for the determined network availability state.

[0132] The availability state can apply to at least one resource. The availability state can apply to at least one time period, such as a time slot or a time symbol. The availability state can apply to a serving cell, a cell group, a frequency band, a bandwidth part, a frequency range within the bandwidth part.

[0133] NES status change indication can indicate an upcoming / immediate change, or may carry timing information (e.g., the NES status will change to the indicated status after a certain duration or at a specific absolute time).

[0134] In NR, a WTRU can be in one of three RRC states: RRC_CONNECTED (also known as "connected mode"); RRC_INACTIVE (also known as "inactive mode"); and RRC_IDLE (also known as "idle mode").

[0135] In RRC_CONNECTED, the WTRU is actively connected to the network, where signaling and data radio bearers are established (SRB and DRB), and it is capable of receiving downlink (DL) data from the network in unicast and also capable of sending uplink (UL) data to the network. The mobility of the WTRU from one cell / node to another is controlled by the network. The network can configure the WTRU to send measurement reports periodically or when certain conditions are met (e.g., an adjacent cell becomes better than the serving cell by more than a certain threshold), and based on these reports, the network can send a handover command to the WTRU to move it to another cell / node. The network can also be configured with conditional handover (CHO), where when certain conditions are met, the WTRU executes a pre-configured handover command instead of sending measurement reports. The network can also send a HO command to the WTRU without receiving any measurement reports (e.g., based on the implementation, such as the determination of the current location).

[0136] Keeping the WTRU in the connected mode is power-intensive for the WTRU (e.g., the WTRU needs to continuously monitor the PDCCH of the serving cell, e.g., for determining the arrival of DL data, for UL data scheduling, etc.), and a specific cell / gNB can accommodate a specific number of WTRUs in the connected mode (e.g., due to resource limitations). As such, when there is no activity in the UL or DL for a certain duration (e.g., based on an inactivity timer maintained at the network), the network can send the WTRU to the RRC_INACTIVE or RRC_IDLE state.

[0137] If the network expects the WTRU to become active for a long duration, the network may send the WTRU to the RRC_IDLE state. When in RRC_IDLE, the WTRU camps on the best cell (the cell with the best signal level at the highest priority RAT and at the highest priority frequency within that RAT), which will help the WTRU establish a connection via that cell in case there is a need for the WTRU to transition back to the connected state. More details of the cell reselection process to ensure the WTRU always camps on the best cell are provided herein. The WTRU may monitor the downlink paging channel to detect the arrival of DL data. If the WTRU detects a paging indicating the arrival of DL data from the network, or if the WTRU needs to send UL data, it may initiate a connection setup / establishment process.

[0138] During connection setup or restoration, before sending an RRC setup request or an RRC restoration request message, the WTRU may perform a random access (RA) process (also referred to in this disclosure as a random access channel RACH process). The RA process serves two main purposes: obtaining UL synchronization between the WTRU and the network (e.g., gNB); and obtaining resources that will be used to send the request message.

[0139] During the RA process, the WTRU may send a message containing a preamble and an RA-RNTI (random access - radio network temporary identifier) on the RACH (referred to as msg1) to the gNB. In the case of contention-based random access (CBRA), the preamble is randomly selected from a set of possible preamble values (i.e., there may be contention if another WTRU initiates a random access process using the same preamble value). In the case of contention-free random access (CFRA), a specific preamble is provided to the WTRU in advance (e.g., when the WTRU is in the connected state, during the transition to the idle / inactive state, etc.). The RA-RNTI is calculated based on the PRACH (physical RACH) occasion on which the random access message will be sent to the network.

[0140] The gNB responds with msg2 containing a Random Access Response (RAR) upon receiving msg1. To enable the WTRU to obtain the RAR, the network may send a DCI (Downlink Control Indicator) scrambled with the RA-RNTI in the PDCCH, which the WTRU uses to determine on which resources (i.e., time and frequency) the RAR (and other relevant information) will be provided to the WTRU. The WTRU attempts to detect this DCI within a period of time (referred to as the RAR window) after transmitting the preamble. If such a DCI is not received, the WTRU may retransmit the preamble again. If the DCI is received, the WTRU may obtain the RAR at the time and frequency resources indicated in the PDSCH. In the RAR and associated information, a Timing Advance (TA) may be provided to the WTRU for use in transmitting UL data, a TC-RNTI (Temporary Cell RNTI), and UL resources for transmitting setup / resume request messages.

[0141] The WTRU may obtain detailed information / configurations regarding the use of the random access channel, such as RACH occasions, random access response windows, etc., via dedicated configuration when in the connected state, during transitions in the idle / inactive state, or from the System Information Broadcast (SIB).

[0142] Figure 7 and Figure 8 The figures illustrate the RRC connection establishment / setup and connection resume procedures. The RA procedure is not shown in these figures. The term msg3 is used to refer to the RRC resume request or the RRC setup request. The term msg4 is used to refer to the RRC resume or the RRC setup. The term msg5 is used to refer to the RRC resume complete or the RRC setup complete. If the WTRU resumes the connection in the same gNB, messages 2, 3, and 6 to 9 may not be required, and accordingly, the WTRU may resume without involving the Core Network (CN).

[0143] As described below Figure 7 and Figure 8 As shown in the above description and the following description, the RRC connection setup procedure is a lengthy procedure that requires several round-trip times to complete and involves the CN. This is because when the WTRU enters the idle mode, the RRC context of the WTRU is released, and accordingly, the WTRU is unknown at the RAN layer, and the RAN must obtain the WTRU context from the CN. In addition, after this, security must be re-established, and the WTRU must be reconfigured with DRBs and SRBs before UL / DL data transmission / reception can occur.

[0144] Such a long setup process is not compatible with low-latency services, and thus NR has introduced an intermediate state between the connected and idle states, called the inactive state. This state has most of the power-saving advantages of the idle state (e.g., the WTRU does not need to continuously monitor the PDCCH, which is one of the most power-consuming processes in the connected state), but at the same time, the RAN maintains the RRC / security context of the WTRU. When it is necessary to transition the WTRU to the connected mode (e.g., due to the arrival of UL data or the reception of a paging indicating the arrival of DL data), the connection can be restored very quickly without involving the CN, reconstructing the WTRU's security context, and reconfiguring the bearers.

[0145] Figure 7 An example RRC connection setup process 700 is illustrated. In process 700, the WTRU 705 communicates via the gNB 715 (also referred to as the base station) and the AMF 735. At 710, the WTRU 705 may be in the RRC_IDLE CM-IDLE mode. At 702, the WTRU 705 sends an RRC setup request message to the gNB 715. At 704, the gNB 715 may provide an RRC setup message to the WTRU 705.

[0146] At 720, the WTRU 705 may be in the RRC-CONNECTED CM-IDLE mode. At 706, the WTRU 705 may send an RRC setup complete message to the gNB 715. At 708, the gNB 715 may signal the AMF 735 with an initial WTRU message. At 712, the AMF 735 may provide a downlink NAS transport to the gNB 715.

[0147] At 730, the WTRU 705 may be in the RRC_CONNECTED CM-CONNECTED state. At 714, the gNB 715 may signal the WTRU 705 for DL information transfer. At 716, the WTRU 705 may signal the gNB 715 for UL information transfer.

[0148] At 712, the gNB 715 may signal the AMF 735 with an uplink NAS transport. At 722, the AMF 735 may signal the gNB 715 for an initial context setup request.

[0149] The gNB 715 and the WTRU 705 signal back and forth regarding security and reconfiguration. For example, at 724, the gNB 715 signals a security mode command to the WTRU 705. At 726, the WTRU 705 signals security mode complete to the gNB 715. At 728, the gNB 715 signals an RRC reconfiguration to the WTRU 705. At 732, the WTRU 705 signals RRC reconfiguration complete to the gNB 715.

[0150] Figure 8 An example RRC connection setup procedure 800 is illustrated. In procedure 800, the WTRU 805 communicates via the gNB 815 (also referred to as the base station), the last serving gNB 825, and the AMF 835. At 810, the WTRU 805 may be in the RRC_INACTIVE CM-CONNECTED mode. At 802, the WTRU 805 sends an RRC resume request message to the gNB 815.

[0151] At 804, the gNB 815 signals a retrieve WTRU context request to the last serving gNB 825. At 806, the last serving gNB 825 may signal a retrieve WTRU context response to the gNB 815. At 808, the gNB 815 provides an RRC resume message to the WTRU 805. The WTRU 805 enters the RRC-CONNECTED CM-CONNECTED state 820.

[0152] At 812, the WTRU 805 sends an RRC resume complete message to the gNB 815. At 814, the gNB 815 provides an Xn-U address indication message to the last serving gNB 825. At 816, the gNB 815 signals a path switch request to the AMF 835. At 818, the AMF 835 provides a path switch request response to the gNB 815. At 822, the gNB 815 provides a WTRU context release message to the last serving gNB 825.

[0153] Figure 9 Different RRC states and transitions that may occur in depiction 900 are illustrated. One state is the NR RRC_CONNECTED state 910. From the RRC_CONNECTED state 910, a resume / release with a suspend transition 905 can occur to enter the NR RRC_INACTIVE state 920. The resume / release with a suspend transition 905 can operate to transition from the RRC_INACTIVE state 920 to the RRC_CONNECTED state 910.

[0154] From the RRC_INACTIVE state 920, a release transition 915 may occur to enter the NR RRC_IDLE state 930.

[0155] From the RRC_CONNECTED state 910, an establishment / release transition 925 may occur to move to the RRC_IDLE state 930. The establishment / release transition 925 may operate to transition from the RRC_IDLE state 930 to the RRC_CONNECTED state 910.

[0156] When the WTRU performs a connection setup / establishment or resume procedure, it includes (in the RRC setup request or RRC resume request) an establishment or resume cause. Currently, the following causes are defined.

[0157]

[0158] For example, if the connection is being set up / resumed due to a voice call or video call originating from the WTRU, the WTRU may set the establishment / resume cause to mo-VoiceCall (mobile-originated voice call) or mo-VideoCall (mobile-originated video call). As another example, if the connection is being set up / resumed due to a downlink paging indicating DL data, the WTRU may set the establishment / resume cause to one of mt-Access (mobile terminal access), highPriorityAccess, mps-PriorityAccess, or mcs-PriorityAccess (depending on the access category of the WTRU).

[0159] When the WTRU is sent to the inactive state 920, the network may include suspendConfig in the RRC release message. SuspendConfig contains the following information. This information may include the resume identities (short identity, shortI-RNTI, and long identity, full-RNTI) to be used by the WTRU. The WTRU may determine which identity to use based on the system information broadcast in the target cell (e.g., use the long identity if useFullResumeID is indicated in the SIB, otherwise use the short identity). This information may include the RAN paging area (e.g., a list of cells), which is the RAN area where the WTRU can be paged at the RAN level. If the WTRU performs a cell reselection to a cell outside the RAN area, the WTRU performs a RAN area update procedure. This information may include the nextHopChaining count, which is used to derive the security context (e.g., encryption / integrity protection keys) when resuming the connection.

[0160] As described herein, NES is performed by controlling the power level of, or even shutting down, the serving cell. However, this may have an adverse impact on the performance of the WTRU. For example, if a cell is shut down, multiple WTRUs may detect an RLF and initiate an RRC reconstruction. From the perspective of both the WTRU and the network, this behavior is highly undesirable. For the WTRU, the reconstruction may result in a significant service interruption as most of the WTRU context is released, the PDCP / RLC is reconstructed, the MAC is reset, etc. For the network, the reconstruction - especially when several WTRUs trigger the reconstruction - may result in a high signaling overhead (in the air interface for a complete reconfiguration, as well as in a possible X2 interaction between the source and the target if the WTRU context is to be retrieved to avoid involving the CN). Additionally, when several WTRUs attempt to reconstruct simultaneously, RACH collisions during the initial access attempt of the multiple WTRUs to the (one or more) target cells may further delay the reconstruction and exacerbate the service interruption.

[0161] In the context of L1 / L2 mobility, the WTRU may be configured with several candidate cells, some of which belong to the same CU or even to the same DU, where the WTRU can easily perform a handover using L1 / L2 signaling. If the WTRU experiences an RLF, it may be excessive to perform a reconstruction and cause a service interruption when there are cells to which the WTRU can easily handover. As discussed herein, CHO remedies some of the problems (e.g., if the WTRU selects a cell that has been configured for CHO after an RLF, then perform CHO instead of performing a reconstruction). However, CHO will require resource reservation at the target cell / node. Specifically, in scenarios such as network energy saving, it may not be feasible to achieve shutting down a cell without causing a large number of WTRUs to reconstruct by configuring CHO (e.g., there may not be enough resources that can be allocated / reserved for CHO without affecting the WTRUs in the target cell).

[0162] Another scenario similar to the NES scenario is the integrated access and backhaul (IAB) or U2N SL relay case, where multiple WTRUs may be served via a single IAB node or SL relay WTRU. If there is a backhaul link failure between the IAB node or relay WTRU and the gNB, the WTRUs served by the IAB node or relay WTRU may trigger a reconstruction, experience a significant service degradation, and also cause a large amount of network signaling overhead.

[0163] From the perspective of the WTRU and the network, reconstruction - especially in scenarios where several WTRUs trigger reconstruction simultaneously - is highly undesirable. In one solution, a WTRU in RRC_CONNECTED can be configured to trigger an RRC connection restoration procedure when one or more trigger conditions are met, such as: detecting an RLF; when the serving and / or neighbor cells meet the absolute and / or relative thresholds of the serving and / or neighbor cells; when receiving an L1 / L2 mobility indication; the WTRU has not transmitted a previous restoration request with the same MAC-I, I-RNTI, or C-RNTI, possibly to the same network node that received it (e.g., to prevent replay attacks); when detecting that the serving cell has changed or is about to change its NES state; and so on. The WTRU can be configured with a subset of NES states, and when determining that the serving cell has changed to one of these states, the WTRU can consider the condition to be met.

[0164] In one solution, a WTRU in the RRC_CONNECTED state 910 can be configured to trigger an RRC connection restoration procedure on a different cell (e.g., an equivalent cell) (or for a different cell (e.g., an equivalent cell)) when or after detecting BFD on the serving cell (e.g., SpCell), which may be conditional on at least one of the following: measuring at least one beam, where the measured channel condition is higher than a threshold (e.g., Qin); measuring an L3 channel measurement value higher than a threshold and / or higher than that of the serving cell; not measuring any beam with a channel measurement higher than the threshold (including CSI-RS and SSB) on the serving cell (e.g., SpCell); measuring a beam with at least a minimum number of beams having a quality higher than the threshold on an adjacent cell; not performing BFR or BFR-RA on the serving cell; and / or the BFR timer on the SpCell has expired.

[0165] In one solution, the WTRU can be configured with a recovery identity to be used during an RRC connection restoration initiated based on any of the above trigger conditions.

[0166] In one solution, the WTRU can be configured with security-related configurations (e.g., nextHopChaining count) for deriving a security context during the restoration process.

[0167] In one solution, the WTRU can be configured with a list of alternative / equivalent cells to which the WTRU can perform an RRC connection restoration when in RRC_CONNECTED. For example, this can be a list of cell identities (e.g., PCI, CGI, tracking area, etc.).

[0168] The replacement or equivalent cell list may include one or more of the following: candidate cells configured for L1 / L2 mobility; cells configured for CA (e.g., SCell); cells configured for DC (e.g., PSCell, SCG SCell, etc.); and cells that are neither the serving cell nor a mobility candidate cell.

[0169] In one solution, for example, the replacement cell list may be provided explicitly via system information and / or via RRC signaling (e.g., within a previous RRC release and / or a release with a suspension indication). In another example, a cell ID list may be provided via a MAC CE. The MAC CE may indicate the identification information of one or more replacement cells, as well as a flag indicating whether one or more cells are active or deactivated. Alternatively, the WTRU may receive two MAC CEs, one for the active cell list and the other for the deactivated cell list.

[0170] In one solution, replacement cells are implicitly determined by the WTRU to be cells belonging to the same DU or CU. The WTRU may be able to determine from the PCI, PCI range, read CGI, etc. Alternatively, the WTRU may be configured with all cells belonging to the same CU and / or DU and may consider them as replacement cells.

[0171] In one solution, the replacement / equivalent cell list may depend on the current PCell. For example, the WTRU may receive the following configuration: {[PCell = cell x, replacement cells = cells a, b, c], [PCell = cell x, replacement cells = cells a, b, c], etc.}

[0172] In one solution, the WTRU may be configured to trigger an RRC resume to a given cell only if the given cell is configured as a replacement / available cell and is the best cell (e.g., the highest RSRP) that the WTRU can detect.

[0173] In one solution, the WTRU may be configured to trigger an RRC resume to a given cell only if the given cell is configured as a replacement / equivalent cell and its signal level is higher than a specific threshold. If there are several such cells that meet this condition, the WTRU may be configured to select the best cell among them.

[0174] In one solution, the WTRU may be subject to one or more conditions to consider one or more previously indicated cells as valid for RRC resume. For example, the WTRU may consider one or more of the indicated cells as valid for resume for a certain duration after the indication (e.g., the WTRU may start a timer when indicating one or more cells, and when the timer expires, the WTRU no longer considers the cell as valid). In another solution, once the WTRU is triggered and RRC resumes, the WTRU may discard one or more cells previously indicated as valid.

[0175] In one solution, during the RRC resume procedure, the WTRU may be configured to prioritize candidate cells that are also used for L1 / L2 mobility compared to cells that are not candidate cells for L1 / L2 mobility. For example, when deciding which cell the WTRU may initiate RRC resume to, the WTRU may be configured to apply a certain positive offset to the measurement of the candidate cell compared to non-candidate neighbor cells.

[0176] In one solution, during the RRC resume procedure, the WTRU may be configured to prioritize cells that are also serving cells (e.g., SCell, PSCell, SCG SCell, etc.) compared to cells that are not serving cells. For example, when deciding which cell the WTRU may initiate RRC resume to, the WTRU may be configured to apply a certain positive offset to the measurement of the serving cell compared to non-candidate neighboring cells.

[0177] In one solution, the WTRU may be configured to trigger RRC resume to a cell immediately when it determines that the trigger condition for resume is met.

[0178] In one solution, the WTRU may be configured to trigger RRC resume to a cell at a certain time after it determines that the trigger condition for resume is met. For example, if the trigger condition is a change in the NES state and the change in the NES state is indicated / expected to occur after x ms, the WTRU may wait for a specific time (e.g., a random time between 0 and x ms) before triggering RRC resume. This may help prevent a storm of RA requests for a given candidate cell.

[0179] In one solution, the WTRU may be configured to include a resume reason value that indicates which trigger condition caused the start of the resume procedure (e.g., RLF, NES state change, etc.).

[0180] In one solution, the WTRU may be configured to send the most recent measurement results to the target during the recovery procedure (e.g., in the RRC resume complete message). The WTRU may be configured to always include the measurement results, or only include the measurement results if the cell it has resumed to is not the best cell (e.g., there is an alternative cell with a better signal level that is not configured for recovery). For example, this may help the network to immediately handover the WTRU to that cell (e.g., if the difference between the signal levels the WTRU is experiencing at the current serving cell and the unselected best cell is significant, indicating that keeping the WTRU connected to the current serving cell may cause too much interference in the network and may limit the performance the WTRU can achieve).

[0181] In one solution, when in the connected state, the WTRU may receive in the RRC resume command the information that will be used for subsequent RRC resume. This may be information such as the resume identity, the next-hop link count, alternative cells, the trigger conditions for RRC resume, etc. The alternative cells and trigger conditions may be provided in an incremental or fully configured manner (if such information is not received, the WTRU may keep using the same configuration as before).

[0182] In one solution, when T310 is running, e.g., after detecting the N310 out-of-sync indication but before T310 expiration triggers RLF, the WTRU may attempt to perform reconstruction / resumption on either the serving cell or the configured equivalent cells. When T310 expires, the WTRU may attempt to search and reconstruct on any cell (including non-serving cells and non-equivalent cells). In other words, before declaring RLF, the WTRU may attempt to reconstruct on any equivalent cell, not just on the serving cell.

[0183] In one solution, after T310 expiration (RLF) but before T311 (reconstruction) starts, the WTRU may attempt to reconstruct on the equivalent cells. An additional timer may be used to determine the duration for which the WTRU may attempt to reconstruct on the configured equivalent cells before starting T311 and attempting to reconstruct on any cell.

[0184] To prevent replay attacks, if the receiving entity has not received the resumeMAC-I, the WTRU may reuse the resumeMAC-I. Alternatively, the WTRU may transmit another resume request with different input parameters for calculating the resumeMAC-I, including a changed security key, PDCP count, message, direction, and / or bearer. A change in any of the input parameters may be sufficient to generate a different resumeMAC-I to avoid replay attacks.

[0185] To avoid premature recovery at different cells, the WTRU in RRC_CONNECTED can be configured to trigger the RRC connection recovery procedure on (or for) a different cell (e.g., an equivalent cell) conditioned on at least one transition to the NES state in the serving cell, where the DTX period is greater than a configured threshold. The WTRU can be conditioned on the continuous degradation of measurements from the serving cell.

[0186] When any of the above conditions for transmission recovery are met, the WTRU can start a timer before the transmission recovery request. While the timer is running, the WTRU can measure CSI-RS and / or SSB on the serving cell. If the change in the measured SSB and / or CSI-RS (e.g., L3 or L1 RSRP, BLER, and / or SINR) has decreased by more than a predefined or configured tolerance, the WTRU can consider the condition to be met.

[0187] The WTRU can be conditioned on the continuous improvement of measurements from the cell on which the transmission recovery request will be transmitted. The WTRU can start a timer before the transmission recovery request when any of the above conditions for transmission recovery are met. While the timer is running, the WTRU can measure CSI-RS and / or SSB on the target cell. If the change in the measured SSB and / or CSI-RS (e.g., L3 or L1 RSRP, BLER, and / or SINR) has improved by more than a predefined or configured tolerance, the WTRU can consider the condition to be met.

[0188] The WTRU can be conditioned on the expiration of a timer, such as a timer associated with a NES state change (e.g., a timer associated with a signal when the cell is in a dormant / shutdown state) or a mobility-related timer.

[0189] The WTRU can be conditioned on not receiving a response from the serving cell to a wake-up signal transmitted by the WTRU.

[0190] The WTRU can be conditioned on triggering an A3 or A5 event.

[0191] The WTRU can be conditioned on the channel measurement from the serving cell being below a threshold (e.g., L1 or L3, SS-RSRP).

[0192] The WTRU can be conditioned on the channel measurement from the target cell being above a threshold (e.g., L1 or L3, SS-RSRP).

[0193] Even when the WTRU is in the RRC_CONNECTED state, the WTRU can be configured to use a process and configuration similar to that for small data transmission in the RRC_INACTIVE state to transmit an RRC connection recovery message for at least one target cell. This can enable the WTRU to transmit the message with lower latency and may not perform the RACH process. For each cell on which RRC connection recovery may potentially occur, the WTRU can receive at least the following configurations, including: an uplink bandwidth part, which includes PUSCH configuration information, configuration grant information including a retransmission timer, association information between an SSB index and a valid PUSCH occasion (SSB-Subset, SSB-PerCG-PUSCH); power control information (P0, α), DMRS information, a downlink bandwidth part including PDCCH information such as at least one of a core set and a search space, CG-SDT-specific configuration such as a timing alignment timer, timing advance verification information, an RSRP threshold for SSB selection, CS-RNTI, logical channel restriction information (e.g., only SRBs that are allowed to be used for transmission of RRC connection recovery are permitted), a data volume threshold, an RSRP threshold for determining the SDT process, an RSRP threshold for selecting between a normal uplink carrier and a supplementary uplink carrier, and parameters for PUSCH transmission based on random access, such as the number of preambles for each SSB for each shared random access occasion for msg3 or msgA transmission, a PRACH mask index, and a search space. For each target cell on which RRC connection recovery may occur, at least one of the above resources can be configured using the same structure as small data transmission information elements (such as sdt-MAC-PHY-CG-Config and SDT-ConfigCommonSIB).

[0194] For small data transmission, the WTRU can use a process based on the following to perform the transmission message: a configuration-based grant process (CG-SDT) or a random access-based process (RA-SDT). However, at least for the following parameters, the WTRU can utilize information specific to each target cell on which RRC connection recovery may occur (instead of information for the serving cell): SSB information (SSB-PositionsInBurst); UL / DL slot configuration (tdd-UL-DL-ConfigurationCommon); PRACH configuration; and physical cell identity (PCI).

[0195] The WTRU can receive at least a portion of the above configuration via dedicated RRC signaling for each target cell, and / or via the system information of the respective target cell. The WTRU can obtain the system information at the target cell, including sdt-MAC-PHY-CG-Config, before transmitting a recovery request in the target cell. If the target cell is not configured with RA-SDT and / or CG-SDT resources, the WTRU can avoid transmitting a recovery request.

[0196] To distinguish a recovery request transmitted in a target cell from a recovery request for SDT, the WTRU can change or alter the recovery cause associated with the RRC recovery request message. Separate causes (e.g., mobility or handover) can be used to define the UE when transmitting RRC recovery at different cells. The UE can perform this recovery cause change only if SDT resources are used to transmit the RRC recovery message.

[0197] Transmission using the configured grant can occur under the condition that the RSRP of the target cell is higher than a configured threshold (e.g., SDT-rsrp threshold, CG-rsrp threshold, or a different threshold configured for this purpose).

[0198] At least in the following cases, after initiating a CG-SDT procedure in a target cell, the WTRU can fallback to a RACH procedure and / or fallback to the source cell: after transmitting a PUSCH in the target cell, the WTRU does not receive a PDCCH, after transmitting a PUSCH at the target cell, the WTRU does not receive a DL allocation or PDSCH transmission (e.g., DL SDT TB), and / or the WTRU determines a NACK for the payload transmitted on the PUSCH (e.g., by receiving an explicit NACK signal and / or by timer expiration, such as the SDT CG timer, SDT CG retransmission timer, CG timer, or T319a).

[0199] The WTRU can start a timer when transmitting an RRC recovery request message. When the timer expires, the WTRU can fallback to a RACH procedure. When falling back to RACH, the WTRU can prioritize the selection of RA-SDT PRACH resources (if configured). Alternatively or additionally, the WTRU can prioritize the selection of non-SDT RA resources.

[0200] In one method, when the WTRU receives an RRC release from the source cell or the target cell, the WTRU may transmit an RRC resume request at the target cell. The release message may indicate to the WTRU whether to use SDT resources, the target cell index to which the WTRU may transmit the resume request, and / or other relevant transmission configurations included in the RRC release message for SDT. In the absence of an RRC release message, the WTRU may reuse the stored configuration of the SDT that was used when the WTRU last received an RRC message. The WTRU may include its C-RNTI portion in the SDT payload, where the RRC resume is initiated by a handover.

[0201] Figure 10 FIG. illustrates a signaling diagram 1000 of a WTRU 1005 in a connected state 1002, which is configured to perform an RRC resume procedure (e.g., provided with a resume identity, a next-hop link count, etc.) when detecting that a trigger condition (such as RLF) is met. The resume identity, link count, etc. are configurations regarding the information included by the WTRU in the resume request. At 1004, the WTRU 1005 monitors the trigger condition for resume. As discussed herein, the trigger condition may be the receipt of an L1 / L2 mobility indication, the detection of RLF, the serving and / or neighbor cells meeting the absolute and / or relative thresholds of the serving and / or neighbor cells, the WTRU not transmitting a previous resume request with the same MAC-I, I-RNTI, or C-RNTI, possibly to the same network node that received it (e.g., to prevent replay attacks), detecting that the serving cell has changed or is about to change its NES state. For example, the WTRU may be configured with a subset of NES states, and when determining that the serving cell has changed to one of these states, the WTRU may consider the condition to be met.

[0202] At 1006, it is determined whether the condition is met. If it is determined that the condition is not met, then at 1004, the WTRU continues to monitor the trigger condition for resume. If it is determined that the condition is met, then at 1008, it is determined (e.g., after RLF detection) whether the currently selected cell is one of the alternative cells. If it is determined that the currently selected cell is not one of the alternative cells, then a reconstruction may be performed at 1012. If it is determined that the currently selected cell is one of the alternative cells, then at 1014, an RRC resume request (plus a new resume reason) is provided from the WTRU 1005 to the network 1095. At 1016, the network 1095 provides an RRC resume (plus any additional information required for connection, such as a resume identity, a next-hop link count, alternative cells, a resume trigger condition, etc.) to the WTRU 1005. At 1018, the WTRU 1005 provides an RRC resume complete (plus a measurement report) to the network 1095.

[0203] If network 1095 detects that the WTRU 1005 is inactive at 1022, it provides an RRC reconfiguration message to the WTRU at 1024. For example, such a message may include a resume identity, a next-hop link count, an alternative cell, and a resume trigger condition.

[0204] Figure 11 A signaling diagram 1100 of a WTRU 1105 in a connected state 1102 is illustrated, which is configured to perform an RRC resume procedure (e.g., provided with a resume identity, a next-hop link count, etc.) when detecting that a trigger condition (such as RLF) is met. At 1104, the WTRU 1105 monitors the trigger condition for resumption.

[0205] At 1106, it is determined whether the condition is met. If it is determined that the condition is not met, at 1104, the WTRU continues to monitor the trigger condition for resumption. If it is determined that the condition is met, it is determined at 1108 whether there is any alternative cell that meets the configured threshold. If it is determined that there is no alternative cell that meets the configured threshold, a reconstruction may be performed at 1112. If it is determined that there is an alternative cell that meets the configured threshold, the best cell among the suitable alternative cells is selected at 1109. In one example, the best cell may be the cell with the best radio signal level among the candidate cells that meet the conditions.

[0206] Once the best cell is selected from the suitable cells at 1109, an RRC resume request (plus a new resume reason) is provided from the WTRU 1105 to the network 1195 at 1114. At 1116, the network 1195 provides an RRC resume to the WTRU 1105 (plus any additional information required for connection, such as a resume identity, a next-hop link count, an alternative cell, a resume trigger condition, etc.). At 1118, the WTRU 1105 provides an RRC resume complete (plus a measurement report) to the network 1195.

[0207] If network 1195 detects that the WTRU 1105 is inactive at 1122, it provides an RRC reconfiguration message to the WTRU at 1124. For example, such a message may include a resume identity, a next-hop link count, an alternative cell, and a resume trigger condition.

[0208] Figure 12 A signaling diagram 1200 of a WTRU 1205 in a connected state 1202 is illustrated, which is configured to perform an RRC resume procedure (e.g., provided with a resume identity, a next-hop link count, etc.) when detecting that a trigger condition (such as RLF) is met. At 1204, the WTRU 1205 detects RLF. At 1207, the WTRU 1205 determines whether one of the candidate cells meets the required threshold. If it is determined that none of the candidate cells meets the required threshold, a reconstruction is performed at 1212.

[0209] If it is determined that one of the candidate cells does in fact meet the required threshold, then at 1210, reselection can occur to the cell that meets the threshold. At 1214, an RRC resume request is provided from the WTRU 1205 to the network 1295. At 1216, RRC resume is provided by the network 1295 to the WTRU 1205. At 1218, the WTRU 1205 provides an RRC resume complete to the network 1295.

[0210] Figure 13 A method 1300 for performing an RRC resume procedure in accordance with one aspect is illustrated. Method 1300 includes receiving configuration information for performing connection resume at 1310. The configuration information can include at least a list of candidate cells and an acceptable threshold signal level of the cell to be used. The receiving can be in a connected state.

[0211] At 1320, method 1300 includes performing cell selection to a candidate cell whose radio conditions meet the threshold. For example, cell selection can occur when an RLF is detected. By initiating a connection resume procedure, candidate cells can be included in a list of candidate cells whose radio conditions meet the threshold.

[0212] Method 1300 can include one or more WTRU identities to be used during a connection resume procedure and a security configuration to be applied during a connection resume procedure. Method 1300 can include performing a reconstruction procedure if no cell that meets the threshold is included in the candidate cell list. Method 1300 can include determining that radio conditions of one of the candidate cells from the candidate cell list meet the threshold.

[0213] Although the features and elements have been described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used separately or in combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware that is combined in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted by wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed in a wireless transmit / receive unit (WTRU), the method comprising: Receiving configuration information for performing connection recovery upon detection of a radio link failure (RLF), the configuration information including the WTRU identity to be used during the connection recovery process and the security configuration to be applied during the connection recovery process and at least one or more of a candidate cell list and an acceptable threshold signal level of a cell to be used; Upon detection of an RLF, performing cell selection to a candidate cell included in the candidate cell list having radio conditions that meet the acceptable threshold signal level; And Sending a connection recovery request message to the network.

2. The method according to claim 1, wherein the receiving is in a connected state.

3. The method according to claim 1, further comprising receiving subsequent recovery parameters for subsequent recovery.

4. The method according to claim 3, wherein the subsequent recovery parameters include a new recovery identity and a next-hop link count.

5. The method according to claim 1, further comprising including a cause value in the connection recovery request, the cause value indicating at least one cause for triggering the connection recovery.

6. The method according to claim 1, further comprising receiving a connection recovery message from the network, the connection recovery message including the configuration information.

7. The method according to claim 6, further comprising applying the configuration information.

8. The method according to claim 7, wherein the connection recovery request message is sent to the network via the selected candidate cell.

9. The method according to claim 1, further comprising sending a connection recovery complete message to the network, wherein the connection recovery complete message indicates that the WTRU has recovered the connection.

10. The method according to claim 1, further comprising performing a reconstruction process if no cell that meets the acceptable threshold signal level is included in the candidate cell list.

11. The method according to claim 1, further comprising determining that radio conditions of one of the candidate cells from the candidate cell list meet the acceptable threshold signal level.

12. A wireless transmit / receive unit (WTRU) comprising: A processor; And A transceiver communicatively coupled to the processor, the processor and the transceiver operative to: Receive configuration information for performing connection recovery upon detection of a radio link failure (RLF), the configuration information including the WTRU identity to be used during the connection recovery process and the security configuration to be applied during the connection recovery process and at least one or more of a candidate cell list and an acceptable threshold signal level of a cell to be used; Upon detection of an RLF, perform cell selection to a candidate cell included in the candidate cell list having radio conditions that meet the acceptable threshold signal level; Send a connection recovery request message to the network.

13. The WTRU according to claim 12, wherein the receiving is in a connected state.

14. The WTRU according to claim 12, wherein the processor and the transceiver are further operative to receive subsequent recovery parameters for a subsequent recovery, the subsequent recovery parameters including a new recovery identity and a next-hop link count.

15. The WTRU according to claim 12, wherein the processor and the transceiver are further operative to include a cause value in a connection recovery request, the cause value indicating at least one cause that triggered the connection recovery.

16. The WTRU according to claim 12, wherein the processor and the transceiver are further operative to: receive a connection recovery message from the network, the connection recovery message including configuration information; apply the configuration information; and recover connection with the network via a selected candidate cell.

17. The WTRU according to claim 12, wherein the processor and the transceiver are further operative to send a connection recovery complete message to the network.

18. The WTRU according to claim 17, wherein the connection recovery complete message indicates that the WTRU has recovered connection.

19. The WTRU according to claim 12, wherein if no cell meeting an acceptable threshold signal level is included in a candidate cell list, the processor and the transceiver are further operative to perform a re-establishment procedure.

20. The WTRU according to claim 12, wherein the processor and the transceiver are further operative to determine that radio conditions of one of the candidate cells from the candidate cell list meet an acceptable threshold signal level.

Images