Conditional mobility with multi-connectivity

Abstract

To provide a system, a method, and an implementation for mobility and multi-connectivity of wireless transmit / receive units.SOLUTION: A WTRU includes a processor configured to operate in a master cell group (MCG) and a secondary cell group (SCG). The processor is configured to perform uplink transmissions in the MCG while the SCG is deactivated, determine that data associated with the SCG is available for transmission, and transmit a message to a network device associated with the MCG. The message indicates that data associated with the SCG is available for transmission.SELECTED DRAWING: Figure 3

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 by reference herein 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 provide network access to the WTRU using the same radio access technology (RAT) or using different RATs. 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. A WTRU as 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 application of 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 has received the RRC message. The WTRU can monitor a condition for application of the conditional reconfiguration and can determine that the condition for application of the conditional reconfiguration is met. The WTRU may send a second message to the network entity (e.g., based on a determination that a condition for applying the conditional reconfiguration is met), which may then indicate that a condition for applying the conditional reconfiguration is 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 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 description 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 example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, in accordance with an embodiment.

[0007] [Figure 1C] FIG. 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 illustrated in FIG. 1A, according to one embodiment.

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

[0009] [Diagram 2] FIG. 1 illustrates an example timing diagram for beam failure reporting, beam failure configuration, and beam failure recovery.

[0010] [Diagram 3] FIG. 13 is a diagram showing an example of applying an SCG configuration based on certain conditions.

[0011] [Figure 4] A diagram showing an example of applying an SCG configuration based on detection of a radio link failure.

[0012] [Diagram 5] FIG. 13 illustrates an example of an enhanced recovery action.

[0013] [Figure 6] FIG. 1 illustrates an example of monitoring multiple conditional rearrangements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications 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, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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 an industrial and / or automated processing chain context), 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 communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, 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 the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be 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 for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

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

[0019] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c 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 implement LTE radio access and NR radio access together, 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 localized area, such as a location of 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 via 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 act 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 using 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 networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RANs 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 a cellular-based wireless technology and a base station 114b that can use an 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. Although 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, for example, IR, UV, or visible light signals. 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 appreciated 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 use 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, for example, 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. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or 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 a current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of 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, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0037] The WTRU 102 may include a full-duplex radio where the 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 the 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 via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the 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, 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, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0040] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. 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 attachment 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 / 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 land-line 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. Additionally, 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 communications interface (e.g., temporarily or permanently) with the communications network.

[0047] In an exemplary 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 entering and / or leaving the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP, where the source STA may transmit traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted in a direct link setup (DLS) between (e.g., directly between) the source STA and the destination STA. 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 APs, 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 an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be an 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] A High Throughput (HT) STA 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 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 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 that 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 TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0053] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may 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) settings may depend on the condition of the primary channel. For example, if the primary channel is busy due to STAs (that only support the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and available for use.

[0054] In the United States, the available frequency bands that can be used by 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 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, 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, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a, for example, using multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the 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 configuration WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNode-B 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. Although 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. The 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 serves 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 an 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 the corresponding description thereof, 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 to simulate network and / or WTRU functions.

[0066] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or 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] The one or more emulation devices may perform one or more functions, including but not limited to, while not 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. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, 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). The 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 using different RATs. In 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 cases where 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] Latency associated with initial setup and activation of the SCG may have a significant impact on multi-connectivity performance. There may be a delay between a first time instance when a WTRU determines that additional radio resources are required (e.g., for 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), and the like.

[0071] Interruptions during mobility procedures may have a significant impact on multi-connectivity performance. In some examples, mobility robustness may be supported at least when SCG bearers are terminated in the SN, for example, since SCG change failures may cause interruptions to ongoing data transmissions. The delay from the transmission of a measurement report by the WTRU to the receipt of an RRCReconfiguration by the WTRU may be indeterminate due to inter-node coordination between the MN and the target SN. This may 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), in which case the cell size may be small and beamforming may be the 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 SCG. The behavior of the WTRU may be affected by the expected outcome (e.g., success / failure) of simultaneous mobility procedures performed at different layers in a multi-connectivity scenario (e.g., may not be consistent due to expected outcome).

