Conditional Mobility with Multi-Connectivity

Abstract

Systems, methods, and means for mobility and multi-connectivity of wireless transmit / receive units are described herein. These devices can be configured to perform conditional handovers and / or conditional second cell group reconfigurations, including primary secondary cell additions or changes. These devices can exchange information with the network while performing the conditional reconfigurations and / or conditional handovers. These devices can be configured with rules for handling concurrent handover and reconfiguration tasks.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 908,876, filed October 1, 2019, U.S. Provisional Patent Application No. 62 / 930,891, filed November 5, 2019, U.S. Provisional Patent Application No. 62 / 972,842, filed February 11, 2020, and U.S. Provisional Patent Application No. 63 / 061,225, filed August 5, 2020, the disclosures of which are incorporated herein by reference in their entireties. [Background technology]

[0002] Mobile communications are constantly evolving and are already in the fifth generation, or 5G. A wireless transmit receive unit (WTRU) can be configured with multiple connectivity. For example, a WTRU can be configured to communicate with two network nodes that can be connected via a backhaul. These network nodes can use the same radio access technology (RAT) or different RATs to provide network access to the WTRU. The WTRU can send messages to or receive messages from the network nodes. The WTRU and the network nodes can determine each other's condition and / or state via messaging. Summary of the Invention

[0003] Systems, methods, and means for handling mobility and multi-connectivity related tasks associated with a wireless transmit / receive unit (WTRU) are described herein. The WTRU described herein can receive a radio resource control (RRC) message from a network entity, where the RRC message can indicate a conditional reconfiguration to be applied by the WTRU and a condition (e.g., measurement condition) for applying the conditional reconfiguration. The conditional reconfiguration can be associated with a primary secondary cell (PSCell) change, a PSCell addition, a secondary cell group (SCG) change, an SCG addition, etc. The RRC message can indicate multiple candidate PSCells associated with the conditional reconfiguration. In response to receiving the RRC message, the WTRU can send a first message to the network entity indicating in the first message that the WTRU received the RRC message. The WTRU can monitor the condition for applying the conditional reconfiguration and can determine that the condition for applying the conditional reconfiguration is met. The WTRU may send a second message to the network entity (e.g., based on a determination that the conditions for applying the conditional reconfiguration are met), which may indicate that the conditions for applying the conditional reconfiguration are then met. The WTRU may apply the conditional reconfiguration. In some scenarios, the WTRU may determine that applying the conditional reconfiguration has failed. In response to such a failure, the WTRU may send a third message to the network entity, which may indicate the failure to the network entity.

[0004] The network entity described herein may be associated with a master cell group (MCG) of the WTRU, and the WTRU may be configured to transmit at least one of the first, second, or third messages in the MCG. The WTRU may receive a conditional handover command from the network entity while the conditional reconfiguration is still pending, and the WTRU may prioritize execution of the conditional handover command over execution of the conditional reconfiguration. [Brief explanation of the drawings]

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

[0006] [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to an embodiment.

[0007] [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment.

[0008] [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment.

[0009] [Figure 2] FIG. 10 illustrates exemplary timing for beam failure reporting, beam failure configuration, and beam failure recovery.

[0010] [Figure 3] FIG. 10 is a diagram illustrating an example of applying an SCG configuration based on a certain condition.

[0011] [Figure 4] FIG. 1 illustrates an example of applying an SCG configuration based on the detection of a radio link failure.

[0012] [Figure 5] FIG. 10 illustrates an example of an enhanced recovery action.

[0013] [Figure 6] FIG. 10 illustrates an example of monitoring multiple conditional rearrangements. DETAILED DESCRIPTION OF THE INVENTION

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

[0015] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

[0019] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114 a and the WTRUs 102 a, 102 b, 102 c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications 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 Packet Access (HSUPA).

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

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

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

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

[0024] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a location such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0025] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0029] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), 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) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0036] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an 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, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] High Throughput (HT) STAs may, for example, use a 40 MHz wide channel for communication via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

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

[0053] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STA among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the conditions of the primary channel. For example, if the primary channel is busy due to STAs (that only support 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

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

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

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

[0057] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0058] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. The non-standalone configured WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0059] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, 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, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

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

[0062] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0065] 1A-1D and their corresponding descriptions, one or more or all of the functions described herein with respect to one or more of the 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 devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0067] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] As referred to herein, a network may include one or more gNBs, one or more transmission / reception points (TRPs), and / or one or more nodes associated with a radio access network. As referred to herein, multi-radio dual connectivity (MR-DC) may refer to dual connectivity to an E-UTRA node and an NR node, or dual connectivity to two NR nodes.

[0069] A WTRU may be configured with multi-connectivity, such as dual connectivity. For example, a WTRU may be configured to utilize resources provided by two nodes (e.g., two network nodes). These two nodes may be connected, for example, via a non-ideal backhaul. The nodes may provide network access to the WTRU using the same RAT or different RATs. In some examples, a first network node may function as a master node (MN) that may be configured to control resources associated with one or more cells associated with a master cell group (MCG), and a second network node may function as a secondary node (SN) that may be configured to control resources associated with one or more cells associated with a secondary cell group (SCG). The MNs and SNs may be connected via a network interface. At least the MN may be connected to a core network. Example implementations described herein may be applicable to various use cases, including when a WTRU may be configured with two or more secondary cell groups (e.g., possibly controlled by two or more secondary nodes). In one exemplary case of dual connectivity, the WTRU may be configured to implement multiple medium access controls or MACs (e.g., via respective MAC entities). One or more MACs (e.g., MAC entities) may be associated with an MCG, and one or more MACs (e.g., MAC entities) may be associated with an SCG. The WTRU may be configured to receive and process radio resource control (RRC) messages, such as RRC reconfiguration messages, via the MCG. The RRC messages (e.g., RRC reconfiguration messages) may be associated with (e.g., may include information for) SCG addition, SCG change or modification, and / or SCG release.

[0070] The latency associated with the initial setup and activation of the SCG can significantly impact multi-connectivity performance. There may be a delay between a first time instance when a WTRU determines that it needs additional radio resources (e.g., for a high-throughput data transmission) and a second time instance when the WTRU is ready to transmit on the SCG. This delay may be associated with (e.g., caused by) aspects including signaling delays over the Uu interface (e.g., buffer status, measurement reports, etc.), signaling delays over the Xn interface (e.g., coordination between master and secondary nodes), etc.

[0071] Interruptions during mobility procedures can significantly impact multi-connectivity performance. In some examples, mobility robustness can be supported at least when an SCG bearer is terminated within the SN, for example, because an SCG change failure can cause an interruption of ongoing data transmission. The delay from the transmission of a measurement report by the WTRU to the receipt of an RRCReconfiguration by the WTRU can be indeterminate due to inter-node coordination between the MN and the target SN. This can result in an SCG change that is too late or too early. If the SCG is deployed in a higher frequency (e.g., Frequency Range 2 (FR2), such as 24.25 GHz to 52.6 GHz), the cell size may be small and beamforming may be a weak link.

[0072] Mobility interactions between different connectivity legs of a multi-connected WTRU may be significantly affected. The WTRU may be configured to perform network-controlled mobility operations towards the MCG and conditional mobility operations towards the SCG. The WTRU may be configured to perform network-controlled mobility operations towards the SCG and conditional mobility operations towards the MCG. The WTRU may be configured to perform conditional mobility operations towards both the MCG and the SCG. The behavior of the WTRU may be affected (e.g., may be inconsistent due to the expected results) by the expected results (e.g., success / failure) of simultaneous mobility procedures performed at different layers in a multi-connectivity scenario.

[0073] The WTRU may be configured to perform mobility-related operations in multi-connectivity scenarios. Descriptions provided herein regarding conditional handover (CHO) may be at least partially applicable to conditional reconfiguration, and vice versa. Similarly, descriptions regarding conditional PSCell addition and / or change (CPAC) may be at least partially applicable to conditional PS cell change (CPC), and vice versa. Examples of CPAC may include performing a reconfiguration associated with a secondary cell group if preconfigured execution conditions or triggers are met. Such execution conditions and / or triggers may be preconfigured by a network entity, for example, via higher layer signaling. Examples provided herein with reference to a master node (MN) may be at least partially applicable to a master cell group (MCG), and vice versa. Examples provided herein with reference to a secondary node (SN) may be at least partially applicable to a secondary cell group (SCG), and vice versa.

[0074] The WTRU may apply a configuration associated with the secondary cell group as a function of a condition (e.g., based on a preconfigured condition). The WTRU may be configured to perform cell group configuration or reconfiguration of the secondary cell group if the preconfigured condition is met. The secondary cell group may support (e.g., use) the same RAT as the master cell group, or the second cell group may use a different RAT than the RAT used by the master cell group (e.g., the second cell group may be a multi-radio secondary cell group). The secondary cell group configuration or reconfiguration may be synchronous (e.g., may include a preamble transmission that may be configured using a configuration parameter such as reconfigurationWithSync). The cell group configuration or reconfiguration may be signaled as part of an RRC reconfiguration message.

[0075] A WTRU may be configured with one or more multi-connectivity conditional reconfigurations (e.g., the WTRU may receive one or more multi-connectivity conditional reconfigurations), e.g., at least one reconfiguration may be associated with an MCG and at least one reconfiguration may be associated with an SCG. The WTRU may be configured with multiple conditional reconfigurations, a first subset of the conditional reconfigurations may be associated with a master cell group, and a second subset (e.g., the remainder) of the conditional reconfigurations may be associated with a secondary cell group. The WTRU may be configured with multiple conditional reconfigurations, where the multiple conditional reconfigurations may correspond to the master cell group and the secondary cell group. The WTRU may apply an MCG reconfiguration and / or an SCG reconfiguration if a trigger condition (e.g., a trigger condition associated with the conditional reconfiguration) is met. The WTRU may be configured with multiple conditional reconfigurations, where one or more conditional reconfigurations associated with a secondary cell group may be linked to a conditional reconfiguration of the master cell group. The WTRU may apply a conditional reconfiguration associated with the master cell group if a first trigger condition is met. The WTRU may apply a conditional reconfiguration associated with a secondary cell group linked to the currently activating master cell group if a second trigger condition is met.

[0076] Configuration aspects associated with conditional secondary cell group configuration or reconfiguration may be described herein. The WTRU may be configured to apply an SCG configuration if a preconfigured condition is met. The SCG configuration may include one or more of a special cell configuration (e.g., spCellConfig, etc.), which may include PSCell configuration information; a configuration for performing reconfiguration with synchronization; a radio bearer configuration, which may include packet data convergence protocol (PDCP) configuration information, radio link control (RLC) configuration information, and / or logical channel configuration information; a MAC configuration (e.g., configuration information of a MAC entity associated with a cell group); or configurations associated with zero or more SCells to be added, modified, and / or released.

[0077] A WTRU may be configured with linkages (e.g., mappings, associations, relationships, etc.) between SCG configurations and trigger conditions. One SCG configuration may be associated with multiple trigger conditions. Multiple SCG configurations may be associated with a single trigger condition. A WTRU may be configured to determine which of one or more conditional SCG configurations may be applicable to a given MCG configuration. The WTRU may use such determination to perform monitoring associated with one or more SCG configurations. For example, the WTRU may be configured to monitor trigger conditions associated with SCG configurations linked to a currently active MCG configuration. A WTRU may be configured with linkages between MCG candidates and SCG candidates. In some examples, a WTRU may be configured with linkages between conditional handover (CHO) candidates (e.g., on an MCG) and conditional SCG reconfiguration candidates. Such linkages may be used, for example, to exploit preferences and / or restrictions of a particular network (NW) regarding MN and SN combinations to which the WTRU may connect. The behavior of the WTRU may be significantly influenced by the linkage as described herein, which may imply or control the behavior of the WTRU, for example, with respect to changes in the CHO and / or PSCell.

[0078] The WTRU may trigger a conditional SCG reconfiguration as a result of performing a CHO. In some examples, the WTRU may be configured to trigger a conditional SCG reconfiguration at or following a CHO. The conditional SCG reconfiguration may be triggered due to a lack of linkage between the CHO target and the current PSCell or SCG configuration. In some examples, the WTRU may be configured with an SCG configuration corresponding to a CHO candidate (e.g., a candidate master node). The WTRU may trigger a PSCell configuration based on the CHO trigger. The WTRU may be configured with several conditions (e.g., as described herein) for performing an SCG reconfiguration after a CHO. For example, if one or more of the conditions are met, the WTRU may perform a PSCell change to the linked configuration; if none of the conditions are met, the WTRU may release or suspend the SCG configuration or maintain the current configuration.

[0079] The WTRU may trigger CHO as a result of a conditional SCG reconfiguration. For example, the WTRU may be configured to trigger CHO when or after a conditional PSCell change is triggered. One or more aspects of the above examples (e.g., for performing a conditional SCG reconfiguration as a result of performing CHO) may be applied to perform CHO as a result of a conditional SCG reconfiguration. For example, the WTRU may be configured with several conditions (e.g., as described herein) for performing CHO after an SCG reconfiguration. If one or more of the conditions are met, the WTRU may perform CHO; if none of the conditions are met, the WTRU may release or suspend CHO.

