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 on October 1, 2019; U.S. Provisional Patent Application No. 62 / 930,891, filed on November 5, 2019; U.S. Provisional Patent Application No. 62 / 972,842, filed on February 11, 2020; and U.S. Provisional Patent Application No. 63 / 061,225, filed on August 5, 2020, the disclosures of which are hereby incorporated by reference in their entirety.

Background Art

[0002] Mobile communications are constantly evolving and have already reached the fifth generation, namely 5G. A wireless transmit receive unit (WTRU) can be configured with multiple connectivities. 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 different RATs. The WTRU can transmit messages to a network node or receive messages from a network node. The WTRU and the network node can determine each other's status 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 radio transceiver unit (WTRU) are described herein. The WTRU described herein can receive radio resource control (RRC) messages from a network entity, the RRC messages may indicate a conditional reconfiguration applied by the WTRU and the conditions for the application of the conditional reconfiguration (e.g., measurement conditions). This conditional reconfiguration may be associated with primary-secondary cell (PSCell) changes, PSCell additions, secondary cell group (SCG) changes, SCG additions, etc. The RRC message may indicate multiple candidate PSCells associated with the conditional reconfiguration. In response to receiving an RRC message, the WTRU may transmit a first message to the network entity indicating in the first message that the WTRU has received the RRC message. The WTRU can monitor the conditions for the application of the conditional reconfiguration and determine that the conditions for the application of the conditional reconfiguration are met. The WTRU may send a second message to the network entity (for example, based on a determination that the conditions for applying conditional reconfiguration are met), which may indicate that the conditions for applying conditional reconfiguration are met. The WTRU may then apply conditional reconfiguration. In some scenarios, the WTRU may determine that the application of conditional reconfiguration has failed. In response to such a failure, the WTRU may send a third message to the network entity, which may indicate the failure to the network entity.

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

[0005] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented.

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

[0007] [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment.

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

[0009] [Figure 2] This figure shows a beam fault report, beam fault configuration, and exemplary timing for beam fault recovery.

[0010] [Figure 3] This figure shows an example of applying an SCG configuration based on certain conditions.

[0011] [Figure 4] This figure shows an example of applying an SCG configuration based on the detection of a wireless link failure.

[0012] [Figure 5] This figure shows an example of an enhanced healing action.

[0013] [Figure 6] This figure shows an example of monitoring multiple conditional reconfigurations. [Modes for carrying out the invention]

[0014] Figure 1A shows an exemplary 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, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), and / or similar.

[0015] As shown in Figure 1A, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio 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 radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating in commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

[0016] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node B, eNode B, Home Node B, Home eNode B, gNB, NR Node B, Site Controller, Access Point (AP), Wireless Router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0017] Base station 114a may be part of 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), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a can use multiple-input multiple output (MIMO) technology and utilize multiple transceivers per sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0018] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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 described above, the communication system 100 can be a plurality of access systems and can use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN 104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0020] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can 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 can implement radio technologies such as New Radio (NR) radio access, which can establish the air interface 116 using NR.

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

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

[0024] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and any suitable RAT can be used to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d can establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0025] RAN104 / 113 can communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 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, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN104 / 113. For example, in addition to being connected to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 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), the datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which can use cellular-based radio technology, and base station 114b, which can use IEEE 802 radio technology.

[0028] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the aforementioned elements while maintaining consistency with one embodiment.

[0029] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and 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) via 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 signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0031] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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 radio signals via the air interface 116.

[0032] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0034] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method, while maintaining consistency with one embodiment.

[0036] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, 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 photography and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0037] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating 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, WTRU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

[0038] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0039] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0041] The CN106 shown in Figure 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 aforementioned elements is depicted as part of CN106, 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 MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating WTRU102a, 102b, 102c users for bearer activation / deactivation and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0043] The SGW164 can be connected to each of the eNode B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0044] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0045] CN106 can facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, and 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 shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

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

[0048] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the APs and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via the APs; a source STA may send traffic to the AP, and the AP 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 between a source STA and a destination STA (for example, directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

[0049] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, for example in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time in a given BSS.

[0050] A high-throughput (HT) STA can, for example, form a 40MHz wide channel for communication by using a 40MHz wide channel via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels.

[0051] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can 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. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing can be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to Medium Access Control (MAC).

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

[0053] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The 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 set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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 state of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

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

[0055] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 employs NR radio technology and can communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 can also communicate with CN115.

[0056] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, and the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0057] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0058] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. Non-standalone WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0059] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in 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 and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0060] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally, a Data Network (DN)185a, 185b. Although each of the aforementioned elements is illustrated as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0061] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signal transmission, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 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 similar. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0062] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0063] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, which may provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 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, and providing mobility anchoring.

[0064] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Furthermore, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0065] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0066] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or 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 network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented and / or deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

[0067] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0068] Where 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. Where referred to herein, MR-DC (multi-radio dual connectivity) may refer to dual connectivity to an E-UTRA node and an NR node, or dual connectivity to two NR nodes.

[0069] A WTRU can be configured with multi-connectivity, such as dual connectivity. For example, a WTRU may be configured to utilize resources provided by two nodes (e.g., two network nodes). These two nodes may be connected, for example, via a non-ideal backhaul. These nodes may use the same RAT or different RATs to provide network access to the WTRU. In several examples, a first network node may function as a master node (MN), which can be configured to control one or more cells associated with a master cell group (MCG) and associated resources, and a second network node may function as a secondary node (SN), which can be configured to control one or more cells associated with a secondary cell group (SCG) and associated resources. These MNs and SNs may be connected via network interfaces. At least one MN may be connected to the core network. The exemplary embodiments described herein may be applicable to a variety of use cases, including cases where the WTRU may consist of 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 media access controls or MACs (e.g., via their 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. RRC messages (e.g., RRC reconfiguration messages) may be associated with SCG additions, SCG changes or modifications, and / or SCG releases (e.g., may contain information for those).

[0070] Initial setup and latency associated with SCG activation can significantly impact multi-connectivity performance. A delay may exist between a first time instance when a WTRU determines it requires additional radio resources (e.g., for high-throughput data transmission) and a second time instance when the WTRU is ready to transmit via the SCG. This delay may be associated with (or caused by) various factors, including signal transmission delays via the Uu interface (e.g., buffer status, measurement reports) and signal transmission delays via the Xn interface (e.g., coordination between master and secondary nodes).

[0071] Interruptions during mobility procedures can significantly impact multiconnectivity performance. In several cases, mobility robustness can only be supported when the SCG bearer terminates within the SN, for example, because an SCG change failure can cause an interruption to ongoing data transmission. The delay between the transmission of the measurement report by the WTRU and the reception of the RRCReconfiguration by the WTRU can be undefined due to inter-node coordination between the MN and the target SN. This can result in SCG changes being too late or too early. SCGs may be deployed in higher frequencies (e.g., frequency range 2 (FR2) such as 24.25 GHz to 52.6 GHz), in which case cell sizes may be smaller and beamforming may result in a vulnerable link.

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

[0073] WTRU may be configured to perform mobility-related operations in multi-connectivity scenarios. The descriptions provided herein with respect to conditional handover (CHO) may be at least partially applicable to conditional reconfiguration, and vice versa. Similarly, the descriptions with respect to conditional PSCell addition and / or change (CPAC) may be at least partially applicable to conditional PS cell change (CPC), and vice versa. An example of CPAC may include performing a reconfiguration associated with a secondary cell group when pre-configured execution conditions or triggers are met. Such execution conditions and / or triggers may be pre-configured by a network entity, for example, via high-layer signaling transmission. 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 can apply configurations associated with secondary cell groups as a function of conditions (e.g., based on pre-configured conditions). The WTRU may be configured to perform cell group configuration or reconfiguration of secondary cell groups if the pre-configured conditions are met. The secondary cell group may correspond to (e.g., use) the same RAT as the master cell group, or the second cell group may use a different RAT than the one 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 which can be configured using configuration parameters such as reconfigurationWithSync). The cell group configuration or reconfiguration may be signaled as part of an RRC reconfiguration message.

[0075] A WTRU may consist of one or more multiconnectivity conditional reconfigurations (e.g., the WTRU may receive one or more multiconnectivity conditional reconfigurations), for example, at least one of which may be associated with an MCG, and at least one of which may be associated with an SCG. A WTRU may consist of multiple conditional reconfigurations, of which a first subset may be associated with a master cell group, and a second subset of which (e.g., the remainder) may be associated with a secondary cell group. A WTRU may consist of multiple conditional reconfigurations, of which multiple conditional reconfigurations may correspond to a master cell group and a 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 the conditional reconfiguration) is met. A WTRU may consist of multiple conditional reconfigurations, of which 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. If the second trigger condition is met, the WTRU can apply a conditional reconfiguration associated with the secondary cell group linked to the currently activated master cell group.