[0073] The WTRU may be configured to perform mobility-related operations in a multi-connectivity scenario. Descriptions provided herein with respect to a conditional handover (CHO) may be at least partially applicable to a conditional reconfiguration, and vice versa. Similarly, descriptions with respect to a conditional PSCell addition and / or change (CPAC) may be at least partially applicable to a conditional PS cell change (CPC), and vice versa. Examples of CPAC may include performing a reconfiguration associated with a secondary cell group if a preconfigured execution condition or trigger is met. Such execution condition and / or trigger 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 the condition (e.g., based on a preconfigured condition). The WTRU may be configured to perform a 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., the at least one reconfiguration may be associated with an MCG and the at least one reconfiguration may be associated with an SCG. A WTRU may be configured with a plurality of 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. A WTRU may be configured with a plurality of conditional reconfigurations, where the plurality of conditional reconfigurations may correspond to the master cell group and the secondary cell group. A WTRU may apply an MCG reconfiguration and / or an SCG reconfiguration if a trigger condition (e.g., a trigger condition associated with a conditional reconfiguration) is met. A WTRU may be configured with a plurality of conditional reconfigurations, where one or more conditional reconfigurations associated with a secondary cell group may be linked to a conditional reconfiguration of a master cell group. A WTRU may apply a conditional reconfiguration associated with a 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 a 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 a 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 a configuration 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 an SCG configuration that is 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) with respect to 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. The linkage 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 examples, the WTRU may be configured to trigger a conditional SCG reconfiguration at or following a CHO. A conditional SCG reconfiguration may be triggered due to a lack of linkage between a CHO target and a current PSCell or SCG configuration. In 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 triggering of the CHO. 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, and 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 CHO execution) 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 SCG reconfiguration. If one or more of the conditions are met, the WTRU may perform CHO, and 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 the CHO based on certain conditions related to the linkage. For example, the WTRU may perform a 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 to operate 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 to 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 a linkage does not exist 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 selection of 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 be applied 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, e.g., depending on the existence of a linkage between the current PSCell and the CHO candidate (e.g., the WTRU may prioritize a candidate with linkage over a candidate without linkage). For example, the WTRU may be configured with triggering conditions for conditional HO candidates based on measurements. The WTRU may further be configured with biases for such measurements, or with different measurements depending on whether there is a 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 a linkage of the current PCell with the conditional PSCell candidate. This behavior of the WTRU may also be applied in 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 a linkage of the current PCell / PSCell with the conditional PCell / PSCell candidate in question.