[0080] The WTRU may decide to suspend, release, or maintain the currently active SCG configuration after CHO based on certain conditions related to the linkage. For example, the WTRU may perform CHO to a target and may decide to activate, suspend, or release the current SCG configuration depending on the linkage of the SCG configuration with the target. For example, if the WTRU is configured with a linkage between the CHO and the current SCG, the WTRU may continue operating on the SCG. If the WTRU is not configured with a linkage between the CHO and the current SCG, the WTRU may suspend the SCG, release the SCG, activate a different SCG, or perform a reconfiguration for a different SCG.

[0081] The WTRU may suspend or release certain bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs)) based on one or more conditions related to the linkage. For example, the WTRU may suspend or release DRBs during a CHO or conditional PSCell change if no linkage exists between the CHO candidate and the current SCG or between the PSCell candidate and the current PCell. The WTRU may be configured with a list of bearers to be suspended and / or released if a linkage as described herein exists. The WTRU may be configured with a list of bearers to be suspended and / or released if a linkage as described herein does not exist.

[0082] The WTRU may perform radio bearer reconfiguration (e.g., from split bearers to MCG / SCG bearers) based on certain conditions related to the linkage described herein. For example, the WTRU may perform radio bearer reconfiguration if no linkage exists. For example, if no linkage exists between the CHO target and the current PSCell, the WTRU may reconfigure one or more split bearers (e.g., all split bearers) to MCG bearers or SCG bearers.

[0083] The WTRU may decide to reconfigure portions of the SCG configuration after CHO based on certain conditions related to the linkage described herein. For example, the WTRU may be provided with a reconfiguration of the SCG. The WTRU may apply such a reconfiguration on the condition (e.g., only on the condition) that the CHO target is not linked to the current active SCG configuration. The WTRU may not apply such a reconfiguration if a linkage exists (e.g., between the CHO target and the current active SCG configuration).

[0084] The WTRU may consider a subset of configured conditional PSCell candidates (e.g., only the subset of configured conditional PSCell candidates) that the WTRU can access to perform conditional PSCell modification based on a given active PCell or MCG configuration. For example, after selecting a CHO candidate, the WTRU may select a subset of corresponding PSCell candidates (e.g., only the subset of corresponding PSCell candidates) that the WTRU can use if a PSCell reconfiguration is triggered along with or as a result of the CHO.

[0085] The WTRU may consider a subset of configured conditional handover (HO) (e.g., PCell) candidates (e.g., only a subset of configured conditional HO (PCell) candidates) that the WTRU can access to perform conditional HO based on a given active PCell or SCG configuration. This WTRU behavior may also apply when a conditional PSCell configuration triggers CHO (e.g., after or during a conditional PSCell configuration).

[0086] The WTRU may bias the triggering conditions for conditional HO to the PCell, for example, depending on the existence of linkage between the current PSCell and the CHO candidate (e.g., the WTRU may prioritize candidates with linkage over candidates without linkage). For example, the WTRU may be configured with triggering conditions for conditional HO candidates based on measurements. The WTRU may be further configured with biases for such measurements, or with different measurements depending on whether there is linkage between the CHO candidate and the current PSCell. The WTRU may bias the triggering conditions for conditional PSCell change depending on the existence of linkage between the current PCell and the conditional PSCell candidate. This behavior of the WTRU may also be applied in the case of conditional PSCell configuration. The WTRU may decide to select one or more candidates with a priority (e.g., when multiple candidates exist and a CHO or conditional PSCell change is triggered) depending on the existence of linkage between the current PCell / PSCell and the conditional PCell / PSCell candidate in question.

[0087] The WTRU may, for example, receive signaling and / or identification of linkage from higher layers. The WTRU may receive explicit signaling of such linkage during MCG and / or SCG conditional HO. Such explicit signaling may be in one or more of the following forms: The WTRU may receive a list of allowed or linked PSCells and / or applicable SCG configurations for each PCell CHO candidate when CHO is performed for the candidate (e.g., for each candidate). The WTRU may, for example, receive a list of allowed or linked PCells and / or applicable MCG configurations for a PSCell candidate (e.g., for each PSCell candidate) when conditional SCG reconfiguration is performed. The WTRU may receive an identifier in the cell configuration (e.g., with each cell configuration). The WTRU may assume linkage between the MCG and SCG when, for example, the MCG and SCG have the same identifier or associated identifiers. The WTRU may receive a table of linked PCells and / or PSCells (e.g., a table of cell IDs, etc.), e.g., via dedicated configuration information or via a SIB. The WTRU may be configured with multiple conditions to trigger a reconfiguration. For example, a first condition may apply if there is linkage between a candidate cell associated with the reconfiguration and a serving cell (e.g., a serving cell associated with an MCG and / or SCG), and a second condition may apply if there is no linkage between the candidate cell associated with the reconfiguration and a serving cell (e.g., a serving cell associated with an MCG and / or SCG).

[0088] The WTRU may implicitly determine the linkage based on one or more of the following: The WTRU may implicitly determine such linkage based on a relationship between parameters associated with each configuration. The WTRU may consider linked cells to be linked if they have the same security parameters or if there is some correlation between the security parameters of each cell. In examples, the WTRU may consider cells to be linked if there is some direct correlation between cell IDs. In examples, the WTRU may consider cells to be linked if they have the same configuration for a particular bearer (e.g., a split bearer). The WTRU may consider an SCG to be linked to an MCG, for example, if the SCG and MCG are included (e.g., configured) in the same RRC reconfiguration message. The linkage may be explicit or implicit, for example, by including the masterCellGroup configuration and the secondaryCellGroup configuration in the RRCReconfiguration message.

[0089] The linkage between the MCG candidate and the SCG candidate may depend on specific trigger conditions. This linkage between the MCG candidate and the SCG candidate may depend on specific triggers for CHO and / or conditional PSCell change. A WTRU may be configured with a first set of one or more triggers based on the premise that a first linkage or set of linkages exists, and the WTRU may be configured with a second (e.g., separate) set of one or more triggers based on the premise that a second linkage or set of linkages exists. In some examples, a WTRU may be configured with conditional PSCell candidates 1 and 2. Conditional PSCell candidate 1 may have linkage to the current PCell, and conditional PSCell candidate 2 may not have linkage to the current PCell. Such linkage may be applicable to triggering (e.g., triggering only) data arrival on an SCG bearer, but may not be applicable to triggering SCG cell quality. For example, if the WTRU triggers a conditional PSCell change due to data arriving while camped on the current PCell, the WTRU may prioritize or restrict the PSCell change to PSCell candidate 1 (e.g., and not to PSCell candidate 2). If the WTRU triggers a conditional PSCell change due to SCG cell quality, the WTRU may allow the PSCell change to PSCell candidate 1 or PSCell candidate 2 without prioritizing either of the candidates.

[0090] A WTRU may receive a generic cell group configuration that may be used as an MCG or SCG configuration. The WTRU may receive one or more conditions associated with application of a CG configuration as an MCG configuration or an SCG configuration. In some examples, the WTRU may be configured with a first set of one or more conditions under which the generic cell group configuration may be applied as an MCG configuration and a second set (e.g., potentially different from the first set) of one or more conditions under which the generic cell group configuration may be applied as an SCG configuration. In some examples, the WTRU may receive a generic cell group configuration that may be used for conditional PSCell addition and / or conditional PSCell modification. For example, if the conditions for conditional PSCell addition and / or conditional PSCell modification are met and the WTRU does not have an active SCG configuration, the WTRU may perform a conditional PSCell addition. If the conditions for conditional PSCell addition and / or conditional PSCell modification are met and the WTRU has an active SCG configuration, the WTRU may perform a conditional PSCell modification. The examples described herein may be applicable when a generic cell group is configured for conditional PSCell addition and conditional PSCell modification.

[0091] A WTRU may identify a generic CG if it is also configured with other non-generic CG candidates. For example, a WTRU may be configured with one or more generic CG configurations in addition to an MCG-specific configuration or an SCG-specific configuration. The WTRU may identify a generic CG configuration based on explicit signaling (e.g., based on respective identities or identifiers included in the generic CG configuration or based on the use of separate information elements (IEs) for the generic CG configuration). The WTRU may identify a generic CG configuration based on being provided with a complete (e.g., non-delta) configuration for the generic CG configuration.

[0092] The CG configuration may be provided as delta signaling (e.g., in addition to other signaling). The WTRU may receive the comprehensive CG configuration as delta signaling and apply the delta signaling to derive the resulting MCG or SCG configuration. If separate delta configurations comprise the MCG and SCG, one or more of the following may apply: The CG configuration may be provided in separate parts, e.g., a delta configuration associated with the MCG and a delta configuration associated with the SCG. In examples, if the WTRU determines to apply a conditional CG configuration to the SCG, the WTRU may apply the delta configuration associated with the SCG to the current SCG configuration (e.g., while ignoring the delta configuration associated with the MCG). In examples, the WTRU may apply both the MCG configuration and the SCG delta configuration regardless of which CG is changed.

[0093] If a CG configuration is provided to an MCG or SCG as a delta signaling, one or more of the following may apply: This CG configuration may be provided to the currently configured CG (e.g., MCG or SCG) as a delta configuration. If a CG configuration is provided for an MCG, and if CHO is performed on the PCell, the WTRU may apply the delta configuration to its current MCG configuration (e.g., to derive the MCG configuration after CHO). If a CG configuration is provided for an MCG, and if a conditional PSCell change is performed, the WTRU may apply the delta configuration to its current MCG configuration (e.g., to derive the SCG configuration after the conditional PSCell change). If a CG configuration is provided as a delta configuration for an SCG, and if a conditional PSCell change is performed, the WTRU may apply the delta configuration to its current SCG configuration (e.g., to derive the SCG configuration after the conditional PSCell change). The WTRU may receive signaling (e.g., in the candidate configuration itself) regarding whether a delta configuration may be applied for an MCG or SCG.

[0094] The WTRU may be configured with one or more trigger conditions for secondary cell group configuration or reconfiguration. The WTRU may be configured to apply a reconfiguration associated with a secondary cell group if one or a combination of the trigger conditions described herein are met. For example, the WTRU may be configured to apply an SCG reconfiguration if a measurement-based condition is met. This measurement-based condition may correspond to a cell quality measurement such as RSRP, RSRQ, or SINR. This measurement-based condition may be configured, for example, as a measurement event (e.g., Ax, Bx, etc.) with one or more appropriate thresholds. The WTRU may apply an SCG reconfiguration if the measurement-based condition and one or more of the following trigger conditions are met:

[0095] The trigger condition may be associated with a user plane status. The WTRU may be configured to apply an SCG configuration, for example, if a measurement-based condition and a user plane-based condition are met. For example, a user plane condition may be met if one or more of the following occur: The user plane condition may be met based on data associated with a preconfigured logical channel (LCH) or logical channel group (LCG) (e.g., such an LCH / LCG may correspond to an SCG bearer or a split bearer) becoming available for transmission. The user plane condition may be met if the buffer status of one or more bearers reaches a threshold (e.g., this threshold may correspond to a data splitting threshold or may be derived from data splitting thresholds of multiple bearers). For example, the user plane condition may be met if the WTRU determines that the amount of pending PDCP and RLC data on all split bearers is above a threshold that may trigger application of an SCG configuration or activate an SCG. The user plane condition may be met if a latency associated with a data transmission is greater than a preconfigured threshold. A user plane condition may be met if the latency associated with a scheduling request is greater than a preconfigured threshold. A user plane condition may be met if the number of RLC retransmissions is greater than a preconfigured threshold. A user plane condition may be met if one or more conditions of a buffer status related to a time aspect are met. For example, whether a user plane condition may be met may be determined based on the amount of time that one or a subset of bearers exceeds a threshold (e.g., a trigger may be the amount of time above the threshold). A user plane condition may be met if the increase in buffer status (e.g., over time units) is greater than a threshold.A user plane condition may be met when a buffer status report (BSR) is triggered or sent (e.g., the triggering of a BSR may be associated with the existence of another condition, e.g., the buffer status of one or more split bearers exceeds a threshold).

[0096] In some examples, a WTRU may be configured with two thresholds for split bearers (e.g., for each split bearer). The WTRU may activate or apply an SCG configuration, for example, if pending PDCP and RLC data for (e.g., any) bearer exceeds a first threshold. With an SCG configuration activated or applied, the WTRU may continue to emit data to (e.g., only to) the MCG leg of the split bearer. The WTRU may continue to emit data to the SCG leg of the split bearer, for example, if pending PDCP / RLC data for the bearer exceeds a second threshold. The WTRU may follow similar rules for deactivation.