[0076] Configurations associated with conditional secondary cell group configurations or reconfigurations may be described herein. A WTRU may be configured to apply an SCG configuration if pre-configured conditions are met. An SCG configuration may include one or more of the following: a configuration of a special cell that may include PSCell configuration information (e.g., spCellConfig); a configuration for performing reconfiguration with synchronization; a radio bearer configuration that 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 that are added, modified, and / or released.

[0077] A WTRU may consist of linkages (e.g., mappings, associations, relationships) 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 can use such determination to perform monitoring associated with one or more SCG configurations. For example, the WTRU may be configured to monitor trigger conditions associated with SCG configurations linked to the currently active MCG configuration. A WTRU may consist of linkages between MCG candidates and SCG candidates. In several examples, a WTRU may consist of linkages between a candidate conditional handover (CHO) (e.g., on an MCG) and a candidate conditional SCG reconfiguration. Such linkages may be used, for example, to take advantage of specific network (NW) preferences and / or limitations with respect to the combinations of MN and SN that the WTRU can connect to. The behavior of the WTRU can be significantly influenced by linkages, as described herein. Linkages can implicitly indicate or control the behavior of the WTRU, for example, with respect to changes in the CHO and / or PSCell.

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

[0079] A WTRU can trigger a CHO as a result of a conditional SCG reconfiguration. For example, a WTRU may be configured to trigger a CHO when a conditional PSCell change is triggered or thereafter. One or more embodiments of the above examples (e.g., for performing a conditional SCG reconfiguration as a result of a CHO execution) can be applied to execute a CHO as a result of a conditional SCG reconfiguration. For example, a WTRU may consist of several conditions (e.g., those described herein) for executing a CHO after an SCG reconfiguration. If one or more of these conditions are met, the WTRU can execute the CHO; if none of these conditions are met, the WTRU can release or suspend the CHO.

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

[0081] A WTRU may suspend or release a specific bearer (e.g., a data radio bearer (DRB) and / or a signaling radio bearer (SRB)) based on one or more conditions related to the linkage. For example, a WTRU may suspend or release a DRB during a CHO or conditional PSCell change if no linkage exists between a CHO candidate and the current SCG, or between a PSCell candidate and the current PCell. A WTRU may consist of a list of bearers that are suspended and / or released if the linkages described herein exist. A WTRU may consist of a list of bearers that are suspended and / or released if the linkages described herein do not exist.

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

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

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

[0085] A 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 a conditional HO based on a given active PCell or SCG configuration. This behavior of the WTRU may also apply when a conditional PSCell configuration triggers a CHO (e.g., after or during the conditional PSCell configuration).

[0086] WTRU can, for example, apply a bias to the PCell for trigger conditions for conditional HO depending on the existence of a linkage between the current PSCell and the CHO candidate (for example, WTRU can prioritize candidates with linkages over candidates without linkages). For example, WTRU can consist of trigger conditions for conditional HO candidates based on measurements. WTRU can be further composed of biases on such measurements, or different measurements depending on whether there is a linkage between the CHO candidate and the current PSCell. WTRU can apply a bias to trigger conditions for conditional PSCell changes depending on the existence of a linkage between the current PCell and the conditional PSCell candidate. This behavior of WTRU can also apply to conditional PSCell configurations. WTRU can decide to select one or more candidates with priority depending on the existence of a linkage between the current PCell / PSCell and the conditional PCell / PSCell candidate in question (for example, if multiple candidates exist and a CHO or conditional PSCell change is triggered).

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

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

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

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

[0091] A WTRU can identify an inclusive CG if it is also composed of other non-inclusive CG candidates. For example, a WTRU may consist of one or more inclusive CG configurations in addition to MCG-specific or SCG-specific configurations. A WTRU can identify an inclusive CG configuration based on explicit signaling (e.g., based on the identification information or identifiers contained within the inclusive CG configuration, or based on the use of separate information elements (IE) for the inclusive CG configuration). A WTRU can identify an inclusive configuration based on the fact that it was provided in a complete (e.g., non-delta) configuration for the inclusive CG configuration.

[0092] A CG configuration may be provided as a delta signal transmission (for example, in addition to other signal transmissions). A WTRU may receive a comprehensive CG configuration as a delta signal transmission and apply that delta signal transmission to derive the resulting MCG or SCG configuration. If separate delta configurations comprise both an MCG and an SCG, one or more of the following may apply: The CG configuration may be provided in separate parts, e.g., a delta configuration associated with the MCG and a delta configuration associated with the SCG. In several examples, if a WTRU decides 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 (for example, while ignoring the delta configuration associated with the MCG). In several examples, a WTRU may apply both the MCG configuration and the SCG delta configuration regardless of which CG is modified.

[0093] When a CG configuration is provided to an MCG or SCG as a delta signal transmission, one or more of the following may apply: This CG configuration may be provided to a CG (e.g., an MCG or SCG) that is currently configured as a delta configuration. If the CG configuration is provided with respect to an MCG and 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 a CHO). If the CG configuration is provided with respect to an MCG and 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 the CG configuration is provided as a delta configuration with respect to an SCG and 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 a signal transmission (e.g., within the candidate configuration itself) regarding whether the delta configuration can be applied to an MCG or SCG.

[0094] A WTRU may consist of one or more trigger conditions for secondary cell group configuration or reconfiguration. A 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 is met. For example, a WTRU may be configured to apply an SCG reconfiguration if a measurement-based condition is met. This measurement-based condition may correspond to a cell quality measurement such as RSRP, RSRQ, or SINR. This measurement-based condition may be configured, for example, as a measurement event with one or more appropriate thresholds (e.g., Ax, Bx, etc.). A WTRU may apply an SCG reconfiguration if the measurement-based condition and one or more of the following trigger conditions are met.

[0095] Trigger conditions may be associated with user plane status. WTRU may be configured to apply SCG configuration when, for example, measurement-based conditions and user plane-based conditions are met. For example, user plane conditions may be met when one or more of the following occur: User plane conditions may be met based on data associated with a pre-configured logical channel (LCH) or logical channel group (LCG) (for example, such LCH / LCG may correspond to an SCG bearer or split bearer) becoming available for transmission. User plane conditions may be met when the buffer status of one or more bearers reaches a threshold (for example, this threshold may correspond to a data splitting threshold or may be derived from the data splitting thresholds of multiple bearers). For example, user plane conditions may be met when WTRU determines that the amount of pending PDCP and RLC data on all split bearers exceeds a threshold that can trigger the application of SCG configuration or activate the SCG. User plane conditions may be met when the latency associated with data transmission exceeds a pre-configured threshold. A user plane condition may be met if the latency associated with a scheduling request exceeds a pre-configured threshold. A user plane condition may be met if the number of RLC retransmissions exceeds a pre-configured threshold. A user plane condition may be met if one or more conditions of the buffer status related to the time mode are met. For example, whether a user plane condition may be met may be determined based on the amount of time in the buffer status (e.g., one or a subset of bearers exceeding a threshold (e.g., a trigger may exceed the threshold)). A user plane condition may be met if the increase in the buffer status (e.g., over a time unit) exceeds a threshold.User plane conditions can be met when a buffer status report (BSR) is triggered or sent (for example, a BSR trigger 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 several examples, a WTRU may consist of two thresholds for split bearers (e.g., for each split bearer). The WTRU may activate or apply the SCG configuration if, for example, the pending PDCP and RLC data for any bearer exceeds the first threshold. With the SCG configuration activated or applied, the WTRU may continue to transmit data to the MCG leg of the split bearer (e.g., only to that leg). The WTRU may continue to transmit data to the SCG leg of the split bearer if, for example, the pending PDCP / RLC data for the bearer exceeds the second threshold. The WTRU may follow similar rules for deactivation.

[0097] Trigger conditions may be associated with SRB3. WTRU may be configured to apply the SCG configuration if it is unable to respond to an RRCReconfiguration message received via SRB3, for example, if the PSCell associated with a stored SCG configuration meets the measurement and / or compliance criteria.

[0098] The trigger condition may be associated with an SCG failure. The WTRU may be configured to apply an SCG configuration when an SCG failure is detected. This SCG configuration may be responsive to SN changes. 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 the detection of a radio link failure in the SCG. An SCG failure may be detected in response to the detection of a reconfiguration with a synchronization failure in the SCG. An SCG failure may be detected in response to the detection of an SCG configuration failure. An SCG failure may be detected in response to the reception of an integrity check failure instruction from a lower layer of the SCG regarding SRB3.

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

[0100] Trigger conditions may be associated with the MCG radio link status. The WTRU may be configured to apply an SCG configuration as a function of the radio link status associated with the MCG. For example, the WTRU may be configured to apply an SCG configuration when an RLF is detected in the MCG. In several examples, the WTRU may be configured to execute an RRC embodiment based on a stored SCG if an MCG RLF exists. One or more of the following may apply: In the case of an MCG RLF, if the WTRU has a stored configuration for the SCG, and the PSCell associated with that SCG meets the compliance criteria, and 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., the reason for the MCG failure and a trigger for applying an SCG configuration such as an MCG RLF) to the SCG. In the case of an MCG RLF, 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 indicating, for example, the reason for the MCG failure and a trigger for applying the SCG configuration, such as an MCG RLF. In the case of an MCG RLF, if the WTRU is configured with a comprehensive cell group configuration, the WTRU may facilitate the cell group configuration into an MCG configuration and perform a conditional handover to that facilitated MCG configuration.