[0087] The WTRU may, for example, receive signaling and / or identification of the 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, for each PCell CHO candidate, a list of allowed or linked PSCells and / or applicable SCG configurations if CHO is performed for the candidate (e.g., for each candidate). The WTRU may, for example, receive, for a PSCell candidate (e.g., for each PSCell candidate), a list of allowed or linked PCells and / or applicable MCG configurations if a 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 a linkage between the MCG and SCG, for example, if the MCG and SCG have the same identifier or an associated identifier. 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 a 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 a 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 for each cell or if there is some association between the security parameters for each cell. In examples, the WTRU may consider cells to be linked if there is some direct association on the 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 a specific trigger condition. This linkage between the MCG candidate and the SCG candidate may depend on a specific trigger for CHO and / or conditional PSCell change. The WTRU may be configured with a first set of one or more triggers based on a 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 a premise that a second linkage or set of linkages exists. In some examples, the WTRU may be configured with conditional PSCell candidates 1 and 2. Conditional PSCell candidate 1 may have a linkage to the current PCell, and conditional PSCell candidate 2 may not have a linkage to the current PCell. Such linkage may be applicable to triggers (e.g., only triggers) of data arrival on an SCG bearer, but not to triggers of SCG cell quality. For example, if the WTRU triggers a conditional PSCell change due to data arriving while camping 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] The 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 or SCG configuration. In 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 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 a condition for conditional PSCell addition and / or conditional PSCell modification is met and the WTRU does not have an active SCG configuration, the WTRU may perform a conditional PSCell addition. If a condition for conditional PSCell addition and / or conditional PSCell modification is 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 or 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 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 a delta signaling (e.g., in addition to other signaling). The WTRU may receive a comprehensive CG configuration as a delta signaling and may apply the delta signaling to derive a resulting MCG or SCG configuration. If separate delta configurations comprise the MCG and SCG, one or more of the following may be applied: 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 being 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: The 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 a CHO is performed on a PCell, the WTRU may apply the delta configuration to its current MCG configuration (e.g., to derive an 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 an SCG configuration after a 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 an SCG configuration after a 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. The measurement-based condition may correspond to a cell quality measurement such as RSRP, RSRQ, or SINR. The 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 satisfied. For example, a user plane condition may be met if one or more of the following occur: A 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. A user plane condition may be met if a 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 a data splitting threshold of multiple bearers). For example, a 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. A 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 a latency associated with a scheduling request is greater than a preconfigured threshold. A user plane condition may be met if a 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 is above a threshold (e.g., a trigger may be the amount of time above the threshold). A user plane condition may be met if an increase (e.g., over time units) in the buffer status is greater than a threshold.A user plane condition may be met when a buffer status report (BSR) is triggered or transmitted (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 examples, the 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 a (e.g., any) bearer exceeds a first threshold. With an SCG configuration activated or applied, the WTRU may continue to emit data on (e.g., only on) the MCG leg of the split bearer. The WTRU may continue to emit data on 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 suitability 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 an SCG. An SCG failure may be detected in response to detecting a reconfiguration with SCG synchronization failure. 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 an SCG lower layer for an 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 a dormant SCG if a beam failure is detected on a PSCell. In case of a pending and / or dormant SCG or a dormant 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 case of 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 beam failure recovery procedure) and / or activate a dormant 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 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 a 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 the MCG RLF) to the SCG. For the MCG RLF case, the WTRU may initiate a 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 to indicate, for example, the reason for the MCG failure and a trigger for applying the SCG configuration, such as the 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 the MCG configuration and may perform a conditional handover towards the promoted MCG configuration.

[0101] The trigger condition may be associated with the execution of an MCG conditional reconfiguration. The WTRU may be configured to apply an SCG configuration if a conditional reconfiguration associated with the MCG is successfully executed. The WTRU may be configured to execute a conditional SCG configuration after a conditional MCG configuration, e.g., 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 towards an MCG and the current SCG configuration is not linked to such MCG.

[0102] There may be an 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 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 MCG reconfiguration, if the stored SCG is linked to the serving MCG, the WTRU may apply the SCG reconfiguration, and if the stored SCG is not linked to the serving MCG, the WTRU may release the SCG configuration. If conditions for MCG and SCG (re)configuration are met (e.g., simultaneously), the WTRU may be configured with rules to determine 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 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 a condition. 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 a 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 a 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 changing 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 may select an SCG for activation. For example, the WTRU may be configured with multiple dormant SCG configurations, each of which 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 meet 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 a selected SCG (e.g., if valid scheduling request (SR) resources are configured and / or UL time normalization is enabled). The WTRU may provide an activation indication using any of the mechanisms described herein to indicate an acceptable SCG.