[0097] The trigger condition may be associated with SRB3. The WTRU may be configured to apply an SCG configuration if the WTRU is unable to comply with an RRCReconfiguration message received over SRB3, e.g., if a PSCell associated with the stored SCG configuration meets measurement and / or eligibility criteria, as the case may be.

[0098] The trigger condition may be associated with an SCG failure. The WTRU may be configured to apply an SCG configuration if an SCG failure is detected. The SCG configuration may correspond to an SN change. An SCG failure may be detected if one or more of the following conditions are met: An SCG failure may be detected in response to detecting a radio link failure of the SCG. An SCG failure may be detected in response to detecting a reconfiguration involving a synchronization failure of the SCG. An SCG failure may be detected in response to detecting an SCG configuration failure. An SCG failure may be detected in response to receiving an integrity check failure indication from the SCG lower layer for SRB3.

[0099] The trigger condition may be associated with a beam failure (e.g., of a PSCell of an SCG). The WTRU may be configured to apply an SCG configuration (e.g., as described herein) and / or activate an inactive SCG if a beam failure is detected on a PSCell. In the case of a pending and / or inactive SCG or an inactive SCell (e.g., a cell operating on a secondary frequency to provide additional radio resources to a CA-configured WTRU), the WTRU may continue to perform beam monitoring on that cell. In the case of a beam failure, the WTRU may initiate a beam failure recovery procedure (e.g., to receive a random access channel (RACH) in response to a physical downlink control channel (PDCCH) for the beam failure recovery procedure) and / or activate an inactive SCG, PSCell, and / or SCell.

[0100] The trigger condition may be associated with the MCG radio link status. The WTRU may be configured to apply the SCG configuration as a function of the radio link status associated with the MCG. For example, the WTRU may be configured to apply the SCG configuration if an RLF is detected in the MCG. In some examples, the WTRU may be configured to perform RRC implementations based on a stored SCG if an MCG RLF is present. One or more of the following may apply: For the MCG RLF case, if the WTRU has a stored configuration for an SCG, and if the PSCell associated with that SCG meets the eligibility criteria, and if SRB3 or split SRB1 is configured for the SCG, the WTRU may apply the stored SCG configuration and / or send an MCG failure message (e.g., indicating the reason for the MCG failure and a trigger for applying an SCG configuration such as an MCG RLF) to the SCG. For the MCG RLF case, the WTRU may initiate re-establishment. As part of this re-establishment, the WTRU may perform cell selection. If the selected cell is the same as the PSCell associated with the SCG configuration, the WTRU may apply the stored SCG configuration and / or send an MCG failure message to the SCG, indicating, for example, the reason for the MCG failure and a trigger for applying the SCG configuration, such as an MCG RLF. For the MCG RLF case, if the WTRU is configured with a generic cell group configuration, the WTRU may promote the cell group configuration to an MCG configuration and may perform a conditional handover towards the promoted MCG configuration.

[0101] The trigger condition may be associated with performing an MCG conditional reconfiguration. The WTRU may be configured to apply an SCG configuration if a conditional reconfiguration associated with the MCG is successfully performed. The WTRU may be configured to perform a conditional SCG configuration after a conditional MCG configuration, for example, if one or more additional trigger conditions described herein are met. The WTRU may be configured to release an SCG configuration if a conditional reconfiguration is applied toward an MCG and the current SCG configuration is not linked to such MCG.

[0102] There may be interaction (e.g., information exchange) between monitoring the procedure for a conditional MCG reconfiguration and monitoring the procedure for a conditional SCG reconfiguration. The WTRU may be configured to simultaneously monitor trigger conditions associated with a conditional SCG reconfiguration and trigger conditions associated with a conditional MCG reconfiguration. The WTRU may be configured to start monitoring one or more trigger conditions associated with one or more SCG reconfigurations, where these SCG reconfigurations may be active or linked to MCG configurations for which trigger conditions may be met.

[0103] If the trigger conditions for MCG (re)configuration and / or SCG (re)configuration are met (e.g., simultaneously), the WTRU may be configured to prioritize MCG reconfiguration. After the MCG reconfiguration, if the stored SCG is linked to the serving MCG, the WTRU may apply the SCG reconfiguration; if the stored SCG is not linked to the serving MCG, the WTRU may release the SCG configuration. If the conditions for MCG and SCG (re)configuration are met (e.g., simultaneously), the WTRU may be configured with rules for determining which (re)configuration to prioritize. For example, the rules for prioritization may be based on the relative cell quality of the MCG and SCG.

[0104] If a trigger condition associated with the MCG is met during the progress of a conditional SCG reconfiguration, the WTRU may be configured with the following behavior: The WTRU may be configured to release the SCG reconfiguration and trigger an MCG reconfiguration. This behavior may be limited to situations where the SCG reconfiguration is not linked to the MCG reconfiguration. The WTRU may be configured to continue with the MCG and SCG reconfiguration. The WTRU may be configured to indicate to the MCG for the SCG reconfiguration.

[0105] If a trigger condition associated with the SCG is met during the progress of a conditional MCG reconfiguration, the WTRU may be configured with the following behaviors: The WTRU may be configured to postpone SCG reconfiguration, for example, until MCG reconfiguration is completed or until MCG reconfiguration fails. The WTRU may indicate to the MCG that SCG reconfiguration is triggered (e.g., in case of MCG reconfiguration success). The WTRU may report an MCG failure to the SCG (e.g., in case of MCG failure).

[0106] The WTRU may be configured to handle the SCG state based on conditions. For example, the WTRU may be configured to activate (or deactivate) an SCG (e.g., an SCG configuration) based on one or more preconfigured triggers. For example, the WTRU may be configured with one or more SCG configurations that may be dormant, and the WTRU may be further configured with one or more configurations or conditions for activating an SCG configuration (e.g., moving an SCG configuration from an dormant state to an activated state) or suspending an SCG configuration (e.g., moving an SCG configuration from an activated state to an dormant state). The dormant state may be characterized by one or more conditions, such as a condition associated with an dormant SCell where the WTRU can perform channel quality indicator (CQI) / radio resource management (RRM) measurements but cannot decode the PDCCH. In some examples, having an SCG configuration in an dormant state may mean storing the SCG configuration in the WTRU but not providing it. The WTRU may apply any of the triggers described herein to activate an SCG (e.g., in connection with modifying or adding a conditional PSCell). The WTRU may operate with multiple activated SCGs if the triggers for activation of these SCGs are met without meeting the triggers for deactivation of these SCGs.

[0107] Given multiple SCG configurations, the WTRU can select an SCG for activation. For example, the WTRU may be configured with multiple dormant SCG configurations, where each SCG configuration may include a PSCell and zero or more SCells. The WTRU may select an SCG for activation based on preconfigured criteria. The WTRU may select the SCG with the best PSCell or SCell (e.g., based on RRM measurements). The WTRU may select the SCG with the best PSCell or SCell based on channel state information (CSI) measurements. The WTRU may select an SCG configured with dedicated RACH resources. The WTRU may select an SCG with the greatest number of beams above a threshold. The WTRU may select an SCG with the greatest number of SCells that meets minimum RSRP, RSRQ, SINR, and / or CSI thresholds. The WTRU may select the last active SCG.

[0108] The WTRU may be configured to indicate SCG activation to the network based on the activation of the SCG. The WTRU may send a scheduling request to the selected SCG (e.g., if valid scheduling request (SR) resources are configured and / or if UL time normalization is enabled). The WTRU may provide an activation indication using any of the mechanisms described herein to indicate acceptable SCGs.

[0109] The WTRU may provide an indication to the dormant SCG, for example, based on an action on the MCG. The WTRU may be configured to perform one or more actions on the dormant SCG based on one or more of the triggers described herein (e.g., before or as part of activating the dormant SCG). The actions may be performed in a predefined order. The actions may include, for example, one or more of the following: The actions may include transmitting an SR to the SCG; The actions may include transmitting a RACH message (e.g., a RACH preamble) to the SCG; The actions may include transmitting a CSI reference signal (CSI-RS) report and / or beam measurements to the SCG; The actions may include initiating transmission of an SRS; The actions may include initiating a beam management procedure on the SCG; The actions may include changing beam management behavior or configuration on the SCG (e.g., changing from a wide beam to a narrow beam, changing the number of beams being monitored / reported, etc.). The actions may include starting PDCCH monitoring on the SCG. For example, the WTRU may start normal PDCCH monitoring after the transmission. The WTRU may perform PDCCH monitoring for a response and may continue such monitoring after receiving the response, e.g., if the response is positive (e.g., indicating SCG activation).

[0110] Activation of the SCG may be signaled by the network (e.g., via RRC signaling or MAC control element (CE) by the MCG). Activation of the SCG may be characterized in the WTRU, for example, by active PDCCH monitoring on the SCG. The WTRU may be configured (e.g., prior to such activation) with a trigger that initiates an action (e.g., one or more of the actions described herein) prior to receipt of the activation message.

[0111] The WTRU may be configured with a dedicated RACH configuration and / or a dedicated SR configuration and may send an indication to the SCG. The WTRU may be configured with a dedicated RACH configuration and / or a dedicated SR configuration and may perform access to a dormant SCG. The WTRU may perform a RACH procedure or send an SR to a dormant SCG based on one or more of the following: The WTRU may perform a RACH procedure or send an SR to a dormant SCG based on a timing advance timer (TAT) associated with the MCG and / or SCG (e.g., the WTRU may perform a RACH if the TAT expires in the SCG). The WTRU may perform a RACH procedure or send an SR to a dormant SCG based on the WTRU's configuration for random access and / or scheduling requests. For example, the WTRU may perform a RACH procedure if the WTRU is not configured with SR resources, or the WTRU may perform a RACH procedure if the WTRU is configured with dedicated RACH resources. As referred to herein, performing a RACH or a RACH procedure may include sending and / or receiving random access related messages such as a random access preamble, a random access request, a random access response, and the like.

[0112] The WTRU may trigger a BSR to the MCG and trigger random access, and / or a scheduling request to the SCG, for example, when the amount of PDCP or RLC data on one or more split bearers (e.g., on all split bearers) exceeds a threshold. The WTRU may initiate an SR or RACH request transmission to the SCG, for example, when the WTRU triggers a BSR transmission (e.g., to the MCG). The SR or RACH trigger to the SCG may be adjusted, for example, to the available data on one or more split bearers (e.g., on all split bearers) when the BSR is triggered. The WTRU may send an SR or RACH request when the available data at the WTRU on one or more split bearers (e.g., on all split bearers) exceeds a threshold (e.g., at the time of the BSR). The WTRU may be configured with a BSR trigger that is associated with a trigger related to data arrival.

[0113] The WTRU may receive an indication from the network (e.g., from the MCG) to initiate a procedure towards the SCG. This indication may be included, for example, in a downlink control information (DCI) message, a MAC CE, or an RRC message. In response to receiving such a message, the WTRU may initiate an SR or RACH procedure towards the SCG. The WTRU may initiate a procedure towards the SCG with or without sending an RRC message to the SCG. For example, the WTRU may initiate a RACH procedure towards the SCG without sending an RRC reconfiguration-related message to the SCG. For example, the WTRU may perform a beam failure recovery procedure based on a trigger. The WTRU may initiate a beam management procedure based on a trigger. The WTRU may perform a sequence of one or more of the actions described herein, in any order, based on the triggers described herein. For example, the WTRU may (e.g., initially) send a RACH request, (e.g., after sending the RACH request) start monitoring CSI-RS, start reporting CSI-RS, and / or change the manner of CSI-RS monitoring and / or reporting.

[0114] The WTRU may initiate CSI-RS measurements and reporting to the SCG based on a trigger (e.g., one or more of the triggers described herein). The WTRU may provide an indication to the SCG implicitly, for example, by reporting CSI-RS measurements. The WTRU may maintain one or more behaviors associated with sending indications or messages to the SCG (e.g., CSI-RS measurements and / or reporting), for example, for a period of time or until receipt of an activation command (e.g., by the MCG or SCG). The CSI-RS measurement / reporting configuration may be specific to the period between the trigger and the activation command, which may be referred to as the SCG warm-up period. The WTRU may remain in SCG warm-up for a finite period of time before resuming WTRU procedures associated with, for example, an SCG dormant state. The WTRU may start a timer based on a trigger, for example, an indication to the SCG. The WTRU may move the SCG to the activated state and perform procedures associated with the activated state (e.g., normal connected mode procedures), for example, if the WTRU receives an activation command. The WTRU may stop the procedures associated with the SCG warm-up period and may perform the procedures associated with the SCG inactive state, for example, if the timer expires.

[0115] Beam management may be provided for dormant SCGs. A WTRU may select a beam on which it can perform beam management for one or more dormant SCGs. A WTRU may be configured to perform beam management for SCGs in an dormant state. A WTRU may selectively perform beam management for a subset of SCGs (e.g., when multiple SCGs are configured). A WTRU may be configured to perform beam management (e.g., for at least N SCGs and / or for at least M SCells). In some examples, a WTRU may be configured to perform beam management for the top K PCells and SCells, e.g., whose reference signal received power (RSRP) and / or reference signal received quality (RSRQ) and / or signal to noise and interference ratio (SINR) are above a threshold. The values ​​of N, M, and K may be pre-configured.