[0101] Trigger conditions may be associated with the execution of an MCG conditional reconfiguration. A WTRU may be configured to apply an SCG configuration if a conditional reconfiguration associated with an MCG has been successfully executed. A WTRU may be configured to execute a conditional SCG configuration after a conditional MCG configuration if, for example, one or more additional trigger conditions described herein are met. A WTRU may be configured to release an SCG configuration if a conditional reconfiguration has been applied to an MCG and the current SCG configuration is not linked to such an MCG.

[0102] There may be interaction (e.g., information exchange) between monitoring procedures for conditional MCG reconfiguration and monitoring procedures for conditional SCG reconfiguration. WTRU may be configured to simultaneously monitor trigger conditions associated with conditional SCG reconfiguration and trigger conditions associated with conditional MCG reconfiguration. WTRU may be configured to initiate monitoring of one or more trigger conditions associated with one or more SCG reconfigurations, in which case these SCG reconfigurations may be linked to MCG configurations that may be active or whose trigger conditions may be met.

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

[0104] If the trigger conditions associated with the MCG are met during the progress of the conditional SCG reconfiguration, the WTRU may consist of the following behaviors: The WTRU may be configured to release the SCG reconfiguration and trigger the 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 the MCG and SCG reconfiguration. The WTRU may be configured to show the MCG for the SCG reconfiguration.

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

[0106] A WTRU may be configured to process SCG states based on conditions. For example, a WTRU may be configured to activate (or deactivate) an SCG (e.g., an SCG configuration) based on one or more pre-configured triggers. For example, a WTRU may consist of one or more SCG configurations that may be in a dormant state, and the WTRU may further consist of one or more configurations or conditions for activating an SCG configuration (e.g., moving an SCG configuration from a dormant state to an activated state) or interrupting an SCG configuration (e.g., moving an SCG configuration from an activated state to a dormant state). A 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 PDCCH. In several examples, having an SCG configuration in a dormant state may mean that the WTRU stores the SCG configuration but does not provide it. A WTRU may activate an SCG by applying any of the triggers described herein (for example, in connection with a change or addition of a conditional PSCell). A WTRU may operate on activated SCGs if the triggers for activation of multiple activated SCGs are met without the triggers for deactivating those SCGs being met.

[0107] Assuming multiple SCG configurations are given, the WTRU can select an SCG for activation. For example, the WTRU may consist of multiple dormant SCG configurations, each of which may contain PSCells and zero or more SCells. The WTRU can select an SCG for activation based on pre-configured criteria. The WTRU can select an SCG with the best PSCells or SCells (e.g., based on RRM measurements). The WTRU can select an SCG with the best PSCells or SCells based on channel state information (CSI) measurements. The WTRU can select an SCG configured with dedicated RACH resources. The WTRU can select an SCG with the maximum number of beams exceeding a threshold. The WTRU can select an SCG with the maximum number of SCells satisfying the minimum RSRP, RSRQ, SINR, and / or CSI thresholds. The WTRU can select the last active SCG.

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

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

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

[0111] A WTRU can be configured with a dedicated RACH configuration and / or SR configuration to send instructions to the SCG. A WTRU can be configured with a dedicated RACH configuration and / or a dedicated SR configuration to perform access to a dormant SCG. A WTRU can execute a RACH procedure or send an SR to a dormant SCG based on one or more of the following: A WTRU can execute 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 (for example, a WTRU can execute a RACH if the TAT expires in the SCG). A WTRU can execute 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, a WTRU can execute a RACH procedure if it is not configured with an SR resource, or a WTRU can execute a RACH procedure if it is configured with a dedicated RACH resource. Where referred to herein, executing a RACH or RACH procedure may include sending and / or receiving random access-related messages, such as random access preambles, random access requests, and random access responses.

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

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

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

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

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

[0117] A WTRU performing beam management for a dormant SCG triggered by a beam fault may perform beam fault indication and / or report to the network, for example, then proceed to a beam fault recovery procedure. The indication and / or recovery procedure may be delayed until a later time or until the trigger condition is met. The WTRU may maintain the beam fault state (e.g., the beam fault may still remain pending) and corresponding information until a future trigger. The WTRU may, for example, influence the beam fault based on a future trigger (e.g., with respect to or after it) (e.g., provide a beam fault indication and / or perform beam fault recovery). 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). A trigger can be any trigger associated with data reaching a WTRU, such as data reaching a bearer, in which case the bearer may be configured to trigger such an action (e.g., an SCG bearer or a split bearer), or the bearer may have a unique characteristic associated with latency or similar QoS characteristics (e.g., a bearer associated with logical channel prioritization (LCP) limits). A trigger can be when the current buffer status in a WTRU exceeds or falls below a threshold (e.g., ul-dataSplitThreshold), such as a buffer status associated with one or more bearers. A trigger can include the expiration of a timer. A trigger can include mobility events in the MCG and / or SCG (e.g., HO, conditional HO, SCG change, or conditional SCG change). A trigger can be when a measurement report is triggered based on other measurement-related triggers associated with the MCG and / or SCG.For example, a WTRU may report pending beam fault indications based on measurement events configured by the WTRU related to the quality of cells within an MCG and / or SCG, or a WTRU may report beam faults in a dormant SCG as part of an RRM trigger 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 fault recovery configuration). The trigger may be based on measurements of candidate or faulty beams (e.g., the WTRU may trigger a beam fault recovery action if one or more candidate beams are measured above a threshold after a beam fault declaration).

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

[0119] A WTRU can report beam failure events within an SCG to an MCG. For example, a WTRU can report beam failure events detected in a dormant SCG to an MCG. Beam failure indications or reports provided by a 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 dormant SCG configurations). The beam failure indication or report may include measurements of the faulty beam, all candidate beams, or a subset of candidate beams (e.g., N best candidates). Beam fault indications or reports may include, for example, one or more of the following: RRC messages (e.g., SCGFailureIndication messages or equivalent RRC messages), MAC CE, physical uplink control channel (PUCCH) transmissions, SR transmissions or similar uplink control information (UCI) transmissions, and / or random access preamble transmissions.

[0120] A WTRU can receive configurations (e.g., new configurations) for pending beam fault events. This WTRU can receive configurations (e.g., new configurations) for beam recovery (e.g., RACH resources and / or candidate beams) after a beam fault instruction. This WTRU can receive configurations from the MN, for example, via RRC messages, MAC CE, and / or DCI. A WTRU can receive configurations after transmitting a beam fault instruction. A WTRU can receive configurations (e.g., independently of transmitting a failure instruction) based on one or more of the triggers considered herein. A WTRU can apply configurations for beam fault recovery (e.g., based on the reception of configurations) if beam fault recovery is triggered, for example. For example, a WTRU can store RACH configurations received for beam fault recovery and provide those configurations at the time of a beam fault recovery trigger for a pending beam fault. A WTRU can maintain the most recently received configurations for the application of beam fault recovery.

[0121] In response to detecting a beam fault, the WTRU can determine whether to perform beam fault recovery action (e.g., immediately thereafter) or to delay beam fault recovery action (e.g., until a later time, such as activating a dormant SCG), which is based, for example, on whether the WTRU receives a new configuration associated with the beam fault in response to transmitting a beam fault instruction. For example, if the WTRU does not receive a configuration in response to transmitting a beam fault report or instruction, it may delay beam fault recovery (e.g., until a future trigger, such as those described herein, occurs).