[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 to the dormant SCG based on one or more of the triggers described herein (e.g., prior to or as part of activation of 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 monitored / reported, etc.). The actions may include initiating PDCCH monitoring on the SCG. For example, the WTRU may initiate normal PDCCH monitoring after the transmission. The WTRU may perform PDCCH monitoring for a response and may continue such monitoring after receiving a 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 marked 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 SR configuration and send an indication to the SCG. The WTRU may be configured with a dedicated RACH configuration and / or a dedicated SR configuration to 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 procedure or send an SR to a dormant SCG 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, etc.

[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 transmission of an SR or RACH request 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. The 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 send a RACH request (e.g., initially), start monitoring CSI-RS (e.g., after sending the RACH request), 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, e.g., 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 reports), e.g., 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 period 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, e.g., an SCG dormant state. Based on a trigger of the WTRU, e.g., an indication to the SCG, a timer may be started. The WTRU may move the SCG to the activation state and perform procedures associated with the activation state (e.g., normal connected mode procedures), e.g., 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, eg, if a 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 preconfigured.

[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 execute 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 the first dormant SCG). The WTRU may activate a second dormant SCG if a 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 for which a beam failure is triggered may perform a beam failure indication and / or report to the network, e.g., and then proceed to 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., 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., regarding or following) 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 the 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, exceeds or falls below a threshold (e.g., ul-dataSplitThreshold). The trigger may include 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 beam failure of a dormant 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 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 a type or amount of data available for transmission at the WTRU. The WTRU may delay beam failure recovery based on a 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 for 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 the 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 a configuration of the RS when the SCG is dormant and / or based on 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 beam failure events in an SCG to the MCG. For example, the WTRU may report beam failure events detected in an inactive SCG to the MCG. A 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 the 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, e.g., 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), e.g., when 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 latest 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 shown herein) occurs. The WTRU may perform 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 trigger 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 following 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 on the failed beam and / or candidate beams after beam failure and while beam failure recovery is pending. The WTRU may perform beam measurements with reduced frequency, power, or measurement period for the failed beam and / or one or more candidate beams. 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, e.g., 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, e.g., if a trigger (e.g., later activation) occurs. A WTRU that cancels 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 for the WTRU to report beam failure, receive a configuration associated with beam failure, or recover from beam failure may vary based on multiple factors. For example, the WTRU may report beam failure at or near the time of the beam failure (e.g., immediately after detection of 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 beam failure to the network (e.g., at or near the time of failure), receive a beam failure configuration such as a new beam failure configuration (e.g., which may provide dedicated RACH resources) near 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 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 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 depending on the configuration received after SCG activation.

[0126] The WTRU may report beam failure upon SCG activation, receive a RACH configuration upon its activation, and perform beam failure recovery upon its activation. For example, the WTRU may detect a beam failure but may delay reporting and recovery of the beam failure until SCG activation. The WTRU may report a beam failure indication during activation and may 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 a 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 may not receive a RACH configuration and may still perform beam failure recovery (e.g., with an 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 beam failure at or near the time of failure (e.g., immediately after 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 beam failure to the MCG at or near the time of failure (e.g., immediately after 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 stored configuration.

[0130] FIG. 2 illustrates an example timing of beam failure reporting, configuration, and recovery. In the example scenario illustrated in FIG. 2, the 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 the order in which each operation occurs, as an example, although the order of occurrence or interactions and / or interaction participants illustrated in the figure may be different 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 may 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 during an SCG dormant state. For example, the WTRU may detect an MCG failure when at least one SCG is in a 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 conditional PSCell change) when deactivating an SCG. For example, a trigger applicable to change from one SCG to another may be applicable to deactivate 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 has failed. The WTRU may be configured with multiple conditional SCG configurations, and the WTRU may attempt to apply a conditional reconfiguration to a second SCG if the conditional SCG reconfiguration has failed with a first SCG. In some examples, the WTRU may be configured to report the failure of the conditional SCG reconfiguration to the MCG. This may be done via an SCG failure information message, for example, if all conditional SCG reconfigurations have failed, if n (e.g., n≧1) conditional SCG reconfigurations have failed, or if the conditional SCG reconfiguration does 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 passability 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 any 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 an 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 a dormant SCG and may activate the dormant SCG (e.g., to perform beam failure recovery).

[0136] 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 stored 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., a 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 during INACTIVE) and may send an SCG failure (e.g., SCGFailureIndication) or another RRC error message to the MCG if the PSCell quality falls 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 PSCells of the SCG exceed a threshold (before accessing the SCG). The WTRU may send an RRC error message after or along with an RRC completion message indicating the WTRU's transition to RRC_CONNECTED (e.g., if measurements of the PSCells of the SCG do not exceed a threshold). The WTRU may be configured with dormant SCGs and / or pending SCGs. The WTRU may trigger activation of dormant and / or pending SCGs based on a particular trigger (e.g., a data-related trigger), and if the WTRU determines that a previously dormant and / or pending 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 stored while the WTRU is in the INACTIVE state. The WTRU may receive a resume message with an instruction from the network to resume the stored 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 stored 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 the WTRU may 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 the SCG is determined to be acceptable. The WTRU may stop 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 some examples, the WTRU may be configured to perform an 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 a 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 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 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 a bearer type associated with 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 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 or a 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 an LCP restriction 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 or a 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 resume procedure or a resume 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 a SCGFailureInformation message in a resume complete message. The WTRU may include a pass / fail indication in the resume message to indicate a pass / fail status of the SCG access before the resume procedure. The WTRU may select from a subset of RACH preambles to indicate a pass / fail status of the SCG access before the resume procedure. The WTRU may select a RACH type (e.g., 2-step RACH vs. 4-step RACH) or include a pass / fail indication in data transmitted in the 2-step RACH procedure.

[0143] The WTRU may be configured to handle an MCG failure during (e.g., simultaneously with) a tolerability indication procedure towards 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 declare an RLF, for example, immediately. The WTRU may wait for the result of the tolerability indication towards the SCG or conditional SCG configuration. The WTRU may indicate an MCG failure based on a determination that the tolerability indication towards the SCG or conditional SCG configuration is passed. The WTRU may declare an RLF based on a failed tolerability indication towards the SCG. The WTRU may be configured with a timer or period for completing the tolerability indication or conditional SCG configuration, and the WTRU may trigger a connection re-establishment if the tolerability indication or conditional SCG configuration is not completed before expiration of the timer or period.

[0144] The WTRU may provide the 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 SCGs are allowable. In some examples, the WTRU may initiate a new RACH procedure to indicate the allowability of the stored, configured, and / or pending SCGs. 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 acceptable or unacceptable SCGs and may perform a RACH procedure using the appropriate preamble (e.g., depending on WTRU 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 permissibility. The WTRU may send the MAC CE to the MCG to indicate SCG permissibility, reasons for non-permissibility, a specific SCG configuration for which the WTRU is reporting permissibility 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) if an RRC configuration or reconfiguration associated with the CPAC may already exist (e.g., may already be stored) on the WTRU 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 configurations or reconfigurations when the WTRU is configured with both CPAC and CHO configurations. Different WTRU behaviors may be defined herein based on the potential 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 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 at the same time. 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 is already present 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, and 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 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 a 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 associated with 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 if the CHO trigger condition satisfies an entry condition (e.g., 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 a network node 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). The 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 of 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 examples, the WTRU may send the indication to the source PCell if CPAC is triggered at the same time as CHO. In examples, the WTRU may send the indication to the source PCell if the trigger time of CHO occurs after the trigger time of 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 relation to 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 to not 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) would result in a 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 an 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 completion of CHO. 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 completion if CHO has not been 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 a 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 CHO and CPAC. The WTRU may be configured to apply CHO if the trigger condition is met with a first threshold and apply CPAC if the trigger condition is met with a second threshold.

[0161] The WTRU may be configured to process the CPAC candidates based on the CHO or HO. The WTRU may be configured to perform one or more of the following when processing the CPAC configuration (e.g., upon completion of the CHO procedure): The radio resource configuration associated with the 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 the MCG (e.g., switching to a different MCG) while connected to the same SCG may include that one or more stored CPAC configurations may or may not be valid in the target MCG. The WTRU may be configured to determine the validity of the stored 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 the 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) if the WTRU successfully completes the CHO procedure and / or if 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) if the WTRU successfully completes the CHO. The WTRU may include an identity 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 if a stored CPAC configuration is received from a secondary node, e.g., if 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 an identity of a 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 towards the SCG. The WTRU may send such an indication if a stored CPAC configuration is received from a secondary node, e.g., 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 a CPAC configuration based on the completion of the CHO. The WTRU may be configured to suspend or release a CPAC configuration based on one or more of the following conditions: The WTRU may be configured to suspend or release a CPAC configuration based on the origin of the CPAC configuration. For example, the WTRU may be configured to release or suspend those CPAC configurations received from the secondary node and maintain the 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 the CPAC configurations received from the secondary node.