[0116] The WTRU may be configured to activate an SCG if a beam failure is detected for at least one SCell in that SCG. The WTRU may then perform a beam failure recovery procedure defined for the SCG. The WTRU may enter a dormant state for that SCG (e.g., based on successful beam failure recovery). The WTRU may activate a second dormant SCG (e.g., based on beam recovery failure in a first dormant SCG). The WTRU may activate a second dormant SCG if the beam quality associated with the second SCG is above a threshold. The WTRU may select an SCG for activation based on preconfigured criteria described herein. If beam failure recovery in a dormant SCG fails, the WTRU may report such failure to the MCG, for example, using an SCG failure indication procedure. The WTRU may delay (e.g., perform at a later time) beam failure indication and / or beam failure recovery for the dormant SCG.

[0117] A WTRU performing beam management of a dormant SCG in which a beam failure is triggered may perform a beam failure indication and / or report to the network, e.g., then proceed with a beam failure recovery procedure. The indication and / or recovery procedure may be delayed until a later time or until a trigger condition is met. The WTRU may maintain the beam failure state (e.g., the beam failure may still remain pending) and corresponding information until a future trigger. The WTRU may affect the beam failure (e.g., provide a beam failure indication and / or perform beam failure recovery), e.g., based on (e.g., in connection with or after) a future trigger. The triggers described herein may include one or more of the following: The trigger may be the WTRU receiving an SCG activation message or command from the network. The trigger may be the WTRU deciding to autonomously activate an SCG (e.g., based on a trigger described herein). The trigger may be the WTRU performing a state transition (e.g., leading to deactivation or vice versa). The trigger may be (e.g., any) trigger associated with data arriving at the WTRU, such as data arriving on a bearer, where the bearer may be configured to trigger such an action (e.g., an SCG bearer or a split bearer), or the bearer may have inherent characteristics associated with latency or similar QoS characteristics (e.g., a bearer associated with a logical channel prioritization (LCP) restriction). The trigger may be that a current buffer status at the WTRU, such as a buffer status associated with one or more bearers, is above or below a threshold (e.g., ul-dataSplitThreshold). The trigger may include the expiration of a timer. The trigger may include a mobility event in the MCG and / or SCG (e.g., HO, conditional HO, SCG change, or conditional SCG change). The trigger may be that a measurement report is triggered based on other measurement-related triggers associated with the MCG and / or SCG.For example, the WTRU may report a pending beam failure indication based on a WTRU-configured measurement event related to the quality of cells in the MCG and / or SCG, or the WTRU may report a beam failure of an inactive SCG as part of an RRM-triggered measurement report associated with such an event. The trigger may be the WTRU receiving a reconfiguration from the network (e.g., the WTRU receiving a new beam failure recovery configuration). The trigger may be based on measurements of candidate or failing beams (e.g., the WTRU may trigger a beam failure recovery action if one or more candidate beams are measured above a threshold after a beam failure declaration).

[0118] The WTRU may be configured with one or more conditions for keeping beam failure pending. The WTRU may be configured with one or more conditions for delaying beam failure recovery. The WTRU may initiate beam failure recovery (e.g., immediately after or shortly after beam failure), which may include activating a dormant SCG if one or more conditions associated with delaying beam failure recovery are not met. The WTRU may delay beam failure recovery, for example, if at least one of the following conditions is not met: The WTRU may delay beam failure recovery based on the type or amount of data available for transmission at the WTRU. The WTRU may delay beam failure recovery based on network configuration. For example, the WTRU may be configured to delay beam failure recovery if data pending for transmission at the WTRU is associated with a particular LCH or a particular radio bearer. For example, the WTRU may be configured with a set of LCHs on which the WTRU should perform beam failure recovery (e.g., immediately after beam failure) if data is available for transmission over the bearer. The WTRU may be configured to delay beam failure recovery, for example, if the amount of data available for transmission at the WTRU falls below a threshold for a subset of radio bearers. As another example, the WTRU may be configured with configuration information indicating when the WTRU should delay beam failure recovery procedures (e.g., when an SCG is pending) or when the WTRU should perform beam failure recovery without a delay (e.g., immediately after beam failure). Such configuration information may be provided explicitly or implicitly (e.g., via higher layer signaling), for example, based on the configuration of the RS when the SCG is dormant and / or based on the beam recovery resources (e.g., the configuration may indicate whether the WTRU is configured with beam recovery resources while the SCG is pending or not pending, the configuration may indicate the respective beam recovery resources for the WTRU to use while the SCG is pending and not pending, etc.).

[0119] The WTRU may report a beam failure event in an SCG to the MCG. For example, the WTRU may report a beam failure event detected in an inactive SCG to the MCG. The beam failure indication or report provided by the WTRU may include one or more of the following: The beam failure indication or report may include a report of the beam failure event (e.g., failure type). The beam failure indication or report may include a report of the beam index or identification of the failed beam. The beam failure indication or report may include an identification of the specific SCG configuration in which the beam failure occurred (e.g., if the WTRU has multiple saved or inactive SCG configurations). The beam failure indication or report may include measurements of the failed beam, all candidate beams, or a subset of candidate beams (e.g., the N best candidates). The beam failure indication or report may include, for example, one or more of an RRC message (e.g., an SCGFailureIndication message or equivalent RRC message), a MAC CE, a physical uplink control channel (PUCCH) transmission, an SR transmission or similar uplink control information (UCI) transmission, and / or a random access preamble transmission.

[0120] The WTRU may receive a configuration (e.g., a new configuration) for a pending beam failure event. The WTRU may receive a configuration (e.g., a new configuration) for beam recovery (e.g., RACH resources and / or candidate beams) after a beam failure indication. The WTRU may receive a configuration from the MN, for example, via an RRC message, MAC CE, and / or DCI. The WTRU may receive a configuration after transmission of a beam failure indication. The WTRU may receive a configuration (e.g., independent of transmission of a failure indication) based on one or more of the triggers discussed herein. The WTRU may apply a configuration for beam failure recovery (e.g., based on receiving a configuration), for example, if beam failure recovery is triggered. For example, the WTRU may store a received RACH configuration for beam failure recovery and provide that configuration at the time of beam failure recovery trigger for the pending beam failure. The WTRU may maintain the most recently received configuration for application of beam failure recovery.

[0121] The WTRU may determine whether to perform a beam failure recovery action in response to detecting a beam failure (e.g., immediately thereafter) or to delay the beam failure recovery action (e.g., until a later time, such as activation of a dormant SCG), based on, for example, whether the WTRU receives a new configuration associated with the beam failure in response to transmitting a beam failure indication. In one example, the WTRU may delay beam failure recovery (e.g., until a future trigger occurs as described herein) if the WTRU does not receive a configuration in response to transmitting a beam failure report or indication.

[0122] The WTRU may have the following behaviors while beam failure recovery is pending in an inactive SCG. For example, the WTRU may detect a beam failure in an inactive SCG and keep the beam failure pending until a trigger (e.g., one or more of the triggers described herein) occurs. The WTRU may do one or more of the following while beam failure recovery is pending in an inactive SCG: The WTRU may stop (e.g., all) beam measurements in (e.g., all) beams of the inactive SCG until a later time (e.g., until a beam failure recovery action is triggered or a beam failure recovery trigger). For example, the WTRU may stop (e.g., all) beam measurements in (e.g., all) beams of the inactive SCG until SCG activation. The WTRU may start beam measurements according to or during the activation procedure. The beam measurements may be facilitated (e.g., by the network) by transmission of an RS signal at the time of activation. The WTRU may start the beam recovery procedure after performing initial measurements after or during activation. The WTRU may continue to perform beam measurements for the failed beam and / or candidate beams after a beam failure and while beam failure recovery is pending. The WTRU may perform beam measurements for the failed beam and / or one or more candidate beams with reduced frequency, power, or measurement period. For example, the WTRU may perform measurements based on a new RS periodicity determined for performing beam measurements, where the RS periodicity may be configured by the network before the beam failure or after a beam failure indication to the network.

[0123] The WTRU may cancel a pending beam failure recovery, for example, if the beam improves. For example, the WTRU may cancel a pending beam failure recovery if the failing beam measurements improve while the beam failure remains pending. The WTRU may avoid performing a beam failure recovery procedure, for example, if a trigger (e.g., later activation) occurs. A WTRU canceling a pending beam failure recovery may provide an indication to the network regarding the cancellation. This cancellation message may be similar to the original message indicating the pending beam failure recovery.

[0124] The time at which a WTRU reports a beam failure, receives a configuration associated with the beam failure, or recovers from the beam failure may vary based on multiple factors. For example, the WTRU may report the beam failure at or near the time of the beam failure (e.g., immediately after detecting the beam failure). The WTRU may receive a configuration associated with the beam failure after the report, and the WTRU may initiate beam failure recovery at the time of activation. The WTRU may report the beam failure to the network (e.g., at or near the time of the failure), receive a beam failure configuration such as a new beam failure configuration (e.g., which may provide dedicated RACH resources) around the time of the beam failure report, and perform beam failure recovery actions after activation of the SCG in which the beam failure occurred.

[0125] The WTRU may report a beam failure at or near the time of the failure (e.g., immediately after the failure), receive a configuration associated with the beam failure with SCG activation, and initiate beam failure recovery with activation. For example, the WTRU may report a beam failure to the network at or near the time of the failure (e.g., immediately after the failure), receive a beam failure configuration (e.g., which may provide dedicated RACH resources), such as a new beam failure configuration with activation, and perform beam failure recovery actions according to the configuration received after SCG activation.

[0126] The WTRU may report beam failure upon SCG activation, receive a RACH configuration upon activation, and perform beam failure recovery upon activation. For example, the WTRU may detect a beam failure but delay reporting and recovery of the beam failure until SCG activation. The WTRU may report a beam failure indication during activation and receive a corresponding configuration for beam failure recovery. The WTRU may perform beam failure recovery to the SCG, for example, after activation and / or after receiving the configuration.

[0127] The WTRU may decide not to report beam failure and then receive a RACH configuration upon activation of the SCG and perform beam failure recovery upon the activation. For example, the WTRU may detect beam failure and perform recovery actions upon activation of the SCG. The WTRU may receive the RACH configuration upon activation (e.g., as part of signaling for the activation procedure). The WTRU may perform beam failure recovery to the SCG based on the configuration received upon activation signaling or thereafter.

[0128] The WTRU may not report a beam failure or receive a RACH configuration and still be able to perform beam failure recovery (e.g., with the original or existing RACH configuration) upon SCG activation. For example, the WTRU may perform recovery (e.g., without reporting recovery) at or after SCG activation, e.g., by utilizing a stored RACH configuration. Such a stored RACH configuration may have been received before the beam failure (e.g., when the SCG was placed in an inactive state or while the SCG was inactive).

[0129] The WTRU may report the beam failure at or near the time of failure (e.g., immediately after the beam failure), receive a RACH configuration periodically after the failure (e.g., immediately after the failure), and perform beam failure recovery upon SCG activation. For example, the WTRU may report the beam failure to the MCG at or near the time of failure (e.g., immediately after the beam failure). The WTRU may continue to report measurements to the network periodically (e.g., based on a configured period) while the beam failure in the SCG is pending. The WTRU may update its RACH configuration, for example, as part of the periodic reporting procedure. The WTRU may receive the configuration while the beam failure is pending. The WTRU may perform beam failure recovery upon activation (e.g., at or after SCG activation) using the last saved configuration.

[0130] FIG. 2 illustrates example timing for beam failure reporting, configuration, and recovery. In the example scenario illustrated in FIG. 2, a WTRU may report a beam failure at or near the time of the beam failure (e.g., immediately after the beam failure), receive configuration upon SCG activation, and recover from the beam failure upon activation. The numbers illustrated in FIG. 2 may indicate, by way of example, the order in which each action occurs, although the order of occurrence or interactions and / or interaction participants illustrated in the figure may differ in other examples. As illustrated in the example of FIG. 2, one or more of the following may be performed by the WTRU: The WTRU may receive an SCG suspend message (e.g., an RRC message) from the MN. The WTRU may suspend the SCG and continue to perform beam measurements on one or more SCG SCells while the SCG is suspended. A beam failure may be detected (e.g., at a subsequent time) by the WTRU on a cell associated with the SCG. The WTRU may send a beam failure indication message to the MN. The MN may decide to activate the failed SCG (e.g., at a subsequent time) and may send an SCG activation RRC message (e.g., including beam failure recovery resources) to the WTRU. The WTRU may perform a beam failure recovery procedure (e.g., a RACH procedure) to the SCG (e.g., using the resources provided in the SCG activation RRC message).