[0122] A WTRU may have the following behaviors while beam fault recovery is pending in a dormant SCG: For example, a WTRU may detect a beam fault in a dormant SCG and keep the beam fault pending until a trigger (e.g., one or more of the triggers described herein) occurs. A WTRU may perform one or more of the following while beam fault recovery is pending in a dormant SCG: A WTRU may suspend beam measurements (e.g., all) on (e.g., all) beams of a dormant SCG until a later time (e.g., until a beam fault recovery action is triggered, or until a beam fault recovery trigger occurs). For example, a WTRU may suspend beam measurements (e.g., all) on (e.g., all) beams of a dormant SCG until the SCG is activated. A WTRU may initiate beam measurements according to or during an activation procedure. Beam measurements may be facilitated by transmitting an RS signal (e.g., via a network) at the time of activation. A WTRU may initiate a beam recovery procedure after performing initial measurements after or during activation. The WTRU can continue performing beam measurements on the faulty beam and / or candidate beams after a beam fault and while beam fault recovery is pending. The WTRU can perform beam measurements on the faulty beam and / or one or more candidate beams with reduced frequency, intensity, or measurement duration. For example, the WTRU can perform measurements based on a new RS periodicity determined for performing beam measurements, in which case the RS periodicity may be configured by the network before the beam fault or after beam fault notification to the network.

[0123] A WTRU can, for example, cancel a pending beam fault recovery if the beam improves. For instance, a WTRU can cancel a pending beam fault recovery if fault beam measurements improve while the beam fault remains pending. A WTRU can also avoid executing a beam fault recovery procedure if a trigger (e.g., later activation) occurs. A WTRU canceling a pending beam fault recovery can provide instructions to the network regarding the cancellation. This cancellation message can be similar to the original message indicating the pending beam fault recovery.

[0124] The time it takes for a WTRU to report a beam fault, receive configurations associated with the beam fault, or recover from a beam fault can vary based on several factors. For example, a WTRU may report a beam fault at or near the time of the fault (e.g., immediately after detection). After reporting, the WTRU may receive configurations associated with the beam fault, and the WTRU may initiate beam fault recovery at the time of activation. A WTRU may report a beam fault to the network (e.g., at or near the time of failure), receive beam fault configurations such as new beam fault configurations (e.g., this may provide dedicated RACH resources) around the time of the beam fault report, and perform beam fault recovery actions after activation of the SCG where the beam fault occurred.

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

[0126] The WTRU can report beam faults upon SCG activation, receive RACH configurations upon SCG activation, and perform beam fault recovery upon SCG activation. For example, the WTRU can detect beam faults but delay reporting and recovery until SCG activation. The WTRU can report beam fault indications during activation and receive corresponding configurations for beam fault recovery. The WTRU can, for example, perform beam fault recovery to the SCG after activation and / or after receiving the configurations.

[0127] The WTRU may decide not to report a beam fault and then receive the RACH configuration during SCG activation, and perform beam fault recovery during that activation. For example, the WTRU may detect a beam fault and perform a recovery action during SCG activation. The WTRU may receive the RACH configuration during activation (for example, as part of the signal transmission for the activation procedure). The WTRU may perform beam fault recovery to the SCG based on the configuration received during or after the activation signal transmission.

[0128] The WTRU may not report a beam fault or receive a RACH configuration, and beam fault recovery can still be performed (e.g., with the original or existing RACH configuration) upon SCG activation. For example, the WTRU may perform recovery at or after SCG activation (e.g., without reporting recovery) by utilizing a saved RACH configuration. Such a saved RACH configuration may have been received before the beam fault (e.g., if the SCG was placed in a dormant state, or while the SCG was dormant).

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

[0130] Figure 2 shows exemplary timing for beam fault reporting, configuration, and recovery. In the exemplary scenario shown in Figure 2, the WTRU can report the beam fault at or near the time of the beam fault (e.g., immediately after the beam fault), receive configuration with SCG activation, and recover from the beam fault with activation. The numbers shown in Figure 2 may, as an example, indicate the order in which each operation occurs, but the order of occurrences, or interactions and / or participants in interactions, shown in the figure may differ in other examples. As shown in the example in Figure 2, one or more of the following may be performed by the WTRU: The WTRU can receive an SCG interruption message (e.g., an RRC message) from the MN. The WTRU can interrupt the SCG and continue performing beam measurements on one or more SCG SCells while the SCG is suspended. The beam fault may be detected by the WTRU on the cell associated with the SCG (e.g., at a later time). The WTRU can send a beam fault indication message to the MN. This MN may decide to activate a failed SCG (for example, at a later time) and send an SCG activation RRC message (e.g., including beam fault recovery resources) to the WTRU. The WTRU may then execute a beam fault recovery procedure (e.g., a RACH procedure) on the SCG (e.g., using the resources provided in the SCG activation RRC message).

[0131] A WTRU may be configured to handle MCG failures while an SCG is in a dormant state. For example, a 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), for example, it may not immediately declare an RLF. A WTRU may be configured to activate dormant SCGs, and under normal activation conditions, the WTRU may send an MCG failure report to the SCG. The MCG failure report may be sent during the procedure in which SCG activation is indicated to the network, or it may be sent after the procedure for SCG activation (for example, immediately thereafter).

[0132] A WTRU may be configured to deactivate an SCG based on one or more pre-configured triggers. When deactivating an SCG, a WTRU may apply one or more triggers described herein (e.g., those described in relation to conditional PSCell changes). For example, a trigger applicable to changing from one SCG to another may also be applicable to deactivating an SCG while activating a separate SCG.

[0133] A WTRU may be configured to handle conditional SCG reconfiguration failures. Trigger conditions may exist associated with conditional SCG reconfiguration failures. For example, a WTRU may be triggered to apply a conditional SCG configuration or reconfiguration if a previous conditional SCG reconfiguration has failed. A WTRU may consist of multiple conditional SCG configurations, and if a conditional SCG reconfiguration fails using a first SCG, the WTRU may attempt to apply the conditional reconfiguration to a second SCG. In several examples, a WTRU may be configured to report conditional SCG reconfiguration failures to the MCG. This may be done, for example, via an SCG failure information message if all conditional SCG reconfigurations have failed, if n (e.g., n≧1) conditional SCG reconfigurations have failed, or if a conditional SCG reconfiguration does not satisfy any of the trigger conditions configured for SCG reconfiguration.

[0134] A WTRU can receive an acceptable SCG instruction or configuration. A WTRU may be configured to determine the passability of a stored or received SCG configuration (for example, based on measurements). For example, a WTRU can 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 exceeding a threshold). A WTRU can determine the acceptability of an SCG or SCG configuration based on PSCell quality exceeding a threshold.

[0135] A WTRU can determine the acceptability of an SCG or SCG configuration based on a timer associated with SCG expiration. Such timers may indicate the last time the WTRU accessed the SCG, the last time the WTRU executed a restart procedure to enter the RRC_CONNECTED state, etc. A WTRU can determine the acceptability of an SCG or SCG configuration based on CSI measurements performed on the SCG's cells (e.g., the SCG's PSCell). For example, a WTRU can perform CSI measurements on the PSCell without reporting such measurements to the network. A WTRU can determine the acceptability of an SCG or SCG configuration based on beam measurements performed on the SCG. For example, a WTRU can determine whether an SCG or SCG configuration is acceptable based on whether a beam fault was detected on the SCG's PSCell. A WTRU can perform beam fault detection on the PSCell of a dormant SCG and activate the dormant SCG (e.g., to perform beam fault recovery).

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

[0137] The WTRU may trigger the sending of an RRC failure message to the MCG based on a determination of an unacceptable SCG or SCG configuration. The WTRU may send an RRC failure message (e.g., SCGFailureIndication) to the MCG if the stored and / or configured SCG is unacceptable (e.g., an SCGFailureIndication message may be triggered based on measurements of the stored / configured SCG). The WTRU may resume a stored SCG configuration (e.g., by a resume message or command to the WTRU) as instructed by the network (e.g., during a transition from INACTIVE to CONNECTED). The WTRU can compare the stored SCG configuration (e.g., collected during INACTIVE) with associated PSCell measurements 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. Error message transmission may occur before sending a Random Access Channel (RACH) request to the SCG or before the WTRU attempts to access the SCG. A WTRU may consist of SCG configurations in a resume message from the network during the WTRU's transition to RRC_CONNECTED. The WTRU can determine whether the SCG's PSCell measurement exceeds a threshold (before accessing the SCG). The WTRU may send an RRC error message after or with an RRC completion message indicating the WTRU's transition to RRC_CONNECTED (e.g., if the SCG's PSCell measurement does not exceed a threshold). A WTRU may consist of dormant and / or pending SCGs. The WTRU may trigger the activation of dormant and / or pending SCGs based on specific triggers (e.g., data-related triggers), and if the WTRU determines that a previously dormant and / or pending SCG, or one of the SCGs, is unacceptable, the WTRU may send an RRC failure message to the MCG or another SCG.