[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 a CPAC procedure. The radio resource configuration associated with a CHO configuration may be a function of a 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 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 a CHO configuration that is 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 the 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 the WTRU 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 an identity of a cell for which the CPAC conditions are met. 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.

[0175] The WTRU may 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 on 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. The examples described herein in the context of MN and / or SN initiated CPAC configurations may also be applicable to situations in which MN and / or SN initiated RRC reconfiguration may have a significant impact on the stored SCG configuration and / or active SCG configuration. The examples described herein may also be applicable if the WTRU is configured to store at least one SN initiated CPAC 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 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 that it cannot comply with the CPAC configuration and the reason why it cannot (e.g., an earlier configuration from a different cell group exists at the WTRU). In some examples, the WTRU may ignore a CPAC 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 that it cannot comply with the CPAC configuration and the reason why it cannot (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 why it cannot (e.g., the CPAC configuration is overwritten by a new configuration or a later arriving configuration).

[0180] In some examples (e.g., when the WTRU receives a CPAC configuration from a 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 why it cannot (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 despite 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 an explicit instruction. The WTRU may be configured to prioritize CPAC configurations based on an explicit priority instruction, such as one included as part of a CPAC configuration. The WTRU may be configured to prioritize a low priority CPAC configuration over a high priority CPAC configuration.

[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 a CPAC configuration if 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) a previous CPAC configuration was received from the same cell group. The WTRU may be configured to report (e.g., to a network node) a cell group whose CPAC configuration has been preferred or modified.

[0184] The WTRU may be configured to handle an SCG failure, e.g., 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), e.g., with or without sending an SCGFailureInformation to the MN.

[0185] The WTRU may determine 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. If not, the WTRU may initiate an SCG failure procedure (e.g., 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 upon the occurrence of an 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. FIG. 3 illustrates 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) that 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 start monitoring the trigger condition included or indicated in the message. The WTRU may be configured to send a first message (e.g., RRC Response 1 in FIG. 3) to the MN based on receiving the configuration message. The WTRU may indicate in a first message (e.g., RRC Response 1) that the WTRU 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 WTRU's state and / or subsequent actions). 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, application of a conditional SCG reconfiguration (e.g., execution of 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) in the presence of RLF. The WTRU may detect a radio link problem such as RLF while monitoring, e.g., with an MCG, a trigger condition for application of an SCG configuration or reconfiguration. In such a situation, the WTRU may expedite 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 an RLF. The WTRU may be configured with a generic cell group configuration, such 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 towards the MCG corresponding to the expedited MCG configuration.

[0190] The WTRU may be configured to apply a conditional MCG reconfiguration, for example, while connected to the SCG. FIG. 5 illustrates 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 the conditional MCG reconfiguration. In examples, the WTRU may experience radio link problems in the source MCG, for example, while waiting for a trigger condition for the candidate MCG. In such a case, 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 a connection re-establishment. For example, if the WTRU selects a candidate MCG, the WTRU may perform a CHO (e.g., to the candidate MCG) using the stored MCG reconfiguration. The WTRU may be configured with one or more rules on 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, presence of SCG bearers, presence of SRB3, or split SRB1 / 2, etc.

[0191] In 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 an 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 outcome of the conditional reconfiguration on the MCG is known. If the conditional handover to the MCG fails, 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, e.g., 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] The WTRU may be provided with concurrent conditional MCG reconfiguration and SCG reconfiguration. FIG. 6 illustrates an example of a WTRU monitoring for conditional configuration or reconfiguration. The WTRU may be configured with multi-connectivity, e.g., 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., a 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, e.g., corresponding to a handover to a candidate MCG. The WTRU may also receive a conditional SCG configuration or reconfiguration, e.g., 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 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 a 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 a target PCell (e.g., for MCG reconfiguration) and / or a target PSCell (e.g., for SCG reconfiguration) with respective associated trigger conditions. The WTRU may receive a conditional reconfiguration IE associated with a PSCell change via SRB3 (e.g., conditionalReconfiguration) 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 there is at least one entry with sn-ExecutionCond 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 an RRCReconfiguration received via SRB3 and / or based on a conflict with an 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 the CHO-ConfigId in VarCHO-Config. The WTRU may perform conditional handover monitoring, e.g., as specified herein.

[0197] The WTRU may be configured, for example, to ignore a received PSCell conditionalReconfiguration if at least one PCellconditionalReconfiguration is stored. 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 the cho-ConfigToAddModList IE, etc.): The WTRU may report an SCG configuration failure (e.g., according to an inability to comply with a received RRCReconfiguration 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 there is no entry with mn-ExecutionCond 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 includes mn-ExecutionCond, 2>If at least one entry with sn-ExecutionCond exists 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-clauses 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 includes 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 according to the sub-clause corresponding to "unable to comply with 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. Although the features and elements are described above in a particular combination, one 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 over a wired or wireless connection) 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: A processor configured to operate with a master cell group (MCG) and a secondary cell group (SCG), the processor comprising: performing uplink transmissions on the MCG while the SCG is deactivated; determining that data associated with the SCG is available for transmission; sending a message to a network device associated with the MCG, the message indicating that data associated with the SCG is available for transmission; A WTRU comprising a processor configured to:

2. 2. The WTRU of claim 1, wherein the processor being configured to determine that data associated with the SCG is available for transmission comprises the processor being configured to determine that the data is associated with a radio bearer associated with the SCG.

3. The WTRU of claim 1 , wherein after transmitting the message to the network device, the processor is further configured to activate the SCG to transmit data associated with the SCG.

4. The WTRU of claim 3 , wherein the data is transmitted to a network device associated with the SCG.

5. The WTRU of claim 4 , wherein network devices associated with the SCG include a base station configured to operate as a secondary node (SN) for the WTRU.

6. The WTRU of claim 1 , wherein network devices associated with the MCG include a base station configured to act as a master node (MN) for the WTRU.

7. The WTRU of claim 6 , wherein the processor is further configured to receive configuration information regarding the MCG and the SCG from the MN.

8. The WTRU of claim 7 , wherein the configuration information indicates that the SCG is a deactivated SCG.

9. The WTRU of claim 7 , wherein the configuration information indicates that the SCG is an activated SCG, and the processor is further configured to deactivate the SCG based on a condition.

10. The WTRU of claim 1 , wherein the processor is configured to not monitor a physical downlink control channel associated with the SCG while the SCG is deactivated.

11. 1. A method performed by a wireless transmit / receive unit (WTRU) configured to operate in a master cell group (MCG) and a secondary cell group (SCG), comprising: The method comprises: performing uplink transmissions on the MCG while the SCG is deactivated; determining that data associated with the SCG is available for transmission; sending a message to a network device associated with the MCG, the message indicating that data associated with the SCG is available for transmission; The method includes:

12. The method of claim 11 , wherein determining that data associated with the SCG is available for transmission comprises determining that the data is associated with a radio bearer associated with the SCG.

13. The method of claim 11 , further comprising: after transmitting the message to the network device, activating the SCG to transmit data associated with the SCG.

14. The method of claim 11 , further comprising receiving configuration information regarding the MCG and the SCG.

15. The method of claim 14 , wherein the configuration information indicates that the SCG is a deactivated SCG.

Images