[0131] The WTRU may be configured to handle an MCG failure while in an SCG dormant state. For example, the WTRU may detect an MCG failure when at least one SCG is in an dormant state. In such a case, the WTRU may not declare a radio link failure (RLF), e.g., may not immediately declare an RLF. The WTRU may be configured to activate a dormant SCG, and under normal activation conditions, the WTRU may send an MCG failure report to the SCG. The MCG failure report may be sent during a procedure in which SCG activation is indicated to the network, or the MCG failure report may be sent after (e.g., immediately after) the procedure for SCG activation.

[0132] The WTRU may be configured to deactivate an SCG based on one or more preconfigured triggers. The WTRU may apply one or more triggers described herein (e.g., described in connection with a conditional PSCell change) when deactivating an SCG. For example, a trigger applicable to changing from one SCG to another may be applicable to deactivating an SCG while activating a separate SCG.

[0133] The WTRU may be configured to handle conditional SCG reconfiguration failures. There may be trigger conditions associated with conditional SCG reconfiguration failures. For example, the WTRU may be triggered to apply a conditional SCG configuration or reconfiguration if a previous conditional SCG reconfiguration failed. The WTRU may be configured with multiple conditional SCG configurations, and the WTRU may attempt to apply a conditional SCG reconfiguration to a second SCG if the conditional SCG reconfiguration failed with a first SCG. In some examples, the WTRU may be configured to report a conditional SCG reconfiguration failure to the MCG. This may be done via an SCG failure information message, for example, if all conditional SCG reconfigurations failed, if n (e.g., n≧1) conditional SCG reconfigurations failed, or if the conditional SCG reconfiguration did not meet any of the trigger conditions configured for SCG reconfiguration.

[0134] The WTRU may receive an indication or configuration of an acceptable SCG. The WTRU may be configured to determine the acceptability of a stored or received SCG configuration (e.g., based on measurements). For example, the WTRU may determine the acceptability of an SCG configuration based on measurements of some or all of the cells associated with the SCG (e.g., RSRP / RSRQ measurements of cells above a threshold). The WTRU may determine the acceptability of an SCG or SCG configuration based on PSCell quality being above a threshold.

[0135] The WTRU may determine the acceptability of an SCG or SCG configuration based on a timer associated with SCG expiration. Such a timer may indicate the last time the WTRU accessed the SCG, the last time the WTRU performed a resumption procedure to enter the RRC_CONNECTED state, etc. The WTRU may determine the acceptability of an SCG or SCG configuration based on CSI measurements performed on a cell of the SCG (e.g., a PSCell of the SCG). For example, the WTRU may perform CSI measurements on a PSCell without reporting such measurements to the network. The WTRU may determine the acceptability of an SCG or SCG configuration based on beam measurements performed on the SCG. For example, the WTRU may determine whether an SCG or SCG configuration is acceptable based on whether a beam failure is detected on a PSCell of the SCG. The WTRU may perform beam failure detection on a PSCell of an inactive SCG and may activate the inactive SCG (e.g., to perform beam failure recovery).

[0136] The beam measurements performed on the SCG may or may not be related to triggers associated with conditional SCG addition and / or reconfiguration. The WTRU may indicate acceptability of the SCG or SCG configuration to the network. The WTRU's indication of acceptability of the SCG or SCG configuration to the network may occur under one or more of the following conditions: The WTRU may indicate acceptability of the SCG or SCG configuration to the network when the WTRU decides to activate a pending or dormant SCG while the WTRU is in RRC_CONNECTED. The WTRU may indicate acceptability of the SCG or SCG configuration to the network when the WTRU resumes from INACTIVE to RRC_CONNECTED using the saved SCG or SCG configured in the WTRU in a resume message. The WTRU may indicate acceptability of the SCG or SCG configuration to the network when the WTRU decides to suspend an active SCG while the WTRU is in RRC_CONNECTED. If the WTRU determines that the SCG moves from an acceptable state to an unacceptable state or vice versa (e.g., if the WTRU detects a beam failure on a PSCell), the WTRU may indicate the acceptability of the SCG or SCG configuration to the network.

[0137] The WTRU may trigger an RRC failure message transmission to the MCG based on a determination of an unacceptable SCG or SCG configuration. The WTRU may send an RRC failure message (e.g., SCGFailureIndication) to the MCG if the stored and / or configured SCG is unacceptable (e.g., an SCGFailureIndication message may be triggered based on measurements of the stored / configured SCG). The WTRU may be instructed by the network (e.g., during a transition from INACTIVE to CONNECTED) to resume the stored SCG configuration (e.g., with a resume message or command to the WTRU). The WTRU may compare measurements of the associated PSCell with the stored SCG configuration (e.g., collected while INACTIVE) and may send an SCG failure (e.g., SCGFailureIndication) or another RRC error message to the MCG if the PSCell quality is below a threshold. The error message transmission may be performed before sending a random access channel (RACH) request to the SCG or before the WTRU attempts to access the SCG. The WTRU may be configured with the SCG configuration in a resume message from the network during the WTRU's transition to RRC_CONNECTED. The WTRU may determine whether measurements of the SCG's PSCells exceed a threshold (before accessing the SCG). The WTRU may send an RRC error message after or along with the RRC completion message indicating the WTRU's transition to RRC_CONNECTED (e.g., if measurements of the SCG's PSCells do not exceed a threshold). The WTRU may be configured with a dormant SCG and / or a suspended SCG. The WTRU may trigger activation of a dormant and / or suspended SCG based on a particular trigger (e.g., a data-related trigger), and if the WTRU determines that a previously dormant and / or suspended SCG or one of the SCGs is determined to be unacceptable, the WTRU may send an RRC failure message to the MCG or another SCG.

[0138] The WTRU may perform random access to the SCG if the SCG is acceptable. The WTRU may indicate whether the SCG is acceptable to the SCG via one or more random access messages. The WTRU may perform random access to the SCG if the SCG is acceptable, and the WTRU may not perform random access to the SCG if the SCG is not acceptable. The WTRU may be configured with an SCG, and the configuration may be saved while the WTRU is in the INACTIVE state. The WTRU may receive a resume message with instructions from the network to resume the saved SCG. The WTRU may evaluate whether the SCG is acceptable, and if the SCG is acceptable, the WTRU may initiate random access to the PSCell of the saved SCG. The WTRU may stop performing the RACH procedure if the SCG is determined to be unacceptable by the WTRU. If the WTRU determines that the SCG is unacceptable, the WTRU may keep the SCG configuration in an inactive or pending state until the WTRU is reconfigured with a new SCG. The WTRU may then release the saved configuration. The WTRU may be configured with SCGs in the resume message that it can access when in the RRC_CONNECTED state, and the WTRU may determine whether the SCG is acceptable. The WTRU may perform random access to the configured SCG if it is determined that the SCG is acceptable. The WTRU may refrain from performing random access to the configured SCG if the SCG is not acceptable. The WTRU may perform contention-free or contention-based random access depending on whether the SCG is acceptable. For example, the WTRU may perform contention-free random access if the SCG is acceptable, and may perform contention-based random access if the SCG is not acceptable.

[0139] The WTRU may access the SCG (e.g., perform one or more accesses, such as a random access operation to the SCG) before initiating a resume procedure to the MCG. In examples, the WTRU may be configured to perform the access operation to the SCG (e.g., based on a saved SCG configuration) during a transition from INACTIVE to RRC_CONNECTED. The WTRU may perform the access operation before initiating a resume procedure to the MCG, during the resume procedure to the MCG (e.g., as part of the resume procedure to the MCG), or before completion of the resume procedure.

[0140] Accessing the SCG before the resumption procedure to the MCG may include one or more of: performing a RACH procedure to the SCG, sending an RRC message or data PDU to the SCG, performing a beam failure recovery procedure to the SCG, and / or sending uplink control signals (e.g., SR, PUCCH) to the SCG. The access procedure to the SCG may include one or more other operations or procedures described herein with respect to a dormant SCG.

[0141] The WTRU may determine whether it is allowed to access the SCG before the resume procedure to the MCG (e.g., before sending a resume request or initiating a resume operation) according to one or more of the following conditions: The WTRU may determine whether it is allowed to access the SCG based on a condition related to the time criticality of the data arriving at the WTRU. For example, a RACH procedure to the SCG before the resume procedure or completion of the resume procedure is allowed if the data at the WTRU may be transmitted on a pre-configured LCH (e.g., via LCP restrictions or a specific L1 profile), allowing the RACH procedure (e.g., according to the time criticality of the LCH). The WTRU may determine whether it is allowed to access the SCG based on a condition related to the bearer type associated with the data arriving at the WTRU. For example, a RACH procedure to the SCG before the resume procedure or completion of the resume procedure may be allowed if the data arriving at the WTRU will be transmitted over an SCG bearer. The WTRU may determine whether it is allowed to access the SCG based on a combination of the above conditions. For example, a RACH procedure to the SCG before the completion of the resume procedure may be allowed if the data arriving at the WTRU will be transmitted over an SCG bearer and the LCH associated with that data is configured with LCP restrictions or a specific L1 profile that allows the RACH procedure. The WTRU may determine whether it is allowed to access the SCG based on a comparison of the priorities of the data intended for the MCG and the SCG. For example, a RACH procedure to the SCG before the completion of the resume procedure may be allowed if the data pending at the WTRU at the time of the resume procedure indicates that the priority of the SCG data is higher than the priority of the MCG data. The WTRU may determine whether it is allowed to access the SCG based on information included in the paging message.For example, a RACH procedure to the SCG prior to the completion of the resumption procedure or the resumption procedure may be requested by the network, for example via a specific indication in a paging message.

[0142] A WTRU configured to access the SCG before performing a resume procedure to the MCG may delay initiation of the resume procedure or one or more actions related to the resume procedure, for example, until successful completion of access to the SCG. The WTRU may provide an indication of successful or unsuccessful SCG access to the network during the resume procedure. For example, the WTRU may include an SCGFailureInformation message in a resume complete message. The WTRU may include a pass / fail indication in the resume message to indicate the pass / fail status of the SCG access before the resume procedure. The WTRU may select from a subset of RACH preambles to indicate the pass / fail status of the SCG access before the resume procedure. The WTRU may select a RACH type (e.g., two-step RACH vs. four-step RACH) or include a pass / fail indication in data transmitted in the two-step RACH procedure.

[0143] The WTRU may be configured to handle an MCG failure during (e.g., simultaneously with) a tolerability indication procedure toward the SCG. For example, the WTRU may detect an RLF associated with the MCG while a procedure associated with a tolerability indication or conditional SCG configuration has been initiated or is in progress. In such a case, the WTRU may not immediately declare RLF, for example. The WTRU may wait for the result of the tolerability indication toward the SCG or the conditional SCG configuration. The WTRU may indicate an MCG failure based on a determination that the tolerability indication toward the SCG or the conditional SCG configuration is passed. The WTRU may declare RLF based on a failed tolerability indication toward the SCG. The WTRU may be configured with a timer or period for completing the tolerability indication or the conditional SCG configuration, and the WTRU may trigger connection re-establishment if the tolerability indication or the conditional SCG configuration is not completed before expiration of the timer or period.