[0138] A WTRU can perform random access to an SCG if the SCG is acceptable. A WTRU can indicate whether an SCG is acceptable to an SCG through one or more random access messages. A WTRU can perform random access to an SCG if the SCG is acceptable, and does not have to perform random access to an SCG if the SCG is unacceptable. A WTRU can be composed of an SCG, and its configuration can be saved while the WTRU is in the INACTIVE state. A WTRU can restart a saved SCG by receiving a restart message with instructions from the network. A WTRU can evaluate whether an SCG is acceptable, and if it is, it can initiate random access to the PSCell of the saved SCG. A WTRU can stop executing the RACH procedure if it determines that the SCG is unacceptable. If a WTRU determines that an SCG is unacceptable, it can maintain the SCG configuration in the dormant or pending state until the WTRU is reconfigured with a new SCG. Next, the WTRU can release the saved configuration. The WTRU may consist of SCGs in the resume message that it can access when the WTRU is in the RRC_CONNECTED state, and the WTRU can determine whether the SCG is acceptable. If the WTRU determines that the SCG is acceptable, it can perform random access to the configured SCG. If the WTRU does not want to perform random access to the configured SCG, it can stop performing random access to the configured SCG. Depending on whether the SCG is acceptable, the WTRU can perform either conflict-free or conflict-based random access. For example, if the SCG is acceptable, the WTRU can perform conflict-free random access, and if the SCG is not acceptable, it can perform conflict-based random access.

[0139] A WTRU can access the SCG (for example, perform one or more accesses, such as random access operations to the SCG) before initiating the restart procedure to the MCG. In several examples, a WTRU may be configured to perform access operations to the SCG (for example, based on a saved SCG configuration) during the transition from INACTIVE to RRC_CONNECTED. A WTRU can perform access operations before initiating the restart procedure to the MCG, during the restart procedure to the MCG (for example, as part of the restart procedure to the MCG), or before the restart procedure is completed.

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

[0141] A WTRU may determine whether it is permissible to access the SCG before a restart procedure to the MCG (for example, before sending a restart request or initiating a restart operation) according to one or more of the following conditions: A WTRU may determine whether it is permissible to access the SCG based on conditions related to the temporal criticality of the data arriving at the WTRU. For example, a RACH procedure to the SCG before a restart procedure or the completion of a restart procedure is permissible if the data at the WTRU can be transmitted over a pre-configured LCH (for example, via LCP limits or a specific L1 profile), and the RACH procedure is permissible (for example, according to the temporal criticality of the LCH). A WTRU may determine whether it is permissible to access the SCG based on conditions related to the bearer type associated with the data arriving at the WTRU. For example, a RACH procedure to the SCG before a restart procedure or the completion of a restart procedure may be permissible if the data arriving at the WTRU will be transmitted via an SCG bearer. A WTRU may determine whether it is permissible to access the SCG based on a combination of the above conditions. For example, a RACH procedure to the SCG, either during or before the completion of a restart procedure, may be permissible if the data reaching the WTRU is transmitted via the SCG bearer, and the LCH associated with that data consists of LCP restrictions or a specific L1 profile that enables the RACH procedure. The WTRU can determine whether access to the SCG is permissible based on a comparison of the priority of data intended for the MCG and SCG. For example, a RACH procedure to the SCG, either during or before the completion of a restart procedure, may be permissible if the data held in the WTRU at the time of the restart procedure indicates that the priority of the SCG data is higher than that of the MCG data. The WTRU can determine whether access to the SCG is permissible based on information contained in the paging message.For example, a restart procedure or a RACH procedure to the SCG prior to the completion of a restart procedure may be requested by the network, for example, via specific instructions within a paging message.

[0142] A WTRU configured to access the SCG before executing a restart procedure to the MCG may delay the start of the restart procedure, or one or more actions associated with the restart procedure, until, for example, the access to the SCG is successfully completed. During the restart procedure, the WTRU can provide the network with instructions for successful or failed SCG access. For example, the WTRU may include an SCGFailureInformation message in the restart completion message. The WTRU may include a pass / fail instruction in the restart message to indicate the pass / fail status of SCG access before the restart procedure. The WTRU may indicate the pass / fail status of SCG access before the restart procedure by selecting from a subset of the RACH preamble. The WTRU may select the RACH type (e.g., 2-step RACH vs. 4-step RACH) or include a pass / fail instruction in the data sent in the 2-step RACH procedure.

[0143] A WTRU may be configured to handle MCG failures during (e.g., concurrently with) an acceptability instruction procedure directed to an SCG. For example, while a procedure associated with an acceptability instruction or conditional SCG configuration has been initiated or is in progress, the WTRU may detect an RLF associated with the MCG. In such cases, the WTRU does not have to declare the RLF immediately, for example. The WTRU may wait for the result of the acceptability instruction or conditional SCG configuration directed to the SCG. Based on the determination that the acceptability instruction or conditional SCG configuration directed to the SCG has passed, the WTRU may indicate an MCG failure. Based on a failed acceptability instruction directed to the SCG, the WTRU may declare an RLF. The WTRU may consist of a timer or period for completing the acceptability instruction or conditional SCG configuration, and the WTRU may trigger a connection re-establishment if the acceptability instruction or conditional SCG configuration does not complete before the expiration of that timer or period.

[0144] A WTRU can provide SCG acceptability information to the MCG via a RACH procedure (e.g., a two-step RACH procedure). A WTRU can initiate a RACH procedure to the MCG to indicate whether a saved, configured, and / or pending SCG is acceptable. In several examples, a WTRU can initiate a new RACH procedure to indicate the acceptability of a saved, configured, and / or pending SCG. In several examples, a WTRU can provide acceptability information in a RACH procedure triggered for other purposes (e.g., to resume to RRC_CONNECTED). A WTRU can execute a RACH procedure to the MCG while resuming the RRC_CONNECTED state and provide instructions to the RACH procedure regarding the acceptability of the SCG configuration. A WTRU can provide acceptability information as part of the payload of a two-step RACH procedure (e.g., in MSG B of the RACH procedure). A WTRU can provide instructions in MSG B regarding whether the SCG is acceptable. A WTRU in RRC_CONNECTED with an interrupted and / or dormant SCG may consist of one or more dedicated preambles associated with an acceptable or unacceptable SCG, and can execute a RACH procedure using the appropriate preamble (e.g., depending on the WTRU's measurements and the determination of the SCG's acceptability). A WTRU can execute such a RACH procedure based on receiving instructions from the network (e.g., a PDCCH sequence) in order to execute the RACH procedure.

[0145] The WTRU may transmit a Media Access Control (MAC) control element (CE) to the MCG containing information or an indication of SCG acceptance. The WTRU may transmit a MAC CE to the MCG indicating SCG acceptance, reasons for non-acceptance, specific SCG configurations for which the WTRU reports acceptance information, and / or any combination thereof.

[0146] A WTRU may be configured to support concurrent (e.g., coexisting) CPAC and CHO configurations, including receiving CPAC and CHO configurations simultaneously. In several examples, if an RRC configuration or reconfiguration associated with a CHO may already exist on the WTRU (e.g., may already be stored) and / or if the WTRU may have already begun monitoring trigger conditions for a CHO, the WTRU may receive an RRC configuration or reconfiguration message associated with a CPAC (e.g., associated with a CPAC configuration). The WTRU may receive a CPAC configuration via 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 several cases, if an RRC configuration or reconfiguration associated with a CPAC already exists on the WTRU (e.g., it may already be stored) and / or if the WTRU may have already started monitoring the trigger conditions for the CPAC, the WTRU may receive an RRC configuration or reconfiguration message associated with a CHO (e.g., associated with a CHO configuration). 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 exemplary approaches for handling CPAC configuration or reconfiguration if the WTRU consists of both CPAC and CHO configurations. Different WTRU behaviors may be defined herein based on the potential of the WTRU and / or network to support concurrent (e.g., coexisting) CPAC and CHO configurations. For example, some WTRUs may be capable of handling coexisting CPAC and CHO configurations but may not be configured to monitor both CPAC and CHO trigger conditions. Some WTRUs may be capable of monitoring both CPAC and CHO trigger conditions but may be configured to perform one configuration or reconfiguration (e.g., CPAC or CHO) at a time. Some WTRUs may be capable of performing both CPAC and CHO configuration or reconfiguration simultaneously. In the first exemplary approach, the WTRU may be configured to perform one (e.g., only one) of each configuration (e.g., CHO or CPAC). This WTRU may be configured to send instructions to the SCG (e.g., to the SN associated with the SCG) if it receives a CPAC configuration while it already has a valid CHO configuration stored. This WTRU may also be configured to send instructions to the SCG (e.g., to the SN associated with the SCG) if it receives a CHO configuration (e.g., from the MN) while it already has a valid CPAC configuration stored. Instructions sent by the WTRU may indicate that there may be cases where the WTRU cannot respond to the CPAC configuration or the CHO configuration (e.g., because one of the other CPAC or CHO configurations already exists on the WTRU). The instructions may list the reasons why the WTRU cannot respond to the CPAC configuration or the CHO configuration, such as having a configuration that conflicts with the MN.

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

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

[0150] The behavior of a WTRU when trigger conditions associated with CHO and CPAC are met (for example, simultaneously) can be defined or preconfigured (for example, by a network entity). For example, a 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. A WTRU may consist of one or more of the following behaviors:

[0151] A WTRU can prioritize CHO over CPAC. For example, a 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 multiple examples, a WTRU may abort an ongoing CPAC action if, for example, one or more trigger conditions for CHO are met. A WTRU may be configured to release one or more (e.g., all) CPAC configurations and / or stop monitoring the trigger conditions associated with the CPAC configurations.

[0152] A WTRU can disable one or more CPAC actions. For example, a WTRU may be configured to disable one or more CPAC-related actions in response to determining that a CHO trigger is likely to occur (for example, based on the WTRU's evaluation of one or more CHO trigger conditions). A WTRU may be configured to disable one or more CPAC actions based on pre-configured trigger conditions. In several examples, the pre-configured trigger conditions can be measurement events associated with the CHO trigger conditions. For example, a WTRU may be configured to stop monitoring trigger conditions associated with CPAC when the CHO trigger condition meets an entry condition (for example, when a timer associated with the CHO trigger condition is running).

[0153] A WTRU can support the simultaneous execution of CHO and CPC (for example, without prioritizing one over the other), including triggering or executing CHO and CPAC, for example, simultaneously. For example, a WTRU can trigger a CHO while CPAC is in progress, or a WTRU can trigger a CHO while CPAC is in progress.

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

[0155] A WTRU can be configured to send an instruction (for example, within an RRC message such as the RRCReconfigurationComplete message) indicating that the CPAC execution trigger condition is met. This instruction may be sent to a cell that depends on the progress or trigger of the CHO. A WTRU can send an instruction that the CPAC execution trigger is met for a CHO candidate (e.g., the target of the triggered CHO). A WTRU can send an instruction that the CPAC execution trigger is met for a PCell connected before the WTRU triggers the CHO. A WTRU can determine the destination cell of its instruction based on the timing of the triggers for the CHO and / or CPAC. In several examples, a WTRU can send its instruction to a source PCell if the CPAC is triggered simultaneously with the CHO. In several examples, a WTRU can send its instruction to a source PCell if the CHO's trigger time occurs after the CPAC's trigger time. In several examples, 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, the WTRU may send an instruction to the CHO target. This offset time may be a configured period or may be defined in relation to steps or actions taken by the WTRU in connection with the CHO. For example, the WTRU may send an instruction to the CHO target when it has completed synchronization with the CHO target, or when it has applied the CHO target cell configuration.

[0156] A WTRU may be configured not to send a CPAC execution instruction in certain situations (e.g., when CPAC is triggered simultaneously with a CHO, or when CPAC is triggered during an ongoing CHO). In several examples, a WTRU may discard sending such an instruction if the trigger condition (e.g., for CPAC) is met during the execution of a CHO. In several examples, a WTRU may send its instruction if the trigger condition (e.g., for CPAC) causes the following completion of a CHO (e.g., after receiving an acknowledgment associated with sending a completion message to a target).

[0157] A WTRU may be configured to send a command to a network node (e.g., a secondary node) to perform CPAC if a CHO fails. Such a failure may occur, for example, if the WTRU fails to send the command to perform CPAC or if the CHO causes a delay in sending the command. The WTRU may include the command to perform CPAC in a failure message (e.g., an MCGFailureInformation message), which may be sent after a failed CHO.

[0158] A WTRU may be configured to delay sending the instruction to execute CPAC until the CHO is complete. The WTRU may delay sending, for example, if CPAC and CHO are triggered simultaneously, or if CHO is in progress when the CPAC trigger conditions are met. The WTRU may delay sending the instruction if CHO is likely to be triggered in the near future (for example, when the trigger time associated with the CHO event has started). If CHO is not triggered (for example, if the time to trigger has not expired and / or CHO is not executed), the WTRU may continue sending the instruction after CHO is complete.

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

[0160] A WTRU may consist of an event (e.g., a measurement event) and / or a trigger condition applicable to both CHO and CPAC. For example, a WTRU may consist of a single event applicable to both CHO and CPAC (e.g., by including the configuration of both MCG and SCG in a conditional reconstruction candidate). A WTRU may consist of an offset or threshold associated with a trigger condition (e.g., a measurement event), the offset and threshold may be applied to either CHO or CPAC, for example, when the trigger condition applies to both CHO and CPAC. A WTRU may be configured to apply CHO when the trigger condition is met by a first threshold, and to apply CPAC when the trigger condition is met by a second threshold.

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

[0162] A WTRU may be configured to perform one or more actions associated with a saved CPAC configuration (if any) if the WTRU successfully completes a CHO procedure and / or if trigger conditions associated with the CHO are met. A WTRU may be configured to perform one or more of the following: If the WTRU successfully completes a CHO, it may send instructions to the SCG (e.g., to network nodes associated with the SCG). The WTRU may include identification information for new PCells in its instructions. If an SRB (e.g., SRB3) is configured toward the SCG, the WTRU may send such instructions. If a saved CPAC configuration is received from a secondary node, for example, if the WTRU determines that the master node is not included in the CPAC configuration, it may send such instructions.

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

[0164] The WTRU may be configured to release the saved CPAC configuration (e.g., autonomously) if the CHO completes successfully. The WTRU may stop monitoring the trigger conditions associated with the released CPAC configuration. The WTRU may send instructions 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) the saved CPAC configuration if the CHO completes successfully. The WTRU may stop monitoring the trigger conditions associated with the suspended CPAC configuration. The WTRU may send instructions to the SCG (e.g., to a network node associated with the SCG) indicating the suspension of the CPAC configuration. The WTRU may receive commands (e.g., from the SCG) to activate and / or reconfigure the suspended CPAC configuration.

[0166] The WTRU may be configured to selectively release or suspend CPAC configurations based on the completion of the CHO. The WTRU may be configured to suspend or release CPAC configurations based on one or more of the following conditions. The WTRU may be configured to suspend or release CPAC configurations based on the origin of the CPAC configurations. For example, the WTRU may be configured to release or suspend those CPAC configurations received from secondary nodes and maintain those 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 those CPAC configurations received from secondary nodes.

[0167] WTRUs can be configured to suspend or release CPAC configurations based on their compatibility with cell groups. For example, a WTRU can be configured to release CPAC configurations that are no longer compatible with new MCGs after a CHO. A WTRU can consist of CPAC configuration compatibility information for each CHO candidate (e.g., each one) via a linkage configuration. A WTRU can maintain those (e.g., only those) CPAC configurations associated with CHO candidates whose CHOs have been successfully completed.

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

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

[0170] A WTRU may be configured to determine the validity of a saved CHO configuration based on the execution of a CPAC procedure. A 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 as a function of the Serving SCG to determine potential CHO candidates. The WTRU may consist of associations (e.g., mappings) 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 if, for example, the Serving SCG is modified due to a CPAC procedure. The WTRU may release CHO configurations that are not linked to the current SCG. The WTRU may be configured to report instructions to the MCG (e.g., to network nodes associated with the MCG) regarding the status of CHO candidates based on successful CPAC completion. The WTRU may be configured to perform one or more of the functions described herein for (e.g., solely for) the CPAC configurations configured by the SCG.

[0172] A WTRU may be configured to perform one or more actions associated with a saved CHO configuration, such as when the WTRU successfully completes a CPAC procedure or when trigger conditions associated with CPAC are met. A WTRU may consist of one or more of the following behaviors:

[0173] A WTRU may send instructions to the MCG (e.g., to a network node associated with the MCG) when it has completed CPAC (e.g., if CPAC completes successfully, or if CPAC fails). The WTRU may include identification information for new PSCells in its instructions. A WTRU may send such instructions if it has received the relevant CPAC configuration from the SCG (e.g., from a network node associated with the SCG). A WTRU may send such instructions if it has received the CPAC configuration from a secondary node, for example, if it can determine that the master node is not included in the CPAC configuration.