[0144] The WTRU may provide SCG allowability information to the MCG via a RACH procedure (e.g., a two-step RACH procedure). The WTRU may initiate a RACH procedure to the MCG to indicate whether the stored, configured, and / or pending SCG is allowable. In some examples, the WTRU may initiate a new RACH procedure to indicate the allowability of the stored, configured, and / or pending SCG. In some examples, the WTRU may provide the allowability information in a RACH procedure triggered for other purposes (e.g., for resumption to RRC_CONNECTED). The WTRU may perform a RACH procedure to the MCG while resuming to the RRC_CONNECTED state and may provide the RACH procedure with an indication of the validity of the SCG configuration. The WTRU may provide the allowability information as part of the payload of the two-step RACH procedure (e.g., in MSG B of the RACH procedure). The WTRU may provide an indication to MSG B as to whether the SCG is valid. A WTRU in RRC_CONNECTED with a suspended and / or dormant SCG may be configured with one or more dedicated preambles associated with an SCG that is or is not acceptable, and may perform a RACH procedure using the appropriate preamble (e.g., depending on the WTRU's measurements and a determination of the acceptability of the SCG). The WTRU may perform such a RACH procedure based on receiving an indication from the network (e.g., a PDCCH order) to perform the RACH procedure.

[0145] The WTRU may send a Medium Access Control (MAC) Control Element (CE) to the MCG with information or an indication of SCG allowance. The WTRU may send the MAC CE to the MCG to indicate SCG allowance, reasons for non-allowance, a specific SCG configuration for which the WTRU is reporting allowance information, and / or any combination thereof.

[0146] The WTRU may be configured to support concurrent (e.g., coexisting) CPAC and CHO configurations, including receiving CPAC and CHO configurations simultaneously. In examples, the WTRU may receive an RRC configuration or reconfiguration message associated with CPAC (e.g., associated with a CPAC configuration) when an RRC configuration or reconfiguration associated with CHO may already exist (e.g., may already be stored) on the WTRU and / or the WTRU may have already started monitoring trigger conditions for CHO. The WTRU may receive the CPAC configuration over one or more signaling radio bearers (SRBs), such as SRB1 or SRB3. This CPAC configuration may be associated with an intra-secondary node (intra-SN) or inter-secondary node (inter-SN) change. In examples, the WTRU may receive an RRC configuration or reconfiguration message associated with the CHO (e.g., associated with a CHO configuration) when an RRC configuration or reconfiguration associated with the CPAC may already exist on the WTRU (e.g., may already be stored) and / or the WTRU may have already started monitoring for trigger conditions for the CPAC. The WTRU may receive the CHO configuration via one or more SRBs, such as SRB1.

[0147] A WTRU may be configured to take one or more of the following example approaches for handling CPAC configuration or reconfiguration when the WTRU is configured with both a CPAC configuration and a CHO configuration. Different WTRU behaviors may be defined herein based on the potential capabilities of the WTRU and / or the network to support concurrent (e.g., coexisting) CPAC and CHO configurations. For example, some WTRUs may be capable of handling coexisting CPAC and CHO configurations but may not be configured to monitor both CPAC and CHO trigger conditions. Some WTRUs may be capable of monitoring both CPAC and CHO trigger conditions but may be configured to perform one configuration or reconfiguration (e.g., for CPAC or CHO) at the same time. Some WTRUs may be capable of performing both CPAC and CHO configurations or reconfigurations simultaneously. In a first example approach, the WTRU may be configured to perform one (e.g., only one) of each configuration (e.g., for CHO or CPAC). The WTRU may be configured to send an indication to the SCG (e.g., to an SN associated with the SCG) if the WTRU receives a CPAC configuration while the WTRU has already received and / or stored a valid CHO configuration. The WTRU may be configured to send an indication to the SCG (e.g., to an SN associated with the SCG) if the WTRU receives a CHO configuration while the WTRU has already received and / or stored a valid CPAC configuration (e.g., from an MN). The indication sent by the WTRU may indicate that the WTRU may not be able to comply with the CPAC or CHO configuration (e.g., because the other one of the CPAC or CHO configurations already exists on the WTRU). The indication may list having a conflicting configuration with the MN as a reason for not being able to comply with the CPAC or CHO configuration.

[0148] In a second example approach, a WTRU may be configured to receive and / or store both a CPAC configuration and a CHO configuration. The WTRU may choose to monitor trigger conditions associated with the CHO and ignore monitoring trigger conditions associated with the CPAC, or the WTRU may choose to monitor trigger conditions associated with the CPAC and ignore monitoring trigger conditions associated with the CHO.

[0149] In a third example approach, the WTRU may be configured to receive and / or store a CPAC configuration and a CHO configuration, and to monitor trigger conditions associated with both the CPAC configuration and the CHO configuration.

[0150] The behavior of the WTRU when trigger conditions associated with CHO and CPAC are satisfied (e.g., simultaneously) may be defined or pre-configured (e.g., by a network entity). For example, the WTRU may be configured to perform one or more actions associated with a CPAC configuration based on the status of one or more trigger conditions associated with the CHO configuration. The WTRU may be configured with one or more of the following behaviors:

[0151] The WTRU may prioritize CHO over CPAC. For example, the WTRU may be configured to prioritize CHO over CPAC if one or more trigger conditions associated with both CHO and CPAC are met (e.g., simultaneously). In some examples, the WTRU may abort an ongoing CPAC action if, for example, one or more trigger conditions for CHO are met. The WTRU may be configured to release one or more (e.g., all) CPAC configurations and / or stop monitoring trigger conditions associated with the CPAC configurations.

[0152] The WTRU may disable one or more CPAC actions. For example, the WTRU may be configured to disable one or more actions related to CPAC in response to determining that a CHO trigger is likely (e.g., based on the WTRU's evaluation of one or more CHO trigger conditions). The WTRU may be configured to disable one or more CPAC actions based on a preconfigured trigger condition. In some examples, the preconfigured trigger condition may be a measurement event associated with the CHO trigger condition. For example, the WTRU may be configured to stop monitoring a trigger condition associated with CPAC when the CHO trigger condition satisfies an entry condition (e.g., when a timer associated with the CHO trigger condition is progressing).

[0153] The WTRU may support concurrent execution of CHO and CPC (e.g., rather than prioritizing one over the other), including triggering or executing CHO and CPAC, e.g., simultaneously. For example, the WTRU may trigger CHO while CPAC is in progress, or the WTRU may trigger CHO while CPAC is in progress.

[0154] WTRU behavior as described elsewhere in this disclosure (e.g., related to conditional reconfiguration, monitoring of trigger conditions for conditional reconfiguration, messaging between the WTRU and network nodes related to conditional reconfiguration) may not be affected by the WTRU receiving and processing concurrent CHO and CPC configurations.

[0155] The WTRU may be configured to send an indication that the CPAC execution trigger condition is met (e.g., in an RRC message such as an RRCReconfigurationComplete message). This indication may be sent to a cell, which may depend on the progress or trigger of the CHO. The WTRU may send an indication that the CPAC execution trigger is met for a CHO candidate (e.g., a target for the triggered CHO). The WTRU may send an indication that the CPAC execution trigger is met for a PCell that is connected before the WTRU triggers CHO. The WTRU may determine the destination cell for the indication based on the timing of the triggers for CHO and / or CPAC. In some examples, the WTRU may send the indication to the source PCell if CPAC is triggered at the same time as CHO. In some examples, the WTRU may send the indication to the source PCell if the trigger time for CHO occurs after the trigger time for CPAC. In examples, the WTRU may send the indication to the CHO target if the CPAC trigger condition is met after the CHO is triggered, such as when the CPAC trigger condition is met after an offset time has elapsed since the CHO was triggered. This offset time may be a configured period of time or may be defined with respect to steps or actions taken by the WTRU in connection with the CHO. For example, the WTRU may send the indication to the CHO target if the WTRU has completed synchronization with the CHO target, if the WTRU has applied the CHO target cell configuration, etc.

[0156] The WTRU may be configured not to send an indication to perform CPAC in some circumstances (e.g., if CPAC is triggered simultaneously with CHO, if CPAC is triggered during an ongoing CHO, etc.). In some examples, the WTRU may discard sending such an indication if a triggering condition (e.g., for CPAC) is met during the execution of CHO. In some examples, the WTRU may send the indication if a triggering condition (e.g., for CPAC) causes the following completion of CHO (e.g., after receiving an acknowledgment associated with sending a completion message to the target).

[0157] The WTRU may be configured to send an instruction to perform CPAC to a network node (e.g., to a secondary node) if the CHO fails. Such a failure may occur, for example, if the WTRU did not send an instruction to perform CPAC or delayed sending the instruction to perform CPAC due to the occurrence of the CHO. The WTRU may include the instruction to perform CPAC in a failure message (e.g., an MCGFailureInformation message), which may be sent after the failed CHO.

[0158] The WTRU may be configured to delay sending an instruction to perform CPAC until CHO is completed. The WTRU may delay transmission, for example, if CPAC and CHO are triggered simultaneously or if CHO is in progress at the time a CPAC trigger condition is met. The WTRU may delay sending its instruction if CHO is likely to be triggered in the near future (e.g., if a triggering time associated with a CHO event has started). The WTRU may continue sending its instruction after CHO is completed if CHO is not triggered (e.g., if the time to trigger has not expired and / or if CHO has not been performed).

[0159] The WTRU may determine whether to send a CPAC instruction to trigger the master node or a secondary node based on, for example, the configuration of an SRB (e.g., SRB3) and / or the execution of a CHO. For example, the WTRU may send the instruction via SRB3 if SRB3 is configured and a CHO is in progress.

[0160] The WTRU may be configured with an event (e.g., a measurement event) and / or a trigger condition that is applicable to both CHO and CPAC. For example, the WTRU may be configured with a single event that is applicable to both CHO and CPAC (e.g., by including both MCG and SCG configurations in the conditional reconfiguration candidate). The WTRU may be configured with an offset or threshold associated with the trigger condition (e.g., a measurement event), which may apply to CHO or CPAC, for example, if the trigger condition applies to both. The WTRU may be configured to apply CHO if the trigger condition is met with a first threshold and to apply CPAC if the trigger condition is met with a second threshold.

[0161] The WTRU may be configured to process CPAC candidates based on the CHO or HO. The WTRU may be configured to perform one or more of the following when processing a CPAC configuration (e.g., upon completion of a CHO procedure): The radio resource configuration associated with a CPAC configuration may be a function of the current MCG. In examples, the WTRU may be configured to perform CHO while connected to the same SCG. In examples, the WTRU may be configured to perform HO while connected to the same SCG. The overall impact of changing MCGs (e.g., switching to a different MCG) while connected to the same SCG may include that one or more saved CPAC configurations may or may not be valid in the target MCG. The WTRU may be configured to determine the validity of a saved CPAC configuration based on the CHO or HO procedure. The WTRU may be configured to indicate (e.g., to a secondary node) the status of the CHO or HO procedure. Such an indication may be used (e.g., by the secondary node) to determine whether a CPAC configuration is valid and / or to reconfigure (e.g., update) an existing CPAC configuration if it is no longer valid. One or more of the following techniques may be applicable to both CHO and HO, even though the techniques are described in the context of CHO.

[0162] The WTRU may be configured to perform one or more actions associated with a stored CPAC configuration (if present) when the WTRU successfully completes the CHO procedure and / or when a trigger condition associated with the CHO is met. The WTRU may be configured to perform one or more of the following: The WTRU may send an indication to the SCG (e.g., to a network node associated with the SCG) when the WTRU successfully completes the CHO. The WTRU may include an identification of the new PCell in the indication. The WTRU may send such an indication if an SRB (e.g., SRB3) is configured towards the SCG. The WTRU may send such an indication when a stored CPAC configuration is received from a secondary node, for example, when the WTRU determines that the master node is not included in the CPAC configuration.

[0163] The WTRU may send an indication to the SCG (e.g., to a network node associated with the SCG) if one or more trigger conditions associated with the CHO are met. The WTRU may include identification information of the cell for which the one or more CHO trigger conditions are met. The WTRU may send such an indication if an SRB (e.g., SRB3) is configured for the SCG. The WTRU may send such an indication if a stored CPAC configuration is received from a secondary node, for example, if the WTRU determines that the master node is not included in the CPAC configuration.

[0164] The WTRU may be configured to release (e.g., autonomously release) the stored CPAC configuration if the CHO is completed successfully. The WTRU may stop monitoring a trigger condition associated with the released CPAC configuration. The WTRU may send an instruction to the SCG (e.g., to a network node associated with the SCG) indicating the release of the CPAC configuration.

[0165] The WTRU may be configured to suspend (e.g., autonomously suspend) the stored CPAC configuration if the CHO completes successfully. The WTRU may stop monitoring a trigger condition associated with the suspended CPAC configuration. The WTRU may send an indication to the SCG (e.g., to a network node associated with the SCG) indicating the suspension of the CPAC configuration. The WTRU may receive a command (e.g., from the SCG) to activate and / or reconfigure the suspended CPAC configuration.

[0166] The WTRU may be configured to selectively release or suspend CPAC configurations based on the completion of the CHO. The WTRU may be configured to suspend or release CPAC configurations based on one or more of the following conditions: The WTRU may be configured to suspend or release CPAC configurations based on the origin of the CPAC configurations. For example, the WTRU may be configured to release or suspend those CPAC configurations received from secondary nodes and maintain CPAC configurations received from the master node. The WTRU may be configured to release or suspend those CPAC configurations received from the master node and maintain CPAC configurations received from secondary nodes.

[0167] The WTRU may be configured to suspend or release a CPAC configuration based on the compatibility of the CPAC configuration with a cell group. For example, the WTRU may be configured to release a CPAC configuration that is no longer compatible with the new MCG after CHO. The WTRU may be configured with CPAC configuration compatibility information for (e.g., each) CHO candidate, e.g., via a linkage configuration. The WTRU may maintain those (e.g., only those) CPAC configurations associated with CHO candidates for which CHO was successfully completed.

[0168] The WTRU may be configured to suspend or release a CPAC configuration based on an explicit configuration. For example, the WTRU may be explicitly configured (e.g., by the network) as to which one or more CPAC configurations may be maintained after a successful CHO or HO procedure. The WTRU may be explicitly configured (e.g., by the network) as to which one or more CPAC configurations should be released after a successful CHO or HO procedure.

[0169] The WTRU may be configured to process one or more CHO candidates based on CPAC. The WTRU may be configured to process a CHO configuration based on completion of the CPAC procedure. The radio resource configuration associated with a CHO configuration may be a function of the current SCG associated with the WTRU. In some examples, the WTRU may be configured to perform CPAC while one or more CHO configurations are stored and / or when the WTRU is connected to the same MCG.

[0170] The WTRU may be configured to determine the validity of a stored CHO configuration based on the execution of a CPAC procedure. The WTRU may be configured to indicate the status of the CPAC procedure to the master node. Such an indication may be used by the master node to determine whether the CHO configuration is valid and / or whether to reconfigure the CHO configuration if it is no longer valid.

[0171] The WTRU may be configured to determine potential CHO candidates as a function of the serving SCG. The WTRU may be configured with an association (e.g., mapping) between CPAC configurations and CHO configurations. Two or more CPAC configurations may be associated with the same CHO configuration, and vice versa. The WTRU may be configured to activate and deactivate one or more linked CHO configurations, for example, when the serving SCG changes due to a CPAC procedure. The WTRU may release CHO configurations that are not linked to the current SCG. The WTRU may be configured to report an indication to the MCG (e.g., to a network node associated with the MCG) regarding the status of CHO candidates based on successful CPAC completion. The WTRU may be configured to perform one or more of the functions described herein for (e.g., only for) a CPAC configuration configured by the SCG.

[0172] The WTRU may be configured to perform one or more actions (if any) associated with the stored CHO configuration when the WTRU successfully completes a CPAC procedure, when a trigger condition associated with the CPAC is met, etc. The WTRU may be configured with one or more of the following behaviors:

[0173] The WTRU may send an indication to the MCG (e.g., to a network node associated with the MCG) when it completes CPAC (e.g., if CPAC completed successfully, if CPAC resulted in a failure, etc.). The WTRU may include an identification of the new PSCell in the indication. The WTRU may send such an indication if an associated CPAC configuration is received from an SCG (e.g., from a network node associated with the SCG). The WTRU may send such an indication if a CPAC configuration is received from a secondary node, e.g., if the WTRU can determine that the master node is not included in the CPAC configuration.

[0174] The WTRU may send an indication to the MCG (e.g., to a network node associated with the SCG) if one or more trigger conditions associated with CPAC are met. The WTRU may include identification information of the cell for which the CPAC conditions are met. The WTRU may send such an indication if the CPAC configuration is received from a secondary node, e.g., if the WTRU can determine that the master node is not included in the CPAC configuration.

[0175] The WTRU can selectively release or suspend the CHO configuration based on the CPAC completion. The WTRU may be configured to suspend or release the CHO configuration based on one or more of the following conditions: The WTRU may be configured to suspend or release the CHO configuration based on the origin of the CPAC configuration. For example, the WTRU may be configured to suspend or release the CHO configuration if the CPAC configuration is received from a secondary node.

[0176] The WTRU may be configured to suspend or release a CHO configuration based on an explicit configuration. For example, the WTRU may be explicitly configured with respect to one or more CHO configurations to be maintained after a successful CPAC procedure. The WTRU may be explicitly configured with respect to one or more CHO configurations to be released after a successful CPAC procedure.

[0177] The WTRU may be configured to process concurrent CPAC configurations initiated by a master node (MN) and a second node (SN). A CPAC configuration from one cell group may take precedence over a CPAC configuration from another cell group. The WTRU may be configured to receive a CPAC configuration from an MN or an SN. The WTRU may be configured to process a CPAC configuration from one (e.g., only one) cell group in a preconfigured condition. One or more of the following may be applicable if a CPAC configuration is prioritized based on, for example, the SRB (e.g., SRB1 or SRB3) from which the CPAC configuration is received. Examples described herein in the context of CPAC configurations initiated by an MN and / or an SN may also be applicable to situations in which an RRC reconfiguration initiated by an MN and / or an SN may significantly affect the stored and / or active SCG configuration. Examples described herein may also be applicable if the WTRU is configured to store at least one CPAC initiated by an SN at the WTRU (e.g., upon receiving an RRC reconfiguration from the MN). The examples described herein may also be applicable when the WTRU is configured to store at least one CPAC initiated by the MN at the WTRU (e.g., upon receiving an RRC reconfiguration from the SN).

[0178] The WTRU may be configured to prioritize a CPAC configuration based on the earliest arrival time of the CPAC configuration. In some examples, the WTRU may ignore a CPAC configuration received from an SN (e.g., if the WTRU receives a CPAC configuration from an SN while the WTRU has a valid CPAC configuration received from the MN and stored at the WTRU). The WTRU may be configured to send a failure message to the SN indicating its inability to comply with the CPAC configuration and the reason for the inability (e.g., an earlier configuration from a different cell group exists at the WTRU). In some examples, the WTRU may ignore a CPAC configuration received from an MN (e.g., if the WTRU receives a CPAC configuration from an MN while the WTRU has a valid CPAC configuration received from an SN and stored at the WTRU). The WTRU may be configured to send a failure message to the MN indicating its inability to comply with the CPAC configuration and the reason for the inability (e.g., an earlier configuration from a different cell group exists at the WTRU).

[0179] The WTRU may be configured to prioritize a CPAC configuration based on the latest arrival time of the CPAC configuration. In some examples (e.g., if the WTRU receives a CPAC configuration from the SN while the WTRU has a valid CPAC configuration received from the MN), the WTRU may release the CPAC configuration received from the MN and process (e.g., store) the CPAC configuration received from the SN. The WTRU may be configured to send a failure message to the MN indicating that it cannot comply with the CPAC configuration and the reason for this (e.g., the CPAC configuration will be overwritten by a new or later-arriving configuration).

[0180] In some examples (e.g., when the WTRU receives a CPAC configuration from the MN while the WTRU has a valid CPAC configuration received from the SN), the WTRU may release the CPAC configuration received from the SN and process (e.g., store) the CPAC configuration received from the MN. The WTRU may be configured to send a failure message to the SN indicating that it cannot comply with the CPAC configuration and the reason for this (e.g., the CPAC configuration will be overwritten by a new or later arriving configuration).

[0181] The WTRU may be configured to prioritize a CPAC configuration based on a cell group or SRB associated with the WTRU. In some examples, the WTRU may prioritize a CPAC configuration received from the MN regardless of the presence of an earlier CPAC configuration received from the SN. In some examples, the WTRU may be configured to prioritize a CPAC configuration received on a first SRB (e.g., SRB1) over a CPAC configuration received on a second SRB (e.g., SRB3).

[0182] The WTRU may be configured to prioritize CPAC configurations based on explicit instructions. The WTRU may be configured to prioritize CPAC configurations based on explicit priority instructions, such as those included as part of the CPAC configurations. The WTRU may be configured to prioritize low-priority CPAC configurations over high-priority CPAC configurations.

[0183] The WTRU may be configured to process a CPAC configuration from one cell group as a function of a CPAC configuration from another cell group. The WTRU may be configured to receive and process CPAC configurations from the MCG and SCG. The WTRU may be configured with rules for processing CPAC configurations when the WTRU receives a CPAC configuration associated with the same target PSCell. For example, the WTRU may be configured to replace or modify an existing CPAC configuration with another CPAC configuration (e.g., a new CPAC configuration) if the PSCell associated with the CPAC configuration is the same. The WTRU may be configured to replace or modify an existing CPAC configuration if (e.g., only if) the previous CPAC configuration was received from the same cell group. The WTRU may be configured to report (e.g., to a network node) which cell groups have had their CPAC configurations superseded or modified.

[0184] The WTRU may be configured to handle an SCG failure, for example, if CPAC is configured. The WTRU may trigger an SCG failure (e.g., SCG RLF, CPAC failure, etc.) if CPAC is configured for the WTRU. The WTRU may initiate CPAC on a PSCell candidate (e.g., a stored PSCell candidate based on a previously received configuration message), for example, with or without sending SCGFailureInformation to the MN.

[0185] The WTRU may decide which of one or more of the above behaviors to follow (e.g., trigger CPAC and / or perform an SCG failure procedure) based on one or more of the following: The WTRU may determine its behavior based on the existence of a CHO configuration and / or a currently ongoing CHO procedure. For example, the WTRU may perform CPAC to a candidate PSCell after an SCG failure if the WTRU is currently performing CHO at the time CPAC is triggered. The WTRU may initiate an SCG failure procedure (e.g., sending an SCG failure indication such as an SCGFailureInformation message) to the MN.

[0186] The WTRU may determine its behavior based on the node (MN or SN) that configured the CPAC and / or the SRB used to configure the CPAC. For example, the WTRU may perform CPAC to a candidate PSCell after an SCG failure if the CPAC candidate was configured by the SN or via a specific SRB such as SRB3. Otherwise, the WTRU may initiate an SCG failure procedure (e.g., by sending an SCGFailureInformation message).

[0187] The WTRU may determine its behavior based on the presence of a CHO configuration, such as a CHO configuration linked to a CPAC configuration. For example, the WTRU may perform CPAC to a candidate PSCell after an SCG failure if the WTRU does not have a CHO configuration linked to a CPAC candidate. If the WTRU has a CHO configuration at the time of SCG failure or such a CHO configuration is linked to a CPAC candidate, the WTRU may initiate an SCG failure procedure (e.g., by sending an SCGFailureInformation message to the MN).

[0188] An SCG may be added for the WTRU. Figure 3 shows an example of applying an SCG configuration if a condition is met. The WTRU may be in a connected state with a source MCG. The WTRU may receive a message (e.g., an RRCReconfiguration or RRCConnectionReconfig message) from an MCG (e.g., an MN associated with the MCG), which includes or indicates a trigger condition for performing an SCG configuration, an SCG reconfiguration, and / or an SCG configuration or reconfiguration (e.g., the SCG configuration or reconfiguration may be conditional). As described herein, the SCG configuration or reconfiguration may be related to a PSCell change or addition. In response to receiving the message, the WTRU may store the SCG configuration or reconfiguration and may begin monitoring the trigger condition included in or indicated in the message. The WTRU may be configured to send a first message (e.g., RRC Response 1 in Figure 3) to the MN based on receiving the configuration message. The WTRU may indicate in a first message (e.g., RRC Response 1) that it has received and / or stored the conditional SCG configuration or reconfiguration and has started monitoring the trigger conditions contained therein (e.g., so that the network may know the state and / or subsequent actions of the WTRU). In some examples, this first message (e.g., RRC Response 1) may correspond to an RRC Reconfiguration Complete message. If the trigger conditions are met (e.g., at a later point in time), the WTRU may send a second message (e.g., an RRC response such as RRC Response 2 in FIG. 3) to the MN. The WTRU may indicate in the second message (e.g., RRC Response 2) that the trigger conditions for application of the conditional SCG configuration or reconfiguration are met. In response to determining that the trigger conditions are met, the WTRU may apply the SCG configuration or reconfiguration. For example, the WTRU may initialize a RACH procedure to a candidate SCG. The WTRU may indicate the application of the conditional SCG reconfiguration to the network (eg, MSG or MN), for example, in a second message (eg, RRC Response 2 in FIG. 3) or in a different message.In some examples, the second message (e.g., RRC Response 2) may correspond to an RRC Reconfiguration Complete message. Furthermore, as described herein, applying a conditional SCG reconfiguration (e.g., performing a RACH procedure based thereon) may result in a failure. In such a situation, the WTRU may send a third message to the MN, which may indicate the failure. In some examples, the third message may correspond to an RRC Reconfiguration Failure message.

[0189] FIG. 4 illustrates an example of applying an SCG configuration or reconfiguration (e.g., a conditional SCG configuration or reconfiguration as described herein) when RLF is present. The WTRU may detect a radio link problem, such as RLF, while monitoring, for example, an MCG, for trigger conditions for applying an SCG configuration or reconfiguration. In such a situation, the WTRU may expedite the application of a stored SCG configuration, e.g., access the corresponding SCG (e.g., via a random access procedure) without waiting for the trigger condition to be met. If the random access is successful, the WTRU may indicate an MCG failure to the SCG. If the WTRU is unable to access the SCG, the WTRU may declare RLF. The WTRU may be configured with a generic cell group configuration, so that the configuration may be applied as an MCG configuration or an SCG configuration. In the case of an MCG RLF, the WTRU may expedite the generic cell group configuration as an MCG configuration and perform a conditional handover toward the MCG corresponding to the expedited MCG configuration.

[0190] The WTRU may be configured to apply conditional MCG reconfiguration, for example, while connected to an SCG. FIG. 5 shows an example of a WTRU performing enhanced recovery actions. The WTRU may be configured with multi-connectivity, for example, connected to a source MCG and a source SCG. The WTRU may receive a conditional reconfiguration associated with the MCG. The WTRU may start monitoring trigger conditions for conditional MCG reconfiguration. In some examples, the WTRU may experience radio link problems in the source MCG, for example, while waiting for a trigger condition for a candidate MCG. In such cases, the WTRU may be configured to perform one or more enhanced recovery actions. The enhanced recovery actions may include one or more of the following: The enhanced recovery actions may include transmitting MCG failure information via the source SCG. The enhanced recovery actions may include triggering connection re-establishment. For example, if the WTRU selects a candidate MCG, the WTRU may perform CHO (e.g., to the candidate MCG) using a stored MCG reconfiguration. The WTRU may be configured with one or more rules regarding whether to send MCG failure information over the source SCG and / or trigger connection re-establishment. The one or more rules may be based on an evaluation of cell quality associated with the source SCG and candidate MCGs, the presence of SCG bearers, the presence of SRB3, or split SRB1 / 2, etc.

[0191] In some examples, the WTRU may be configured to transmit MCG failure information over a source SCG for recovery if one or more of the following conditions are met: The WTRU may be configured to transmit MCG failure information over a source SCG if the quality of the source SCG is better than a cell quality threshold and the quality of the candidate MCG is lower than a cell quality threshold. The WTRU may be configured to transmit MCG failure information over a source SCG if the source SCG is configured with SRB3 and / or split SRB1 / 2. If neither condition is met, the WTRU may trigger connection re-establishment. Upon performing connection re-establishment, for example, the WTRU may transmit MCG failure information to the SCG if the cell quality of the SCG meets a minimum threshold.

[0192] In one or more recovery options, the WTRU may be configured with rules for determining the release of the source SCG connection and / or SCG configuration. For example, the WTRU may be configured to continue data transmission towards the source SCG until the result of the conditional reconfiguration on the MCG is known. If the conditional handover to the MCG is unsuccessful, the WTRU may indicate the failure by sending MCG failure information to the source SCG. If the conditional handover on the MCG is successful, the WTRU may release the source SCG configuration, for example, if the source SCG configuration is not linked to a candidate MCG configuration. If the source SCG configuration is linked to a candidate MCG configuration, the WTRU may retain the source SCG configuration.

[0193] A WTRU may be provided with concurrent conditional MCG reconfiguration and SCG reconfiguration. FIG. 6 shows an example of a WTRU monitoring for conditional configuration or reconfiguration. The WTRU may be configured with multi-connectivity, for example, connected to a source MCG and a source SCG. The WTRU may receive an RRC message, such as an RRCReconfiguration message, including an SCG configuration or reconfiguration (e.g., conditional SCG configuration or reconfiguration) for a candidate SCG1 and a trigger condition for the configuration or reconfiguration. The WTRU may store the SCG configuration or reconfiguration and start monitoring the trigger condition associated with SCG1. Such a reconfiguration may correspond to an SCG change procedure. The WTRU may also receive an RRC reconfiguration message including a conditional MCG configuration or reconfiguration, for example, corresponding to a handover to a candidate MCG. The WTRU may also receive a conditional SCG configuration or reconfiguration, for example, corresponding to the addition of an SCG2 linked to the candidate MCG. In terms of monitoring for conditional reconfiguration, the WTRU may be configured to perform one or more of the following: The WTRU may perform monitoring for three candidates, namely, candidate SCG1, candidate SCG2, and candidate MCG. The WTRU may perform selective monitoring, where one or more of the following may apply: The WTRU may be configured to monitor one layer (e.g., one of the candidates). For example, the WTRU may suspend monitoring for the SCG if configured with a candidate MCG reconfiguration. The WTRU may select a subset of SCG reconfigurations to monitor in addition to monitoring the MCG reconfiguration. For example, the WTRU may perform monitoring for candidate SCG1 and candidate MCG, and suspend monitoring for candidate SCG2. The WTRU may start monitoring the trigger condition for SCG2 if the candidate MCG meets the trigger condition. The WTRU may monitor the candidate MCG and candidate SCG2, and suspend monitoring for candidate SCG1.

[0194] If the reconfiguration to the candidate MCG is successful, the WTRU may be configured to do one of the following: The WTRU may release the source SCG configuration if the candidate MCG reconfiguration is triggered. The WTRU may release the source SCG configuration if the source SCG is not linked to the candidate MCG configuration. The WTRU may continue with the source SCG configuration until there is an explicit instruction from the candidate MCG.

[0195] In an example embodiment, the WTRU may be configured with a conditional reconfiguration information element (IE) in an RRC message, such as an RRCReconfiguration message (e.g., conditionalReconfiguration). Such an IE may carry information about the target PCell (e.g., for MCG reconfiguration) and / or the target PSCell (e.g., for SCG reconfiguration) with their associated trigger conditions. The WTRU may receive a conditional reconfiguration IE (e.g., conditionalReconfiguration) associated with a PSCell change via SRB3 and a conditional reconfiguration IE associated with a PCell change via SRB1. The WTRU may be configured to ensure that one (e.g., only one) conditional reconfiguration IE associated with the MCG or SCG is active.

[0196] A stored PSCell conditional reconfiguration IE may be deleted based on reception of a PCell conditional reconfiguration IE. A conditional handover configuration (CHO-Config) may be added or modified. The WTRU may perform one or more of the following (e.g., for a CHO-ConfigId received in a cho-ConfigToAddModList IE, for each CHO-ConfigId received in a cho-ConfigToAddModList IE, etc.): If cho-ConfigToAddModList includes mn-ExecutionCond and at least one entry with sn-ExecutionCond is present in cho-ConfigToAddModList in VarCHO-Config, the WTRU may delete the entry associated with sn-ExecutionCond in VarCHO-Config and may report an SCG configuration failure (e.g., according to an inability to comply with the RRCReconfiguration received via SRB3 and / or based on a conflict with the MCG configuration). If an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList in VarCHO-Config, the WTRU may replace the entry with the received value for this CHO-ConfigId. If an entry with a matching CHO-ConfigId does not exist in cho-ConfigToAddModList in VarCHO-Config, the WTRU may add a new entry for CHO-ConfigId in VarCHO-Config. The WTRU may perform conditional handover monitoring, for example, as specified herein.

[0197] The WTRU may be configured, for example, to ignore a received PSCell conditionalReconfiguration if at least one PCell conditionalReconfiguration is stored. The WTRU may perform one or more of the following (e.g., for a CHO-ConfigId received in the cho-ConfigToAddModList IE, for each CHO-ConfigId received in the cho-ConfigToAddModList IE, etc.): The WTRU may report an SCG configuration failure (e.g., according to an inability to comply with the RRCReconfiguration received via SRB3 and / or based on a conflict with an MCG configuration) if cho-ConfigToAddModList includes sn-ExecutionCond and there is at least one entry with mn-ExecutionCond in cho-ConfigToAddModList in VarCHO-Config. The WTRU may replace an entry with the received value for CHO-ConfigId if cho-ConfigToAddModList includes sn-ExecutionCond, no entry with mn-ExecutionCond exists in cho-ConfigToAddModList in VarCHO-Config, and an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList in VarCHO-Config. The WTRU may add a new entry for this CHO-ConfigId in VarCHO-Config if cho-ConfigToAddModList includes sn-ExecutionCond, no entry with mn-ExecutionCond exists in cho-ConfigToAddModList in VarCHO-Config, and an entry with a matching CHO-ConfigId does not exist in cho-ConfigToAddModList in VarCHO-Config.The WTRU may perform conditional handover monitoring, e.g., as specified herein, if cho-ConfigToAddModList includes sn-ExecutionCond but no entry with mn-ExecutionCond exists in cho-ConfigToAddModList in VarCHO-Config.

[0198] The above logic can be illustrated by the following: For each CHO-ConfigId received in the cho-ConfigToAddModList IE, the WTRU does the following: 1>If cho-ConfigToAddModList contains mn-ExecutionCond, 2>If there is at least one entry with sn-ExecutionCond in cho-ConfigToAddModList in VarCHO-Config, 3>Delete the entry associated with sn-ExecutionCond in VarCHO-Config. 3> Report an SCG configuration failure in accordance with the sub-clause corresponding to "Unable to comply with RRCReconfiguration received via SRB3" and possibly the new clause "Conflicts with MCG configuration". 1> If an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList in VarCHO-Config, 2> Replace the entry with the value received for this CHO-ConfigId. 1>Other 2>Add a new entry for this CHO-ConfigId in VarCHO-Config. 1> Perform conditional handover monitoring as specified herein. For each CHO-ConfigId received in the cho-ConfigToAddModListIE, the WTRU does the following: 1>If cho-ConfigToAddModList contains sn-ExecutionCond, 2>If there is at least one entry with mn-ExecutionCond in cho-ConfigToAddModList in VarCHO-Config, 3> Report an SCG configuration failure in accordance with the sub-clause corresponding to "Unable to respond to RRCReconfiguration received via SRB3" and possibly a new failure clause "conflicting with MCG configuration". 2>Other 3> If an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList in VarCHO-Config, 4> Replace the entry with the value received for this CHO-ConfigId. 3>Other 4>Add a new entry for this CHO-ConfigId in VarCHO-Config. 3> Perform conditional handover monitoring as specified herein.

[0199] While the features and elements of the present disclosure may take into account New Radio (NR) or 5G-specific protocols, it is understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems. While the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via 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). Software and associated processors may be used to implement radio frequency transceivers for use within the devices described herein.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising:

1. A processor, comprising: receiving a radio resource control (RRC) message from a network entity, the RRC message indicating a conditional reconfiguration to be applied by the WTRU and a condition for application of the conditional reconfiguration; transmitting a first message to the network entity in response to receiving the RRC message, the first message indicating that the WTRU has received the RRC message; determining that the condition for applying the conditional reconfiguration is met and applying the conditional reconfiguration based on the determination; transmitting a second message to the network entity, the second message indicating the application of the conditional reconfiguration; and determining that the application of the conditional reconfiguration has failed; and sending a third message to the network entity, the third message indicating the failure; and a processor configured to: A WTRU comprising:

2. The WTRU of claim 1 , wherein the conditional reconfiguration is associated with a primary secondary cell (PSCell) change or a PSCell addition.

3. The WTRU of claim 2 , wherein the RRC message further indicates a plurality of candidate PSCells associated with the conditional reconfiguration.

4. The WTRU of claim 1 , wherein the conditional reconfiguration is associated with a secondary cell group (SCG) addition or an SCG modification.

5. The WTRU of claim 1, wherein the RRC message is received via a Master Cell Group (MCG) bearer, and the first message, the second message, and the third message are transmitted via the MCG bearer.

6. The WTRU of claim 1 , wherein, in response to the reception of the RRC message, the processor is further configured to monitor for the condition for application of the conditional reconfiguration.

7. 2. The WTRU of claim 1, wherein the processor being configured to apply the conditional reconfiguration includes the processor being configured to initiate a random access to a candidate primary secondary cell (PSCell), and the processor being configured to determine that the application of the conditional reconfiguration has failed includes the processor being configured to determine that the random access has failed.

8. The WTRU of claim 1 , wherein the conditions for applying the conditional reconfiguration include measurement conditions for a candidate cell.

9. The WTRU of claim 1 , wherein the conditional reconfiguration is associated with a conditional handover.

10. the conditional reconfiguration includes a conditional primary secondary cell (PSCell) change, receiving a conditional handover command from the network entity; prioritizing execution of the conditional handover command over execution of the conditional reconfiguration; The WTRU of claim 1 , further configured to:

11. 1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving a radio resource control (RRC) message from a network entity, the RRC message indicating a conditional reconfiguration to be applied by the WTRU and a condition for application of the conditional reconfiguration; transmitting a first message to the network entity in response to receiving the RRC message, the first message indicating that the WTRU has received the RRC message; determining that the condition for applying the conditional reconfiguration is met and applying the conditional reconfiguration based on the determination; transmitting a second message to the network entity, the second message indicating the application of the conditional reconfiguration; and determining that the application of the conditional reconfiguration has failed; and sending a third message to the network entity, the third message indicating the failure; and A method comprising:

12. The method of claim 11 , wherein the conditional reconfiguration is associated with a Primary Secondary Cell (PSCell) change or a PSCell addition.

13. The method of claim 12 , wherein the RRC message further indicates a plurality of candidate PSCells associated with the conditional reconfiguration.

14. The method of claim 11 , wherein the conditional reconfiguration is associated with a secondary cell group (SCG) addition or an SCG modification.

15. The method of claim 11 , further comprising monitoring for the conditions for application of the conditional reconfiguration in response to the reception of the RRC message.

16. 12. The method of claim 11, wherein applying the conditional reconfiguration comprises initiating a random access to a candidate primary secondary cell (PSCell), and determining that the applying of the conditional reconfiguration has failed comprises determining that the random access has failed.

17. 12. The method of claim 11, wherein the RRC message is received on a Master Cell Group (MCG) bearer, and the first message, the second message, and the third message are transmitted on the MCG bearer.

18. The method of claim 11 , wherein the conditions for applying the conditional reconfiguration include measurement conditions for a candidate cell.

19. The method of claim 11 , wherein the conditional reconfiguration is associated with a conditional handover.

20. The conditional reconfiguration includes a conditional primary secondary cell (PSCell) change, and the method further comprises: receiving a conditional handover command from the network entity; prioritizing execution of the conditional handover command over execution of the conditional reconfiguration; The method of claim 11 further comprising:

Images