[0174] A WTRU can send instructions to the MCG (for example, to a network node associated with the SCG) if one or more trigger conditions associated with CPAC are met. The WTRU may include identification information for the cell in which the CPAC conditions are met. If the WTRU receives a CPAC configuration from a secondary node, for example, if the WTRU can determine that the master node is not included in the CPAC configuration, it can send such instructions.

[0175] The WTRU can selectively release or suspend the CHO configuration based on 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 was received from a secondary node.

[0176] A WTRU can be configured to suspend or release CHO configurations based on explicit configuration. For example, a WTRU can be explicitly configured to maintain one or more CHO configurations after the success of a CPAC procedure.

[0177] A WTRU may be configured to process concurrently running CPAC configurations initiated by a master node (MN) and a second node (SN). A CPAC configuration from one cell group may take precedence over one from another cell group. A WTRU may be configured to receive CPAC configurations from the MN or SN. A WTRU may be configured to process CPAC configurations from one (e.g., only one) cell group under pre-configured conditions. One or more of the following may apply, for example, when a CPAC configuration takes precedence based on the SRB (e.g., SRB1 or SRB3) from which the CPAC configuration is received. The examples described herein in the context of CPAC configurations initiated by the MN and / or SN may also apply to situations where RRC reconfigurations initiated by the MN and / or SN may have a significant impact on stored SCG configurations and / or active SCG configurations. The examples described herein may also apply when the WTRU is configured to store at least one CPAC initiated by the SN at the WTRU (e.g., when it receives an RRC reconfiguration from the MN). The examples described herein may also be applicable if the WTRU is configured to store at least one CPAC initiated by the MN at the WTRU (for example, when it receives an RRC reconfiguration from the SN).

[0178] A WTRU may be configured to prioritize CPAC configurations based on the earliest arrival time of the CPAC configuration. In several cases (for example, if a WTRU receives a CPAC configuration from an SN while a WTRU has received a valid CPAC configuration from an MN and stored in the WTRU), the WTRU may ignore the CPAC received from the SN. A WTRU may be configured to send a fault message to the SN indicating that it cannot accept the CPAC configuration and why (for example, an earlier configuration from a different cell group exists in the WTRU). In several cases (for example, if a WTRU receives a CPAC configuration from an MN while a WTRU has received a valid CPAC configuration from an SN and stored in the WTRU), the WTRU may ignore the CPAC received from the MN. A WTRU may be configured to send a fault message to the MN indicating that it cannot accept the CPAC configuration and why (for example, an earlier configuration from a different cell group exists in the WTRU).

[0179] A WTRU may be configured to prioritize CPAC configurations based on the most recent arrival time of the CPAC configuration. In several cases (for example, if the WTRU receives a CPAC configuration from an SN while the WTRU has a valid CPAC configuration received from an MN), the WTRU may release the CPAC configuration received from the MN and process (e.g., save) the CPAC configuration received from the SN. The WTRU may be configured to send a failure message to the MN indicating that it cannot accommodate the CPAC configuration and the reason why (e.g., the CPAC configuration is overwritten by a new configuration or a later arriving configuration).

[0180] In several cases (for example, if the WTRU receives a CPAC configuration from the MN while the WTRU has a valid CPAC configuration received from the SN), the WTRU may release the CPAC configuration received from the SN and process (e.g., save) the CPAC configuration received from the MN. The WTRU may be configured to send a fault message to the SN indicating that it cannot accommodate the CPAC configuration and why (e.g., the CPAC configuration is overwritten by a new configuration or a configuration arriving later).

[0181] A WTRU may be configured to prioritize a CPAC configuration based on the cell group or SRB associated with it. In several examples, a WTRU may prioritize a CPAC configuration received from an MN, regardless of the existence of an earlier CPAC configuration received from an SN. In several examples, a 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] A WTRU may be configured to prioritize CPAC configurations based on explicit instructions. A WTRU may be configured to determine the priority of CPAC configurations based on explicit priority instructions, such as those included as part of the CPAC configuration. A WTRU may be configured to prioritize low-priority CPAC configurations over high-priority CPAC configurations.

[0183] A WTRU may be configured to process CPAC configurations from one cell group as a function of CPAC configurations from another cell group. A WTRU may be configured to receive and process CPAC configurations from MCGs and SCGs. A WTRU may be configured with rules for processing CPAC configurations when it receives a CPAC configuration associated with the same target PSCell. For example, a 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. A WTRU may be configured to replace or modify an existing CPAC configuration if the previous CPAC configuration was received from the same cell group (e.g., only in that case). A WTRU may be configured to report to a network node (e.g., to the network node) which cell group's CPAC configuration has been prioritized or modified.

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

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

[0186] The WTRU can 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, if the CPAC candidate was configured by the SN or via a specific SRB such as SRB3, the WTRU can perform a CPAC to the candidate PSCell after an SCG failure. Otherwise, the WTRU can initiate the SCG failure procedure (e.g., by sending an SCGFailureInformation message).

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

[0188] An SCG may be added for a WTRU. Figure 3 shows an example of applying an SCG configuration when certain conditions are met. The WTRU may be in a connected state with a source MCG. This WTRU may receive messages (e.g., RRCReconfiguration or RRCConnectionReconfig messages) from the MCG (e.g., an MN associated with the MCG) that contain or indicate trigger conditions for performing SCG configuration, SCG reconfiguration, and / or SCG configuration or reconfiguration (e.g., SCG configuration or reconfiguration may be conditional). As described herein, SCG configuration or reconfiguration may be related to PSCell changes or additions. In response to receiving a message, the WTRU may save the SCG configuration or reconfiguration and begin monitoring the trigger conditions contained in or indicated in the message. Based on the receipt of the configuration message, the WTRU may be configured to send a first message (e.g., RRC response 1 in Figure 3) to the MN. The WTRU may indicate in a first message (e.g., RRC response 1) that it has received and / or stored a conditional SCG configuration or reconfiguration and has begun monitoring the trigger conditions contained therein (e.g., so that the network can understand the state of the WTRU and / or subsequent actions). In several 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 Figure 3) to the MN. The WTRU may indicate in a second message (e.g., RRC response 2) that the trigger conditions for applying the conditional SCG configuration or reconfiguration have been met. In response to determining that the trigger conditions have been 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, for example, the application of a conditional SCG reconfiguration to the network (e.g., MSG or MN) in a second message (e.g., RRC response 2 in Figure 3) or in a different message.In several examples, the second message (e.g., RRC response 2) may correspond to an RRC reconfiguration completion message. Furthermore, as described herein, the application of conditional SCG reconfiguration (e.g., execution of a RACH procedure based thereon) may result in failure. In such situations, the WTRU may send a third message to the MN, which may indicate failure. In several examples, the third message may correspond to an RRC reconfiguration failure message.

[0189] Figure 4 shows an example of applying an SCG configuration or reconfiguration (e.g., a conditional SCG configuration or reconfiguration as described herein) when an RLF is present. The WTRU can detect radio link problems, such as an RLF, while monitoring trigger conditions for applying an SCG configuration or reconfiguration, for example, in the MCG. In such a situation, the WTRU can facilitate the application of a stored SCG configuration, for example, by accessing the corresponding SCG (e.g., via a random access procedure) without waiting for the trigger conditions to be met. If the random access is successful, the WTRU can indicate an MCG failure to the SCG. If the WTRU cannot access the SCG, the WTRU can declare an RLF. The WTRU may be configured as a comprehensive cell group configuration, which can then be applied as an MCG configuration or an SCG configuration. In the case of an MCG RLF, the WTRU may facilitate a comprehensive cell group configuration as an MCG configuration and perform a conditional handover to the MCG corresponding to the facilitated MCG configuration.

[0190] A WTRU may be configured to apply a conditional MCG reconfiguration while connected to an SCG, for example. Figure 5 shows an example of a WTRU performing enhanced recovery actions. A WTRU may consist of, for example, a source MCG and a multiconnectivity connected to the source SCG. The WTRU can receive conditional reconfigurations associated with the MCG. The WTRU can begin monitoring trigger conditions for conditional MCG reconfiguration. In several examples, the WTRU may face a radio link problem at the source MCG while waiting for trigger conditions for a candidate MCG, for example. In such cases, the WTRU may be configured to perform one or more enhanced recovery actions. Enhanced recovery actions may include one or more of the following: The enhanced recovery action may include transmitting MCG failure information via the source SCG. The enhanced recovery action may include triggering a connection re-establishment. For example, if the WTRU selects a candidate MCG, the WTRU may use a stored MCG reconfiguration to perform a CHO (for example, to the candidate MCG). A WTRU may consist of one or more rules regarding whether MCG failure information should be transmitted via the source SCG and / or whether a connection re-establishment should be triggered. One or more rules may be based on an assessment of cell quality associated with the source SCG and candidate MCGs, the presence of an SCG bearer, the presence of SRB3, or split SRB1 / 2, etc.

[0191] In several examples, the WTRU may be configured to send MCG failure information via the source SCG for recovery if one or more of the following conditions are met: The WTRU may be configured to send MCG failure information via the source SCG if the quality of the source SCG is better than the cell quality threshold and the quality of the candidate MCG is lower than the cell quality threshold. The WTRU may be configured to send MCG failure information via the source SCG if the source SCG consists of SRB3 and / or split SRB1 / 2. If none of the conditions are met, the WTRU can trigger a re-establishment of the connection. When a re-establishment of the connection is performed, for example, if the cell quality of the SCG meets the minimum threshold, the WTRU can send MCG failure information to the SCG.

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

[0193] WTRUs may be provided for concurrently running conditional MCG and SCG reconfigurations. Figure 6 shows an example of a WTRU monitoring for conditional configuration or reconfiguration. A WTRU may consist, for example, of a source MCG and multiconnectivity connected to the source SCG. A WTRU may receive RRC messages, such as an RRCReconfiguration message, which includes an SCG configuration or reconfiguration for candidate SCG1 (e.g., a conditional SCG configuration or reconfiguration) and trigger conditions for the configuration or reconfiguration. A WTRU may save the SCG configuration or reconfiguration and initiate monitoring of trigger conditions associated with SCG1. Such reconfigurations may correspond to SCG change procedures. A WTRU may also receive an RRC reconfiguration message, for example, which includes a conditional MCG configuration or reconfiguration corresponding to a handover to a candidate MCG. A WTRU may also receive a conditional SCG configuration or reconfiguration corresponding to, for example, the addition of an SCG2 linked to the candidate MCG. From the perspective of monitoring for conditional reconfiguration, a WTRU may be configured to perform one or more of the following: The WTRU can perform monitoring for three candidates, namely candidate SCG1, candidate SCG2, and candidate MCG. The WTRU can 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, if the WTRU is configured for candidate MCG reconstruction, it may interrupt monitoring for SCG. The WTRU may select a subset of SCG reconstructions and monitor them in addition to monitoring MCG reconstructions. For example, the WTRU may perform monitoring for candidate SCG1 and candidate MCG, and interrupt monitoring for candidate SCG2. If candidate MCG meets the trigger conditions, the WTRU may start monitoring the trigger conditions for SCG2. The WTRU may monitor candidate MCG and candidate SCG2, and interrupt monitoring for candidate SCG1.

[0194] If the reconfiguration of the candidate MCG is successful, the WTRU may be configured to perform one of the following: The WTRU may release the source SCG configuration if the candidate MCG reconfiguration is triggered. The WTRU may release the source SCG configuration if the source SCG is not linked to the candidate MCG configuration. The WTRU may remain in the source SCG configuration until explicitly instructed to do so by the candidate MCG.

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

[0196] A saved PSCell conditional reconfiguration IE may be deleted based on the receipt of a PCell conditional reconfiguration IE. Conditional handover configurations (CHO-Configs) may be added or modified. The WTRU may do one or more of the following (for example, for each CHO-ConfigId received in a cho-ConfigToAddModList IE): If a cho-ConfigToAddModList contains an mn-ExecutionCond and at least one entry with an sn-ExecutionCond exists in the cho-ConfigToAddModList within VarCHO-Config, the WTRU may delete the entry associated with the sn-ExecutionCond in VarCHO-Config and report an SCG configuration failure (for example, due to the inability to respond to an RRCReconfiguration received via SRB3 and / or due to conflict with the MCG configuration). If an entry with a matching CHO-ConfigId exists in the cho-ConfigToAddModList within VarCHO-Config, the WTRU may replace the entry with the value received for that CHO-ConfigId. If an entry with a matching CHO-ConfigId does not exist in the cho-ConfigToAddModList within VarCHO-Config, the WTRU may add a new entry for the CHO-ConfigId within VarCHO-Config. The WTRU may perform conditional handover monitoring, for example, as specified herein.

[0197] The WTRU may be configured to ignore received PSCell conditionalReconfigurations if, for example, at least one PCellconditionalReconfiguration is stored. The WTRU may do one or more of the following (for example, for each CHO-ConfigId received in the cho-ConfigToAddModList IE, in the case of a CHO-ConfigId received in the cho-ConfigToAddModList IE): The WTRU may report an SCG configuration failure if the cho-ConfigToAddModList contains an sn-ExecutionCond and at least one entry with an mn-ExecutionCond exists in the cho-ConfigToAddModList within VarCHO-Config (for example, because it cannot respond to an RRCReconfiguration received via SRB3 and / or based on conflict with the MCG configuration). If cho-ConfigToAddModList contains sn-ExecutionCond, and no entry with mn-ExecutionCond exists in cho-ConfigToAddModList within VarCHO-Config, and no entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList within VarCHO-Config, then WTRU may replace the entry with the value received for the CHO-ConfigId. If cho-ConfigToAddModList contains sn-ExecutionCond, and no entry with mn-ExecutionCond exists in cho-ConfigToAddModList within VarCHO-Config, and no entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList within VarCHO-Config, then WTRU may add a new entry for this CHO-ConfigId within VarCHO-Config.WTRU may perform conditional handover monitoring, for example, as specified herein, if cho-ConfigToAddModList contains sn-ExecutionCond, but no entry with mn-ExecutionCond exists in cho-ConfigToAddModList within VarCHO-Config.

[0198] The above logic can be demonstrated as follows: For each CHO-ConfigId received within IE, WTRU performs the following: 1>If cho-ConfigToAddModList contains mn-ExecutionCond, 2>If at least one entry with sn-ExecutionCond exists in cho-ConfigToAddModList within VarCHO-Config, 3> Delete the entry associated with sn-ExecutionCond in VarCHO-Config. 3> Report SCG configuration failure in accordance with the subordinate clause corresponding to "Unable to respond to RRCReconfiguration received via SRB3", and possibly a new clause that "Conflicts with MCG configuration". 1> If an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList within 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 within VarCHO-Config. 1> Perform conditional handover monitoring as specified herein. For each CHO-ConfigId received within cho-ConfigToAddModListIE, WTRU performs the following: 1>If cho-ConfigToAddModList contains sn-ExecutionCond, If at least one entry with 2>mn-ExecutionCond exists in cho-ConfigToAddModList within VarCHO-Config, 3> Report SCG configuration failure in accordance with the subordinate clause corresponding to "Received via SRB3 and unable to respond to RRCReconfiguration", and in some cases a new failure clause that "conflicts with MCG configuration". 2>Other 3> If an entry with a matching CHO-ConfigId exists in cho-ConfigToAddModList within VarCHO-Config, 4> Replace the entry with the value received for this CHO-ConfigId. 3>Others 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 this disclosure may take into account New Radio (NR) or 5G-specific protocols, it will be understood that the solutions described herein are not limited to these scenarios and are further applicable to other wireless systems. Although the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). Using software and associated processors, radio frequency transceivers can be implemented for use within the devices described herein.

Claims

1. A wireless transceiver unit (WTRU), The system comprises a processor configured to operate in a master cell group (MCG) and a secondary cell group (SCG), wherein the processor The SCG is deactivated while the MCG performs uplink transmission, To determine whether the data associated with the SCG can be transmitted, Sending a message to a network device associated with the MCG, wherein the message indicates that data associated with the SCG is available for transmission. A WTRU equipped with a processor configured to perform the following tasks.

2. The WTRU according to claim 1, wherein the processor is configured to determine whether data associated with the SCG is transmittable, and the processor is configured to determine whether the data is associated with a wireless bearer associated with the SCG.

3. The WTRU according to claim 1, wherein, after sending 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 according to claim 3, wherein the data is transmitted to a network device associated with the SCG.

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

6. The WTRU according to claim 1, wherein the network device associated with the MCG includes a base station configured to operate as the master node (MN) of the WTRU.

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

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

9. The WTRU according to 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 conditions.

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

11. A method performed by a wireless transceiver unit (WTRU) configured to operate in a master cell group (MCG) and a secondary cell group (SCG), The aforementioned method, The SCG is deactivated while the MCG performs uplink transmission, To determine whether the data associated with the SCG can be transmitted, Sending a message to a network device associated with the MCG, wherein the message indicates that data associated with the SCG is available for transmission. A method that includes this.

12. The method according to claim 11, wherein determining whether the data associated with the SCG is transmittable includes determining whether the data is associated with a wireless bearer associated with the SCG.

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

14. The method according to claim 11, further comprising receiving configuration information relating to the MCG and the SCG.

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

Images